All posts
Supply Chain Compromise

Context Forge Ships Admin-Token Key as Public Literal

CVE-2026-53709: IBM Context Forge gateway shipped its JWT_SECRET_KEY as a public literal, letting unauthenticated attackers mint admin tokens

Securityv0 Intelligence Team OWASP: ASI06 sv0 finding: nhi_compromise
mcp-context-forge mcp cve-2026-53709 nhi-compromise jwt asi06

The Incident

On 2026-10-13, the CVE record for CVE-2026-53709 (CVSS 9.8, CWE-287 Improper Authentication) went live against the mcp-contextforge-gateway package maintained in IBM’s mcp-context-forge repository. All gateway builds at or below 1.0.1 ship a hardcoded HMAC-SHA256 default for JWT_SECRET_KEY as a public literal in both mcpgateway/config.py and the companion .env.example. The gateway’s authentication path accepts HS256 tokens signed with that public value, and when the operator leaves three bootstrap defaults in place — the shipped JWT_SECRET_KEY, PLATFORM_ADMIN_EMAIL=admin@example.com, and REQUIRE_USER_IN_DB=false — the get_current_user() branch synthesizes a virtual platform-admin principal straight from a token’s sub claim without ever touching the user table. An unauthenticated attacker with network reach to the gateway therefore mints its own admin tokens by reading the signing key out of the project’s public repository.

Context Forge is an MCP gateway that fronts MCP servers, A2A agents, and REST/gRPC APIs for LLM agents; the platform-admin principal that CVE-2026-53709 lets an attacker synthesize is the identity that registers and invokes MCP tools, adds and removes gateways, and reads stored OAuth client secrets. The vulnerability carries CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network, no privileges, no user interaction — and the fix lands in mcp-contextforge-gateway 1.0.2. The weak-key validator present in the vulnerable range only logs a startup warning; release 1.0.7 upgrades the same check to raise SecurityConfigurationError and refuse to start in every environment when a placeholder or known-weak secret is present. CVE-2026-53709 is distinct from CVE-2026-53710 (also fixed in 1.0.2), which escaped the RestrictedPython sandbox in the python_sandbox_server subproject of the same umbrella repository — different component, different weakness class, different attack chain. The CVE is not in the CISA KEV catalog and no public PoC has been published at the time of writing.

MITRE ATT&CK coverage: T1552.001 — Credentials In Files, T1078 — Valid Accounts, T1190 — Exploit Public-Facing Application.

The Authority Path That Failed

The identity that carries execution authority at the moment of failure is the virtual platform-admin principal that get_current_user() synthesizes from a JWT’s sub claim when REQUIRE_USER_IN_DB=false. The scope that principal holds in the Context Forge model is full administrative control of the gateway — registering MCP tools and A2A agents, reading stored OAuth client secrets, managing team configuration. The scope it should have exercised is zero: no caller should have been able to assume platform-admin without a human login and a session the operator provisioned, and nothing in the request itself proved the caller had either.

The trust anchor that failed first is the signing key. JWT_SECRET_KEY is a non-human identity — the private half of the gateway’s token-minting authority — and the gateway shipped it as a public literal in mcpgateway/config.py and .env.example. Two downstream checks that could have closed the gap were disarmed by their defaults: the weak-key validator only logged a warning instead of refusing to start, and REQUIRE_USER_IN_DB=false let the admin-bootstrap branch mint a platform admin whose only proof of life was a sub claim equal to the shipped admin@example.com. A user-plane remediation — rotating a human password, deleting a stale account, revoking a session — removes none of this; the signing key is the authority, and any token signed with it keeps being accepted until the key itself is rotated.

SecurityV0 Perspective

CVE-2026-53709 is a textbook nhi_compromise (ASI06). The attack chain consumes machine identities end to end — the attacker never steals a human credential; they read a signing key from a public repository and use it to mint tokens the gateway accepts as a platform administrator. The evidence pack SecurityV0 would produce for a Context Forge deployment names the specific non-human identities and their effective reach: the JWT_SECRET_KEY value compared against a known-weak list of shipped defaults, the PLATFORM_ADMIN_EMAIL and REQUIRE_USER_IN_DB values observed in the running configuration, the HS256 verification settings on the admin API, and the MCP tool and A2A agent entries this gateway can register or invoke downstream.

Pre-exfiltration, the pack answers: did any of our Context Forge gateways run mcp-contextforge-gateway ≤ 1.0.1 with the shipped JWT_SECRET_KEY and REQUIRE_USER_IN_DB=false, and which MCP tools or A2A agents did those gateways front? Post-exfiltration, the pack answers: given a known compromise of the signing key, which forged sub values did get_current_user() accept on which gateways, and which downstream MCP tools or A2A agents did those forged admins register, invoke, or exfiltrate OAuth client secrets from? User-plane rotations answer neither, which is why the identity-plane evidence has to be collected directly.

What To Do

  • Upgrade mcp-contextforge-gateway to 1.0.2 or later and prefer 1.0.7+. 1.0.2 removes the hardcoded default and 1.0.7 upgrades the weak-key validator from a startup log line to a SecurityConfigurationError that refuses to boot when a placeholder or known-weak secret is present in any environment.
  • Rotate JWT_SECRET_KEY before the upgrade reaches your fleet. An attacker who read the shipped literal before the patch landed can keep forging tokens as long as the key is unchanged, so treat the key rotation as the actual remediation and the version bump as the gate that stops the next deployment regressing.
  • Set REQUIRE_USER_IN_DB=true on every Context Forge gateway you run. The admin-bootstrap branch that synthesizes a virtual platform-admin from the sub claim should not be reachable in a production deployment, and this toggle makes get_current_user() require a matching user record before granting any scope.
  • Grep your Context Forge gateway configs for the shipped admin@example.com default and replace it with a value tied to a real human. The precondition chain in CVE-2026-53709 only composes because the shipped admin email meets the shipped signing key; a non-default email breaks the composition even if the key leaks before you can rotate it.
  • Collect a non-human-identity inventory for every MCP gateway you run, not only Context Forge. The pattern — hardcoded signing material in a config file or .env.example, token verification that trusts the key over the user record — repeats across identity planes, so the evidence to produce is the same across gateways: value of the signing material, whether it matches a known-weak list, which admin-bootstrap toggles are enabled, and which MCP tools or A2A agents the resulting admin principal can register or invoke.

Sources

All posts