CVE-2026-59933 in PhpSpreadsheet
Summary
by MITRE • 07/28/2026
PhpSpreadsheet is a pure PHP library for reading and writing spreadsheet files. In versions 4.0.0 through 5.8.0, 3.3.0 through 3.10.6, 2.2.0 through 2.4.6, 2.0.0 through 2.1.17, and all releases up to and including 1.30.5, the OLE reader follows sector chains from attacker-controlled XLS/OLE metadata without detecting cycles or enforcing a maximum chain length. A tiny malformed .xls/OLE file can set the small-block depot sector chain to point back to itself. During normal XLS detection, OLERead::read() appends the same sector data repeatedly until the PHP process exhausts memory. This is reachable from Reader\Xls::canRead() and therefore from automatic spreadsheet type detection. Applications that accept attacker-controlled spreadsheet uploads can suffer denial of service from a very small file. This issue has been fixed in versions 5.8.1, 3.10.7, 2.4.7, 2.1.18 and 1.30.6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/29/2026
PhpSpreadsheet represents a widely adopted pure PHP library for processing spreadsheet files across various applications and platforms. The vulnerability under examination manifests in multiple version ranges spanning from 4.0.0 through 5.8.0 down to 1.30.5, indicating a prolonged exposure period that allowed potential exploitation across numerous implementations. The core technical flaw resides within the OLE reader component which processes sector chains from attacker-controlled XLS/OLE metadata without implementing cycle detection mechanisms or enforcing maximum chain length limitations. This design oversight creates a fundamental weakness in the library's parsing logic where the system blindly follows sector references without validation checks.
The exploitation mechanism involves crafting a minimal malformed .xls/OLE file that specifically manipulates the small-block depot sector chain to create a self-referential loop. When the OLERead::read() method executes during normal XLS detection processes, it repeatedly appends identical sector data to memory allocation until the PHP process exhausts available memory resources. This memory exhaustion occurs through the automatic spreadsheet type detection functionality accessible via Reader\Xls::canRead() method, which provides an indirect attack vector for malicious actors. The vulnerability's reach extends beyond simple denial of service as it can be triggered through normal file upload processing workflows where applications accept user-controlled spreadsheet files.
The operational impact of this vulnerability constitutes a severe denial of service condition that can be achieved with extraordinarily small malicious files, making it particularly dangerous for web applications handling spreadsheet uploads. Attackers need only create a tiny malformed file to potentially crash entire PHP processes or exhaust system resources, leading to application unavailability and service disruption. This vulnerability falls under CWE-400, specifically addressing unspecified resource management issues where the system fails to properly handle resource consumption during parsing operations. From an adversarial perspective, this represents a low-effort, high-impact attack pattern that aligns with ATT&CK technique T1499.004 for network denial of service attacks.
The remediation measures implemented in versions 5.8.1, 3.10.7, 2.4.7, 2.1.18, and 1.30.6 address the core issue by introducing proper cycle detection mechanisms within the OLE reader component. These updates enforce maximum chain length limitations that prevent infinite loops during sector chain processing while maintaining backward compatibility with legitimate spreadsheet files. Organizations should prioritize immediate patching of affected systems to eliminate this vulnerability vector, particularly in applications that process user-uploaded spreadsheet content. Additionally, implementing proper input validation and file type checking measures can provide additional defense-in-depth layers against similar parsing vulnerabilities in other components.