Description

A flaw was found in JSS (Java Security Services). The JSSTrustManager class does not verify NSS trust flags when validating CA certificates, allowing certificates present in the NSS database without TRUSTED_CA flags to be accepted as trust anchors for TLS connections. In non-default configurations where certificate revocation checking is disabled, this could allow a man-in-the-middle attacker to forge certificates accepted by PKI client connections.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-24T12:16:56.250Z",
  "pubdate": "2026-08-24T12:16:56.250Z",
  "executiveSummary": "A validation flaw exists in Java Security Services (JSS), specifically within the JSSTrustManager class, which fails to properly verify NSS trust flags during CA certificate validation. This vulnerability allows certificates present within the NSS database that lack the necessary TRUSTED_CA flags to be improperly accepted as valid trust anchors for TLS connections.\nThe primary impact of this vulnerability is the potential bypass of certificate validation controls. In non-default configurations where certificate revocation checking is explicitly disabled, a man-in-the-middle (MitM) attacker can successfully forge and present certificates that are incorrectly accepted by PKI client connections.\nThe affected product is Java Security Services (JSS), specifically involving the JSSTrustManager component. The risk implication involves the compromise of TLS connection integrity and confidentiality.\nTo exploit this vulnerability, an attacker requires network positioning capable of performing a man-in-the-middle attack against TLS connections. Specific exploitation requirements include a non-default system configuration where certificate revocation checking is disabled, enabling the acceptance of untrusted CA certificates lacking proper NSS trust flags.",
  "technicalDetails": "The vulnerability resides in the JSSTrustManager class of Java Security Services (JSS), which is responsible for managing trust decisions during TLS handshakes and PKI client connections.\nThe root cause of the flaw is the inadequate validation logic implemented when processing certificates against the Network Security Services (NSS) database. Specifically, JSSTrustManager fails to verify the presence of mandatory NSS trust flags, such as the TRUSTED_CA flag, when evaluating CA certificates to be used as trust anchors.\nUnder default operating conditions, mitigating controls such as certificate revocation checking may prevent successful exploitation. However, in non-default configurations where certificate revocation checking is disabled, the system relies entirely on the flawed trust anchor validation performed by JSSTrustManager.\nThe step-by-step attack flow occurs as follows: First, an attacker positions themselves as a man-in-the-middle on the network path between the PKI client and the server. Second, the attacker intercepts the TLS handshake and presents a forged certificate or a certificate signed by an intermediate CA present in the NSS database that lacks the explicit TRUSTED_CA designation. Third, the JSSTrustManager processes the certificate chain and erroneously accepts the untrusted certificate as a valid trust anchor due to the missing NSS trust flag verification. Finally, the TLS connection is established successfully, allowing the attacker to intercept, read, or modify encrypted traffic traversing the connection, resulting in a complete compromise of transport layer security for the affected PKI client connections."
}