Skip to content
Friday, October 16, 2026AboutContactRSS
IBM 1.0.2 Fixes MCP Context Forge JWT Flaw Allowing Persistent Admin Access Without Credentials
Vulnerabilities

IBM 1.0.2 Fixes MCP Context Forge JWT Flaw Allowing Persistent Admin Access Without Credentials

IBM released version 1.0.2 to address a critical flaw that lets attackers forge admin tokens without credentials in older builds.

Key points

  • IBM issued version 1.0.2 to fix CVE-2026-53709, a critical vulnerability in MCP Context Forge.
  • The flaw allows remote attackers to create administrator tokens using a hardcoded JWT secret.
  • Forged access persists even after password changes or account deletions in affected versions.

IBM has released version 1.0.2 of its MCP Context Forge platform to address a critical security vulnerability that allows unauthenticated remote attackers to gain full administrative control. The issue affects all versions prior to 1.0.2 and stems from a hardcoded secret key included in the default configuration files.

Why is this vulnerability considered critical?

The National Vulnerability Database assigns CVE-2026-53709 a CVSS score of 9.8, rating it as critical. The flaw involves multiple weaknesses, including improper authentication and hardcoded credentials. Attackers can use the known secret to sign JSON Web Tokens that the system accepts as valid, bypassing standard login requirements entirely.

How does the attack mechanism work?

Prior to version 1.0.2, the mcpgateway/config.py and .env.example files ship with a known JWT_SECRET_KEY. The verify_jwt_token() function accepts HS256 tokens signed with this key. When REQUIRE_USER_IN_DB is false, get_current_user() creates a platform administrator if the token subject matches PLATFORM_ADMIN_EMAIL, granting immediate administrative privileges without a database account.

What is the operational impact?

Forged administrative access survives standard remediation attempts such as password rotation, account deletion, and session revocation. This persistence allows attackers to maintain control for disclosure, modification, or service disruption. The vulnerability remains active as long as the vulnerable signing key is configured and the platform-admin bootstrap feature is enabled.

Questions to ask your suppliers

Security teams should immediately verify whether any third-party integrations or managed services utilize MCP Context Forge versions prior to 1.0.2. Ask suppliers if they have independent monitoring for anomalous administrative token generation or unexpected configuration changes. Determine who within the organization owns the deployment lifecycle for this gateway and whether they have confirmed the patch status. Ensure incident response plans account for persistent access that survives credential resets, and request evidence that suppliers have validated their environments against this specific CVE.

What to do and how to stay safe: IBM

  • Inventory all instances of IBM MCP Context Forge and verify they are running version 1.0.2 or later.
  • Review logs for any unexpected administrative token creation or access patterns in the period before patching.
  • Rotate any secrets or credentials that may have been exposed during the window of vulnerability.
  • Monitor for unauthorized configuration changes or new administrative accounts created via token forgery.

Step-by-step guide: Vulnerability Scanning: What It Finds and What It Misses

General security guidance from the TechSec Feed newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of MCP Context Forge are affected?

All versions prior to 1.0.2 are affected by CVE-2026-53709.

Is there a fix available?

Yes, IBM released version 1.0.2 which fixes this issue.

Can attackers maintain access after password changes?

Yes, forged access survives password rotation, account deletion, and session revocation.

Sources

  1. CVE Program
IBMMCP Context ForgeCVE-2026-53709JWTCritical

Related stories

EPSS Percentiles: Stop Misreading Your Vulnerability Risk Scores

High EPSS scores predict exploitation likelihood over time, not immediate danger, revealing why prioritization often fails when teams ignore asset context.