<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T18:03:14.224536+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-59932</id>
    <title>CVE-2026-59932 — PhpSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion</title>
    <updated>2026-09-29T18:03:16.765080+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PHPOffice PhpSpreadsheet</p>
<p>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 Gnumeric reader reads attacker-supplied .gnumeric files into memory and, when the file starts with gzip magic bytes, calls gzdecode() on the full compressed contents without enforcing a decompressed-size limit. A very small compressed .gnumeric file can expand to data larger than the PHP memory limit and crash the process during Gnumeric::canRead() before the file is rejected or fully parsed. This is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service. This issue has been fixed in versions 5.8.1, 3.10.7, 2.4.7, 2.1.18 and 1.30.6.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-59932"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-2mrg-gjxq-2gvr</id>
    <title>GHSA-2mrg-gjxq-2gvr — PHPSpreadsheet: Gnumeric reader unbounded gzip expansion causes memory exhaustion</title>
    <updated>2026-09-29T18:03:16.767970+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Packagist: phpoffice/phpspreadsheet</p>
<p>## Summary</p>
<p>PhpSpreadsheet's Gnumeric reader reads attacker-supplied `.gnumeric` files into memory and, when the file starts with gzip magic bytes, calls `gzdecode()` on the full compressed contents without enforcing a decompressed-size limit. A very small compressed `.gnumeric` file can expand to data larger than the PHP memory limit and crash the process during `Gnumeric::canRead()` before the file is rejected or fully parsed.</p>
<p>This is reachable through normal file-type detection and Gnumeric loading paths, so applications that accept attacker-controlled spreadsheet uploads can suffer denial of service.</p>
<p>## Vulnerability details</p>
<p>`Gnumeric::canRead()` invokes `gzfileGetContents()` before deciding whether the file is a valid Gnumeric spreadsheet:</p>
<p>- `src/PhpSpreadsheet/Reader/Gnumeric.php:80-90` calls `$this-&gt;gzfileGetContents($filename)` from `canRead()`.
- `src/PhpSpreadsheet/Reader/Gnumeric.php:105-115` calls `canRead()` and then reads the expanded contents again for worksheet-name listing.
- `src/PhpSpreadsheet/Reader/Gnumeric.php:253-265` calls `canRead()` and then reads the expanded contents again for full loading.</p>
<p>The vulnerable expansion is in `gzfileGetContents()`:</p>
<p>- `src/PhpSpreadsheet/Reader/Gnumeric.php:187-190` reads the entire input file into `$contents` with `file_get_contents()`.
- `src/PhpSpreadsheet/Reader/Gnumeric.php:192-197` detects gzip magic bytes and calls `gzdecode($contents)` without a decompressed-size cap.
- `src/PhpSpreadsheet/Reader/Gnumeric.…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-2mrg-gjxq-2gvr"/>
  </entry>
</feed>
