{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/products/phpspreadsheet/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["PhpSpreadsheet"],"_cs_severities":["critical"],"_cs_tags":["phpspreadsheet","ssrf","rce","php","deserialization"],"_cs_type":"advisory","_cs_vendors":["PhpOffice"],"content_html":"\u003cp\u003ePhpSpreadsheet, a widely used PHP library for reading and writing spreadsheet files, is susceptible to a critical vulnerability that can lead to both Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE). The vulnerability stems from insufficient validation of the \u003ccode\u003e$filename\u003c/code\u003e parameter passed to the \u003ccode\u003eIOFactory::load\u003c/code\u003e function. When this parameter is user-controlled, attackers can leverage PHP wrappers such as \u003ccode\u003eftp://\u003c/code\u003e, \u003ccode\u003ephar://\u003c/code\u003e, and \u003ccode\u003essh2.sftp://\u003c/code\u003e to bypass the \u003ccode\u003eis_file\u003c/code\u003e check, leading to malicious file inclusion or arbitrary code execution. This flaw affects versions up to and including 1.30.2, as well as versions 2.0.0 through 5.5.0. Exploitation can occur even if the specified file inside the phar archive does not exist or is not a supported file type, potentially masking the attack. Due to PhpSpreadsheet\u0026rsquo;s widespread use in other popular libraries like \u003ccode\u003emaatwebsite/excel\u003c/code\u003e and \u003ccode\u003esonata-project/exporter\u003c/code\u003e, the impact of this vulnerability is significant.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious phar archive (\u003ccode\u003eexploit.xlsx\u003c/code\u003e) containing a PHP object with a \u003ccode\u003e__destruct\u003c/code\u003e method that executes arbitrary code via \u003ccode\u003eshell_exec\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker hosts the malicious phar archive on a web server or makes it accessible through other means.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a request to a vulnerable web application using PhpSpreadsheet, providing a \u003ccode\u003ephar://\u003c/code\u003e URL (e.g., \u003ccode\u003ephar://exploit.xlsx/whatever\u003c/code\u003e) as the \u003ccode\u003e$filename\u003c/code\u003e parameter to \u003ccode\u003eIOFactory::load\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003eIOFactory::load\u003c/code\u003e attempts to load the file specified in the \u003ccode\u003e$filename\u003c/code\u003e parameter, which passes through the vulnerable \u003ccode\u003eis_file\u003c/code\u003e check.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ephar://\u003c/code\u003e wrapper triggers PHP\u0026rsquo;s phar extension, which deserializes the metadata within the \u003ccode\u003eexploit.xlsx\u003c/code\u003e archive.\u003c/li\u003e\n\u003cli\u003eDeserialization of the malicious PHP object triggers the \u003ccode\u003e__destruct\u003c/code\u003e method, executing the attacker\u0026rsquo;s arbitrary code via \u003ccode\u003eshell_exec\u003c/code\u003e, achieving RCE. The code creates \u003ccode\u003e/tmp/poc.txt\u003c/code\u003e in the example.\u003c/li\u003e\n\u003cli\u003eAlternatively, the attacker provides an \u003ccode\u003eftp://\u003c/code\u003e URL to \u003ccode\u003eIOFactory::load\u003c/code\u003e, pointing to an attacker-controlled FTP server.\u003c/li\u003e\n\u003cli\u003eThe vulnerable \u003ccode\u003eis_file\u003c/code\u003e check allows the \u003ccode\u003eftp://\u003c/code\u003e connection, leading to an SSRF vulnerability where the server running PhpSpreadsheet connects to the attacker\u0026rsquo;s specified FTP server.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the suggested mitigations by either checking for PHP wrappers in the filename before calling \u003ccode\u003eis_file\u003c/code\u003e or by using \u003ccode\u003erealpath\u003c/code\u003e to ensure a clean absolute path (see code snippets in the advisory).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect_PhpSpreadsheet_Phar_Wrapper\u003c/code\u003e to detect attempts to exploit the RCE vulnerability by monitoring process creation events with command lines containing \u0026ldquo;phar://\u0026rdquo; and \u003ccode\u003ephp\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect_PhpSpreadsheet_Ftp_Wrapper\u003c/code\u003e to detect attempts to exploit the SSRF vulnerability by monitoring network connections with destination ports on FTP protocol (21) and file paths contain ftp.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for requests containing the \u003ccode\u003ephar://\u003c/code\u003e or \u003ccode\u003eftp://\u003c/code\u003e schemes in the filename parameter to \u003ccode\u003eIOFactory::load\u003c/code\u003e.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-30T12:00:00Z","date_published":"2024-01-30T12:00:00Z","id":"/briefs/2024-01-30-phpspreadsheet-rce-ssrf/","summary":"PhpSpreadsheet is vulnerable to Server-Side Request Forgery (SSRF) and Remote Code Execution (RCE) due to improper validation of filenames in the IOFactory::load function, exploitable via PHP wrappers like `phar://` and `ftp://`.","title":"PhpSpreadsheet SSRF and RCE Vulnerability via IOFactory::load","url":"https://feed.craftedsignal.io/briefs/2024-01-30-phpspreadsheet-rce-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["PhpSpreadsheet"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","xml","phpspreadsheet"],"_cs_type":"advisory","_cs_vendors":["phpoffice"],"content_html":"\u003cp\u003eThe PhpSpreadsheet library is susceptible to a denial-of-service (DoS) vulnerability within its SpreadsheetML XML reader (\u003ccode\u003eReader\\Xml\u003c/code\u003e). This flaw arises because the reader fails to validate the \u003ccode\u003ess:Index\u003c/code\u003e row attribute against the maximum allowed row count (\u003ccode\u003eAddressRange::MAX_ROW = 1,048,576\u003c/code\u003e). By crafting a malicious SpreadsheetML XML file containing an extremely large \u003ccode\u003ess:Index\u003c/code\u003e value (e.g., \u0026ldquo;999999999\u0026rdquo;) on a \u003ccode\u003e\u0026lt;Row\u0026gt;\u003c/code\u003e element, an attacker can inflate the internal \u003ccode\u003ecachedHighestRow\u003c/code\u003e property to approximately 1 billion. Subsequently, any call to \u003ccode\u003egetRowIterator()\u003c/code\u003e without a specified end row will attempt to iterate over this inflated range, leading to CPU exhaustion and ultimately a DoS condition. This issue affects versions of PhpSpreadsheet from 2.0.0 to 5.6.0 and poses a risk to PHP applications that process user-uploaded SpreadsheetML XML files.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious SpreadsheetML XML file (e.g., \u003ccode\u003epoc.xml\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe crafted XML file contains a \u003ccode\u003e\u0026lt;Row\u0026gt;\u003c/code\u003e element with an \u003ccode\u003ess:Index\u003c/code\u003e attribute set to a very large integer (e.g., \u003ccode\u003ess:Index=\u0026quot;999999999\u0026quot;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eA PHP application using PhpSpreadsheet loads the malicious XML file using \u003ccode\u003eIOFactory::createReader('Xml')-\u0026gt;load('poc.xml')\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eloadSpreadsheetFromFile\u003c/code\u003e method in \u003ccode\u003esrc/PhpSpreadsheet/Reader/Xml.php\u003c/code\u003e processes the \u003ccode\u003e\u0026lt;Row\u0026gt;\u003c/code\u003e element, reads the \u003ccode\u003ess:Index\u003c/code\u003e value, and casts it to an integer without validation.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003egetRowDimension()\u003c/code\u003e method in \u003ccode\u003esrc/PhpSpreadsheet/Worksheet.php\u003c/code\u003e is called with the attacker-controlled \u003ccode\u003e$rowID\u003c/code\u003e, inflating the \u003ccode\u003ecachedHighestRow\u003c/code\u003e property.\u003c/li\u003e\n\u003cli\u003eA subsequent call to \u003ccode\u003e$sheet-\u0026gt;getRowIterator()\u003c/code\u003e attempts to iterate from the beginning to the inflated \u003ccode\u003ecachedHighestRow\u003c/code\u003e, triggering excessive CPU consumption.\u003c/li\u003e\n\u003cli\u003eThe server\u0026rsquo;s CPU resources are exhausted, leading to a denial-of-service condition.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe 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:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eCPU exhaustion with a small malicious file (~300 bytes).\u003c/li\u003e\n\u003cli\u003eBlocking PHP worker processes, affecting concurrent users.\u003c/li\u003e\n\u003cli\u003eTriggering PHP \u003ccode\u003emax_execution_time\u003c/code\u003e limits while still consuming resources.\u003c/li\u003e\n\u003cli\u003eApplications are vulnerable without authentication if they allow the processing of uploaded SpreadsheetML files.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement validation for the \u003ccode\u003ess:Index\u003c/code\u003e attribute in \u003ccode\u003esrc/PhpSpreadsheet/Reader/Xml.php\u003c/code\u003e to ensure it does not exceed \u003ccode\u003eAddressRange::MAX_ROW\u003c/code\u003e. Apply this validation to both \u003ccode\u003e\u0026lt;Row\u0026gt;\u003c/code\u003e and \u003ccode\u003e\u0026lt;Cell\u0026gt;\u003c/code\u003e elements. Use the fix from the advisory (\u003ca href=\"https://github.com/advisories/GHSA-84wq-86v6-x5j6\"\u003ehttps://github.com/advisories/GHSA-84wq-86v6-x5j6\u003c/a\u003e) as a reference.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetectSuspiciousPhpSpreadsheetXML\u003c/code\u003e to detect the use of extremely large row indexes in SpreadsheetML files.\u003c/li\u003e\n\u003cli\u003eMonitor web server logs for requests uploading XML files and triggering high CPU usage, correlating with the execution of PhpSpreadsheet.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-09T18:45:00Z","date_published":"2024-01-09T18:45:00Z","id":"/briefs/2024-01-09-phpspreadsheet-dos/","summary":"PhpSpreadsheet is vulnerable to a denial-of-service attack by crafting a SpreadsheetML XML file with an excessively large row index, which exhausts server CPU resources due to unbounded iteration.","title":"PhpSpreadsheet XML Reader Denial of Service via Unbounded Row Index","url":"https://feed.craftedsignal.io/briefs/2024-01-09-phpspreadsheet-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["PhpSpreadsheet"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","phpspreadsheet","xlsx","php"],"_cs_type":"advisory","_cs_vendors":["phpoffice"],"content_html":"\u003cp\u003eA vulnerability exists in PhpSpreadsheet versions 1.x through 5.6.0 where the XLSX reader does not properly validate row numbers read from XML attributes within a spreadsheet file. Specifically, the \u003ccode\u003eColumnAndRowAttributes::readRowAttributes()\u003c/code\u003e method lacks a check against the maximum allowed row number (\u003ccode\u003eAddressRange::MAX_ROW = 1,048,576\u003c/code\u003e). An attacker can exploit this by crafting a minimal XLSX file (approximately 1.6KB) containing a \u003ccode\u003e\u0026lt;row r=\u0026quot;999999999\u0026quot;/\u0026gt;\u003c/code\u003e element. When processed, this inflates the \u003ccode\u003ecachedHighestRow\u003c/code\u003e property, causing subsequent row iteration operations to attempt nearly one billion loop cycles, thereby exhausting CPU resources and leading to a denial-of-service condition. This vulnerability can be exploited in web applications that accept user-uploaded spreadsheet files, making it a significant risk for systems using vulnerable versions of PhpSpreadsheet. The vulnerability was reported in GHSA-7c6m-4442-2x6m.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious XLSX file containing an XML \u003ccode\u003e\u0026lt;row\u0026gt;\u003c/code\u003e element with a large \u003ccode\u003er\u003c/code\u003e attribute (e.g., \u003ccode\u003e\u0026lt;row r=\u0026quot;999999999\u0026quot;/\u0026gt;\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker uploads the malicious XLSX file to a web application or system that uses PhpSpreadsheet to process spreadsheet files.\u003c/li\u003e\n\u003cli\u003eThe PhpSpreadsheet library, specifically the \u003ccode\u003eIOFactory::createReader('Xlsx')\u003c/code\u003e component, is used to read the uploaded file.\u003c/li\u003e\n\u003cli\u003eDuring the parsing process, the \u003ccode\u003eColumnAndRowAttributes::readRowAttributes()\u003c/code\u003e method reads the large row number from the XML attribute.\u003c/li\u003e\n\u003cli\u003eThe large row number is then used to update the \u003ccode\u003ecachedHighestRow\u003c/code\u003e property in the \u003ccode\u003eWorksheet\u003c/code\u003e object, effectively setting it to a very high value.\u003c/li\u003e\n\u003cli\u003eA subsequent operation that iterates over rows using \u003ccode\u003egetRowIterator()\u003c/code\u003e or retrieves the highest row using \u003ccode\u003egetHighestRow()\u003c/code\u003e triggers a loop that iterates up to the inflated \u003ccode\u003ecachedHighestRow\u003c/code\u003e value.\u003c/li\u003e\n\u003cli\u003eThe excessive number of loop iterations consumes a significant amount of CPU resources, leading to a denial-of-service condition.\u003c/li\u003e\n\u003cli\u003eThe application becomes unresponsive or crashes due to the CPU exhaustion.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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 \u003ccode\u003egetRowIterator()\u003c/code\u003e or \u003ccode\u003egetHighestRow()\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eApply the recommended fix by adding row bounds validation in \u003ccode\u003ereadRowAttributes()\u003c/code\u003e to check if \u003ccode\u003e$rowIndex\u003c/code\u003e is within the acceptable range (1 to \u003ccode\u003eAddressRange::MAX_ROW\u003c/code\u003e). This is the primary recommendation from the source advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect PhpSpreadsheet Excessive Row Iteration\u003c/code\u003e to detect processes that may be attempting to process XLSX files with extremely high row numbers, indicating a potential exploitation attempt.\u003c/li\u003e\n\u003cli\u003eMonitor 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.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-03-phpspreadsheet-dos/","summary":"A vulnerability in PhpSpreadsheet exists where a crafted XLSX file containing a large row number can cause excessive CPU consumption due to unbounded loop iterations, leading to a denial of service.","title":"PhpSpreadsheet CPU Denial of Service via Unbounded Row Number","url":"https://feed.craftedsignal.io/briefs/2024-01-03-phpspreadsheet-dos/"}],"language":"en","title":"CraftedSignal Threat Feed — PhpSpreadsheet","version":"https://jsonfeed.org/version/1.1"}