high · 8.7 Patched

PhpSpreadsheet ODS Reader: Unbounded number-rows-repeated → CPU & Memory Exhaustion (DoS)

CVE-2026-108359 · GHSA-j2w7-387v-m2rq · published 27 Oct 2026

How serious is it

  • Severity: high, CVSS score 8.7 out of 10.
  • No exploit prediction (EPSS) score yet.
  • Not on the CISA list of exploited vulnerabilities.
  • No public exploit in Exploit-DB.

Is your app affected by CVE-2026-108359?

Paste this prompt into Claude Code, Cursor or any AI coding tool: it runs a free Shippable scan of your project and fixes what it finds. Built with Lovable, Bolt or v0? Scan your live app. Or upload your package file.

Who is affected

  • phpoffice/phpspreadsheet (Packagist) >= 4.0.0, <= 5.9.0
  • phpoffice/phpspreadsheet (Packagist) >= 3.3.0, <= 3.10.7
  • phpoffice/phpspreadsheet (Packagist) >= 2.2.0, <= 2.4.7
  • phpoffice/phpspreadsheet (Packagist) >= 2.0.0, <= 2.1.18
  • phpoffice/phpspreadsheet (Packagist) <= 1.30.6

How to check

  1. Run composer show phpoffice/phpspreadsheet in your project to see the installed version, including copies pulled in by other packages.
  2. Or paste your lockfile into the checker: it lists every package with a known vulnerability, this one included.

How to fix

Copies a prompt for Claude Code, Cursor or Codex: it checks your lockfiles for this and upgrades it.
  1. On >= 4.0.0, <= 5.9.0: Upgrade phpoffice/phpspreadsheet to 5.10.0 or later, commit the lockfile and redeploy.
  2. On >= 3.3.0, <= 3.10.7: Upgrade phpoffice/phpspreadsheet to 3.10.8 or later, commit the lockfile and redeploy.
  3. On >= 2.2.0, <= 2.4.7: Upgrade phpoffice/phpspreadsheet to 2.4.8 or later, commit the lockfile and redeploy.
  4. On >= 2.0.0, <= 2.1.18: Upgrade phpoffice/phpspreadsheet to 2.1.19 or later, commit the lockfile and redeploy.
  5. On <= 1.30.6: Upgrade phpoffice/phpspreadsheet to 1.30.7 or later, commit the lockfile and redeploy.
  6. If a vulnerable version was live, check your logs and rotate the secrets that server could read.

The advisory

## Summary When PhpSpreadsheet loads an OpenDocument Spreadsheet (`.ods`), `Ods::processTableRow()` reads the `table:number-rows-repeated` attribute of a `<table:table-row>` with an unchecked `(int)` cast, then materialises one cell per repeated row. This value is **completely unbounded**, so a **single ~1.4 KB file** can instruct the reader to create up to **millions of cells**, exhausting memory (fatal OOM). No authentication, no special configuration, and the default read filter are required - any application that loads a user-supplied `.ods` is affected. --- ## Affected versions The `number-rows-repeated` expansion has existed in the ODS reader since its inception (pre-dating the current release branches), so all maintained lines are affected. | Branch | Affected | |--------|----------| | 1.x | ≤ 1.30.6 | | 2.0–2.1 | ≤ 2.1.18 | | 2.2–2.4 | ≤ 2.4.7 | | 3.x | ≤ 3.10.7 | | 4.x–5.x | ≤ 5.9.0 (latest) | --- ## Root cause (source → sink) `src/PhpSpreadsheet/Reader/Ods.php`: ```php // line 816 — row repeat, unchecked (int) cast $rowRepeats = (int) $childNode->getAttributeNS($tableNs, 'number-rows-repeated'); ... // line 1151 — row materialisation loop: NO upper bound for ($rowAdjust = 0; $rowAdjust < $rowRepeats; ++$rowAdjust) { $rID = $rowID + $rowAdjust; $cell = $spreadsheet->getActiveSheet()->getCell($columnID . $rID); // allocates a Cell $cell->setValueExplicit($dataValue, $type); // ... no bounds check on $rowAdjust or $rID ... } ``` **Why columns are NOT vulnerable (already bounded):** The column-header loop at line 1326 shows the correct pattern with bounds checking: ```php // line 1326 (processTableColumnHeader): BOUNDED correctly for ($rowRepeats2 = $rowRepeats; $rowRepeats2 > 0 && $tableColumnIndex2 <= AddressRange::MAX_COLUMN_INT; --$rowRepeats2) { // HAS BOUNDS CHECK: && $tableColumnIndex2 <= AddressRange::MAX_COLUMN_INT } ``` Additionally, the cell-data column loop at line 1141 calls `getCell()` which throws exception at `Coordinate.php:448` when column exceeds `MAX_COLUMN_INT` (XFD / 16,384): ```php // Coordinate.php line 448 if ($columnIndex > self::MAX_COLUMN_INT) { throw new Exception('Column string index can not be beyond XFD'); } ``` **Result:** Columns are capped at 16,384. Only rows are unbounded. --- ## Impact **Memory exhaustion (single valued cell, repeated many rows):** A non-null cell value with a huge `number-rows-repeated` attribute materialises millions of `Cell` objects → PHP fatal `Allowed memory size ... exhausted`. **Example:** - Payload: `<table:table-row table:number-rows-repeated="5000000">` (5 million rows) - File size: 1.4 KB - Memory consumed: ~256 MB (one Cell object per row) - Result: OOM at default memory limit --- ## Reproduction **Vulnerable payload (causes OOM):** ```xml <table:table table:name="Sheet1"> <table:table-row table:number-rows-repeated="5000000"> <table:table-cell office:value-type="float" office:value="1"> <text:p>1</text:p> </table:table-cell> </table:table-row> </table:table> ``` **Not vulnerable (for reference - throws exception):** ```xml <table:table table:name="Sheet1"> <table:table-row> <table:table-cell office:value-type="float" office:value="1" table:number-columns-repeated="1000000000"> <text:p>1</text:p> </table:table-cell> </table:table-row> </table:table> ``` This column-repeat example throws `Column string index can not be beyond XFD` exception (bounded defense, already in place).

Check your whole app

Dependencies are only half of it. Free and read-only: before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.

References

Merged from GitHub Advisory Database, OSV. Last updated 28 Oct 2026. All vulnerabilities · RSS · JSON