Skip to content

PHPSpreadsheet has a patch bypass for CVE-2026-34084

Critical severity GitHub Reviewed Published Jun 7, 2026 in PHPOffice/PhpSpreadsheet • Updated Jun 8, 2026

Package

composer phpoffice/phpspreadsheet (Composer)

Affected versions

<= 1.30.4

Patched versions

1.30.5

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.

Branch Latest tag PHP under test Result
1.x 1.30.4 7.4 bypass plus full RCE, gadget wrote marker file
2.1.x 2.1.16 8.3 bypass
2.4.x 2.4.5 8.3 bypass
3.10.x 3.10.5 8.3 bypass
5.6.x 5.6.0 8.3 bypass
5.7.x 5.7.0 8.3 bypass

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.

References

@oleibman oleibman published to PHPOffice/PhpSpreadsheet Jun 7, 2026
Published to the GitHub Advisory Database Jun 8, 2026
Reviewed Jun 8, 2026
Last updated Jun 8, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
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

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(38th percentile)

Weaknesses

Deserialization of Untrusted Data

The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid. Learn more on MITRE.

CVE ID

CVE-2026-45034

GHSA ID

GHSA-87m4-826x-3crx

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.