Skip to main content

PhpSpreadsheet CVE-2026-45034

CRITICAL
Deserialization of Untrusted Data (CWE-502)
2026-06-08 https://github.com/PHPOffice/PhpSpreadsheet GHSA-87m4-826x-3crx
Share

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 08, 2026 - 23:15 vuln.today
Analysis Generated
Jun 08, 2026 - 23:15 vuln.today

DescriptionCVE.org

Summary

CVE-2026-34084 was patched by the helper File::prohibitWrappers. The helper calls parse_url($filename, PHP_URL_SCHEME) and then checks is_string($scheme) && strlen($scheme) > 1 to reject stream wrappers such as phar://, php://, data:// or expect://. The check is not equivalent to "does the path contain a wrapper". When the input has the form phar:///path/file.phar/inner with three or more slashes after the scheme, parse_url returns boolean false instead of returning the scheme string. The is_string($scheme) branch is therefore skipped, the helper returns without throwing, and the caller proceeds. PHP's stream layer, however, still treats phar:///... as a valid phar wrapper and opens the underlying phar file. The result is that IOFactory::load($attackerPath) walks past the patch and still touches the phar wrapper. On PHP 7.x, simply reaching the phar wrapper via is_file is enough for PHP to automatically deserialize the phar metadata, which in turn invokes the magic methods __wakeup and __destruct of an attacker controlled object and gives full RCE. On PHP 8.x, automatic metadata deserialization for plain file ops was removed, so the chain at the PhpSpreadsheet layer reduces to a phar wrapper file read primitive, and RCE only resurfaces if the downstream consumer ever calls Phar::getMetadata.

Vulnerable code

The file vendor/phpoffice/phpspreadsheet/src/PhpSpreadsheet/Shared/File.php is byte identical across all six latest tags listed below:

php
public static function prohibitWrappers(string $filename): void
{
    $scheme = parse_url($filename, PHP_URL_SCHEME);
    if (is_string($scheme) && strlen($scheme) > 1) {
        throw new Exception("Stream wrappers are not permitted as file paths: {$filename}");
    }
}

For input phar://x/dummy.csv the call returns the string "phar" and the throw fires correctly. For input phar:///work/exploit.phar/dummy.csv the same call returns false and the throw is skipped, which is the bypass.

Confirmed affected versions

Tested on 2026-05-03. The prohibitWrappers source on disk is identical across all six tags.

BranchLatest tagPHP under testResult
1.x1.30.47.4bypass plus full RCE, gadget wrote marker file
2.1.x2.1.168.3bypass
2.4.x2.4.58.3bypass
3.10.x3.10.58.3bypass
5.6.x5.6.08.3bypass
5.7.x5.7.08.3bypass

Version 1.30.4 is the latest tag of the 1.x branch, which is the only branch that still supports PHP 7.x. Version 5.7.0 is the latest tag overall on Packagist at the time of testing.

No branch beyond 1.30.x allows any release before Php 8. For branches beyond 1.30.x, although the code identified above is in error, and will be corrected, it does not lead to any security exposure. That would require a Phar::getMetadata call, which is not present in PhpSpreadsheet. If possible and reasonable, the release notes for the fix on the other branches will include release-note: security.

Reproduction

Requires Docker only, no local PHP install. Run:

sh
bash run.sh

The script does the following in order: build exploit.phar using php:7.4-cli with phar.readonly=0, install phpoffice/phpspreadsheet:5.7.0 through composer and run exploit.php on php:8.3-cli to show that the bypass still works against the latest tag, then install 1.30.4 and run again on php:7.4-cli to show the full RCE chain. All output is teed to evidence.txt.

exploit.php ships two controls. The negative control uses phar://x/dummy.csv to confirm that the patch still rejects the standard wrapper form. The positive control uses phar:///work/exploit.phar/dummy.csv to show that the three slash variant slips through. On PHP 7.4 the gadget writes the file pwned_marker containing the lines WAKEUP: phpspreadsheet-bypass and DESTRUCT: phpspreadsheet-bypass, which is the proof that attacker controlled code ran inside the victim process.

Suggested fix

Do not rely on parse_url to detect wrappers, because its behavior depends on the slash count and on the PHP version. Either of these is safe:

php
public static function prohibitWrappers(string $filename): void
{
    if (str_contains($filename, '://')) {
        throw new Exception("Stream wrappers are not permitted as file paths: {$filename}");
    }
}

Alternatively, run the path through realpath() first, since realpath returns false for any wrapper prefixed path.

Files in this report

  • build-phar.php: builds exploit.phar with a gadget object in its metadata.
  • exploit.php: main PoC, with the negative and positive controls.
  • exploit.phar: prebuilt phar, the gadget writes a marker when deserialized.
  • composer.json: spec used by composer to install the version under test.
  • run.sh: end to end reproducer through Docker.
  • evidence.txt: log captured from the most recent run.sh invocation.

AnalysisAI

Insecure deserialization in PhpOffice PhpSpreadsheet 1.30.4 and earlier allows remote code execution when an attacker-controlled file path with three or more slashes after the scheme (e.g. phar:///path/file.phar/inner) is passed to IOFactory::load, bypassing the prohibitWrappers helper introduced as a patch for CVE-2026-34084. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata

Recon
Plant malicious phar on reachable path
Delivery
Submit phar:///abs/path/exploit.phar/inner to app
Exploit
Bypass prohibitWrappers via parse_url false
Install
PHP stream layer opens phar wrapper
C2
Automatic phar metadata deserialization (PHP 7.x)
Execute
Gadget __wakeup/__destruct executes
Impact
RCE as web user

Vulnerability AssessmentAI

Exploitation Requires that the target application call PhpSpreadsheet's IOFactory::load (or any code path routed through File::prohibitWrappers) with an attacker-influenced filename string, and that the attacker can supply a path of the form phar:///<absolute-path>/<file>.phar/<inner> with three or more slashes after the scheme. … Additional conditions and limiting factors are described in the full assessment.
Risk Assessment No CVSS vector, EPSS score, or KEV listing was provided in the input, so quantitative scoring signals are missing and cannot be cross-referenced. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in.
Exploit Scenario An attacker uploads or otherwise plants a crafted phar file containing a serialized gadget object on a host filesystem location reachable by the target PHP application (e.g. via an existing file upload endpoint that stores files under a known path). …
Remediation Vendor-released patch: 1.30.5 for the 1.x branch - upgrade phpoffice/phpspreadsheet to 1.30.5 or later via composer require phpoffice/phpspreadsheet:^1.30.5, which is the priority action for any deployment on PHP 7.x. … Detailed patch versions, workarounds, and compensating controls in full report.

Recommended ActionAI

Within 24 hours: Identify all systems and applications running PhpSpreadsheet 1.30.4 or earlier; audit code to determine if file paths passed to IOFactory::load() are user-controlled or derived from untrusted sources. …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

Share

CVE-2026-45034 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy