The vulnerability exists in the EJBCA service, version 8.0 Enterprise. Not tested in higher versions. By modifying the ‘Host’ header in an HTTP request, it is possible to manipulate the generated links and thus redirect the client to a different base URL. In this way, an attacker could insert his own server for the client to send HTTP requests, provided he succeeds in exploiting it.

The vulnerability exists in the EJBCA service, version 8.0 Enterprise. By making a small change to the PATH of the URL associated with the service, the server fails to find the requested file and redirects to an external page. This vulnerability could allow users to be redirected to potentially malicious external sites, which can be exploited for phishing or other social engineering attacks.

PrimeKey EJBCA 7.9.0.2 Community allows stored XSS in the End Entity section. A user with the RA Administrator role can inject an XSS payload to target higher-privilege users.

The CMP CLI client in KeyFactor EJBCA before 8.3.1 has only 6 octets of salt, and is thus not compliant with the security requirements of RFC 4211, and might make man-in-the-middle attacks easier. CMP includes password-based MAC as one of the options for message integrity and authentication (the other option is certificate-based). RFC 4211 section 4.4 requires that password-based MAC parameters use a salt with a random value of at least 8 octets. This helps to inhibit dictionary attacks. Because the standalone CMP client originally was developed as test code, the salt was instead hardcoded and only 6 octets long.

In the Keyfactor EJBCA before 8.0.0, the RA web certificate distribution servlet /ejbca/ra/cert allows partial denial of service due to an authentication issue. In configurations using OAuth, disclosure of CA certificates (attributes and public keys) to unauthenticated or less privileged users may occur.

An issue exists in PrimeKey EJBCA before 7.4.3 when enrolling with EST while proxied through an RA over the Peers protocol. As a part of EJBCA's domain security model, the peer connector allows the restriction of client certificates (for the RA, not the end user) to a limited set of allowed CAs, thus restricting the accessibility of that RA to the rights it has within a specific role. While this works for other protocols such as CMP, it was found that the EJBCA enrollment over an EST implementation bypasses this check, allowing enrollment with a valid client certificate through any functioning and authenticated RA connected to the CA. NOTE: an attacker must already have a trusted client certificate and authorization to enroll against the targeted CA.

An issue was discovered in PrimeKey EJBCA 6.x and 7.x before 7.4.1. When using a client certificate to enroll over the EST protocol, no revocation check is performed on that certificate. This vulnerability can only affect a system that has EST configured, uses client certificates to authenticate enrollment, and has had such a certificate revoked. This certificate needs to belong to a role that is authorized to enroll new end entities. (To completely mitigate this problem prior to upgrade, remove any revoked client certificates from their respective roles.)

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. Two Cross Side Scripting (XSS) vulnerabilities have been found in the Public Web and the Certificate/CRL download servlets.

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. A Cross Site Request Forgery (CSRF) issue has been found in the CA UI.

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. It is intended to support restriction of available remote protocols (CMP, ACME, REST, etc.) through the system configuration. These restrictions can be bypassed by modifying the URI string from a client. (EJBCA's internal access control restrictions are still in place, and each respective protocol must be configured to allow for enrollment.)

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. The External Command Certificate Validator, which allows administrators to upload external linters to validate certificates, is supposed to save uploaded test certificates to the server. An attacker who has gained access to the CA UI could exploit this to upload malicious scripts to the server. (Risks associated with this issue alone are negligible unless a malicious user already has gained access to the CA UI through other means, as a trusted user is already trusted to upload scripts by virtue of having access to the validator.)

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. In several sections of code, the verification of serialized objects sent between nodes (connected via the Peers protocol) allows insecure objects to be deserialized.

An issue was discovered in EJBCA before 6.15.2.6 and 7.x before 7.3.1.2. An error state can be generated in the CA UI by a malicious user. This, in turn, allows exploitation of other bugs. This follow-on exploitation can lead to privilege escalation and remote code execution. (This is exploitable only when at least one accessible port lacks a requirement for client certificate authentication. These ports are 8442 or 8080 in a standard installation.)

An issue was discovered in Keyfactor PrimeKey EJBCA before 7.9.0, related to possible inconsistencies in DNS identifiers submitted in an ACME order and the corresponding CSR submitted during finalization. During the ACME enrollment process, an order is submitted containing an identifier for one or multiple dnsNames. These are validated properly in the ACME challenge. However, if the validation passes, a non-compliant client can include additional dnsNames the CSR sent to the finalize endpoint, resulting in EJBCA issuing a certificate including the identifiers that were not validated. This occurs even if the certificate profile is configured to not allow a DN override by the CSR.