submit pr

• Outcome: Review
• Latest audit: Sep 11, 2026 · 10:21 AM UTC
• Version: 1.0.2

Overview

The skill is a coherent PR-submission helper, but it has review-worthy safety gaps around shell-handling the PR title and incomplete secret scanning before pushing code.

Install only if you are comfortable with a skill that can stage, commit, push, and create GitHub PRs. Before using it, manually review untracked files and secrets, and avoid passing PR titles containing shell metacharacters, quotes, command substitutions, or newlines until the skill is revised to validate the title and scan the exact staged snapshot.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:144
• Finding: Shell command injection through the user-controlled PR title<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 144-146 **Vulnerability Type**: Shell command injection **Risk Level**: High ### Vulnerable Code ```bash gh pr create \ --title "$ARGUMENTS" \ --body "$(cat <<'EOF' ``` ### Technical Analysis The PR title is obtained from the user through `$ARGUMENTS` and inserted directly into a shell command template. The Skill does not require validation, escaping, or transfer through a structured process-argument interface. Although `$ARGUMENTS` appears between double quotes, raw template substitution may occur before the shell parses the command. An attacker can therefore provide a title containing a double quote, command separator, or command substitution expression that terminates the intended argument and introduces another shell command. The permitted tool configuration includes `Bash(gh pr create:*)`, so an injected suffix embedded in an otherwise permitted `gh pr create` invocation could be interpreted by the shell rather than treated exclusively as PR-title text. ### Attack Path 1. An attacker or untrusted user supplies a crafted PR title containing shell syntax, such as a closing quote followed by a command separator. 2. The Skill substitutes the supplied value for `$ARGUMENTS` in the `gh pr create` command. 3. The injected quote terminates the intended `--title` argument. 4. The shell parses the remaining attacker-controlled content as one or more commands. 5. Those commands execute with the operating-system permissions and accessible environment of the Agent process. ### Impact Assessment Successful exploitation can provide arbitrary command execution under the Agent's local account. Depending on that account's permissions and environment, an attacker could: - Read or modify repository files. - Access credentials available to the process, including Git or GitHub authentication material. - Alter source code or Git history. - Create unauthorized commits or pull requests. - Exfilt ...[truncated 226 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not substitute `$ARGUMENTS` directly into shell source. - Pass the PR title through a structured process API where the title is supplied as a discrete argument without an intervening shell. - If the execution environment requires a shell, transfer the title through a safely initialized environment variable and reference it as a single quoted argument. - Reject control characters, newlines, shell metacharacters, and titles exceeding an appropriate maximum length as defense in depth. - Do not attempt to implement shell escaping through ad hoc character replacement. - Add tests using titles containing quotes, semicolons, dollar signs, backticks, command substitutions, newlines, and leading hyphens. - Require explicit user confirmation of the final title after validation and before PR creation. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: ``` ### Technical Analysis The Skill states that all pending changed files must be scanned before a commit is created. However, `git diff HEAD --name-only` only reports changes represented in Git's tracked-file diff. It does not enumerate ordinary untracked files. Consequently, a newly created file can be absent from the Step 1 scan even though later workflow steps display it through `git status`, allow the user to confirm it, and stage it with `git add`. The workflow can then report that the sensitive-i ...[truncated 1563 chars]:47
• Finding: Secret scanning omits untracked files that may later be committed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 47-51 **Vulnerability Type**: Incomplete sensitive-information scanning **Risk Level**: Medium ### Vulnerable Code ```bash git diff HEAD --name-only git diff HEAD -- <file> ``` ### Technical Analysis The Skill states that all pending changed files must be scanned before a commit is created. However, `git diff HEAD --name-only` only reports changes represented in Git's tracked-file diff. It does not enumerate ordinary untracked files. Consequently, a newly created file can be absent from the Step 1 scan even though later workflow steps display it through `git status`, allow the user to confirm it, and stage it with `git add`. The workflow can then report that the sensitive-information scan passed without ever inspecting that file. The issue affects both content-based secret patterns and sensitive filenames. For example, an untracked `.env`, private-key file, or source file containing an API token can bypass the documented scanner and subsequently enter the commit. ### Attack Path 1. A sensitive file is created in the repository as an untracked file. 2. Step 1 obtains its scan list using `git diff HEAD --name-only`. 3. Git omits the untracked file from that output, so its filename and contents are not scanned. 4. Step 2 obtains repository status and presents the new file for confirmation. 5. The user confirms the file, or does not recognize that it was excluded from the earlier scan. 6. The Skill stages the file with `git add`. 7. The file is committed, pushed to the remote repository, and included in the pull request. ### Impact Assessment This flaw can expose secrets to the remote Git repository and everyone who can access its objects or pull requests. Potentially exposed material includes: - API keys and bearer tokens. - GitHub access tokens. - Cryptocurrency private keys or mnemonic phrases. - Environment configuration containing credentials. - PEM, keystore, or other private-k ...[truncated 217 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Construct the initial scan set from both tracked changes and untracked files. - Enumerate untracked files using a command such as: ```bash git ls-files --others --exclude-standard ``` - Reconcile that output with tracked additions, modifications, renames, and deletions obtained from Git status or diff metadata. - Check sensitive filenames before staging, including `.env`, `.env.*`, private-key formats, and keystore files. - Scan file contents without evaluating or sourcing them. - After the user confirms the file scope and staging is complete, perform a second mandatory scan against the staged snapshot using: ```bash git diff --cached --name-only git diff --cached -- <file> ``` - Abort the workflow if the staged file set differs from the previously scanned and confirmed set. - Prefer a mature secret-scanning tool with entropy detection and well-maintained credential patterns, while retaining explicit sensitive-filename checks. - Record which exact Git object or staged snapshot was scanned so the scan result cannot become stale before commit creation. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: The instructions explicitly require commit subjects to be written entirely in English and forbid Chinese characters. This is a natural-language policy concern because it forces a specific language choice rather than offering the user a language or locale option.

Static analysis

No suspicious patterns detected.