T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:27
- Finding
- Shell Command Injection Through Unsanitized Task Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 27–31 **Vulnerability Type**: OS command injection through shell-interpreted user input **Risk Level**: High ### Vulnerable Code ```text When the user invokes this command: 1) Parse list/title/description exactly. 2) Run: bash -lc '/usr/local/bin/clickup_create_task.sh "<list>" "<title>" "<description>"' ``` ### Technical Analysis The Skill instructs the agent to interpolate the user-controlled `list`, `title`, and `description` values directly into a command string executed through `bash -lc`. Double quotes around the interpolated values do not make this construction safe. A value containing a double quote can terminate its intended argument and introduce shell control operators, command substitutions, redirections, or additional commands. The inner Bash process will parse those injected characters as shell syntax. The instruction to parse the arguments “exactly” provides no allowlist validation, escaping, or structured argument passing. Although the documentation says that `list` must be `visionplay` or `inbox`, the execution instructions do not enforce this constraint. The title and description are necessarily user-controlled free-form values. For example, a crafted title with the conceptual structure: ```text "; <attacker-command>; # ``` could produce an effective inner shell command resembling: ```sh /usr/local/bin/clickup_create_task.sh "visionplay" ""; <attacker-command>; # " "description" ``` The injected command would then be interpreted by Bash rather than passed as task-title data. The `skill.json` file also references the external script, but its implementation is not included in the audited project. Consequently, any additional validation performed by that script cannot be confirmed. Validation inside the script would not reliably mitigate commands already interpreted by `bash -lc`. ### Attack Path 1. An attacker invokes the user-accessible `/clickup-task` command ...[truncated 1322 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove `bash -lc` and avoid constructing a shell command from user-controlled text. 2. Invoke the script through a process-execution API that accepts an executable and a separate argument array, with shell interpretation disabled. Conceptually: ```text executable: /usr/local/bin/clickup_create_task.sh arguments: - validated_list - title - description shell: false ``` 3. Enforce an exact allowlist for the list parameter before execution: ```text list == "visionplay" OR list == "inbox" ``` Reject every other value rather than attempting to sanitize it. 4. Treat the title and description as opaque data. Do not concatenate them into a shell command, and do not use `eval`, `bash -c`, or `bash -lc`. 5. Apply reasonable length limits and reject NUL bytes or other values unsupported by the process-execution interface. 6. Update the Skill instructions to require structured argument passing explicitly and prohibit shell-string execution. 7. Review `/usr/local/bin/clickup_create_task.sh`, which was not included in the project, for additional command injection, unsafe temporary files, token disclosure, insecure API handling, and insufficient input validation. 8. Run the Skill under a least-privileged service account, limit outbound network access to required ClickUp endpoints, and ensure the ClickUp token has only the permissions needed to create tasks in the intended lists. 9. Avoid returning raw error output if it can contain authorization headers, environment variables, or other secrets. Redact sensitive values before presenting errors to users. ]]>