CVE-2025-62819 in EJBCA
Summary
by MITRE • 11/02/2026
Keyfactor EJBCA through 9.3.3 performs insufficient authorization checks when self-renewing a client certificate via the RA (Registration Authority) User Interface. This allows a remote user, authenticated with a valid client certificate, to renew their certificate even if the end entity status and/or profile settings should deny renewal. The attacker must have a valid TLS client certificate, and must be authorized to use the RA User Interface, either with the certificate, or via a role membership for PublicAccessAuthenticationToken.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in Keyfactor EJBCA versions through 9.3.3 represents a critical failure in access control logic within the Registration Authority user interface component of the software. This flaw specifically manifests during the automated self-renewal process for client certificates, where the system fails to adequately verify whether the requesting entity is permitted to perform this action based on its current status or assigned profile settings. The core technical deficiency lies in the authorization checks performed by the server-side logic when processing renewal requests initiated through the RA interface. Instead of strictly enforcing the constraints defined in the end-entity's configuration, such as revocation status or specific profile restrictions that prohibit renewal, the application proceeds with the certificate issuance process if it receives a valid authentication token derived from a TLS client certificate. This indicates a breakdown in the separation between authentication and authorization mechanisms, allowing an authenticated user to bypass administrative controls designed to restrict certificate lifecycle operations.
From a technical perspective, this vulnerability is classified under CWE-269, which denotes Improper Control of Interaction with Multiple Entities or CWE-862, Missing Authorization, depending on the specific implementation details of how the profile settings are ignored. The attacker's prerequisites for exploiting this flaw are relatively straightforward but require prior access to the system. Specifically, an adversary must possess a valid TLS client certificate that is recognized by EJBCA and must also have been granted explicit authorization to use the RA User Interface. This authorization can be achieved either through direct association with the client certificate or via role membership for PublicAccessAuthenticationToken. Once these conditions are met, the attacker can submit renewal requests that would normally be rejected due to policy violations, such as attempting to renew a certificate associated with an end entity marked as revoked or suspended, or one belonging to a profile explicitly configured to disallow self-renewal operations.
The operational impact of this vulnerability is significant for organizations relying on EJBCA for their Public Key Infrastructure management. By allowing unauthorized renewal of certificates, the attacker can effectively extend the validity period of compromised or decommissioned credentials without proper oversight from security administrators. This undermines the integrity of the certificate lifecycle and complicates incident response efforts, as revoked or expired certificates may appear active in logs and systems that rely on EJBCA for validation services. Furthermore, it allows attackers to maintain persistent access using stale credentials that should have been invalidated by existing policies. In environments where automated renewal is critical for service continuity, this flaw could lead to the proliferation of unmanaged or improperly scoped certificates, increasing the attack surface and potentially facilitating lateral movement within a network if these certificates are used for mutual TLS authentication between services.
To mitigate this risk, administrators should immediately apply any available patches from Keyfactor that address the authorization logic in the RA User Interface renewal module. In cases where patching is not immediately feasible, organizations can implement compensating controls by restricting access to the RA interface through network-level firewalls or reverse proxies, ensuring only trusted IP addresses can reach the endpoint. Additionally, reviewing and tightening role-based access control policies within EJBCA can help limit which users are authorized for PublicAccessAuthenticationToken privileges. Regular audits of end-entity statuses and profile configurations should also be conducted to ensure that automated renewal processes align with current security postures. Monitoring logs for unusual patterns in certificate renewals, particularly those involving entities with restricted profiles or revoked status, can aid in early detection of exploitation attempts before significant damage occurs. This vulnerability highlights the importance of rigorous validation at every stage of cryptographic operations within enterprise PKI systems to prevent privilege escalation through logical flaws rather than code execution vulnerabilities.