Fix Llm Artifacts

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:13 AM UTC
• Version: 1.1.5

Overview

This skill is mostly coherent, but it needs review because it can broadly rewrite repository files, run unpinned package tools, and hide JavaScript test failures.

Use this skill only in repositories where you are comfortable letting the agent edit code and run local project tooling. Prefer `--dry-run` first, inspect the final diff, keep the `.beagle` artifacts if you need audit history, and consider requiring pinned or local-only package tools plus real test failure reporting before broad use.

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 (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:213

Finding

Unpinned Package Execution Through npx

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:213-216
Vulnerability Type: Insecure third-party dependency execution
Risk Level: Medium

Vulnerable Code

bash

# Check for eslint
if [ -f "eslint.config.js" ] || [ -f ".eslintrc.json" ]; then
    npx eslint --fix .
fi

Technical Analysis

The skill instructs the agent to execute npx eslint --fix . solely based on the presence of an ESLint configuration file. It does not require ESLint to be installed as a locked local dependency and does not prohibit npx from resolving or downloading a package.

If a suitable local executable is unavailable, npx may obtain and execute package code from the configured npm registry. The executed package version and source are not explicitly pinned or validated by this instruction. This creates a supply-chain execution boundary in which third-party package code may run with the same operating-system permissions and repository access as the agent.

The configuration-file check does not establish that the corresponding executable is trusted, locally installed, or represented in a reviewed lockfile.

Attack Path

1. A repository contains eslint.config.js or .eslintrc.json.
2. ESLint is absent from the local locked dependencies, or package resolution is influenced by the npm environment or registry configuration.
3. The skill runs npx eslint --fix ..
4. npx resolves or downloads a package from the configured registry.
5. Package installation hooks or the resolved executable run with the agent's permissions.
6. A compromised or substituted package can read or alter repository files and access other resources available to the invoking process.

Impact Assessment

Successful exploitation permits code execution with the privileges of the user or agent running the skill. The practical scope may include reading and modifying the checked-out repository, accessing environment variables and credentia ...[truncated 226 chars]

Remediation

View remediation

Remediation Suggestions

• Require ESLint to exist as a reviewed, version-locked local development dependency.

• Invoke the local package without allowing installation, for example:

  bash

  npx --no-install eslint --fix .
  

• Prefer a lockfile-enforced package-manager command, such as npm exec --offline -- eslint --fix ., where supported and appropriately configured.

• Verify that package.json and a recognized lockfile exist before execution.

• Use reproducible installation modes such as npm ci in an isolated environment when dependency installation is necessary.

• Treat missing local tooling as a verification failure rather than automatically retrieving executable code.

• Run formatters and linters in a sandbox with minimal filesystem, credential, and network access.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:240

Finding

JavaScript Test Failures Are Unconditionally Suppressed

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:240-243
Vulnerability Type: Verification failure suppression
Risk Level: Medium

Vulnerable Code

bash

# JavaScript/TypeScript
if [ -f "package.json" ]; then
    npm test 2>/dev/null || yarn test 2>/dev/null || true
fi

Technical Analysis

The final || true forces the command chain to return a successful exit status even when both npm test and yarn test fail. Redirecting standard error to /dev/null also conceals diagnostic information that would otherwise identify test-runner failures or malicious package-script behavior.

This directly conflicts with the skill's stated post-edit hard gate, which says that invoked verification tools must exit successfully and that a non-zero exit status constitutes failure. Because the shell expression always succeeds, downstream logic may incorrectly treat a failed test run as passed.

The cleanup instructions later permit deletion of .beagle/llm-artifacts-review.json and .beagle/llm-artifacts-verification.json after successful completion. A falsely successful test status could therefore allow unverified edits to remain while the review evidence used to produce those edits is removed.

Attack Path

1. The skill applies one or more source-code fixes.
2. An applied fix introduces a regression, or a repository test script deliberately returns a failure.
3. npm test exits with a non-zero status.
4. The fallback yarn test also exits with a non-zero status or cannot run.
5. The terminal true returns status zero, masking both failures.
6. The skill may report verification as successful despite failing tests.
7. Successful-completion cleanup may remove the review and verification artifacts, reducing the evidence available for diagnosis and recovery.

Impact Assessment

This flaw does not independently grant additional system privileges. Its primary impact is integrity loss in the remedi ...[truncated 314 chars]

Remediation

View remediation

Remediation Suggestions

• Remove || true and preserve the selected test command's actual exit status.
• Detect the intended package manager from the repository lockfile rather than trying multiple managers indiscriminately.
• Do not discard standard error; capture and include it in the verification report.
• Fail the post-edit gate when tests fail or cannot be executed.
• Preserve review and verification artifacts whenever any required test command fails.

A hardened implementation could use explicit package-manager selection:

bash

if [ -f "package.json" ]; then
    if [ -f "package-lock.json" ]; then
        npm test
    elif [ -f "yarn.lock" ]; then
        yarn test
    else
        echo "Unable to identify a locked package manager for tests." >&2
        exit 1
    fi
fi

Cleanup should occur only after this command completes with a genuine zero exit status.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (5)

Tool Parameter Abuse

High

• Category: Tool Misuse
• Confidence: 85% confidence

Finding

Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Content

Scanner excerpt · SKILL.md (reported line 279)May include surrounding context.

On successful completion (all verifications pass):

bash

rm -f .beagle/llm-artifacts-review.json .beagle/llm-artifacts-verification.json

If any verification fails, keep the files and report:

Description-Behavior Mismatch

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The post-fix verification stage runs broad mutating commands such as ruff check --fix ., ruff format ., and npx eslint --fix . across the entire repository. That allows the skill to make many unreviewed edits unrelated to the locked findings, defeating the anti-confabulation and narrow-scope safety gates established earlier in the skill.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence

Finding

npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

• Category: Not specified by scanner
• Confidence: 85% confidence

Finding

The skill invokes a wide set of ecosystem tools (npx, npm, yarn, go, pytest, mypy) that go beyond narrowly applying reviewed fixes. These commands can execute project-defined scripts, install or resolve dependencies, and run arbitrary repository code during tests, increasing the attack surface substantially for a skill whose core purpose is supposed to be limited fix application.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 70% confidence

Finding

npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.