MCP Context Forge CVE-2026-53709

Two concrete conditions must both hold: (1) the gateway still uses the known shipped JWT_SECRET_KEY (value 'my-test-key-but-now-longer-than-32-bytes' from pre-1.0.2 config.py/.env.example) rather than a rotated secret, and (2) the platform-admin bootstrap is active, i.e. REQUIRE_USER_IN_DB is false and the attacker sets the token subject to PLATFORM_ADMIN_EMAIL. Tokens must be HS256-signed. LIMITING FACTORS: the commit documents that the production default for REQUIRE_USER_IN_DB is true (which requires a DB-seeded admin and closes the bootstrap path), so strictly default production installs are not exploitable via this path; operators who rotated JWT_SECRET_KEY before 1.0.2 are also protected. Exploitation is remote and needs no user interaction or prior authentication once these conditions are met.

All severity signals align toward high technical impact: the NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 9.8) describes remote, unauthenticated, low-complexity forging of platform-administrator JWTs, matching the CWE-287 improper-authentication classification and the full confidentiality/integrity/availability loss the description enumerates (administrative disclosure, modification, and service disruption). However, the real-world urgency is tempered by preconditions the CVSS vector does not capture: exploitation only works 'while the vulnerable signing key remains configured and the platform-admin bootstrap remains enabled,' and the commit diff shows the production default for REQUIRE_USER_IN_DB is true (the bootstrap path requires it to be false, a documented development setting). No EPSS score, no CISA KEV listing, and no POC were provided in the input, so there is no public evidence of active exploitation or weaponization - this is a high-CVSS issue whose real risk is concentrated in default/development deployments that never rotated the shipped JWT_SECRET_KEY. CONFLICT TO NOTE: CVSS implies default-configuration mass exploitability (PR:N/AC:L), while the description's 'while ... remains configured/enabled' wording and the production REQUIRE_USER_IN_DB=true default imply a config-dependent subset of installs - verify your own REQUIRE_USER_IN_DB and JWT_SECRET_KEY values rather than assuming universal exposure.

An attacker who knows the publicly shipped JWT_SECRET_KEY from config.py/.env.example crafts an HS256 JWT whose subject equals PLATFORM_ADMIN_EMAIL and sends it to the gateway, which verify_jwt_token() accepts and get_current_user() promotes to a platform administrator without any database account. No POC was provided in the input, but the hardcoded key and documented bootstrap logic make exploitation straightforward where REQUIRE_USER_IN_DB is false. Because the forgery depends only on the static key, the access persists through password rotation, account deletion, and session revocation.