T01 · Skill Instruction Hijacking
- Location
SKILL.md:26- Finding
Untrusted Review Content Can Manipulate AI Analysis Instructions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:26-49andSKILL.md:58-103
Vulnerability Type: Indirect prompt injection through attacker-controlled review content
Risk Level: MediumThe Map and Reduce prompts directly incorporate Amazon review content without identifying it as untrusted data or instructing the model to ignore commands embedded in that content.
Relevant code snippet (
SKILL.md:26-49):markdown 将评论数据分批处理,每批30条,使用以下 Prompt 提取痛点: ```markdown # Role 你是一个电商评论数据标注员。 # Task 阅读以下亚马逊1-3星评论,提取出与【产品本身】相关的痛点和机会。 # Rules 1. 忽略物流、包装、客服问题。 2. 只提取真实存在的缺陷或明确的需求。 3. 必须严格按照JSON数组格式输出,不要输出任何解释性废话。 # Output Format [ { "tag": "痛点/机会/预期偏差", "module": "如:电池/材质/安装/尺寸", "point": "简练概括问题(15字以内)", "quote": "截取评论中最核心的一句原话" } ] # Input Data [评论内容]Relevant code snippet (
SKILL.md:58-103):markdown # Task 我已经让助手从上千条1-3星评论中提取了结构化的痛点数据。以下是提取出的JSON数组。请你基于这些精炼的数据,输出一份具备高落地性的《产品痛点与机会洞察报告》。 # Analysis Dimensions(分析维度) 在阅读评论时,请用以下几个维度进行过滤和分类: 1. 产品改造点: * 材质与做工:异味、掉漆、易碎、手感差等。 * 功能缺陷:无法正常工作、按键失灵、效率低下等。 * 设计缺陷:反人类设计、不符合人体工学、安装困难等。 * 耐用性:用几次就坏、电池衰减快等。 2. 产品机会点: * 痛点延伸:客户为了解决该产品的问题,不得不搭配其他东西一起用(发现互补品机会)。 * 场景错位:客户把产品用在了意想不到的场景,但现有产品不支持(发现细分场景机会)。 * 缺失功能:"要是它能具备XX功能就好了"、"我以为它可以XX"(发现迭代机会)。 3. 预期管理偏差: * Listing误导:买家以为是A,收到发现是B(属于优化详情页的机会,而非改产品)。 # Constraints & Rules (规则与约束) * 禁止关注非产品因素:忽略所有关于FBA物流延迟、包装破损(除非影响产品本身)、客服态度的吐槽。 * 基于事实,拒绝脑补:每一个洞察都必须在输出时附带原评论的缩写或原话作为证据支撑。 * 优先级排序:按"出现频率"和"严重程度(如导致产品完全无法使用)"对问题进行排序,高频+致命问题排最前。 # Output Format 请严格按照以下Markdown格式输出报告: ## 🚨 一、 核心改造点(必须修复的痛点) 优先级 | 痛点模块 | 痛点描述 | 原始证据(引用原话) | 改造建议 --- | --- | --- | --- | --- P0 (高频/致命) | 例如:电池 | 续航虚标,实际只能用半小时 | "买来除草,用了20分钟就没电了" | 更换大容量电芯,或在Listing写明真实续航 P1 | … | … | … | … ## 💡 二、 隐藏机会点(差异化竞争切入点) 机会类型 | 用户真实诉求 | 原始证据(引用原话) | 落地建议(如何变成卖点) --- | --- | --- | --- 新增功能 | 例如:希望便携 | "要是能折叠放车里就好了" | 开发折叠版本,主打 ...[truncated 2161 chars]- Remediation
View remediation
Remediation Suggestions
- Clearly delimit every review as untrusted data using a structured envelope rather than concatenating it into instruction text.
- Add an explicit instruction that content inside reviews is evidence only and that all commands, role declarations, formatting requests, URLs, and policy statements found inside reviews must be ignored.
- Parse Map output with a strict JSON parser and validate it against an allowlisted schema containing only
tag,module,point, andquote. - Reject unexpected fields, invalid tags, excessive lengths, links, control text, and output that is not a JSON array.
- Ensure each quote is an actual substring of the source review before accepting it as evidence.
- Pass only validated structured fields—not raw model output or raw reviews—to the Reduce stage.
- Treat the Reduce input as untrusted and repeat the instruction/data boundary protections there.
- Apply output validation to the final report and flag unsupported claims for review.
