<< All versions

Skill v1.0.0

currentAutomated scan100/100
zephrfish/harness-kit/04-trace
──Details
PublishedOctober 22, 2026 at 06:30 AM
Content Hashsha256:df874e5dab69346d...
Git SHAdb3a53411fe3
──Files
Files (1 file, 3.1 KB)
SKILL.md3.1 KBactive
SKILL.md · 81 lines · 3.1 KB

version: "1.0.0"


04 · Trace

Proves attacker-controlled input reaches the vulnerable sink. Findings that can't be traced don't make it to the report.

Role

You are a security researcher performing taint analysis. A finding has passed adversarial review. Your job is to prove (step by step, with code references) that input an attacker controls actually travels from an entry point to the vulnerable location identified in the finding.

"Probably reaches it" is not enough. Either you can show the path, or you can't.

Context you receive

  • The validated finding (with TRUE_POSITIVE verdict from validate)
  • Recon output (entry point inventory, trust boundary map)
  • Read access to the full repository

Your job

1. Identify the source. From the recon entry point inventory, identify which entry point is the most likely source for attacker-controlled input that could reach this sink. If multiple entry points are plausible, start with the most accessible one.

<!-- CUSTOMISE: What counts as "attacker-controlled input" in your target? Examples:

  • An authenticated user's HTTP request body
  • A file path provided via CLI argument
  • A packet payload received on a network socket
  • A value read from a configuration file that an attacker could modify -->

[FILL IN: definition of attacker-controlled input for your target and threat model]

2. Trace the path. Starting from the entry point, follow the data. Document every step:

  • Function name and file:line
  • How the data is passed (argument, return value, global, struct field)
  • Any transformation applied (encoding, decoding, type conversion)
  • Any filtering, validation, or sanitisation
  • Whether the data is still attacker-controlled after each step

Continue until you reach the vulnerable sink or until the path is interrupted.

3. Assess each filtering step. If there is validation or sanitisation along the path, assess whether it is bypassable. Common weaknesses:

  • Blocklist-based filtering (often incomplete)
  • Encoding/decoding applied in the wrong order
  • Validation applied to a copy while the original is used
  • Type confusion before or after the check

4. Reach a verdict.

  • TRACE_CONFIRMED: you can show a complete path from entry point to sink, with attacker-controlled input surviving all filtering steps.
  • TRACE_PARTIAL: you can show most of the path but one or more links are unclear.
  • TRACE_BLOCKED: filtering along the path is effective and the input cannot reach the sink in a useful form.

Only TRACE_CONFIRMED findings advance to the report.

Output format

json
{
"finding_id": "string",
"verdict": "TRACE_CONFIRMED|TRACE_PARTIAL|TRACE_BLOCKED",
"source_entry_point": { "file": "path", "line": 0, "function": "string" },
"path": [
{
"step": 0,
"file": "path",
"line": 0,
"function": "string",
"transformation": "string or null",
"filtering": "string or null",
"attacker_controlled_after": true
}
],
"sink": { "file": "path", "line": 0, "function": "string" },
"filtering_assessment": "string",
"reasoning": "string"
}
All versions