Attack Chain

1. An attacker crafts a malicious phar archive (exploit.xlsx) containing a PHP object with a __destruct method that executes arbitrary code via shell_exec.
2. The attacker hosts the malicious phar archive on a web server or makes it accessible through other means.
3. The attacker crafts a request to a vulnerable web application using PhpSpreadsheet, providing a phar:// URL (e.g., phar://exploit.xlsx/whatever) as the $filename parameter to IOFactory::load.
4. IOFactory::load attempts to load the file specified in the $filename parameter, which passes through the vulnerable is_file check.
5. The phar:// wrapper triggers PHP’s phar extension, which deserializes the metadata within the exploit.xlsx archive.
6. Deserialization of the malicious PHP object triggers the __destruct method, executing the attacker’s arbitrary code via shell_exec, achieving RCE. The code creates /tmp/poc.txt in the example.
7. Alternatively, the attacker provides an ftp:// URL to IOFactory::load, pointing to an attacker-controlled FTP server.
8. The vulnerable is_file check allows the ftp:// connection, leading to an SSRF vulnerability where the server running PhpSpreadsheet connects to the attacker’s specified FTP server.

Impact

Successful exploitation of this vulnerability can lead to a range of severe consequences. Remote Code Execution (RCE) allows an attacker to execute arbitrary commands on the server, potentially leading to complete system compromise. The SSRF vulnerability enables an attacker to probe internal network resources, potentially exposing sensitive information or allowing further attacks on internal systems. Given PhpSpreadsheet’s use in numerous web applications and frameworks, a successful attack could impact a large number of users and organizations. Example impact includes attackers gaining initial access to internal applications.

Recommendation

• Apply the suggested mitigations by either checking for PHP wrappers in the filename before calling is_file or by using realpath to ensure a clean absolute path (see code snippets in the advisory).
• Deploy the Sigma rule Detect_PhpSpreadsheet_Phar_Wrapper to detect attempts to exploit the RCE vulnerability by monitoring process creation events with command lines containing “phar://” and php.
• Deploy the Sigma rule Detect_PhpSpreadsheet_Ftp_Wrapper to detect attempts to exploit the SSRF vulnerability by monitoring network connections with destination ports on FTP protocol (21) and file paths contain ftp.
• Monitor web server logs for requests containing the phar:// or ftp:// schemes in the filename parameter to IOFactory::load.

Attack Chain

1. An attacker crafts a malicious SpreadsheetML XML file (e.g., poc.xml).
2. The crafted XML file contains a <Row> element with an ss:Index attribute set to a very large integer (e.g., ss:Index="999999999").
3. A PHP application using PhpSpreadsheet loads the malicious XML file using IOFactory::createReader('Xml')->load('poc.xml').
4. The loadSpreadsheetFromFile method in src/PhpSpreadsheet/Reader/Xml.php processes the <Row> element, reads the ss:Index value, and casts it to an integer without validation.
5. The getRowDimension() method in src/PhpSpreadsheet/Worksheet.php is called with the attacker-controlled $rowID, inflating the cachedHighestRow property.
6. A subsequent call to $sheet->getRowIterator() attempts to iterate from the beginning to the inflated cachedHighestRow, triggering excessive CPU consumption.
7. The server’s CPU resources are exhausted, leading to a denial-of-service condition.

Impact

The vulnerability allows attackers to cause a denial-of-service condition on servers running PHP applications that utilize PhpSpreadsheet to process SpreadsheetML XML files. The impact includes:

• CPU exhaustion with a small malicious file (~300 bytes).
• Blocking PHP worker processes, affecting concurrent users.
• Triggering PHP max_execution_time limits while still consuming resources.
• Applications are vulnerable without authentication if they allow the processing of uploaded SpreadsheetML files.

Recommendation

• Implement validation for the ss:Index attribute in src/PhpSpreadsheet/Reader/Xml.php to ensure it does not exceed AddressRange::MAX_ROW. Apply this validation to both <Row> and <Cell> elements. Use the fix from the advisory (https://github.com/advisories/GHSA-84wq-86v6-x5j6) as a reference.
• Deploy the Sigma rule DetectSuspiciousPhpSpreadsheetXML to detect the use of extremely large row indexes in SpreadsheetML files.
• Monitor web server logs for requests uploading XML files and triggering high CPU usage, correlating with the execution of PhpSpreadsheet.

Attack Chain

1. An attacker crafts a malicious XLSX file containing an XML <row> element with a large r attribute (e.g., <row r="999999999"/>).
2. The attacker uploads the malicious XLSX file to a web application or system that uses PhpSpreadsheet to process spreadsheet files.
3. The PhpSpreadsheet library, specifically the IOFactory::createReader('Xlsx') component, is used to read the uploaded file.
4. During the parsing process, the ColumnAndRowAttributes::readRowAttributes() method reads the large row number from the XML attribute.
5. The large row number is then used to update the cachedHighestRow property in the Worksheet object, effectively setting it to a very high value.
6. A subsequent operation that iterates over rows using getRowIterator() or retrieves the highest row using getHighestRow() triggers a loop that iterates up to the inflated cachedHighestRow value.
7. The excessive number of loop iterations consumes a significant amount of CPU resources, leading to a denial-of-service condition.
8. The application becomes unresponsive or crashes due to the CPU exhaustion.

Impact

Successful exploitation of this vulnerability leads to a CPU denial of service. A small, 1.6KB crafted XLSX file can trigger almost one billion iterations, causing the system to become unresponsive for an extended period (estimated at ~144 seconds per file). This impacts any application using getRowIterator() or getHighestRow() methods, making the system unavailable. Applications processing the spreadsheet may also exhaust memory if they attempt to accumulate data during the iteration process. The high amplification factor (small input leading to massive CPU consumption) makes this vulnerability particularly dangerous, especially in web applications that process user-supplied spreadsheets.

Recommendation

• Apply the recommended fix by adding row bounds validation in readRowAttributes() to check if $rowIndex is within the acceptable range (1 to AddressRange::MAX_ROW). This is the primary recommendation from the source advisory.
• Deploy the Sigma rule Detect PhpSpreadsheet Excessive Row Iteration to detect processes that may be attempting to process XLSX files with extremely high row numbers, indicating a potential exploitation attempt.
• Monitor web server logs for suspicious file uploads, specifically XLSX files with unusually small sizes, which might indicate an attempt to upload a malicious file exploiting this vulnerability.