Notifications
Clear all
Topic starter
12/06/2026 9:35 pm
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.
NHIMG editorial — based on content published by Orca Security: PhpSpreadsheet CVE-2026-45034 and the wrapper-bypass remote code execution risk
By the numbers:
- CVE-2026-45034 carries a CVSS score of 9.8.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Treat phar-capable paths as execution boundaries Review any code that may deserialize archive metadata, especially on PHP 7.x.
What's in the full article
Orca Security's full research covers the operational detail this post intentionally leaves for the source:
- The exact vulnerable versions and patched release guidance for affected PHP deployments
- The proof-of-concept conditions that trigger wrapper bypass and metadata deserialisation
- The asset exposure context Orca uses to prioritise internet-facing and runtime-reachable instances
- The specific mitigation advice for replacing parse_url-based wrapper detection in custom code
👉 Read Orca Security’s analysis of the PhpSpreadsheet CVE-2026-45034 wrapper bypass →
PhpSpreadsheet wrapper bypass: are your upload paths still exposed?
Explore further
12/06/2026 11:46 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PhpSpreadsheet CVE-2026-45034 exposes wrapper-bypass RCE risk
