TL;DR: CVE-2026-45034 gives attackers remote code execution through a bypass of PhpSpreadsheet’s wrapper protection, with public proof-of-concept code and affected versions through 1.30.4, according to Orca Security. The failure is not just a library bug but a reminder that user-controlled filenames can turn file-import features into server compromise paths.
At a glance
What this is: This is a critical PhpSpreadsheet vulnerability that allows wrapper-bypass remote code execution when user-controlled filenames reach spreadsheet import code.
Why it matters: IAM and security teams should treat file-import paths as a trust boundary, because unsanitized inputs can turn application logic into server compromise even without authentication.
By the numbers:
- CVE-2026-45034 affects PhpSpreadsheet versions through 1.30.4.
Context
PhpSpreadsheet is a PHP library used to read and write spreadsheet files, and its import paths become security-sensitive when applications accept user-supplied filenames. In this case, the flaw is not a generic parsing error but a wrapper-validation bypass that lets a crafted path reach dangerous stream handling.
For identity and access programmes, the important point is that application entry points often accept data before any identity control is involved. When a file import feature can trigger code execution or file read access, the real governance question is how the application constrains untrusted inputs before they reach privileged runtime behaviour.
Key questions
Q: What breaks when a spreadsheet import library trusts parsed file paths?
A: A parser edge case can bypass wrapper detection, letting attacker-controlled filenames reach dangerous stream handling. That turns an import feature into a potential code-execution or file-read path, because the application believes validation succeeded while the runtime still accepts the payload.
Q: Why do user-controlled filenames create server compromise risk in import features?
A: Because filenames can influence wrapper resolution, archive handling, and downstream parsing before identity or authorization checks matter. If the application does not strictly constrain those inputs, a normal upload or import flow can become an execution path instead of a data-processing path.
Q: How do teams know whether wrapper-bypass remediation is actually working?
A: They should confirm the patched library version, test the application's own filename filters with wrapper-like payloads, and verify that no downstream code reinterprets the same input as a stream or archive. If any one of those layers still accepts crafted syntax, the fix is incomplete.
Q: What should organisations do when a library patch fixes only part of a file-handling flaw?
A: Treat the first patch as a starting point, not closure. Re-test the affected code path against alternate syntax, remove any custom validation that relies on ambiguous parsing helpers, and verify that runtime behaviour no longer matches the bypass condition.
Technical breakdown
How triple-slash paths bypass wrapper detection
The vulnerability sits in the interaction between PhpSpreadsheet's File::prohibitWrappers() logic and PHP's parse_url() behaviour. When a path contains three or more slashes after the scheme, parse_url() can return false instead of a scheme string, which means the wrapper check is skipped. The PHP stream layer may still recognise the same value as a valid wrapper, so the application believes it blocked the path while the runtime still accepts it. That mismatch between validation code and interpreter behaviour is what turns a defensive check into an bypassable control.
Practical implication: do not rely on URL parsing alone to decide whether a path is safe for upload or import handling.
Why IOFactory::load() becomes a code-execution path
When IOFactory::load() receives a crafted filename, PhpSpreadsheet can pass that value into stream handling in a way that triggers phar metadata deserialisation on PHP 7.x. That makes the file import feature behave like an execution primitive rather than a data-processing function. On PHP 8.x, the same technique can produce file read exposure, and later metadata access can still restore code execution conditions. The security issue is therefore not just the library call itself, but the assumption that an import API only ever processes benign files.
Practical implication: treat spreadsheet import entry points as high-risk attack surfaces, not routine business logic.
Why patched code still needs input governance
The article makes clear that earlier remediation for CVE-2026-34084 was incomplete, which is a familiar pattern in wrapper and deserialisation bugs. A partial fix that blocks one wrapper interpretation but leaves another parsing path open creates a false sense of closure. For defenders, that means patch status alone is not enough if custom validation, filename handling, or downstream metadata access still reintroduce the same exposure. The control failure here is not only at the library level; it is also in application design that trusts user-controlled filenames to remain inert.
Practical implication: review every code path that accepts filenames for wrapper handling, metadata access, or deserialisation side effects.
Threat narrative
Attacker objective: The attacker aims to turn a user-controlled file import into remote code execution or file disclosure on the application server.
- Entry occurs when an attacker supplies a specially crafted filename to an upload or import function that uses PhpSpreadsheet.
- Credential access is not the issue here; instead, the attacker abuses wrapper parsing to reach the stream layer despite application-side checks.
- Escalation follows when phar metadata deserialisation or file read behaviour is triggered, depending on the PHP version and downstream code path.
- Impact is server compromise, sensitive file exposure, or broader infrastructure compromise through arbitrary code execution.
Breaches seen in the wild
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Wrapper validation is not the same as runtime containment: This vulnerability exists because the application assumes parse_url() will reliably classify dangerous wrapper syntax. That assumption fails when the runtime still recognises the payload even after the validator returns false. The implication is that input validation for file paths must be judged against the interpreter's own parsing rules, not against a single library helper.
Import features are execution-adjacent controls, not low-risk convenience code: Spreadsheet ingestion often sits close to privileged file access, archive handling, and downstream parsing. In practice, that means a benign-looking upload endpoint can become an RCE or file-read primitive when wrapper handling is incomplete. Practitioners should treat spreadsheet import libraries as part of the attack surface, not merely data transformation code.
Partial remediation creates wrapper-bypass debt: The article shows the earlier fix for CVE-2026-34084 did not fully close the path. That is a classic governance problem in parser-adjacent vulnerabilities, where one condition is blocked but alternate syntax still reaches the same dangerous behaviour. The lesson for security teams is to verify both the patched version and the application's own filename controls before declaring the issue closed.
File-import trust boundaries need explicit ownership: Many organisations let application teams assume that security review will happen at the library layer, while platform teams assume input sanitisation belongs to the app. This vulnerability shows that split accountability leaves a gap exactly where untrusted filenames cross into privileged runtime behaviour. The practical conclusion is that the trust boundary around file imports must be owned and tested end to end.
Wrapper-bypass exposure is a control-design failure, not just a bug class: The named concept here is wrapper-bypass trust debt. Once a control depends on a parser edge case, the organisation has implicitly accepted that attacker-controlled syntax can outpace the validation rule. Security teams should recognise that as a durable design weakness, not an isolated defect.
What this signals
Wrapper-bypass trust debt: Once a file-handling control depends on parser behaviour, security teams need to assume that attacker-controlled syntax will eventually find an alternate interpretation. The practical effect is that import endpoints must be governed like privileged execution paths, not like ordinary application forms.
Spreadsheet ingestion belongs in the same governance conversation as secrets handling and remote code paths because the boundary being crossed is trust, not file type. When a filename can alter runtime behaviour, the control objective is to stop untrusted input at the earliest possible point and to validate the patched state as well as the application logic.
For practitioners
- Patch PhpSpreadsheet to 1.30.5 immediately Upgrade every affected deployment to the fixed release and confirm no service still runs 1.30.4 or earlier. Prioritise internet-facing applications and any workflow that calls IOFactory::load() on user-supplied files.
- Block user-controlled wrapper syntax at the application boundary Replace parse_url-based wrapper checks with explicit string containment logic and deny filenames containing scheme-like wrapper patterns before they reach spreadsheet parsing code.
- Audit spreadsheet import paths for deserialisation side effects Review any code that handles phar archives, metadata access, or chained file-processing steps after import. Separate file validation from content processing so that a blocked wrapper cannot re-enter through downstream logic.
- Restrict IOFactory::load() to trusted sources only Require server-generated filenames or pre-approved upload objects for spreadsheet ingestion and reject direct user filename passthrough. Apply the same rule to batch imports, API uploads, and framework helpers.
Key takeaways
- The vulnerability is a wrapper-bypass problem that converts a spreadsheet import path into a possible RCE or file-read path.
- The risk is amplified by public proof-of-concept availability and by the fact that affected versions extend through 1.30.4.
- Effective containment requires both the vendor patch and application-side filename governance, because parser edge cases can survive a library-only fix.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw bypasses wrapper checks that should prevent unsafe runtime access to user-controlled paths. |
| NHI-06 — Insecure Cloud Deployment Configurations | User-controlled import paths can expose runtime configuration weaknesses in application deployments. | |
| NHI-02 — Secret Leakage | The same exploit chain can expose sensitive files from the filesystem after the bypass succeeds. | |
| Recommendation — Treat wrapper validation as an authentication boundary for file inputs and reject ambiguous path syntax before execution. Harden upload and import endpoints so untrusted filenames cannot reach privileged parsing or stream handlers. Scan for file-read exposure in import workflows and remove any path that can disclose secrets or credentials. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0004 — Initial Access; Credential Access; Privilege Escalation | The attack moves from crafted input to code execution through a validation bypass and runtime abuse. |
| Recommendation — Map the exploit chain to initial access, credential-access-adjacent file exposure, and escalation to arbitrary code execution. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The issue is a direct failure of safe handling for attacker-controlled input. |
| Recommendation — Apply SI-10 to validate and constrain every user-supplied filename before it reaches import logic. | ||
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.
- User-Controlled Filename: A user-controlled filename is any file path or name supplied directly by an external user, API client, or upload workflow. If that value can influence wrapper resolution, archive parsing, or downstream file access, it becomes a security boundary that must be treated as untrusted input rather than metadata.
- Import Surface: An import surface is the set of application endpoints, libraries, and parsing routines that accept files and turn them into business data. In identity and security analysis, it matters because these entry points often sit close to privileged runtime behaviour, making them attractive targets for code execution and data exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org