Back to skill

Security audit

Repo Security Auditor

Security checks for vulnerabilities and agentic risk

Overview

The skill is a plausible repository security auditor, but its bundled scripts handle untrusted repositories in ways that can copy or overwrite host files and invoke network-backed tools without clear consent.

Review before installing or running this skill against untrusted or private repositories. If used, run it only in a disposable sandbox or container with no host credentials, use a trusted output directory outside the repository, avoid the unpinned pip install step, and opt in explicitly before GitHub, npm, Snyk, or other network-backed scans.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (6)

T08 · Insecure Dependencies

Error
Location
SKILL.md:97
Finding

Unpinned Third-Party Security Tool Installation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:97-100
Vulnerability Type: Unpinned dependency installation from a remote package registry
Risk Level: High

Complete Code Snippet

bash
# JavaScript/TypeScript
npm audit --json 2>/dev/null > npm-audit.json || echo "No npm audit available"

# Python
pip install safety 2>/dev/null && safety check -r requirements.txt --json 2>/dev/null > safety-report.json || echo "No safety check available"

Technical Analysis

The documented audit procedure installs the latest available release of safety from the configured Python package registry. It does not pin a version, verify a package hash, validate provenance, or create an isolated environment.

Package installation can process registry-controlled package content and may execute installation or build logic with the privileges of the user running the Skill. The installation also modifies the Agent's Python environment. Automatic installation is not necessary for the declared auditing functionality because the Skill can require a preinstalled, approved scanner or use an isolated, reproducible scanning environment.

Attack Path

  1. A user invokes the Skill and follows the dependency-scanning procedure.
  2. The Agent executes pip install safety.
  3. pip obtains the package and its transitive dependencies from the configured registry or mirror.
  4. A compromised release, dependency, registry, or mirror supplies attacker-controlled package content.
  5. Installation or subsequent execution of the package runs that content with the Agent's privileges.

Impact Assessment

Successful exploitation could execute code as the account running the Skill, modify its Python environment, access files and credentials available to that account, and use its network permissions. The impact is bounded by the privileges and sandbox controls applied to the Agent process but could include full user-level comprom ...[truncated 4 chars]

Remediation
View remediation

Remediation Suggestions

  • Do not install scanning tools automatically during an audit.
  • Require tools to be provisioned through an administrator-approved environment.
  • If installation is explicitly authorized, pin the exact package and transitive dependency versions.
  • Require package hashes, such as with pip install --require-hashes.
  • Install into an ephemeral virtual environment or container without access to host credentials.
  • Use a trusted registry and verify package provenance or signatures where supported.
  • Display the proposed installation and obtain explicit user approval before modifying the environment.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/audit-repo.sh:76
Finding

Host File Disclosure Through Repository-Controlled Symbolic Links

Content
View full analysis

Vulnerability Details

File Location: scripts/audit-repo.sh:76-104
Vulnerability Type: Unsafe file reads from an untrusted repository
Risk Level: High

Complete Code Snippet

bash
# Package.json
if [ -f "package.json" ]; then
    cat package.json > "$AUDIT_DIR/package.json"
    npm audit --json 2>/dev/null > "$AUDIT_DIR/npm-audit.json" || true
fi

# Python
if [ -f "requirements.txt" ]; then
    cat requirements.txt > "$AUDIT_DIR/requirements.txt"
fi
if [ -f "pyproject.toml" ]; then
    cat pyproject.toml > "$AUDIT_DIR/pyproject.toml"
fi

# Rust
if [ -f "Cargo.toml" ]; then
    cat Cargo.toml > "$AUDIT_DIR/Cargo.toml"
fi

# Go
if [ -f "go.mod" ]; then
    cat go.mod > "$AUDIT_DIR/go.mod"
fi

# License
echo "📄 License check..."
LICENSE_FILE=$(find . -maxdepth 2 -iname "license*" -o -iname "copying*" | head -1)
if [ -n "$LICENSE_FILE" ]; then
    cat "$LICENSE_FILE" > "$AUDIT_DIR/LICENSE-content.txt"
fi

Technical Analysis

The script clones an untrusted repository and then reads conventional manifest and license paths without rejecting symbolic links or checking their resolved destinations. The -f test follows symbolic links, and cat subsequently reads the linked target.

