GHSA-2mrg-gjxq-2gvr

Summary

PhpSpreadsheet's Gnumeric reader reads attacker-supplied .gnumeric files into memory and, when the file starts with gzip magic bytes, calls gzdecode() on the full compressed contents without enforcing a decompressed-size limit. A very small compressed .gnumeric file can expand to data larger than the PHP memory limit and crash the process during Gnumeric::canRead() before the file is rejected or fully parsed.

This is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.

Vulnerability details

Gnumeric::canRead() invokes gzfileGetContents() before deciding whether the file is a valid Gnumeric spreadsheet:

• src/PhpSpreadsheet/Reader/Gnumeric.php:80-90 calls $this->gzfileGetContents($filename) from canRead().
• src/PhpSpreadsheet/Reader/Gnumeric.php:105-115 calls canRead() and then reads the expanded contents again for worksheet-name listing.
• src/PhpSpreadsheet/Reader/Gnumeric.php:253-265 calls canRead() and then reads the expanded contents again for full loading.

The vulnerable expansion is in gzfileGetContents():

• src/PhpSpreadsheet/Reader/Gnumeric.php:187-190 reads the entire input file into $contents with file_get_contents().
• src/PhpSpreadsheet/Reader/Gnumeric.php:192-197 detects gzip magic bytes and calls gzdecode($contents) without a decompressed-size cap.
• src/PhpSpreadsheet/Reader/Gnumeric.php:204-205 scans the expanded data only after decompression has already completed.

Because decompression occurs before XML scanning or structural validation, a tiny gzip payload can force large memory allocation even if the resulting XML is meaningless or invalid.

Impact

A small .gnumeric upload can crash a PHP worker during spreadsheet type detection or import. This can cause denial of service in web applications, queue workers, preview services, document converters, or any service...