PhpSpreadsheet CVE-2026-45034 exposes wrapper-bypass RCE risk

At a glance

What this is: A critical PhpSpreadsheet vulnerability allows wrapper-bypass remote code execution when user-controlled filenames reach IOFactory::load().

Why it matters: It matters because spreadsheet import and file-processing paths sit inside many IAM-adjacent workflows, where one exposed parser can become a full server compromise path.

By the numbers:

• PhpSpreadsheet has over 312 million downloads.
• CVE-2026-45034 carries a CVSS score of 9.8.

👉 Read Orca Security’s analysis of the PhpSpreadsheet CVE-2026-45034 wrapper bypass

Context

PhpSpreadsheet is a PHP library used for spreadsheet import and export, so the security issue sits in a common application path: taking a filename, parsing it, and loading file content. In this case, the weakness is not in spreadsheet handling itself but in wrapper detection, where a crafted path can steer execution into an unexpected file scheme.

For identity and access teams, the broader lesson is that application-layer parsing often decides whether a workload can touch files, deserialize content, or reach adjacent systems. When those paths accept user-controlled input, the resulting exposure can extend well beyond the original library and into service accounts, runtime privileges, and downstream data access.

Key questions

Q: What breaks when user-controlled filenames reach PhpSpreadsheet import paths?

A: The main failure is that a filename can steer the loader into wrapper or archive handling instead of ordinary file reading. If validation relies on parser output, an attacker can bypass the intended check and reach phar-based behaviour, including deserialisation on PHP 7.x or file read primitives on PHP 8.x. That turns an import feature into a server-side attack surface.

Q: Why do spreadsheet import endpoints increase remote code execution risk?

A: Import endpoints often accept externally supplied paths, which makes them a trust boundary rather than a convenience feature. When the application passes those paths into a loader that can recognise dangerous wrappers, the boundary between data handling and execution becomes thin. A vulnerable import flow can expose code execution, file access, and lateral movement opportunities in the same request.

Q: How do teams know whether their PhpSpreadsheet exposure is real or theoretical?

A: Exposure is real when external users can influence the filename argument passed to IOFactory::load() or any equivalent wrapper around it. The strongest signal is a path that allows uploads, imports, or object storage references to reach the loader without a strict allowlist. If the service account that runs the job can also reach sensitive files, the blast radius is immediate.

Q: Who is accountable when an incomplete library patch leaves wrapper bypass risk in production?

A: Application owners and platform teams are accountable for proving that the patched version is deployed everywhere and that the vulnerable path is no longer reachable. Security teams should verify dependency updates, but operational ownership sits with the service that exposes the import function. In practice, incomplete remediation is a governance failure, not just a library issue.

Technical breakdown

How triple-slash paths bypass wrapper detection

The bypass hinges on a mismatch between PHP’s parse_url() behavior and stream wrapper handling. PhpSpreadsheet introduced File::prohibitWrappers() to block wrapper-based paths, but parse_url() returns false when a scheme is followed by three or more slashes, such as phar:///path/to/file. That false return skips the is_string($scheme) guard, while the PHP stream layer still recognises the phar wrapper. The result is that a filename which looks filtered at the application layer can still reach an active wrapper at runtime.

Practical implication: Validate wrapper checks against the exact runtime parser behaviour, not just the expected string pattern.

Why phar metadata can turn file load into code execution

On PHP 7.x, loading a crafted phar path can trigger automatic Phar metadata deserialisation. That matters because deserialisation is not a passive read operation, it can invoke object handlers and gadget chains embedded in the archive metadata. On PHP 8.x, the same path initially yields a file read primitive, but RCE can return if the application later calls Phar::getMetadata(). The vulnerability therefore mixes parsing, file access, and deserialisation in one control flow.

Practical implication: Treat any file-loading path that can reach phar metadata as a code-execution boundary, not a simple import feature.

Why unsanitized filenames are the real control plane

IOFactory::load() becomes dangerous when its filename argument is attacker-influenced. The issue is not limited to direct uploads, because any framework or service that passes user-supplied file paths into the loader can inherit the same exposure. In practice, the attack surface includes upload handlers, import APIs, and middleware that trust path validation upstream. Once the input reaches the loader, library-level checks may be too late if the parsing assumptions are already broken.

Practical implication: Remove user control from filename resolution before the loader is called, rather than relying on downstream filtering.

Threat narrative

Attacker objective: The attacker wants to convert a benign-looking file import into server-side code execution and broader filesystem exposure.

1. Entry occurs when an attacker supplies a crafted filename containing a phar path with triple slashes to IOFactory::load().
2. Escalation happens when parse_url() returns false, the wrapper check is bypassed, and the PHP stream layer still accepts the phar wrapper.
3. Impact follows when phar metadata deserialisation or file-read behaviour exposes code execution, sensitive files, or server compromise.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Wrapper validation failed because the parser and the runtime disagreed. The control was designed for a world where parse_url() reliably identified the scheme before file loading. That assumption fails when the actor is a crafted path that deliberately produces a false parse result while the stream layer still honours the wrapper. The implication is that parser-dependent allow or deny logic cannot be treated as a stable security boundary.

