<?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://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-10T14:38:26.552777+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" 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://db.gcve.eu/vuln/fkie_cve-2026-107212</id>
    <title>fkie_cve-2026-107212</title>
    <updated>2026-10-10T14:38:26.580491+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, Rows.Columns accepts a look-ahead row number above TotalRows without applying the limit enforced by Rows.Next. File.GetRows relies on Rows.Next and Rows.Columns, but Rows.Columns consumes the row r attribute without the limit check in Rows.Next. When a crafted worksheet places an oversized row number after an ordinary valid row and the application calls GetRows or iterates Rows, the iterator advances through every missing row number instead of rejecting the workbook, allowing an attacker to consume a CPU core for an attacker-controlled duration. No fixed version is available as of this review.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-107212"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-jw42-f3rr-4cc3</id>
    <title>GHSA-jw42-f3rr-4cc3 — Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days</title>
    <updated>2026-10-10T14:38:26.580574+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/xuri/excelize/v2</p>
<p>### Summary</p>
<p>A worksheet whose `&lt;row r="..."&gt;` number is far past Excel's 1,048,576-row limit makes `File.GetRows` and the `Rows` iterator loop once for every missing row. The row limit is checked in `Rows.Next`, but not in `Rows.Columns`, which also reads `&lt;row&gt;` elements. A 1.5 KB file with `&lt;row r="231999999999940"&gt;` after an ordinary first row keeps `GetRows` busy for an estimated 11 days (about 4 ns per missing row), using one CPU core and little memory. Any service that calls `GetRows` or iterates `Rows` on an uploaded workbook can be tied up by a single request.</p>
<p>### Details</p>
<p>`Rows.Next` checks the row number:</p>
<p>```go
rowNum, _ := attrValToInt("r", xmlElement.Attr)
if rowNum &gt; TotalRows {
    rows.err = ErrMaxRows
    return false
}
```</p>
<p>But `Rows.Columns` reads the cells of the current row by consuming tokens until it reaches the *next* `&lt;row&gt;` element, and it sets `rows.curRow` from that element's `r` without the check (rows.go, around line 179 at 3985c1f):</p>
<p>```go
if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
    rows.curRow = rowNum
}
```</p>
<p>After that, `rows.curRow` is 231999999999940, and each later `Next()` call takes the `rows.curRow &gt;= rows.seekRow` shortcut and returns `true` without reading any XML. `GetRows` then calls `Next()` and `Columns()` once per row number from 2 to 231999999999940. The check in `Next()` never runs, because the oversized `&lt;row&gt;` element was already consumed by `Columns()`.</p>
<p>If the oversized row is the *f…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-jw42-f3rr-4cc3"/>
  </entry>
</feed>
