MCP Context Forge up to 1.0.1 shipped a known default JWT signing key. With default admin settings, an unauthenticated attacker could gain platform admin. CVSS 9.8; fixed in 1.0.2.
IBM's MCP Context Forge gateway, up to and including 1.0.1, shipped a known default signing key for its JSON Web Tokens (JWTs). With the default admin email and the default REQUIRE_USER_IN_DB=false, an unauthenticated attacker who knew that key could mint a token the gateway accepted as platform administrator. The flaw is CVE-2026-53709, rated CVSS 9.8, and it is fixed in 1.0.2. We have not checked whether anyone has exploited it, and it is not in CISA's KEV catalog as of 15 October 2026.
What happened
The advisory (GHSA-m8rv-5m6m-32ff) says the JWT_SECRET_KEY default in mcpgateway/config.py, and the matching live line in .env.example, was a fixed value that every install shared. The gateway verifies HS256 tokens, which are signed and checked with the same secret, so anyone holding that value can produce tokens the gateway treats as valid (we covered a similar LiteLLM forged admin token flaw). The affected package on PyPI is mcp-contextforge-gateway, versions up to 1.0.1; 1.0.2 is the first fixed release. The advisory's own proof of concept was tested on 1.0.0, so 1.0.0 and 1.0.1 are both affected. The current release is v1.0.11 (28 September on GitHub and PyPI).
GitHub, acting as CNA, scored it CVSS 3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and mapped it to CWE-287, CWE-321, CWE-798 and CWE-1188. NVD published the record on 13 October with status "Received", so NVD has not added a score of its own. The reporter is credited as hewei-gikaku.
The dates do not line up. The fix commit is dated 22 May 2026 and v1.0.2 was published on GitHub and PyPI on 26 May. The GitHub advisory API gives a published_at of 15 June 2026, so the advisory was public four months before the CVE reached NVD on 13 October. The v1.0.2 release notes do not mention the security fix, so anyone who upgraded for other reasons may not know they are covered.
Why it matters
Context Forge is a gateway that sits in front of MCP servers and tools, so a platform administrator there controls what agents can reach (compare the MCP Atlassian server auth bypass). NVD describes the impact as disclosure, modification and service disruption.
The persistence is the part that catches people out. Per NVD, forged access survives password rotation, account deletion and session revocation for as long as the weak key and the admin bootstrap path remain. Resetting the admin's password does not remove the problem, because a forged token never depended on that password.
Severity needs one qualification. The 9.8 assumes the default configuration. The advisory says the only configuration changes that close the path are a random key of 32 bytes or more set before first start, and either an unpredictable PLATFORM_ADMIN_EMAIL or REQUIRE_USER_IN_DB=true after a real admin is seeded. A deployment that did both is in a different position from a copy of .env.example left as shipped.
The advisory also lists what a platform administrator can do: read stored OAuth client secrets and other auth credentials, because the encryption secret (AUTH_ENCRYPTION_SECRET) has the same insecure-default problem.
Technical details
Three defaults combined:
- Known signing key. The shipped
JWT_SECRET_KEYwas the same on every install. - Open network binding. The shipped
.env.examplealso setHOST=0.0.0.0, so the gateway listened on all interfaces by default, per the advisory. - Admin bootstrap without a database account. Per NVD,
get_current_user()creates a platform administrator when the token's subject matchesPLATFORM_ADMIN_EMAILandREQUIRE_USER_IN_DBis false. The default admin email wasadmin@example.com, and false was the default.
No account has to exist for this to work, which is why account deletion changes nothing. We are not publishing the key or any token construction steps; the advisory and fix commit are linked below for those who need them.
What 1.0.2 changes, according to fix commit 2af690f:
- A weak or default
JWT_SECRET_KEY(andAUTH_ENCRYPTION_SECRET) now stops the gateway at startup withSecurityConfigurationError, unless the environment isdevelopment, where it only logs a warning. .env.examplenow uses__REPLACE_ME__placeholders. Any value starting with that string is rejected in every environment.- The source default is now the sentinel
changeme, which is on the weak-value list. REQUIRE_USER_IN_DBnow defaults to true.- The bootstrap path takes admin status from the token's
is_adminclaim instead of hardcoding true. python -m mcpgateway.scripts.init_secretsgained weak-value detection; its--stdoutoption prints newly generated secrets.
What defenders should do
1. Find out whether you are exposed. Check the installed version of mcp-contextforge-gateway. Anything at 1.0.1 or below is affected. The advisory describes a remote check, which we do not reproduce. The simpler route is local: compare the JWT_SECRET_KEY your gateway actually uses (environment variable, .env file or container secret) against the value in the .env.example of the version you deployed, without pasting either into tickets or chat. If you copied .env.example and never edited that line, assume you are running the default. Also check PLATFORM_ADMIN_EMAIL, REQUIRE_USER_IN_DB, and whether HOST left the gateway reachable from untrusted networks.
2. Upgrade to the latest release (1.0.11), 1.0.2 being the first fixed one. After upgrading, a default key outside a development environment makes the gateway refuse to start, which tells you quickly if you still had one. Instances with the environment set to development only get a warning, so do not rely on that for anything reachable by others. One side effect: REQUIRE_USER_IN_DB now defaults to true, and the fix commit says existing deployments that rely on the bootstrap must set it explicitly. Admin logins that depended on the bootstrap will stop working until a real admin exists in the database. That default change is separate from key rotation and does not replace it.
3. Rotate the key, not just the password. Set JWT_SECRET_KEY to a random value of 32 bytes or more; init_secrets can generate one. Do the same for AUTH_ENCRYPTION_SECRET, which also shipped with a default; do not reuse the old value. Because HS256 tokens are checked against the secret, changing it should stop tokens signed with the old key from validating, forged or legitimate. That follows from how HS256 works; the advisory does not spell it out. Plan to reissue tokens for users and API clients afterwards.
4. Treat an exposed instance as possibly accessed. The advisory says a platform administrator can read stored OAuth client secrets and other auth credentials, so rotate the upstream credentials the gateway holds if it was reachable on a default key. Search gateway logs for the platform_admin_bootstrap security event ("Platform admin bootstrap authentication for <email>") from unexpected sources or times. A legitimate bootstrap login logs the same line, and the advisory says forged tokens carry no indicator that tells them apart from real ones, so absence of hits is not proof. Also review registered servers and tools.
5. If you cannot upgrade yet. Per the advisory, the only configuration changes that close this path are both of: (a) replace JWT_SECRET_KEY with a cryptographically random value of 32 bytes or more before the gateway is started for the first time, and (b) either change PLATFORM_ADMIN_EMAIL to an unpredictable value, or set REQUIRE_USER_IN_DB=true after seeding a real admin user. The second can lock you out of a fresh install.
This is the second recent MCP-ecosystem story where upgrading is only part of the fix. In the MCP Python SDK OAuth credential-theft flaw, operators also had to change configuration after patching. Here, they have to replace a secret.
What is still unclear
- Exploitation. We did not search for exploitation reports beyond the advisory and NVD, and the CVE is absent from CISA's KEV JSON as checked on 15 October. That is not evidence that no one has exploited it; forged-token bugs have been exploited before, as with the WSO2 API Manager JWT bypass.
- Whether old tokens fail after rotation. The vendor does not state it; our reading is based on how HS256 works.
- How many deployments run the default. No scan or install count has been published.
- Why the record came months after the fix. The gap between the May fix and the 13 October CVE publication is unexplained, even though the advisory was public in June.