Apache CXF CVE-2026-78384

Exploitation requires the target application to invoke CompressionUtils.inflate() on attacker-controlled data via one of two specific CXF paths: (1) JWE decryption with the 'zip=DEF' compression header set - e.g. a JoseSessionTokenProvider configured with RSA-OAEP key wrap - or (2) SAML token inflation over the HTTP redirect or POST binding. No authentication, valid key, or valid signature is required because decompression runs before/independent of trust validation (consistent with PR:N). The key LIMITING factor is configuration/deployment: CXF instances that do not expose JWE with DEFLATE compression or SAML binding inflation are not reachable through this flaw, so it is not universal to all CXF installs. The fix adds a configurable cap (default 10 MiB, org.apache.cxf.compression-max-inflated-size) that aborts with DataFormatException when exceeded.

This is a remote, unauthenticated, low-complexity data-amplification (decompression bomb) flaw (CWE-409) in Apache CXF. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) confirms it is reachable by remote attackers with no authentication (PR:N) and no user interaction, and critically the description notes decompression happens BEFORE/independent of trust validation - so no valid signature, key, or session is needed. However, the signals conflict on impact: the vendor vector encodes C:H/I:N/A:N (confidentiality impact), yet the CWE-409 classification, the 'Denial Of Service' tag, and the description (KB payload expanding to GB on the heap → memory exhaustion) all point to an AVAILABILITY impact, not confidentiality - the C:H appears mislabeled and should be A:H. Despite the easy-to-reach nature, real-world urgency is tempered: EPSS is only 0.16% (4th percentile), there is no CISA KEV listing and no public exploit identified, and exploitation is gated on the application actually exposing a vulnerable code path (JWE decryption with zip=DEF compression, or SAML redirect/POST token inflation). Net: a legitimate patch-worthy DoS exposure for CXF deployments using JOSE/JWE compression or SAML token inflation, but not an emergency - treat as a standard-priority patch rather than an actively-exploited critical.

A remote, unauthenticated attacker sends a small (~KB) crafted message containing a DEFLATE-compressed payload to a CXF endpoint that performs JWE decryption with zip=DEF (e.g. a JoseSessionTokenProvider using RSA-OAEP key wrap) or that inflates SAML tokens over the redirect/POST binding. Because decompression occurs before any trust/signature validation, CompressionUtils.inflate() expands the payload to gigabytes on the heap, exhausting memory and crashing or hanging the service. No public exploit code has been identified, but the attack requires no special tooling beyond crafting a standard zip bomb.