PhpSpreadsheet CVE-2026-45034: Three Slashes Defeat the Phar Wrapper Guard — a Patch Bypass for CVE-2026-34084 with RCE Potential

TL;DR — 90 seconds

Affected?

Any PHP project with phpoffice/phpspreadsheet ≤ 1.30.4 as a Composer dependency that passes filenames — directly or indirectly — from user input to IOFactory::load() or related reader functions.

Risk?

Complete bypass of the phar wrapper guard from CVE-2026-34084 (CVSS 4.0 9.2, CWE-502). On PHP 7.x, potential remote code execution via phar deserialization and object-injection gadget chains; on PHP 8.x, a file-read primitive.

Immediate action?

composer require phpoffice/phpspreadsheet:^1.30.5 — or, if an update isn't possible right away, explicitly reject any filename input containing the substring :// before processing.

Recommendation?

Check your Composer dependency tree for transitive use of PhpSpreadsheet (e.g. via reporting/export bundles), explicitly set phar.readonly to On, and filter file uploads with an extension allowlist rather than a blocklist.

Criticality?

high — high CVSS score, a publicly documented bypass mechanism and proof-of-concept code exist, but no known active in-the-wild exploitation so far, and success depends on PHP version, phar.readonly configuration, and the availability of a usable gadget chain.

What is the problem?

PhpSpreadsheet is the de facto standard library for reading and writing Excel, CSV, and ODS files in PHP — it ships, directly or via wrapper packages, inside a large number of PHP frameworks, CMS extensions, and business applications, everywhere users can upload or download spreadsheets. In May 2026, CVE-2026-34084 became known: files smuggled in via the phar:// stream wrapper could trigger deserialization of phar metadata and potentially lead to remote code execution. In response, the maintainers introduced the File::prohibitWrappers() method, meant to check filenames for dangerous schemes such as phar://, php://, or zip:// before processing.

CVE-2026-45034 shows that this protection can be bypassed entirely. The cause lies in a quirk of PHP's built-in parse_url() function: when a URL contains three or more slashes directly after the scheme colon — for example phar:///path/exploit.phar/dummy.csv — parse_url() interprets this structure as invalid and returns false instead of extracting the expected string "phar" as the scheme. The validation code in prohibitWrappers() then checks with is_string($scheme) whether a scheme was detected at all — for false that's not the case, so the check is skipped entirely and the filename is passed through as harmless.

The problem: PHP's underlying stream layer uses its own, more robust URI resolution and still correctly interprets the same path as a phar:// wrapper access. The discrepancy between the (flawed) validation logic and the actual behaviour of the stream layer is the core of the bypass: what looks like an ordinary filename to prohibitWrappers() is still opened by PHP itself as a phar archive — including automatic processing of the attacker-controlled serialized metadata it contains.

Who is affected?

The vulnerability was published via the GitHub Advisory Database on 7 Jun 2026 as GHSA-87m4-826x-3crx, with CVSS 4.0 9.2 (Critical, CWE-502). No confirmed in-the-wild exploitation is documented as of this writing, but publicly available proof-of-concept code exists for this CVE — the technical details of the bypass are fully public, which increases the risk of near-term exploitation.

Impact

On PHP 7.x, the bypass opens the classic phar deserialization attack path: if an attacker-crafted .phar file is passed to PhpSpreadsheet via a filename matching the three-slash pattern described above, PHP automatically processes the serialized metadata contained in the phar stub upon access — regardless of whether the application actually expects or reads a spreadsheet file. If the target application's autoloader contains suitable classes with exploitable __wakeup() or __destruct() methods (a so-called gadget chain), this can result in remote code execution with the privileges of the PHP process — in many deployments meaning access to database credentials, API keys, and the application's filesystem.

On PHP 8.x, the immediate impact is, per current public knowledge, limited to a file-read primitive — the bypass still allows PhpSpreadsheet to read content outside the expected file context, which depending on the application can lead to disclosure of configuration files, credentials, or other sensitive files on the server. Because PhpSpreadsheet is frequently used in export/import functions of admin backends, reporting modules, and data migration workflows — contexts that already tend to carry elevated privileges and access to sensitive data — the potential blast radius of a successful attack is relevant regardless of PHP version.

Mitigation / immediate steps

Operational decision block

• Act today if … your application passes file uploads or user-influenced filenames to PhpSpreadsheet reader functions and is still running version ≤ 1.30.4.
• Check with priority if … PhpSpreadsheet is only included transitively via a reporting or export package — the version binding is then easy to overlook.
• Just monitor if … your application only ever applies PhpSpreadsheet to fixed, server-generated file paths with no user input at all.

