CVE-2025-13877 Overview
CVE-2025-13877 is a hard-coded cryptographic key vulnerability [CWE-320] in NocoBase versions up to 1.9.4 and 2.0.0-alpha.37. The flaw resides in the JWT Service component, specifically in nocobase/packages/core/auth/src/base/jwt-service.ts, where the API_KEY argument uses a hard-coded cryptographic key. Attackers can exploit the issue remotely without authentication, though the attack complexity is high. A public proof-of-concept exists, but the vendor did not respond to disclosure attempts.
Critical Impact
Attackers who recover the hard-coded key can forge JSON Web Tokens (JWTs) and impersonate legitimate users of the NocoBase platform.
Affected Products
- NocoBase versions up to and including 1.9.4
- NocoBase 2.0.0-alpha.37 and earlier alpha releases
- Deployments using the default jwt-service.ts configuration
Discovery Timeline
- 2025-12-02 - CVE-2025-13877 published to the National Vulnerability Database
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-13877
Vulnerability Analysis
The vulnerability originates in the NocoBase authentication package. The jwt-service.ts file implements JSON Web Token (JWT) signing and verification for the platform. The service accepts an API_KEY argument that references a hard-coded cryptographic secret rather than a value generated per deployment. Because JWTs rely on secret confidentiality for integrity, any exposure of this secret allows token forgery.
Exploitation is remote and requires no authentication or user interaction. Confidentiality, integrity, and availability impacts are each rated low individually, but successful key recovery can escalate the impact through forged authentication tokens. A public proof-of-concept has been published on GitHub Gist.
Root Cause
The root cause is the embedding of a static cryptographic key inside the source code of the JWT service. When multiple deployments reuse the same shared secret, an attacker who obtains the key from the public repository can generate valid tokens for any instance that has not overridden the default. This pattern violates cryptographic hygiene requirements under [CWE-320] Key Management Errors.
Attack Vector
An attacker inspects the NocoBase source repository to extract the hard-coded API_KEY value. Using the recovered secret, the attacker crafts a signed JWT with arbitrary claims — such as a privileged user identifier — and submits it to the target NocoBase API. The server validates the token using the same static key and accepts the forged identity. The high attack complexity reflects the need to correctly enumerate valid claim structures and target deployments that have not rotated the default secret.
See the GitHub Gist PoC and VulDB entry #334033 for further technical detail.
Detection Methods for CVE-2025-13877
Indicators of Compromise
- Authentication events using JWTs signed with the default hard-coded API_KEY value present in the NocoBase repository.
- Unexpected API sessions originating from external IP addresses for privileged NocoBase accounts.
- JWT payloads containing claim values or issuance timestamps that do not correspond to legitimate login flows.
Detection Strategies
- Audit the runtime NocoBase configuration to confirm whether API_KEY was overridden from the repository default.
- Inspect authentication logs for tokens whose iat and exp claims do not align with recorded user login activity.
- Correlate JWT usage against source IP reputation and geographic baselines to surface unauthorized session use.
Monitoring Recommendations
- Forward NocoBase application logs to a centralized analytics platform for continuous review of authentication events.
- Monitor for repeated failed and successful authentications tied to the same account across disparate network locations.
- Alert on administrative actions performed by accounts that have not recently completed an interactive login.
How to Mitigate CVE-2025-13877
Immediate Actions Required
- Replace the default API_KEY in nocobase/packages/core/auth/src/base/jwt-service.ts with a cryptographically random secret unique to each deployment.
- Invalidate all existing JWTs by rotating the signing key and forcing users to reauthenticate.
- Restrict administrative endpoints to trusted networks until remediation is complete.
Patch Information
At the time of publication, the vendor did not respond to disclosure attempts, and no official patch is referenced in the NVD entry. Administrators should track the NocoBase project for future releases addressing hard-coded key handling and apply updates as they become available.
Workarounds
- Override the JWT signing secret through environment variables at deployment time rather than relying on source defaults.
- Place NocoBase behind an authenticating reverse proxy that enforces an additional identity check independent of the JWT.
- Reduce JWT token lifetime to limit the window in which a forged token remains valid.
# Configuration example: set a strong random JWT secret at deployment
export API_KEY="$(openssl rand -hex 64)"
# Restart the NocoBase service so the new key takes effect
systemctl restart nocobase
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
