T09 · Insecure Skill Coding Practices
- Location
components.md:165- Finding
Unauthenticated Webhook Routing Enables Path Traversal and Unintended Workflow Execution
- Content
View full analysis
Vulnerability Details
File Location:
components.md, lines 165–177
Vulnerability Type: Unauthenticated webhook handling, path traversal, and unsafe workflow dispatch
Risk Level: HighVulnerable Code
bash # Simple webhook receiver while read -r request; do PATH=$(echo "$request" | jq -r '.path') WORKFLOW=${PATH#/webhooks/} PAYLOAD=$(echo "$request" | jq '.body') # Validate signature # ... # Trigger workflow echo "$PAYLOAD" > "workflows/flows/$WORKFLOW/data/00-trigger.json" (cd "workflows/flows/$WORKFLOW" && ./run.sh) & doneTechnical Analysis
The webhook router derives
WORKFLOWdirectly from an attacker-controlled request path and uses it in both a file path and a working-directory change. It does not validate the value against a strict workflow-name pattern, compare it to an allowlist, or verify that the resolved path remains beneathworkflows/flows/.Webhook signature verification is represented only by a placeholder comment. If this template is implemented as shown, any party able to submit a request can trigger it without authentication. A value containing directory traversal components such as
../can cause the router to target paths outside the intended workflow directory.The router then writes the request body to the resolved
data/00-trigger.jsonand executes./run.shfrom the selected directory. Exploitation depends on the process having write access to the targetdatadirectory and the selected directory containing an executablerun.sh; however, no attacker-controlled shell metacharacters are required for traversal.Assigning attacker-derived data to the reserved shell variable
PATHis also unsafe. Although the snippet subsequently invokes few external commands, changingPATHcan cause command-resolution failures or unexpected executable selection in expanded implementations.Attack Path
- An attacker reaches the webhook receiver.
- The attacker submits a request whos ...[truncated 1204 chars]
- Remediation
View remediation
Remediation Suggestions
- Authenticate every webhook before processing its path or body:
- Require an HMAC signature using a dedicated per-workflow secret.
- Compare signatures in constant time.
- Validate a signed timestamp and reject stale or replayed requests.
- Permit only registered workflow identifiers:
- Enforce a pattern such as
^[a-z0-9]+(-[a-z0-9]+)*$. - Resolve the identifier through a fixed allowlist rather than treating it as a path.
- Enforce a pattern such as
- Canonicalize the selected directory and verify that it remains beneath the canonical
workflows/flowsroot. - Reject absolute paths,
.and..components, slashes, backslashes, control characters, and symbolic-link escapes. - Rename the request-path variable to
REQUEST_PATH; never overwrite the shell'sPATHvariable. - Use a fixed dispatcher that maps workflow IDs to known executable paths rather than executing
./run.shfrom an attacker-influenced directory. - Run the webhook service as a dedicated, unprivileged account with write access only to required workflow trigger locations.
- Write payloads atomically, enforce size limits and schemas, and avoid launching unbounded background processes.
- Log rejected requests without recording authentication secrets or sensitive payload contents.
- Authenticate every webhook before processing its path or body: