Apache Tomcat EUVD-2026-105004

Exploitation requires a specific non-default configuration: OpenSSLLifecycleListener must be explicitly enabled and set to FIPS mode, AND FIPS activation must actually fail at runtime (e.g., absent/incompatible FIPS-capable OpenSSL provider). This is strongly limiting - environments not using OpenSSLLifecycleListener, or not requesting FIPS mode, or where FIPS activation succeeds, are entirely unaffected. There is no attacker-triggered network request; the condition is an operator-controlled configuration state plus a startup failure, so realistic impact is confined to organizations with FIPS compliance requirements that experience a silent FIPS activation failure.

This is a low-to-moderate operational security issue, NOT an urgent remote-exploitation priority. No CVSS score was provided by Apache (CVSS: N/A), there is no CISA KEV listing, no EPSS score supplied, and no public exploit identified - so there is no signal of active or imminent exploitation. The vulnerability is a 'fail open' design flaw (CWE-636): when OpenSSLLifecycleListener is configured for FIPS mode and FIPS activation fails, Tomcat logs an error but silently continues serving TLS via JSSE in non-FIPS mode. There is no attacker-initiated exploit step here; the risk is that an operator who believes they have a FIPS-validated cryptographic posture is in fact running non-FIPS crypto, undermining compliance (e.g., FedRAMP/FISMA) and potentially permitting weaker cipher usage. The 'Information Disclosure' tag overstates the direct impact - the flaw does not itself disclose data, but a non-FIPS TLS stack could weaken confidentiality guarantees. Because no CVSS vector was published, attack vector and privilege requirements cannot be confirmed from input and are inferred from the described configuration dependency; this should be verified against the Apache advisory.

An administrator deploys Tomcat with OpenSSLLifecycleListener set to FIPS mode to meet a compliance mandate; FIPS activation fails at startup (e.g., missing or incompatible FIPS OpenSSL provider), but Tomcat only logs an error and continues serving TLS in non-FIPS JSSE mode. The organization operates believing it is FIPS-compliant while cryptographic operations are not FIPS-validated, and no public exploit is required or known - the exposure is a silent degradation of the intended cryptographic assurance.