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…
| CVE ID | CVE-2026-34084 |
| Vendor | composer |
| Affected Product | phpoffice/phpspreadsheet |
| Vulnerability Type | Vulnerability |
| CVSS Score | 7.5 (HIGH) |
| Actively Exploited | ❌ No known exploitation |
| Patch Status | See Vendor Advisory → |
| Reported By | CYBERDUDEBIVASH SENTINEL APEX Intelligence (via github_advisories) |
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).
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: ```
Sigma rules, YARA signatures, IOC table, and SIEM queries for Splunk, Elastic, Sentinel, and Chronicle — deployable in 5 minutes.