T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:145
- Finding
- Unsafe Interpolation of Email-Derived Data into Shell and AppleScript Commands## Vulnerability Details **File Location**: `SKILL.md`, lines 145-162 **Vulnerability Type**: Command and script injection **Risk Level**: High ### Vulnerable Code ```bash ### Google Calendar (via `gog` or API) ```bash gog calendar create \ --title "Event Title" \ --start "2026-02-17T09:00:00-05:00" \ --end "2026-02-17T10:00:00-05:00" \ --description "Extracted from email: [subject]" \ --location "Zoom link or address" ``` ### Apple Calendar (via `osascript`) ```bash osascript -e 'tell application "Calendar" tell calendar "Work" make new event with properties {summary:"Event Title", start date:date "Monday, February 17, 2026 at 9:00:00 AM", end date:date "Monday, February 17, 2026 at 10:00:00 AM", description:"Extracted from email", location:"Zoom"} end tell end tell' ``` ``` ### Technical Analysis The documented calendar-creation flow places event titles, email subjects, descriptions, and locations into shell and AppleScript command strings. These fields can originate from untrusted email content. The instructions do not require validation, context-specific escaping, or invocation through a structured API or shell-free argument array. Quoting a value is not sufficient when the value itself may contain quotation marks, command substitutions, shell metacharacters, or AppleScript syntax. If an agent replaces the example placeholders through direct string interpolation, crafted email content could terminate the intended string and inject additional shell or AppleScript operations. The Google Calendar example is vulnerable when the assembled command is passed through a shell, such as with `sh -c`, because malicious values may escape their quoted argument or trigger shell expansion. The Apple Calendar example is especially sensitive because the complete program is supplied as one string to `osascript -e`; an injected quotation mark can alter the program structure and add arbitrary AppleS ...[truncated 1843 chars]
- Remediation
- ## Remediation Suggestions 1. Prefer structured calendar APIs over generated shell or AppleScript source. Pass event properties as typed API fields. 2. When invoking `gog`, use a subprocess argument array with shell execution disabled. Each untrusted value must be supplied as a separate argument rather than concatenated into a command string. 3. Never pass an assembled command containing email-derived values to `sh -c`, `bash -c`, `eval`, or an equivalent shell interpreter. 4. For Apple Calendar, avoid embedding untrusted content directly into the `osascript -e` program. Pass values as separate `argv` parameters to an AppleScript `run argv` handler and treat them only as data. 5. If source generation cannot be avoided, apply proven context-specific escaping for AppleScript string literals. Generic shell escaping is not valid for AppleScript and vice versa. 6. Validate extracted fields before calendar creation. Enforce reasonable length limits, reject control characters, normalize line breaks, and allow only expected URL schemes such as `https`. 7. Preserve the existing user-confirmation requirement, but do not treat confirmation as a substitute for safe command construction because users cannot reliably identify embedded injection syntax. 8. Add security tests containing quotation marks, backticks, command substitutions, semicolons, newlines, and AppleScript delimiters in every email-derived field. Verify that these values remain literal calendar data and cannot change command behavior.