Step 1 — Update to the fixed version

# Composer update to the fixed version
composer require phpoffice/phpspreadsheet:^1.30.5

# Check which version is actually installed
composer show phpoffice/phpspreadsheet | grep -i versions

# If PhpSpreadsheet is only included transitively:
composer why phpoffice/phpspreadsheet

Step 2 — Short-term compensation if an update isn't immediately possible

# Input validation BEFORE every IOFactory::load() call:
# reject filenames containing the substring "://" outright,
# regardless of parse_url() results
if (str_contains($filename, '://')) {
    throw new InvalidArgumentException('Invalid filename');
}

# Additionally: only allow expected file extensions (allowlist, not blocklist)
$allowed = ['xlsx', 'xls', 'csv', 'ods'];
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
if (!in_array($ext, $allowed, true)) {
    throw new InvalidArgumentException('File type not allowed');
}

Step 3 — Harden PHP configuration

# Explicitly enforce phar.readonly (prevents writing new phar archives,
# but does NOT by itself protect against this deserialization bypass chain)
php -i | grep phar.readonly
# set explicitly in php.ini:
# phar.readonly = On

Detection / verification

Check installed version and usage

# Direct dependency?
grep -A2 '"phpoffice/phpspreadsheet"' composer.lock

# Transitive dependency via which package?
composer why phpoffice/phpspreadsheet

# Search the codebase for direct IOFactory calls
grep -rn "IOFactory::load(\|IOFactory::createReaderForFile(" --include="*.php" .

Search logs and uploads for suspicious filenames/paths

# Search access/application logs for the three-slash pattern
grep -E "phar:///" /var/log/*/access.log storage/logs/*.log 2>/dev/null
grep -E "[a-z]+:/{3,}" storage/logs/*.log 2>/dev/null

# Check upload directories for .phar files with unusual names
find /path/to/uploads -iname "*.phar*" -o -iname "*phar*"

Runtime indicators

• File upload or import requests with filenames containing the substring :// — that should never occur in a regular Excel/CSV upload
• Unexpected PHP errors or warnings related to unserialize() or phar processing shortly after a file upload
• Unusual outbound connections or process starts immediately following a file import request

Operator guidance

Mid-market

Check your Composer lockfile for phpoffice/phpspreadsheet — including transitive inclusion via reporting or export packages — and update to 1.30.5 promptly. Where an immediate update isn't possible, put the described :// substring check in front as compensation.

Enterprise

Additionally: identify all code paths that pass user-controlled filenames to PhpSpreadsheet or similar file-processing libraries, and where possible run that processing in isolated workers with minimal privileges and no access to production credentials. Explicitly set phar.readonly to On across all environments, and inventory PHP versions with an eye on remaining PHP 7.x installations — that's where the RCE potential is greatest.

All Composer projects with file uploads

Regardless of PhpSpreadsheet specifically: this case is a good example of why validation based on parse_url() alone isn't sufficient to reliably prevent stream wrapper abuse. Wherever filenames originate from user input, an additional strict extension allowlist and an explicit check for the substring :// should be applied — regardless of which library ultimately processes the file.

Decision block

• Patch immediately: Composer update to 1.30.5, check the dependency tree for transitive usage.
• Compensate if the patch is delayed: apply input validation for the :// substring and an extension allowlist.
• Monitor: check logs for the three-slash pattern and unusual deserialization errors, even after patching — as evidence of whether exploitation attempts occurred before the update.

Conclusion

CVE-2026-45034 is a textbook example of how fragile security validation can be when it relies on the edge-case behaviour of a single function like parse_url() without cross-checking the actual interpretation performed by the underlying stream layer. The original fix for CVE-2026-34084 was well-intentioned but missed an edge case — with the result that the protection can be fully defeated with a single extra slash in the filename. For operators, this means: Composer updates are necessary, but for file-processing libraries they're often not sufficient on their own — an independent validation layer for user-controlled filenames remains worthwhile, precisely because even established, widely used libraries can overlook bypasses like this one.

Sources

• GitHub Advisory Database — GHSA-87m4-826x-3crx: PHPSpreadsheet has a patch bypass for CVE-2026-34084 (CVE-2026-45034)
• Orca Security — CVE-2026-45034: PhpSpreadsheet RCE Patch Bypass
• GitLab Advisory Database — CVE-2026-45034 (phpoffice/phpspreadsheet)