Back to skill

Security audit

mcp-bridge

Security checks for vulnerabilities and agentic risk

Overview

The skill is a straightforward MCP bridge setup guide, with disclosed npm installation and MCP server configuration, but users should treat its unpinned package commands and token example carefully.

Before installing, pin reviewed package versions where possible, avoid running npx -y against unreviewed packages, prefer a project-local install over a global install, and provide GitHub credentials through a secret manager or protected environment rather than typing a real token into the command line.

Vulnerability Patterns
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:12
Finding
Unpinned Third-Party Packages Are Downloaded and Executed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 12–16 and 37–51 **Vulnerability Type**: Unsafe and unpinned third-party dependency execution **Risk Level**: Medium ### Vulnerable Code ```markdown ## Installation ```bash npm install -g mcp-bridge-openclaw ``` ``` ```markdown ## Configuration Create `config.json`: ```json { "servers": { "filesystem": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"], "env": {} } } } ``` ``` ### Technical Analysis The installation command globally installs `mcp-bridge-openclaw` without pinning an exact version or verifying package integrity. The example configuration also invokes `npx` with the `-y` option to retrieve and execute the latest package version without requiring confirmation. Both package references are mutable. The effective code executed by a user can therefore differ from the code available when this skill was reviewed. The project contains no vendored dependency source, lockfile, integrity hash, or executable implementation that would allow the package behavior to be independently verified. The global installation command can also run npm lifecycle scripts with the invoking user's privileges. Likewise, `npx -y` can download and execute package code automatically. This creates supply-chain exposure if the package, publisher account, dependency tree, or package registry distribution channel is compromised. ### Attack Path 1. An attacker compromises the publisher account, package release process, or a transitive dependency. 2. The attacker publishes a malicious version under the referenced package name. 3. A user follows the skill instructions and runs the unpinned global installation command, or starts the configured server using `npx -y`. 4. npm retrieves the current malicious release because no exact version or integrity value is specified. 5. Malicious lifecycle or runtime code executes with the privileges and envi ...[truncated 850 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every package to a reviewed exact version, including packages launched through `npx`. 2. Replace the automatic invocation with an explicitly versioned command, such as: ```bash npx --no-install @modelcontextprotocol/server-filesystem@REVIEWED_VERSION /tmp ``` Install the reviewed dependency locally beforehand. 3. Maintain a lockfile and verify package integrity using registry integrity metadata or independently recorded checksums. 4. Prefer a project-local installation over `npm install -g` to limit scope and improve reproducibility. 5. Review direct and transitive dependency source code before approving updates. 6. Disable npm lifecycle scripts during installation where package functionality permits: ```bash npm install --ignore-scripts ``` 7. Run the bridge and MCP servers in a sandbox or container with only the minimum required filesystem and network permissions. 8. Remove `-y` so package download and execution cannot occur without an explicit user decision. 9. Establish an update process that requires security review before changing pinned versions. ]]>

T09 · Insecure Skill Coding Practices

Note
Location
SKILL.md:69
Finding
Example Encourages Entering an Access Token Directly in a Shell Command<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 69 **Vulnerability Type**: Potential credential disclosure through shell history **Risk Level**: Low ### Vulnerable Code ```markdown Then run: `GITHUB_TOKEN=your_token mcp-bridge --config config.json` ``` ### Technical Analysis The example encourages users to replace `your_token` with a real GitHub token directly in an interactive shell command. Although prefixing a command with an environment-variable assignment limits the variable to the launched process, it does not prevent the complete command text from being recorded by shell history, terminal logging, session recording, audit tooling, support captures, or history synchronization. The token can also be visible briefly through process inspection on platforms or execution environments that expose command arguments or shell command lines. This conflicts with the preceding recommendation to avoid plaintext token storage because the example itself can create a persistent plaintext copy outside the configuration file. ### Attack Path 1. A user replaces `your_token` with a valid GitHub access token and executes the example command. 2. The shell or terminal records the complete command in a history file, session log, or synchronized history service. 3. Another local user, administrator, support operator, backup reader, or party with access to the history data retrieves the token. 4. The attacker submits the token to GitHub. 5. GitHub operations are performed within the scopes and repository access granted to the exposed token. ### Impact Assessment The impact is limited by the permissions assigned to the exposed token. Depending on its scopes, an attacker may be able to: - Read private repositories. - Modify repository content. - Access organization resources. - Read or modify issues, pull requests, packages, or workflows. - Perform other API operations authorized by the token. This finding does not establish that a real credential is ...[truncated 150 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not instruct users to place literal secrets directly in command lines. 2. Recommend obtaining the token from a secret manager or protected credential store. 3. If an interactive workflow is necessary, use a hidden prompt: ```bash read -rsp "GitHub token: " GITHUB_TOKEN echo export GITHUB_TOKEN mcp-bridge --config config.json unset GITHUB_TOKEN ``` 4. Document that users should verify the permissions of shell history and terminal logs. 5. Recommend narrowly scoped, short-lived tokens rather than broad or long-lived credentials. 6. Advise immediate token revocation and rotation if a token is accidentally entered into a recorded command line. 7. Ensure verbose bridge logging never emits environment-variable values or authorization headers. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.