CVE-2026-119597 in OpenDeepWiki
Summary
by MITRE • 10/30/2026
OpenDeepWiki through 2.0.6 contains a hard-coded JWT signing key vulnerability that allows unauthenticated attackers to forge administrator tokens using the publicly known Jwt:SecretKey in appsettings.json. Attackers can mint HS256 bearer tokens with an Admin role claim to access /api/admin endpoints and control users, roles, repositories, settings, and API keys.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in OpenDeepWiki versions through 2.0.6 constitutes a critical authentication bypass resulting from the improper storage of cryptographic secrets. Specifically, the application utilizes a hard-coded JSON Web Token signing key within its configuration file, appsettings.json. This practice violates fundamental security principles regarding secret management, as it exposes sensitive credentials to anyone with read access to the source code or deployed artifacts. The specific flaw allows unauthenticated attackers to derive the exact symmetric key used for token generation and verification. By leveraging this publicly known Jwt:SecretKey, an attacker can independently generate valid HS256 signed JSON Web Tokens without any interaction with the application's legitimate authentication mechanisms.
From a technical perspective, the exploitation of this vulnerability relies on the properties of HMAC-SHA256 signing algorithms commonly used in JWT implementations. Since the secret key is static and known to all users who can access the configuration files or repository history, an attacker does not need to perform any complex cryptographic attacks such as timing analysis or brute force. Instead, they simply construct a token payload containing an Admin role claim, sign it using the exposed key, and present this forged bearer token to the application's API endpoints. The server, operating under the assumption that any validly signed token is authentic, accepts these malicious tokens as legitimate administrative credentials. This effectively nullifies the authentication layer for all protected routes that rely on JWT validation.
The operational impact of this vulnerability is severe due to the high privilege level granted by the forged tokens. Once an attacker successfully mints a bearer token with Admin role claims, they gain unrestricted access to sensitive /api/admin endpoints. This grants full control over critical application components including user management, where attackers can create, modify, or delete user accounts and assign arbitrary roles. Furthermore, administrators have authority over repositories, allowing for the modification of source code storage structures, as well as access to global settings that dictate application behavior. The ability to manage API keys means an attacker can also generate new credentials for other services, potentially leading to broader infrastructure compromise. This level of access enables data exfiltration, persistence through backdoor accounts, and potential lateral movement within the associated network environment.
This vulnerability maps directly to CWE-798: Use of Hard-coded Credentials in the Common Weakness Enumeration framework, which highlights the risk of embedding secrets directly into source code or configuration files rather than using secure vaults or environment variables with restricted access controls. In terms of offensive security tactics, this aligns with MITRE ATT&CK technique T1078: Valid Accounts, specifically involving the misuse of legitimate credentials to bypass authentication mechanisms. The exploitation path also reflects aspects of T1528: Steal Application Access Token, where an attacker obtains a token that provides access to cloud or application resources without needing traditional login procedures.
To mitigate this vulnerability and prevent similar issues in future deployments, it is imperative to remove the hard-coded secret from appsettings.json immediately. The signing key should be generated using a cryptographically secure random number generator with sufficient entropy and stored securely outside of version control systems. Recommended practices include utilizing environment variables for configuration secrets or integrating with dedicated secret management solutions such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These services provide mechanisms for automatic rotation, access auditing, and restricted permissions that prevent unauthorized reading of sensitive keys. Additionally, implementing a key revocation strategy is essential; since the current hard-coded key has likely been exposed in public repositories, it must be considered compromised. The application should support dynamic key updates so that previously issued tokens can be invalidated upon secret rotation, forcing all active sessions to re-authenticate with new credentials derived from the secure store.