CVE-2026-78323 in Certificate System
Summary
by MITRE • 08/24/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/24/2026
The Java Security Services (JSS) library contains a critical validation flaw within the JSSTrustManager class that undermines the integrity of Transport Layer Security (TLS) certificate verification processes. This vulnerability stems from an oversight in how trust anchors are evaluated against the underlying Network Security Services (NSS) database flags. Specifically, when validating Certificate Authority certificates, JSS fails to check for the TRUSTED_CA flag within the NSS database entries. In standard PKI operations, this flag is essential because it explicitly designates a certificate as a trusted root or intermediate authority capable of signing other certificates. By ignoring this attribute, the library incorrectly accepts any certificate present in the NSS store as a valid trust anchor, regardless of whether that certificate was intended for end-entity use rather than CA functions. This behavior deviates from established security protocols and creates a significant gap in the chain-of-trust validation logic.
The operational impact of this flaw is severe, particularly in environments where default configurations have been modified to disable certificate revocation checking. Under normal circumstances, even if an invalid trust anchor were accepted, real-time revocation checks might detect compromised or unauthorized certificates before they are fully trusted. However, when revocation checking is disabled—a common configuration choice for performance optimization or due to connectivity issues with Certificate Revocation List (CRL) distribution points—the absence of the TRUSTED_CA flag check becomes a critical failure point. An attacker positioned in the network path can exploit this by presenting a forged certificate that exists within the NSS database but lacks the proper CA designation. Because JSS does not verify the flag, it accepts this untrusted or misconfigured certificate as valid, thereby establishing a secure session with an entity controlled by the attacker.
This vulnerability directly facilitates man-in-the-middle attacks where sensitive data can be intercepted, modified, or exfiltrated without detection. Since the client application believes it is communicating with a legitimate server validated by a trusted CA, all subsequent encrypted traffic flows through the attacker's infrastructure. The attacker can decrypt, inspect, and re-encrypt communications using their own keys while maintaining the appearance of a secure connection to the end user. This compromises confidentiality, integrity, and potentially availability depending on the nature of the intercepted data or services involved. The risk is amplified in enterprise environments where custom NSS databases are used for internal PKI management, as these often contain numerous certificates that may not all be intended for CA roles but remain accessible within the same store.
From a classification perspective, this issue aligns with CWE-295 Improper Certificate Validation and CWE-347 Improper Verification of Cryptographic Signature, as it involves failing to properly validate the properties required for certificate trust establishment. In terms of adversary tactics, this vulnerability supports MITM techniques described in the ATT&CK framework under T1078 Valid Accounts or more broadly within network interception strategies where valid-looking credentials are used to bypass security controls. To mitigate this risk, organizations should ensure that JSS is updated to versions that enforce strict checking of TRUSTED_CA flags during certificate validation. Additionally, administrators must avoid disabling certificate revocation checks unless absolutely necessary and implement alternative monitoring mechanisms if such configurations remain in place. Regular audits of NSS databases can also help identify certificates that are improperly flagged or stored without appropriate restrictions, reducing the attack surface available to potential adversaries seeking to exploit this trust anchor misconfiguration.