CVE-2025-49602 in EJBCA
Summary
by MITRE • 10/30/2026
An issue was discovered in Keyfactor EJBCA 9. When an administrator is removed from its administrator role while having a valid TLS session, EJBCA may, in certain circumstances, cache authentication for longer than the configured maximum time (default: 30 seconds), which results in the former administrator retaining access that they should no longer have.
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 within Keyfactor EJBCA version 9 represents a critical session management flaw that undermines the principle of least privilege and immediate revocation of administrative privileges. This issue specifically targets the authentication caching mechanism employed by the application when an administrator's role is revoked while they maintain an active Transport Layer Security connection to the system. In standard security operations, the removal of an admin account or role should result in the immediate invalidation of all associated sessions to prevent unauthorized access. However, due to a logic error in how EJBCA handles session validation against cached authentication tokens, the application fails to check for updated permission states during the lifespan of existing TLS sessions that were established prior to the revocation event.
Technically, this flaw stems from an excessive caching duration for authentication data relative to the configured maximum time limit, which defaults to thirty seconds but can be extended depending on system configuration and specific operational circumstances. When a user is demoted or removed from the administrator group, the backend database reflects these changes immediately. Yet, the application layer continues to serve requests based on stale cached credentials that have not yet expired according to their original creation timestamp rather than checking against real-time role assignments. This discrepancy allows the former administrator to execute privileged operations through the lingering valid TLS session, effectively bypassing access control mechanisms designed to restrict such actions to current authorized personnel only.
The operational impact of this vulnerability is severe for organizations relying on EJBCA for public key infrastructure management and certificate lifecycle automation. An attacker who has compromised an administrative account or gained physical or logical access to a workstation used by a departing employee could exploit this window of opportunity to perform sensitive tasks such as issuing new certificates, modifying trust stores, or altering system configurations without detection. Since the session appears valid from the perspective of the web server and application logic until it naturally times out based on its initial creation time rather than current policy enforcement points, traditional audit logs may not immediately flag anomalous behavior if the attacker operates within normal parameters during this grace period. This creates a significant risk for compliance frameworks that require strict separation of duties and immediate revocation capabilities upon personnel changes or security incidents.
From an industry standard perspective, this vulnerability aligns with CWE-613, which describes insufficient session expiration, as well as aspects of CWE-284 regarding improper access control where authorization checks are not performed against the most current state of user permissions. In terms of the MITRE ATT&CK framework, this behavior facilitates lateral movement and privilege escalation by allowing an actor to maintain persistence in a privileged role despite explicit de-provisioning efforts. It also relates to T1078, Valid Accounts, as it allows continued use of legitimate credentials for unauthorized purposes after their intended privileges have been withdrawn.
Mitigation strategies must focus on ensuring that session validation is tightly coupled with real-time authorization checks rather than relying solely on cached authentication tokens. Administrators should verify if any patches or updates from Keyfactor address this specific caching logic error, as vendor-supplied fixes typically involve modifying the session management layer to invalidate sessions immediately upon role changes. In the interim, organizations can implement compensating controls such as reducing the maximum allowed TLS session timeout duration to minimize the window of exposure. Additionally, enforcing strict monitoring and alerting on administrative actions performed by accounts that have recently undergone status changes can help detect exploitation attempts. Regular audits of active sessions against current user roles in the identity provider or database layer are also recommended to identify any lingering unauthorized access before it leads to broader compromise.