CVE-2026-53709: MCP Context Forge: Hardcoded default JWT_SECRET_KEY shipped in source and .env.example enables pre-authentication platform admin token forgery
MCP Context Forge is an MCP gateway and administrative platform. Prior to 1.0.2, mcpgateway/config.py and .env.example ship a known JWTSECRETKEY, while verifyjwttoken() accepts HS256 tokens signed with that key and getcurrentuser() creates a platform administrator when the token subject matches PLATFORMADMINEMAIL and REQUIREUSERINDB is false. A remote unauthenticated attacker can therefore mint accepted administrator tokens without a database account. While the vulnerable signing key remains configured and the platform-admin bootstrap remains enabled, forged access survives password rotation, account deletion, and session revocation, allowing administrative disclosure, modification, and service disruption. This issue is fixed in version 1.0.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MCP Context Forgeto a version that resolves this vulnerability.Fixed in 1.0.2
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated administrator takeover?
Deployments prior to 1.0.2 are exposed if they still use the shipped known JWT_SECRET_KEY and have the platform-admin bootstrap path enabled: REQUIRE_USER_IN_DB is false and a token subject matches PLATFORM_ADMIN_EMAIL. The attacker does not need a database account or prior authentication.
What should be changed if upgrading immediately is not possible?
Replace the known JWT_SECRET_KEY with a unique secret and disable the platform-admin bootstrap condition by requiring users to exist in the database. These conditions must both be addressed because forged tokens are accepted while the vulnerable signing key remains configured and the bootstrap remains enabled.
Will password resets, account deletion, or session revocation remove forged access?
No. Forged administrator access survives password rotation, account deletion, and session revocation while the vulnerable signing key and platform-admin bootstrap remain in effect. Rotate the JWT signing secret and correct the bootstrap configuration to invalidate this access.
How can administrators determine whether their instance is affected?
Check whether the deployment is running a version earlier than 1.0.2, whether its JWT_SECRET_KEY matches the value shipped in the source or .env.example, and whether REQUIRE_USER_IN_DB is false. Also verify whether PLATFORM_ADMIN_EMAIL is configured, since tokens using that subject can create a platform administrator under the vulnerable conditions.