CVE-2026-90942 in Casdoor
Summary
by MITRE • 09/14/2026
Casdoor through 4.4.0 fails to properly mask the instance-wide built-in certificate private key in /api/get-certs and /api/get-cert endpoints, allowing organization administrators to retrieve it. Attackers can use the exposed private key to forge JWT tokens for any user in any organization, including global administrators.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Casdoor versions up to 4.4.0 represents a critical failure in access control and sensitive data handling mechanisms within the authentication service's API layer. Specifically, the endpoints /api/get-certs and /api/get-cert are designed to retrieve certificate information for organizational use; however, they erroneously include the instance-wide built-in private key alongside public certificates when accessed by organization administrators. This design flaw violates fundamental security principles regarding the separation of duties and the protection of cryptographic material, as private keys must never be exposed through administrative interfaces intended for non-privileged users or even privileged users who do not require direct access to root-level infrastructure secrets. The exposure occurs because the API response serialization process fails to filter out sensitive fields before transmission, allowing any user with organization administrator privileges to extract a key that is shared across all organizations within the Casdoor instance.
From an operational perspective, this vulnerability has severe implications for the integrity and confidentiality of the entire authentication ecosystem managed by Casdoor. Since the private key in question is used to sign JSON Web Tokens (JWTs), possession of this key effectively grants an attacker the ability to forge valid tokens for any user account within any organization hosted on that instance. This capability bypasses all standard authentication mechanisms, allowing unauthorized access with arbitrary privileges. An adversary could impersonate global administrators, escalate their own permissions by forging admin-level tokens, or perform actions as legitimate users without detection through traditional login logs. The impact extends beyond simple data theft to a complete compromise of trust within the identity provider, potentially leading to widespread lateral movement and persistence in connected downstream applications that rely on Casdoor for authentication validation.
This flaw aligns with CWE-201: Exposure of Sensitive Information Through an Endpoint, as it involves the unintended disclosure of sensitive system information via API responses. Furthermore, the exploitation technique maps directly to MITRE ATT&CK Tactic TA0004 (Privilege Escalation) and specifically Technique T1528: Steal Application Access Token, where attackers leverage compromised credentials or keys to forge tokens for unauthorized access. The ability to create arbitrary JWTs also relates to CWE-347: Improper Verification of Cryptographic Signature if the downstream services fail to validate that the token was signed by a trusted key they expect, although in this case, the attacker possesses the legitimate signing key, making signature verification pass successfully.
Mitigation strategies must prioritize immediate remediation through software updates and architectural adjustments. The primary solution is to upgrade Casdoor to version 4.4.1 or later, where this endpoint behavior has been corrected to exclude private keys from API responses regardless of user role. In environments where upgrading is not immediately feasible, administrators should implement strict network-level access controls to restrict visibility of these endpoints to only the most privileged system operators who require direct infrastructure management, ideally behind a firewall or reverse proxy with IP whitelisting. Additionally, organizations should rotate all JWT signing keys and invalidate existing tokens across all affected instances upon detection of potential exposure. Long-term architectural improvements include implementing strict role-based access control (RBAC) policies that separate administrative functions from certificate retrieval operations and ensuring that sensitive cryptographic material is stored in secure hardware modules or vaults rather than being serialized into standard API responses accessible by application-level administrators.