A malicious repository can contain a tracked symbolic link whose apparent path is package.json, requirements.txt, Cargo.toml, go.mod, or a matching license name while its target is a file outside the repository. If the target exists and is readable, its contents are copied into the audit directory.

This violates the least-privilege boundary expected for repository analysis: the scanner should read only content physically contained within the cloned repository.

Attack Path

  1. An attacker creates a repository containing a symbolic link with a trusted manifest or license filename.
  2. The link references a predictable host path, such as a user configuration or credential-re ...[truncated 827 chars]
Remediation
View remediation

Remediation Suggestions

  • Reject every candidate for which [ -L "$path" ] is true.
  • Resolve each path with realpath and verify that it remains beneath the canonical repository root.
  • Use boundary-aware checks rather than a simple textual prefix comparison.
  • Open untrusted files with no-follow semantics where the platform supports them.
  • Run repository analysis inside a sandbox that cannot read home-directory credentials or unrelated host files.
  • Treat malformed, broken, absolute, and repository-escaping links as explicit findings rather than following them.
  • Apply the same validation before passing a manifest to any package-management command.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/extract-features.sh:18
Finding

Host File Disclosure During Feature Extraction

Content
View full analysis

Vulnerability Details

File Location: scripts/extract-features.sh:18-27
Vulnerability Type: Unsafe symbolic-link traversal when copying repository metadata
Risk Level: High

Complete Code Snippet

bash
# README
echo "📖 README analysis..."
if [ -f "README.md" ]; then
    cat README.md > "$OUTPUT_DIR/README-original.md"
fi

# Package metadata
echo "📦 Package metadata..."
if [ -f "package.json" ]; then
    cat package.json | jq '{name, description, version, main, exports, dependencies, peerDependencies}' 2>/dev/null > "$OUTPUT_DIR/package-metadata.json" || cat package.json > "$OUTPUT_DIR/package-metadata.json"
fi

Technical Analysis

README.md and package.json are read from a potentially hostile repository without ensuring that they are regular, non-symbolic-link files contained within the repository. Both [ -f ... ] and cat follow symbolic links.

The package.json fallback is particularly relevant because, if jq cannot parse the target, the command copies its complete contents into the output file. The vulnerability does not require command injection; filesystem link resolution alone causes the unauthorized read.

Attack Path

  1. An attacker commits README.md or package.json as a symbolic link to a predictable host file.
  2. The repository is cloned onto a system where the target path exists.
  3. The feature-extraction script is run against the repository.
  4. The file check accepts the symbolic link because its target is a regular file.
  5. cat reads the external target and writes it into the feature-extraction output.
  6. The generated artifacts expose the copied data to reviewers or downstream systems.

Impact Assessment

The attacker can cause the script to copy files readable by the Agent account into generated artifacts. Potentially affected data includes configuration, local project files, and file-based credentials. The vulnerability does not itsel ...[truncated 123 chars]

Remediation
View remediation

Remediation Suggestions

  • Refuse to process README.md, package.json, or other inputs if they are symbolic links.
  • Canonicalize the repository root and each input, then enforce containment beneath the root.
  • Copy files through a helper that uses no-follow file-opening behavior.
  • Execute extraction in a filesystem sandbox exposing only the repository and a newly created output directory.
  • Fail safely rather than falling back to an unrestricted cat package.json.
  • Add regression tests using absolute, relative, nested, and broken symbolic links.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/dependency-scan.sh:10
Finding

Arbitrary File Overwrite Through Repository-Controlled Scan Output Links

Content
View full analysis

Vulnerability Details

File Location: scripts/dependency-scan.sh:10-24
Vulnerability Type: Symbolic-link file overwrite in a predictable in-repository output directory
Risk Level: High

Complete Code Snippet

bash
cd "$REPO_PATH"
OUTPUT_DIR="${2:-./security-scan}"
mkdir -p "$OUTPUT_DIR"

echo "🔍 Scanning dependencies in: $REPO_PATH"

# JavaScript/Node.js
if [ -f "package.json" ]; then
    echo "📦 Node.js project detected"
    
    # NPM audit
    if command -v npm >/dev/null; then
        echo "  Running npm audit..."
        npm audit --json > "$OUTPUT_DIR/npm-audit.json" 2>/dev/null || true
        npm audit --audit-level=moderate 2>&1 | tee "$OUTPUT_DIR/npm-audit-summary.txt" || true
    fi

