<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 10 Oct 2026 14:38:26 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-107212</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-107212</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-107212</guid>
    </item>
    <item>
      <title>GHSA-jw42-f3rr-4cc3 — Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days</title>
      <link>https://db.gcve.eu/vuln/ghsa-jw42-f3rr-4cc3</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/xuri/excelize/v2&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A worksheet whose `&amp;lt;row r=&amp;#34;...&amp;#34;&amp;gt;` number is far past Excel&amp;#39;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 `&amp;lt;row&amp;gt;` elements. A 1.5 KB file with `&amp;lt;row r=&amp;#34;231999999999940&amp;#34;&amp;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`Rows.Next` checks the row number:&lt;/p&gt;
&lt;p&gt;```go
rowNum, _ := attrValToInt(&amp;#34;r&amp;#34;, xmlElement.Attr)
if rowNum &amp;gt; TotalRows {
    rows.err = ErrMaxRows
    return false
}
```&lt;/p&gt;
&lt;p&gt;But `Rows.Columns` reads the cells of the current row by consuming tokens until it reaches the *next* `&amp;lt;row&amp;gt;` element, and it sets `rows.curRow` from that element&amp;#39;s `r` without the check (rows.go, around line 179 at 3985c1f):&lt;/p&gt;
&lt;p&gt;```go
if rowNum, rowIterator.err = attrValToInt(&amp;#34;r&amp;#34;, xmlElement.Attr); rowNum != 0 {
    rows.curRow = rowNum
}
```&lt;/p&gt;
&lt;p&gt;After that, `rows.curRow` is 231999999999940, and each later `Next()` call takes the `rows.curRow &amp;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 `&amp;lt;row&amp;gt;` element was already consumed by `Columns()`.&lt;/p&gt;
&lt;p&gt;If the oversized row is the *f…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/xuri/excelize/v2&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;A worksheet whose `&amp;lt;row r=&amp;#34;...&amp;#34;&amp;gt;` number is far past Excel&amp;#39;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 `&amp;lt;row&amp;gt;` elements. A 1.5 KB file with `&amp;lt;row r=&amp;#34;231999999999940&amp;#34;&amp;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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;`Rows.Next` checks the row number:&lt;/p&gt;
&lt;p&gt;```go
rowNum, _ := attrValToInt(&amp;#34;r&amp;#34;, xmlElement.Attr)
if rowNum &amp;gt; TotalRows {
    rows.err = ErrMaxRows
    return false
}
```&lt;/p&gt;
&lt;p&gt;But `Rows.Columns` reads the cells of the current row by consuming tokens until it reaches the *next* `&amp;lt;row&amp;gt;` element, and it sets `rows.curRow` from that element&amp;#39;s `r` without the check (rows.go, around line 179 at 3985c1f):&lt;/p&gt;
&lt;p&gt;```go
if rowNum, rowIterator.err = attrValToInt(&amp;#34;r&amp;#34;, xmlElement.Attr); rowNum != 0 {
    rows.curRow = rowNum
}
```&lt;/p&gt;
&lt;p&gt;After that, `rows.curRow` is 231999999999940, and each later `Next()` call takes the `rows.curRow &amp;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 `&amp;lt;row&amp;gt;` element was already consumed by `Columns()`.&lt;/p&gt;
&lt;p&gt;If the oversized row is the *f…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-jw42-f3rr-4cc3</guid>
    </item>
  </channel>
</rss>
