<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Xlsx — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/xlsx/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/xlsx/feed.xml" rel="self" type="application/rss+xml"/><item><title>PhpSpreadsheet CPU Denial of Service via Unbounded Row Number</title><link>https://feed.craftedsignal.io/briefs/2024-01-03-phpspreadsheet-dos/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-03-phpspreadsheet-dos/</guid><description>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.</description><content:encoded><![CDATA[<p>A 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 <code>ColumnAndRowAttributes::readRowAttributes()</code> method lacks a check against the maximum allowed row number (<code>AddressRange::MAX_ROW = 1,048,576</code>). An attacker can exploit this by crafting a minimal XLSX file (approximately 1.6KB) containing a <code>&lt;row r=&quot;999999999&quot;/&gt;</code> element. When processed, this inflates the <code>cachedHighestRow</code> 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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker crafts a malicious XLSX file containing an XML <code>&lt;row&gt;</code> element with a large <code>r</code> attribute (e.g., <code>&lt;row r=&quot;999999999&quot;/&gt;</code>).</li>
<li>The attacker uploads the malicious XLSX file to a web application or system that uses PhpSpreadsheet to process spreadsheet files.</li>
<li>The PhpSpreadsheet library, specifically the <code>IOFactory::createReader('Xlsx')</code> component, is used to read the uploaded file.</li>
<li>During the parsing process, the <code>ColumnAndRowAttributes::readRowAttributes()</code> method reads the large row number from the XML attribute.</li>
<li>The large row number is then used to update the <code>cachedHighestRow</code> property in the <code>Worksheet</code> object, effectively setting it to a very high value.</li>
<li>A subsequent operation that iterates over rows using <code>getRowIterator()</code> or retrieves the highest row using <code>getHighestRow()</code> triggers a loop that iterates up to the inflated <code>cachedHighestRow</code> value.</li>
<li>The excessive number of loop iterations consumes a significant amount of CPU resources, leading to a denial-of-service condition.</li>
<li>The application becomes unresponsive or crashes due to the CPU exhaustion.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>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 <code>getRowIterator()</code> or <code>getHighestRow()</code> 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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Apply the recommended fix by adding row bounds validation in <code>readRowAttributes()</code> to check if <code>$rowIndex</code> is within the acceptable range (1 to <code>AddressRange::MAX_ROW</code>). This is the primary recommendation from the source advisory.</li>
<li>Deploy the Sigma rule <code>Detect PhpSpreadsheet Excessive Row Iteration</code> to detect processes that may be attempting to process XLSX files with extremely high row numbers, indicating a potential exploitation attempt.</li>
<li>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.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>denial-of-service</category><category>phpspreadsheet</category><category>xlsx</category><category>php</category></item></channel></rss>