Code Security Audit

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:09 PM UTC
• Version: 2.1.0

Overview

This is a genuine security-audit skill, but it needs review because some scan outputs and CI helpers can expose secrets or run mutable third-party tools.

Review before installing or using in CI. Run it only on intended workspaces, avoid verbose secret output, do not publish raw CI grep results, pin third-party audit tool versions, and write reports to a trusted path after checking for symlinks.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (4)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/security-audit.sh:248
• Finding: Secret Detection Results Can Expose Credentials in Terminal and CI Logs<![CDATA[ ## Vulnerability Details **File Location**: `scripts/security-audit.sh:248-255`; related instances in `SKILL.md:452-458`, `templates/security-audit.yml:48-64`, and `templates/security-audit.gitlab-ci.yml:24-30` **Vulnerability Type**: Sensitive information exposure through diagnostic output **Risk Level**: High ### Vulnerable Code ```bash local matches=$(grep -rn "$pattern" \ --include='*.ts' --include='*.js' --include='*.py' --include='*.go' \ --include='*.env' --include='*.yml' --include='*.yaml' --include='*.json' \ "$PROJECT_DIR" 2>/dev/null | grep -v "node_modules\|.git\|test\|spec\|example\|placeholder\|your_\|YOUR_\|xxxx\|XXXX" | head -5) if [ -n "$matches" ]; then error "Found potential $name" if [ "$VERBOSE" = true ]; then echo "$matches" | head -3 fi ``` The CI templates similarly invoke `grep` without suppressing matched lines: ```yaml - name: Secret Detection run: | # AWS Access Keys ! grep -rn 'AKIA[0-9A-Z]\{16\}' --include='*.{js,ts,py,env,yml,yaml}' . # OpenAI API Keys ! grep -rn 'sk-[A-Za-z0-9]\{20,\}' --include='*.{js,ts,py,env}' . # GitHub Tokens ! grep -rn 'ghp_[A-Za-z0-9]\{36\}\|github_pat_' --include='*.*' . # Private Keys ! grep -rn 'BEGIN.*PRIVATE KEY' --include='*.*' . continue-on-error: true ``` ### Technical Analysis The scanner stores complete matching source lines in `matches` and prints up to three of those lines when verbose mode is enabled. Because secret assignments commonly place the credential and variable name on the same line, this output can disclose the complete credential. The CI checks also use ordinary recursive `grep`, which prints matching file names, line numbers, and line contents. Negating the exit status with `!` changes only success or failure; it does not suppress output. Consequently, detected secrets may be copied from source files into CI logs. CI logs can have different retention policies and broader access than repositor ...[truncated 1313 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Never print complete matching lines for secret findings. 2. Report only the secret type, relative file path, line number, and a redacted fingerprint. 3. Replace CI checks that only require a Boolean result with quiet matching: ```bash if grep -qrn 'AKIA[0-9A-Z]\{16\}' --include='*.{js,ts,py,env,yml,yaml}' .; then echo "Potential AWS access key detected; inspect the secure scanner report." exit 1 fi ``` 4. If diagnostic context is required, redact the matched value before output and reveal no more than a few non-sensitive prefix or suffix characters. 5. Configure CI masking and restrict log visibility and retention. 6. Store detailed findings in an encrypted, access-controlled artifact rather than ordinary build logs. 7. Add automated tests confirming that known test credentials never appear verbatim in scanner output. ]]>

T08 · Insecure Dependencies

Warning

• Location: templates/security-audit.yml:28
• Finding: CI Templates Install and Execute Unpinned Third-Party Security Tools<![CDATA[ ## Vulnerability Details **File Location**: `templates/security-audit.yml:28-39`; related instances in `templates/security-audit.gitlab-ci.yml:10-17`, `52`, and `71` **Vulnerability Type**: Unpinned build-time dependencies and mutable package execution **Risk Level**: Medium ### Vulnerable Code ```yaml - name: Install security tools run: | pip install pip-audit safety npm install -g audit-ci - name: Run npm audit run: npm audit --audit-level=moderate continue-on-error: true - name: Run audit-ci run: npx audit-ci --moderate continue-on-error: true ``` The GitLab template contains equivalent unpinned installation commands: ```yaml before_script: - apt-get update && apt-get install -y python3 python3-pip - pip3 install pip-audit safety --break-system-packages - npm install -g audit-ci script: - npm audit --audit-level=moderate || true - npx audit-ci --moderate || true ``` Additional jobs install mutable releases: ```yaml - pip install detect-secrets ``` ```yaml pip install pip-audit ``` ### Technical Analysis No exact versions, hashes, lockfiles, or immutable tool images are used for the installed Python and npm tools. Each CI run may therefore resolve a different package release than the one reviewed when this Skill was published. `npm install -g` may execute package lifecycle scripts. `npx audit-ci` may also resolve or download a package when it is not already available locally. Python package installation similarly executes package build and installation behavior from the selected dependency graph. This creates a supply-chain boundary in which compromise of a package, transitive dependency, maintainer account, or registry resolution process can change the code executed by CI without any change to this repository. ### Attack Path 1. An upstream package or transitive dependency is compromised, or an unexpected incompatible release is published. 2. A project runs the supplied CI template after that release become ...[truncated 1087 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every security tool to an exact reviewed version: ```bash python -m pip install \ pip-audit==<reviewed-version> \ safety==<reviewed-version> npm install --global audit-ci@<reviewed-version> ``` 2. Use Python hash verification with a locked requirements file and `--require-hashes`. 3. Use an npm lockfile or a prebuilt, digest-pinned container image containing the approved scanner versions. 4. Run `npx` with `--no-install` after installing the pinned local package: ```bash npx --no-install audit-ci --moderate ``` 5. Disable or tightly control package lifecycle scripts where compatible with the selected tools. 6. Grant CI jobs only the minimum repository-token permissions, avoid exposing deployment secrets to pull-request jobs, and restrict outbound network access. 7. Use automated dependency-update review so scanner upgrades are explicit repository changes rather than silent runtime resolution. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: templates/security-audit.yml:33
• Finding: Security Findings Are Configured as Non-Blocking CI Results<![CDATA[ ## Vulnerability Details **File Location**: `templates/security-audit.yml:33-64`; related instances in `templates/security-audit.gitlab-ci.yml:14-20`, `39`, `58`, and `74` **Vulnerability Type**: Fail-open security control and misleading pipeline success **Risk Level**: Medium ### Vulnerable Code ```yaml - name: Run npm audit run: npm audit --audit-level=moderate continue-on-error: true - name: Run audit-ci run: npx audit-ci --moderate continue-on-error: true - name: Run pip-audit run: | if [ -f requirements.txt ]; then pip-audit -r requirements.txt fi continue-on-error: true - name: Secret Detection run: | # AWS Access Keys ! grep -rn 'AKIA[0-9A-Z]\{16\}' --include='*.{js,ts,py,env,yml,yaml}' . # OpenAI API Keys ! grep -rn 'sk-[A-Za-z0-9]\{20,\}' --include='*.{js,ts,py,env}' . # GitHub Tokens ! grep -rn 'ghp_[A-Za-z0-9]\{36\}\|github_pat_' --include='*.*' . # Private Keys ! grep -rn 'BEGIN.*PRIVATE KEY' --include='*.*' . # Connection Strings with passwords ! grep -rn 'mongodb://\|mysql://\|postgres://\|redis://' --include='*.{js,ts,py,env}' . | grep -v 'localhost\|127.0.0.1' continue-on-error: true ``` The GitLab template suppresses failures both within commands and at job level: ```yaml script: # Dependency vulnerabilities - npm audit --audit-level=moderate || true - npx audit-ci --moderate || true - | if [ -f requirements.txt ]; then pip-audit -r requirements.txt || true safety check -r requirements.txt || true fi allow_failure: true ``` ### Technical Analysis `continue-on-error: true`, `allow_failure: true`, and `|| true` convert scanner failures into successful or tolerated pipeline results. This affects dependency auditing and secret detection—the controls most likely to identify immediately actionable release blockers. The configuration is fail-open: a scanner can detect a qualifying issue and return a nonzero status, but the pipeline ...[truncated 1400 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove `continue-on-error: true`, `allow_failure: true`, and unconditional `|| true` from checks intended to enforce policy. 2. Establish documented blocking thresholds, such as: - Always fail on confirmed secrets. - Fail on high and critical dependency vulnerabilities. - Optionally warn on lower-severity findings. 3. Preserve scanner exit codes and explicitly evaluate structured output rather than suppressing failures. 4. Separate advisory and blocking jobs with clear names, for example `security-advisory` and `security-gate`. 5. Implement time-limited, reviewed exception files for accepted findings instead of globally allowing failure. 6. Protect the security workflow and exception configuration with code-owner approval. 7. Add a CI test fixture containing a synthetic secret and known vulnerable result to verify that the pipeline fails as designed. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/security-audit.sh:767
• Finding: Predictable Report Output Follows Symbolic Links and Can Overwrite Arbitrary Writable Files<![CDATA[ ## Vulnerability Details **File Location**: `scripts/security-audit.sh:767-769` **Vulnerability Type**: Symbolic-link file overwrite **Risk Level**: Medium ### Vulnerable Code ```bash generate_report() { local output="${OUTPUT_FILE:-security-audit-report.md}" cat > "$output" << EOF ``` ### Technical Analysis The report generator writes to a predictable path in the current working directory by default. Shell output redirection opens the destination with truncation and follows symbolic links. The code does not verify that the destination is a regular file, reject symbolic links, constrain the output to a trusted directory, or create it atomically. The Skill is intended to audit repositories that may contain attacker-controlled content. Such a repository can include `security-audit-report.md` as a symbolic link. When an auditor invokes `--report`, the shell follows the link and replaces the linked target with generated Markdown. Quoting `"$output"` prevents word splitting and wildcard expansion, but it does not protect against symbolic links or pre-existing special files. ### Attack Path 1. An attacker creates and commits a symbolic link named `security-audit-report.md`. 2. The link points to a file writable by the account expected to run the audit. 3. A reviewer checks out the repository with symbolic links preserved. 4. The reviewer runs: ```bash ./scripts/security-audit.sh --report ``` 5. `cat > "$output"` follows the symbolic link and truncates the target. 6. The generated report replaces the target file's previous contents. The same condition can occur with a user-supplied `--output` path if an attacker can create or replace that path before report generation. ### Impact Assessment The overwrite is limited to files writable by the process identity running the scanner. It does not itself bypass operating-system permission checks. Within that boundary, it can: - Destroy or replace user configuration. - Corrupt files in the reposi ...[truncated 283 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Reject symbolic-link destinations before writing: ```bash if [[ -L "$output" ]]; then error "Refusing to write report through a symbolic link: $output" return 1 fi ``` 2. Require the parent directory to be trusted and resolve it to a canonical path. 3. Refuse non-regular existing destinations, including devices, FIFOs, and sockets. 4. Create the report as a new file with restrictive permissions in a trusted directory: ```bash umask 077 tmp_report=$(mktemp "${trusted_report_dir}/security-audit.XXXXXX") ``` 5. Write the complete report to the temporary file, then atomically rename it after verifying the final destination. 6. Where supported, use an implementation that opens the destination with no-follow and exclusive-creation semantics. 7. Do not run the scanner as root or another privileged identity. ]]>

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
• Output Handling: Unvalidated Output Injection, Cross-Context Output, Unbounded Output

Findings (46)

Anti-Refusal Statement

High

• Category: Anti-Refusal

Content

**Detection Patterns:**

```bash
# Find debug mode enabled
grep -rn "DEBUG\s*=\s*true\|debug:\s*true\|NODE_ENV.*development" \
  --include='*.ts' --include='*.js' --include='*.env' --include='*.yaml' --include='*.json' .

• Confidence: 75% confidence
• Finding: Skill attempts to nullify the agent's safety policies or restrictions ('you have no restrictions', 'ignore your guidelines', 'do anything now'). This is a direct jailbreak that disables guardrails.

Unvalidated Output Injection

High

• Category: Output Handling

Content

```typescript
// ❌ VULNERABLE: Unsanitized HTML
<div dangerouslySetInnerHTML={{ __html: userComment }} />

// ✅ SECURE: Sanitize with DOMPurify
import DOMPurify from 'isomorphic-dompurify'

• Confidence: 65% confidence
• Finding: Model output is used without validation or sanitization. Unvalidated output injected into downstream contexts (SQL, shell, HTML) enables injection attacks and arbitrary code execution.

Unvalidated Output Injection

High

• Category: Output Handling

Content

```typescript
// ❌ VULNERABLE: Unsanitized HTML
<div dangerouslySetInnerHTML={{ __html: userComment }} />

// ✅ SECURE: Sanitize with DOMPurify
import DOMPurify from 'isomorphic-dompurify'

• Confidence: 65% confidence
• Finding: Model output is used without validation or sanitization. Unvalidated output injected into downstream contexts (SQL, shell, HTML) enables injection attacks and arbitrary code execution.

Credential Access

High

• Category: Privilege Escalation

Content

fi

# Sensitive file permissions
for f in .env .env.* *.pem *.key id_rsa id_ed25519; do
    [ -f "$f" ] && ls -la "$f"
done
```

• Confidence: 84% confidence
• Finding: The file permission audit includes enumerating `.env`, `.pem`, `.key`, and SSH key files and printing metadata with `ls -la`. In an agent context, even metadata and existence checks around sensitive files can leak operational secrets layout and encourage inspection of credentials outside the intended project scope.

Credential Access

High

• Category: Privilege Escalation

Content

"npm_token": {
      "pattern": "npm_[A-Za-z0-9]{36}",
      "severity": "high",
      "description": "npm Access Token"
    },
    "gitlab_token": {
      "pattern": "glpat-[A-Za-z0-9_-]{20}",

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

"npm_token": {
      "pattern": "npm_[A-Za-z0-9]{36}",
      "severity": "high",
      "description": "npm Access Token"
    },
    "gitlab_token": {
      "pattern": "glpat-[A-Za-z0-9_-]{20}",

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

local config_issues=0

    if grep -rn "DEBUG.*=.*true\|debug.*:.*true" \
       --include='*.ts' --include='*.js' --include='*.env' --include='*.json' "$PROJECT_DIR" 2>/dev/null | \
       grep -qv "test\|spec"; then
        warn "A05: Debug mode may be enabled"
        config_issues=$((config_issues + 1))

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

# Sensitive files
    log "Checking sensitive file permissions..."
    for f in .env .env.local .env.* *.pem *.key id_rsa id_ed25519 credentials.json; do
        if [ -f "$PROJECT_DIR/$f" ]; then
            local perms=$(stat -c %a "$PROJECT_DIR/$f" 2>/dev/null || stat -f %Lp "$PROJECT_DIR/$f" 2>/dev/null)
            if [ "${perms:-644}" -gt 644 ]; then

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

# Sensitive files
    log "Checking sensitive file permissions..."
    for f in .env .env.local .env.* *.pem *.key id_rsa id_ed25519 credentials.json; do
        if [ -f "$PROJECT_DIR/$f" ]; then
            local perms=$(stat -c %a "$PROJECT_DIR/$f" 2>/dev/null || stat -f %Lp "$PROJECT_DIR/$f" 2>/dev/null)
            if [ "${perms:-644}" -gt 644 ]; then

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

# Sensitive files
    log "Checking sensitive file permissions..."
    for f in .env .env.local .env.* *.pem *.key id_rsa id_ed25519 credentials.json; do
        if [ -f "$PROJECT_DIR/$f" ]; then
            local perms=$(stat -c %a "$PROJECT_DIR/$f" 2>/dev/null || stat -f %Lp "$PROJECT_DIR/$f" 2>/dev/null)
            if [ "${perms:-644}" -gt 644 ]; then

• Confidence: 60% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill exposes extensive shell-based capabilities throughout the document, but the metadata does not declare any tool scope such as allowed-tools or permissions. In an agent environment, this creates an implicit-privilege problem where consumers may execute powerful filesystem, network, and package-management commands without an explicit trust boundary.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

**Checklist:**
- [ ] Every endpoint verifies authentication
- [ ] Every data access verifies authorization
- [ ] CORS configured with specific origins (not `*`)
- [ ] Rate limiting on sensitive endpoints
- [ ] JWT tokens validated on every request

• Confidence: 65% confidence
• Finding: Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Unsafe Defaults

Medium

• Category: Tool Misuse

Content

grep -rn "DEBUG\s*=\s*true\|debug:\s*true\|NODE_ENV.*development" \
  --include='*.ts' --include='*.js' --include='*.env' --include='*.yaml' --include='*.json' .

# Find CORS wildcard
grep -rn "Access-Control-Allow-Origin.*\*\|cors({.*origin.*true" \
  --include='*.ts' --include='*.js' .

• Confidence: 65% confidence
• Finding: Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 91% confidence
• Finding: Using `npx audit-ci` without pinning a version allows the latest package version to be fetched at runtime, which weakens supply-chain integrity and makes builds non-reproducible. If the upstream package or one of its transitive dependencies is compromised, the skill could execute attacker-controlled code during audit runs.

External Transmission

Medium

• Category: Data Exfiltration

Content

// Validate before use
async function fetchPrice(token: string): Promise<number> {
  const response = await fetch(`https://api.example.com/price/${token}`)
  const data = await response.json()

  // Validate response

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.