CVE-2026-78323: JSS Information Disclosure Vulnerability

CVE-2026-78323 Overview

CVE-2026-78323 is an improper certificate validation flaw [CWE-295] in JSS (Java Security Services). The JSSTrustManager class does not verify Network Security Services (NSS) trust flags when validating Certificate Authority (CA) certificates. Certificates stored in the NSS database without the TRUSTED_CA flag are accepted as trust anchors for Transport Layer Security (TLS) connections. In non-default configurations where certificate revocation checking is disabled, a man-in-the-middle attacker can forge certificates that Public Key Infrastructure (PKI) client connections will accept as valid.

Critical Impact
A network-positioned attacker can impersonate trusted TLS endpoints when revocation checking is disabled, compromising confidentiality of PKI client traffic.

Affected Products

JSS (Java Security Services)
Red Hat products bundling vulnerable JSS releases
PKI clients relying on JSSTrustManager for TLS trust validation

Discovery Timeline

2026-08-24 - CVE-2026-78323 published to the National Vulnerability Database (NVD)
2026-08-24 - Last updated in NVD database

Technical Details for CVE-2026-78323

Vulnerability Analysis

JSS provides a Java interface to NSS cryptographic services and manages TLS trust decisions through the JSSTrustManager class. The trust manager consults the NSS certificate database to determine whether a presented CA certificate can serve as a trust anchor. NSS attaches trust flags to each certificate entry indicating the purposes for which that certificate is authorized, such as CT (trusted CA) or C (trusted client CA).

The flaw is that JSSTrustManager reads certificates from the NSS database but does not inspect their trust flags. Any certificate present in the store is treated as a valid trust anchor, even when its flags explicitly do not grant CA authority. Operators frequently import intermediate, peer, or utility certificates without TRUSTED_CA flags, expecting them to be inert for trust decisions.

Exploitability depends on configuration. When revocation checking through Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) is enabled, forged certificates typically fail revocation validation. When revocation checking is disabled, no secondary control blocks the forged chain.

Root Cause

The root cause is missing enforcement of NSS trust flag semantics during trust anchor selection. JSSTrustManager conflates certificate presence in the NSS database with authorization to sign server or client certificates, violating the trust model NSS provides.

Attack Vector

An attacker in a network position between a JSS-based PKI client and its intended server presents a TLS certificate signed by any certificate loaded in the target's NSS database, regardless of trust flag configuration. If the client operator has disabled revocation checking, JSSTrustManager accepts the chain and completes the TLS handshake with the attacker.

The vulnerability requires a non-default configuration and a network foothold suitable for traffic interception, which limits opportunistic exploitation. See the Red Hat CVE-2026-78323 Advisory and Red Hat Bug Report #2521775 for technical details.

Detection Methods for CVE-2026-78323

Indicators of Compromise

Unexpected certificates present in the NSS database without TRUSTED_CA flags but appearing in successful TLS handshakes
PKI client logs showing TLS sessions to unfamiliar endpoints or IP addresses
Configuration files where OCSP or CRL checking has been disabled for JSS-backed clients

Detection Strategies

Audit NSS databases with certutil -L -d <dbdir> and review the trust flag column for every stored certificate
Inventory JSS client configurations to identify hosts where revocation checking is not enforced
Compare observed TLS peer certificates against the expected issuer set for each PKI service

Monitoring Recommendations

Log all TLS handshake outcomes for PKI client processes and alert on issuer changes
Monitor network egress from PKI clients for connections to unapproved destinations
Track changes to NSS database files (cert9.db, key4.db) and JSS configuration properties

How to Mitigate CVE-2026-78323

Immediate Actions Required

Apply vendor updates for JSS as they become available through the Red Hat CVE-2026-78323 Advisory
Re-enable OCSP or CRL revocation checking on any JSS-based PKI client where it has been disabled
Remove certificates from NSS databases that do not require presence for trust or operational reasons

Patch Information

Refer to the Red Hat CVE-2026-78323 Advisory for fixed package versions and errata. The upstream fix modifies JSSTrustManager to consult NSS trust flags and reject certificates that lack the TRUSTED_CA designation when used as trust anchors.

Workarounds

Enable certificate revocation checking on all JSS clients to prevent forged certificates from completing TLS validation
Restrict NSS databases to contain only certificates with correctly assigned trust flags, purging unused entries
Enforce network segmentation and mutual TLS to reduce opportunities for man-in-the-middle positioning against PKI clients

bash

# Inspect NSS trust flags and re-mark certificates appropriately
certutil -L -d /etc/pki/nssdb
certutil -M -d /etc/pki/nssdb -n "Example CA" -t "CT,C,C"

# Remove an unintended certificate from the NSS database
certutil -D -d /etc/pki/nssdb -n "Untrusted Cert"