T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:45
- Finding
- Shell Command Injection Through Unsafe User-Input Interpolation## Vulnerability Details **File Location**: `SKILL.md`, lines 45–59 **Vulnerability Type**: Shell command injection caused by unsafe JSON construction **Risk Level**: High The vulnerable instructions provide shell commands in which a user-supplied email address and one-time verification code are expected to be substituted directly into single-quoted JSON arguments: ```bash curl -s -X POST "https://getyoutubetranscript.com/api/v1/signup" \ -H "Content-Type: application/json" \ -d '{"email": "the_user_email"}' ``` ```bash curl -s -X POST "https://getyoutubetranscript.com/api/v1/signup/verify" \ -H "Content-Type: application/json" \ -d '{"email": "the_user_email", "otp": "123456"}' ``` ### Technical Analysis The Skill directs the Agent to insert user-controlled values into shell commands but does not require validation, shell-safe argument handling, or JSON serialization. The JSON body is enclosed in a single-quoted shell argument. If an Agent performs literal textual substitution, a value containing a single quote can terminate that argument. Additional shell syntax can then be interpreted as a separate local command. User consent to transmit an email address does not mitigate this issue because consent controls whether the network request is allowed, not whether the supplied value is safe to embed in shell source. JSON encoding alone is also insufficient if encoding is performed before unsafe interpolation into a shell command; the value must remain data throughout command construction. ### Attack Path 1. The Skill determines that no API key is available and asks the user for an email address. 2. A malicious user supplies an email-like value containing a single quote followed by shell control syntax and an attacker-selected command. 3. The Agent replaces `the_user_email` in the documented command with that value without using a safe serializer or separate argument channel. 4. The injected single quote cl ...[truncated 1222 chars]
- Remediation
- ## Remediation Suggestions - Do not instruct the Agent to perform textual substitution inside shell command source. - Store the email address and OTP in separately quoted variables and use a JSON serializer such as `jq` to construct the request body: ```bash EMAIL="$USER_PROVIDED_EMAIL" OTP="$USER_PROVIDED_OTP" PAYLOAD="$(jq -n \ --arg email "$EMAIL" \ --arg otp "$OTP" \ '{email: $email, otp: $otp}')" curl --silent --show-error --fail-with-body \ -X POST "https://getyoutubetranscript.com/api/v1/signup/verify" \ -H "Content-Type: application/json" \ --data-binary "$PAYLOAD" ``` - Apply equivalent safe serialization to the initial signup request. - Validate the OTP against an exact six-digit allowlist pattern before invoking `curl`. - Validate the email for expected length and structure, while treating validation only as defense in depth rather than a replacement for safe command construction. - Prefer implementing signup as a dedicated script or structured HTTP tool whose API accepts individual data fields, avoiding generation of shell source entirely. - Preserve the existing explicit-consent requirement and continue restricting transmission to the documented HTTPS origin. - Add tests using values containing single quotes, double quotes, command substitutions, semicolons, newlines, and Unicode characters to verify that every value remains inert request data.