Technical Analysis

The default output directory is ./security-scan, relative to the untrusted repository. mkdir -p accepts an already existing directory and does not validate whether the directory or its files are symbolic links.

Shell output redirection follows symbolic links and truncates the resolved destination before the command runs. tee similarly follows a destination link. Other report files later in this script use the same unsafe pattern, so the issue is not limited to the two filenames shown above.

Attack Path

  1. An attacker prepares a repository containing a security-scan directory.
  2. Inside it, the attacker places npm-audit.json or npm-audit-summary.txt as a symbolic link to a predictable writable host file.
  3. The victim runs dependency-scan.sh without specifying a safe external output directory.
  4. mkdir -p leaves the attacker-created directory and links intact.
  5. Shell redirection or tee follows the link and truncates or replaces the target.
  6. Corruption of a security-sensitive configuration or script can support subsequent code execution when another component later consumes that file.

Impact Assessment

The immediate capa ...[truncated 392 chars]

Remediation
View remediation

Remediation Suggestions

  • Create output outside the repository with mktemp -d under a trusted parent directory.
  • Do not reuse an existing output directory when processing an untrusted repository.
  • Reject symbolic links in every component of the output path.
  • Create report files atomically with exclusive-create and no-follow semantics.
  • Set restrictive permissions, such as umask 077, before creating reports.
  • If a caller supplies an output path, canonicalize it and require it to be outside the repository.
  • Clean up temporary report directories after controlled export of the results.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/extract-features.sh:9
Finding

Arbitrary File Overwrite Through Feature-Extraction Output Links

Content
View full analysis

Vulnerability Details

File Location: scripts/extract-features.sh:9-27
Vulnerability Type: Symbolic-link file overwrite in a repository-controlled output directory
Risk Level: High

Complete Code Snippet

bash
OUTPUT_DIR="${2:-./feature-extraction}"
mkdir -p "$OUTPUT_DIR"

cd "$REPO_PATH"

echo "🔍 Extracting features from: $REPO_PATH"

# README
echo "📖 README analysis..."
if [ -f "README.md" ]; then
    cat README.md > "$OUTPUT_DIR/README-original.md"
fi

# Package metadata
echo "📦 Package metadata..."
if [ -f "package.json" ]; then
    cat package.json | jq '{name, description, version, main, exports, dependencies, peerDependencies}' 2>/dev/null > "$OUTPUT_DIR/package-metadata.json" || cat package.json > "$OUTPUT_DIR/package-metadata.json"
fi

Technical Analysis

The script creates the default output path before changing into the repository. When invoked from the repository root, as suggested by the default, the output directory is repository-controlled. Existing directories and output files are not checked for symbolic links.

The output redirections follow links and truncate their targets. Numerous later commands write additional predictable filenames under the same directory, increasing the number of possible overwrite targets.

Attack Path

  1. An attacker includes a feature-extraction directory in the repository.
  2. A predictable report filename, such as README-original.md or package-metadata.json, is a symbolic link to a host file writable by the Agent.
  3. The victim invokes the script from the repository without an explicit trusted output path.
  4. mkdir -p preserves the existing attacker-controlled directory.
  5. Redirection follows the symbolic link and replaces or truncates the target file.
  6. If the overwritten target is later interpreted as configuration or executable content, the corruption may lead to further compromise.

Impact Assessment

...[truncated 331 chars]

Remediation
View remediation

Remediation Suggestions

  • Always create feature-extraction output in a fresh trusted temporary directory outside the source repository.
  • Apply umask 077 before creating output.
  • Reject existing output directories and symbolic-link path components.
  • Use exclusive, atomic, no-follow file creation for each report.
  • Canonicalize caller-supplied output paths and enforce separation from the repository tree.
  • Export finalized reports to a user-selected location only after validating the destination.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/dependency-scan.sh:39
Finding

Implicit Disclosure of Repository Metadata to Snyk

Content
View full analysis

Vulnerability Details

File Location: scripts/dependency-scan.sh:39-43
Vulnerability Type: Undisclosed invocation of a network-backed third-party scanner
Risk Level: Medium

Complete Code Snippet

bash
# Snyk if available
if command -v snyk >/dev/null; then
    echo "  Running Snyk test..."
    snyk test --json > "$OUTPUT_DIR/snyk-test.json" 2>/dev/null || true
