T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:713
- Finding
- Receiver Signing Key Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `SKILL.md`, lines 713-718 **Vulnerability Type**: Secret exposure through command-line arguments **Risk Level**: Medium **Vulnerable Code**: ```bash maton trigger destination create --trigger {trigger_id} \ --url https://my-fn-3k9xq2v.maton.app --method POST --name prod \ --header X-Signature-Key={{ your_receiver_key }} ``` ### Technical Analysis The example instructs users to place a receiver-issued signing key directly in a command-line argument. Although the surrounding guidance correctly prohibits using Maton or provider credentials in destination headers, the permitted receiver key is still a credential and requires confidential handling. Command-line secrets can be exposed through shell history, terminal session recording, CI logs, command auditing, crash diagnostics, or process-argument inspection while the command is running. This practice also conflicts with the Skill's safer API-key guidance, which warns against passing credentials on a command line. ### Attack Path 1. A user replaces `{{ your_receiver_key }}` with a real shared signing key and executes the documented command. 2. The command, including the plaintext key, is retained in shell history, logs, audit telemetry, or observable process arguments. 3. An attacker with access to one of those local or centralized records extracts the key. 4. The attacker submits forged requests carrying the stolen `X-Signature-Key`. 5. If the receiving endpoint treats the key as proof of authenticity, it accepts attacker-generated requests as trusted webhook traffic. ### Impact Assessment Exploitation does not grant direct access to the Maton or Stripe OAuth credentials. However, it may allow an attacker to impersonate an authorized webhook sender to the destination protected by the shared key. Depending on the receiver's behavior, forged events could trigger downstream processing, data changes, notifications, workflows ...[truncated 189 chars]
- Remediation
- ## Remediation Suggestions - Remove plaintext secret values from command-line examples. - Update the CLI to accept sensitive header values through a hidden interactive prompt, protected standard input, a restricted file descriptor, or a secret-manager reference. - Prefer a dedicated option such as `--header-secret-env X-Signature-Key=RECEIVER_KEY`, provided the CLI reads the environment internally and does not echo the value. - Ensure secret values are redacted from verbose output, errors, telemetry, and diagnostic logs. - Document rotation procedures for any key exposed through shell history, process monitoring, CI output, or terminal recording. - If no secure input mechanism currently exists, explicitly warn users about the exposure and avoid presenting inline command-line secrets as the recommended workflow.