ScopeBlind Red Team

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:45 AM UTC
• Version: 0.1.1

Overview

The skill is a plausible security benchmarking helper, but its install and run instructions execute mutable npm packages and mix scoped and unscoped package names.

Install only after verifying the npm package publisher and intended binary name. Prefer exact pinned versions, a project-local install with a lockfile, and an isolated environment with minimal secrets and filesystem access before running the benchmark commands.

A.I.G

Vulnerability Patterns

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

T08 · Insecure Dependencies

Error

• Location: SKILL.md:12

Finding

Inconsistent and Unpinned npm Package Execution Enables Supply-Chain Code Execution

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 12-13 and 29-32
Vulnerability Type: Dependency confusion and execution of mutable third-party dependencies
Risk Level: High

Vulnerable Code

yaml

install: |
  npm install -g @scopeblind/red-team@latest protect-mcp@latest

bash

# Run the default attack suite against a policy
npx scopeblind-red-team --policy protect-mcp.json

# Run against a specific incident policy
npx scopeblind-red-team --policy node_modules/protect-mcp/policies/clinejection.json

Technical Analysis

The installation instructions specify the scoped npm package @scopeblind/red-team, but the execution examples invoke the distinct unscoped package name scopeblind-red-team through npx.

If the requested unscoped package is not locally available, npx may retrieve and execute it from the npm registry. Consequently, users following the documented workflow can execute a package different from the scoped dependency they were instructed to install. This creates a package-confusion risk if the unscoped package is unintended, compromised, or controlled by another publisher.

The installation also uses the mutable latest tag for both dependencies. No exact version, lockfile, integrity hash, or vendored implementation is provided. The effective code can therefore change after this skill has been reviewed without any modification to SKILL.md. npm lifecycle scripts and package CLI entry points can execute arbitrary code with the permissions of the invoking user.

The project contains no local implementation through which the claimed deterministic behavior, signed receipts, or badge generation can be independently verified.

Attack Path

1. A user follows the skill instructions and globally installs @scopeblind/red-team@latest and protect-mcp@latest.
2. A malicious or compromised release is published under either mutable dependency tag, or an attacker controls or compromises the separately reference ...[truncated 1344 chars]

Remediation

View remediation

Remediation Suggestions

1. Use the scoped package consistently in both installation and execution instructions. Confirm the executable name exported by the scoped package before documenting it.
2. Pin every dependency to an exact, reviewed version instead of using @latest.
3. Prefer project-local dependencies with a committed lockfile and npm integrity metadata rather than global installations.
4. If the scoped package exports the scopeblind-red-team binary, invoke an explicitly pinned package, for example:

bash

npx --package=@scopeblind/red-team@1.2.3 scopeblind-red-team --policy protect-mcp.json

5. When relying on an already installed and verified executable, use npx --no-install or invoke the local binary directly so that execution fails instead of downloading an unexpected package.
6. Verify package publisher identity, provenance, signatures, registry source, lifecycle scripts, and release integrity before approving a version.
7. Pin protect-mcp to an audited version as well, and update it only through a controlled dependency-review process.
8. Run the benchmarking tool in a sandbox or isolated CI job with minimal filesystem access, no unnecessary credentials, restricted network access, and a non-privileged account.

SkillSpector

Vulnerability Patterns

• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• 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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (3)

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.

Rp1

Medium

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

Finding

The skill instructs users to run npx scopeblind-red-team without pinning a version, which allows retrieval of the latest package at execution time. If the upstream package is compromised, unpublished/republished, or a malicious version is pushed, users could execute attacker-controlled code directly in their environment.

Content

No source excerpt is available for this finding.

Rp1

Medium

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

Finding

This second example repeats the same unsafe pattern: executing npx scopeblind-red-team without a pinned version. Because this skill is explicitly positioned as a red-team/security benchmarking tool and may be run in sensitive environments against policy packs, unpinned remote package execution is more dangerous than in a low-trust sandbox because it invites supply-chain compromise in a security-critical workflow.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.