File import endpoints are identity-adjacent trust boundaries, not just application conveniences. When a service account or application runtime can invoke loader code on user-controlled paths, the privilege question is no longer about authentication alone. It becomes a question of which identity is allowed to transform untrusted input into filesystem access, deserialisation, or code execution. Practitioners should treat these paths as governed execution surfaces.

Phar metadata deserialisation is the named failure mode this breach pattern exposes. The issue is not merely risky input handling, but an execution path where archive metadata can activate object behaviour during load. That means the defensive assumption is wrong at the design level: file loading is not always read-only. The implication is that teams must re-evaluate any workflow that treats loader calls as low-risk utility operations.

Attack surface tracks integration density, not just library popularity. A library with hundreds of millions of downloads becomes materially more dangerous when embedded into upload flows, document processing, and automation pipelines. OWASP NHI thinking applies here because the compromise path often starts with a service identity that is trusted to process files at runtime. Practitioners should inventory every place the loader is exposed to external input.

The previous fix failed because the same trust model was reused after the bug was patched. A patch that blocks one parser quirk can still leave the broader wrapper-handling assumption intact. This is a control-gap lesson for all identity-adjacent file workflows: if the runtime still recognises a dangerous scheme, the boundary has not actually moved. Practitioners should assume that incomplete remediation is a first-order risk.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37%, according to the same study.
• For adjacent context on how attackers move from exposed credentials to rapid access attempts, see LLMjacking: How Attackers Hijack AI Using Compromised NHIs, which reports attempts within 17 minutes on average after public AWS credential exposure.

What this signals

Wrapper-bypass bugs should be treated as identity-adjacent exposure, not just application hygiene. If a service account or workload identity can invoke file import logic, the control question becomes who can transform untrusted input into execution. Teams should map these paths into their NHI governance model and review them alongside secrets and runtime privileges.

Phar metadata deserialisation is a useful named concept for this class of issue. It captures the point where archive processing becomes active code behaviour rather than passive file handling. Practitioners should watch for any workflow that still assumes loader calls are low-risk utilities, especially where platform teams manage shared import services.

The operational signal is not just whether the vulnerable package exists, but whether the import path is reachable by external input and backed by a privileged runtime. If that combination exists, remediation should move from backlog item to incident-class priority. The same principle applies to other libraries that hide execution inside parsing.

For practitioners

• Inventory every IOFactory::load() call site Map all code paths where user-controlled filenames or import parameters reach PhpSpreadsheet, including indirect framework wrappers and background jobs. Prioritise any path that accepts uploaded files, remote URLs, or staged object storage references.
• Block wrapper schemes before the loader executes Replace parser-dependent checks with explicit filename allowlists and reject any path containing dangerous wrapper indicators before the application reaches PhpSpreadsheet. Where possible, restrict imports to server-assigned object names rather than caller-supplied paths.
• Treat phar-capable paths as execution boundaries Review any code that may deserialize archive metadata, especially on PHP 7.x. If a workflow can touch phar archives, separate it from privileged service accounts and constrain filesystem reach to the minimum required scope.
• Verify the patched version is actually deployed Confirm that PhpSpreadsheet 1.30.5 or later is running everywhere the library is embedded, including containers, batch workers, and older application branches that may have retained the vulnerable dependency.

Key takeaways

• CVE-2026-45034 shows that wrapper validation can fail even after a prior patch if parser behaviour and runtime behaviour are not aligned.
• The public proof-of-concept and the library’s scale make user-controlled import paths a credible server-compromise risk, not a niche edge case.
• The control that matters is strict input ownership at the loader boundary, backed by verified patching and removal of dangerous wrapper reachability.

Key terms

• Wrapper bypass: A wrapper bypass happens when validation logic rejects a dangerous file scheme in one layer, but the runtime still accepts it in another. In PHP applications, that gap can let attacker-controlled paths reach file handlers, deserialisers, or remote wrappers that the developer believed were blocked.
• Phar metadata deserialisation: Phar metadata deserialisation is the process where PHP reads archive metadata and reconstructs objects from it. That behaviour becomes dangerous when untrusted archives are loaded, because object handlers or gadget chains can execute during what appears to be ordinary file access.
• Loader boundary: A loader boundary is the point where an application turns a filename or path into filesystem activity. It matters because input validation, privilege scope, and runtime parsing all converge there, so any mismatch can convert a harmless-looking import into code execution or data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: PhpSpreadsheet CVE-2026-45034 and the wrapper-bypass remote code execution risk. Read the original.