CVE-2026-59932 is a denial-of-service vulnerability in PhpSpreadsheet's Gnumeric file reader, but the interesting part is where it strikes: inside the canRead() method, before any application-layer security controls engage. When an application calls canRead() to validate an uploaded file, the Gnumeric reader checks for gzip magic bytes and immediately decompresses the entire content. If the compressed file expands beyond PHP's memory_limit, the process terminates abruptly—before the application can reject the file, log the attempt, or take any defensive action.
This matters because applications that use canRead() as a pre-validation gate are not protected; they are the target. The method name implies a cheap, exploratory check—something like reading file headers. Instead, it performs unbounded decompression of untrusted content. This is an API design failure: the library presents a safety checkpoint that actually performs the most dangerous possible operation on unvalidated input. Developers using PhpSpreadsheet as intended, following documentation that suggests canRead() as the entry point for file validation, are systematically led into this trap.
The vulnerability exists across PhpSpreadsheet versions 1.x, 2.x, 3.x, and 4.x/5.x, which indicates the decompress-then-limit pattern was never audited systematically during development. This raises a critical question: does the patched version implement a universal decompression size budget that would protect other format readers, or is this a targeted fix for Gnumeric only?
If it's targeted, you should assume every other format reader in PhpSpreadsheet that invokes decompression carries the same latent vulnerability. The library contains readers for numerous dead or rarely-used formats—Lotus, Quattro Pro, Sylk, Xbase, and others—whose code paths have likely received minimal scrutiny. Abandoned format handlers are not audited code; they are technical debt that accumulates assumptions the runtime has outgrown.
What to check: review your application's use of canRead() and verify whether any downstream security controls assume it represents a safe, exploratory operation. Consider implementing your own file size or expansion ratio checks before passing files to PhpSpreadsheet. If you maintain systems running unpatched PhpSpreadsheet versions, treat the dead-format readers as higher-risk until you confirm the patch is architectural rather than targeted.