fi

Technical Analysis

The script automatically invokes Snyk whenever the CLI is installed. Snyk is a third-party, network-backed scanning service, and its invocation can transmit dependency and project metadata according to the installed CLI's configuration and service behavior.

Although remote vulnerability analysis is related to the Skill's declared purpose, automatic third-party transmission is not required for local dependency scanning. The script does not request consent, identify the remote destination, describe the transmitted fields, or provide an explicit local-only mode. Suppressing standard error also makes network behavior and failures less visible.

Attack Path

  1. A user runs the dependency scanner against a private or sensitive repository.
  2. The host already has an authenticated Snyk CLI installation.
  3. The script detects the executable and invokes snyk test automatically.
  4. The CLI processes project manifests and communicates with Snyk services as configured.
  5. Dependency or project metadata leaves the local environment without per-scan approval.

Impact Assessment

Potentially disclosed information includes dependency names and versions, project structure, manifest-derived metadata, and vulnerability context. The finding does not demonstrate transmission of credentials or source files by this script itself. The exact disclosure depends on the installed Snyk version, authentication state, configuration, and service behavior.

Remediation
View remediation

Remediation Suggestions

  • Make all network-backed scanners explicitly opt-in.
  • Prompt for approval before invoking Snyk against each repository.
  • Clearly disclose the destination service and categories of metadata that may be transmitted.
  • Provide a documented local-only mode that never invokes remote services.
  • Avoid suppressing all error output; retain a sanitized execution log for review.
  • Run remote scanners with credentials and network permissions scoped to the minimum required.
  • For sensitive repositories, prefer offline advisory databases or approved internally hosted scanners.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (7)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding

The code generally aligns with the high-level idea of auditing a GitHub repository for security-relevant patterns: it clones a repo, inventories files, scans for suspicious patterns, checks for a license file, and performs npm audit when applicable. However, the declared description promises broader and more complete functionality than this script actually implements. In particular, it does not generate a security report, does not perform any clean reimplementation/scaffolding, and only provides narrow dependency analysis (mainly npm audit plus copying manifest files for other ecosystems without analysis). The script is therefore materially less capable than the declared purpose, making the description inaccurate overall.

Content

No source excerpt is available for this finding.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding

The declared description centers on security auditing of third-party GitHub repositories. However, this code chunk only extracts structural and descriptive artifacts from an already-local repository path. It gathers README content, package metadata, exports, types, classes, functions, config/test/doc files, and writes a feature-summary document explicitly framed for clean reimplementation. There is no logic for identifying vulnerabilities, suspicious behavior, obfuscation, unsafe dependencies, licenses, or malicious patterns, and no safety pass/fail decision. Because the implemented behavior has a materially different primary purpose and lacks the core declared security-analysis capabilities, this is a clear mismatch.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
Confidence
86% confidence
Finding

The skill instructs installing a package (pip install safety) during analysis of potentially untrusted repositories. Even though the target package is a known scanner, introducing ad hoc package installation increases supply-chain and environment-modification risk, especially in shared or sensitive environments, and is not strictly necessary if tooling should be preprovisioned.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
81% confidence
Finding

The manifest says the skill may 'optionally scaffold a clean reimplementation,' which suggests limited template generation after safety checks. The documented behavior goes further by prescribing creation of an entire replacement project tree with README, license, dependency manifest, source, tests, and architecture docs, which is more expansive than a narrow audit/report role.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
88% confidence
Finding

The skill directs cloning a repository into /tmp and writing multiple audit artifacts without warning the user that it will modify the local filesystem. In security-review contexts, silent artifact creation can surprise users, consume disk, leave sensitive remnants, or create compliance issues when analyzing private repositories.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
84% confidence
Finding

The dependency scanning workflow performs external network actions (npm audit, pip install, GitHub API access) without explicitly warning about outbound requests or possible disclosure of repository/dependency metadata. In some environments, even dependency names, private package references, or repository identifiers are sensitive and should not be transmitted without informed consent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
87% confidence
Finding

This shell script writes extracted repository content and metadata into a new output directory, including copying README.md and package.json contents. While the script prints progress messages, it does not clearly warn the user that repository data will be duplicated into generated files under the output path.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.