CVE-2026-75936 in ion-java exposes a design failure that goes beyond a typical decompression bomb vulnerability. The library shipped with GZIP auto-decompression enabled by default, and critically, upgrading to the patched version 1.12.0 does not automatically close the vulnerability—it merely provides a configuration option (withGzipDecompressionEnabled) that developers must explicitly set. Organizations that apply the upgrade without reconfiguring their code remain vulnerable while believing they've remediated the issue. This creates a dangerous false sense of resolution that satisfies automated scanners but leaves the exploitation path intact.
The Ion binary format compounds this risk through opacity. Unlike text formats where compressed content is visible, binary Ion documents with embedded GZIP are invisible to casual inspection. Developers accepting Ion from external sources may not realize they're handing their parser compressed data that will auto-decompress without resource limits.
The EPSS score of 0.00441 is a poor proxy for actual exposure. As a library dependency, ion-java propagates through dozens of downstream applications via transitive dependency chains. Applications that bundle a library which bundles ion-java inherit the vulnerability with no mechanism to configure around it at their layer. This second-order blast radius is invisible to dependency scanners and uncountable from the outside.
Immediate actions: verify whether your code explicitly calls withGzipDecompressionEnabled and sets it to false, or configures an appropriate decompression buffer limit. Do not assume the 1.12.0 upgrade alone resolves the issue. If you consume Ion from untrusted sources, disable auto-decompression by default. Audit your full dependency tree for transitive ion-java exposure—this vulnerability may be present in code you don't directly depend on but that your dependencies pull in.