Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘 Packagist
Not in CISA KEV

GHSA-87m4-826x-3crx

GHSA-87m4-826x-3crx is a Deserialization of Untrusted Data vulnerability in phpoffice/phpspreadsheet. O3 Security confirms whether GHSA-87m4-826x-3crx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

PHPSpreadsheet has a patch bypass for CVE-2026-34084

Also known asCVE-2026-45034
Published
Jun 8, 2026
Updated
Jun 8, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA’s SSVC triage for GHSA-87m4-826x-3crx.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs38th percentile — riskier than 38% of all scored CVEsHighest risk
0.00%0.32%0.64%0.96%0.4%0.4%0.5%0.5%Jul 26Sep 26Sep 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

1 pkg affected
🐘phpoffice/phpspreadsheet

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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:

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:

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:

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistphpoffice/phpspreadsheetall versions1.30.5

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for phpoffice/phpspreadsheet. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update phpoffice/phpspreadsheet to 1.30.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-87m4-826x-3crx is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-87m4-826x-3crx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-87m4-826x-3crx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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 witho
O3 Security · Impact-Aware SCA

Is GHSA-87m4-826x-3crx in your dependencies?

O3 detects GHSA-87m4-826x-3crx across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-87m4-826x-3crx: PHPSpreadsheet has… | O3 Security