Live › vulnerability › CVE-2025-62819
Keyfactor EJBCA through 9.3.3 fails to enforce end entity status and profile rules when a user renews their own client certificate through the RA web interface. An attacker who already holds a valid client certificate can renew it even where renewal should be denied.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 15:24 UTC. All times on this page are UTC.
Organizations running Keyfactor EJBCA 9.3.3 or earlier with the RA User Interface reachable by users who already hold client certificates. Per the description, the attacker needs a valid client certificate and RA UI authorization, either via the certificate or a role membership for PublicAccessAuthenticationToken. Deployments without the RA UI exposed or without such role membership are less exposed; the sources do not say more.
No product ranges from the sources yet.
9.3.3).PublicAccessAuthenticationToken.No fix yet, per the sources.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2025-62819")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.