<?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-10T10:30:21.531994+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-107216</id>
    <title>fkie_cve-2026-107216</title>
    <updated>2026-10-10T10:30:21.560439+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.8.1 to 2.11.0, ANCHORARRAY recursively calls the exported CalcCellValue function, creating a fresh calculation context at each cycle and bypassing in-flight and iteration controls. ANCHORARRAY calls CalcCellValue instead of cellResolver, so each recursive hop receives a new calcContext and loses cycle state. When mutually referencing dynamic-array formulas are evaluated directly or through formula-evaluating APIs, each recursion hop resets the cycle budget and prevents completion-based caches from breaking the cycle, allowing an attacker to cause a fatal Go stack overflow and abort the process. No fixed version is available as of this review.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-107216"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-wp2g-vpjj-g53r</id>
    <title>GHSA-wp2g-vpjj-g53r — Excelize ANCHORARRAY: mutually-referencing array formulas recurse unboundedly via re-entrant CalcCellValue, causing a f…</title>
    <updated>2026-10-10T10:30:21.560553+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>`ANCHORARRAY` (calc.go:15137 on current master) evaluates each cell of the referenced spill range by calling the **exported** `CalcCellValue`, which unconditionally constructs a fresh `calcContext` — fresh entry marker, fresh iterations map, full `MaxCalcIterations` budget (calc.go:896-900). The circular-reference control only exists **within one context**: the entry-exclusion marker and per-ref iteration budget are fields of that single context, and completion-based caching (`formulaArgCache`/`calcRawCache`) only ever stores results of evaluations that *finish*.</p>
<p>During a pure cycle no nested evaluation ever finishes, so nothing is ever cached to break the recursion, and each hop re-arms the entire budget. Two ordinary, Excel-legal constructs in an attacker-supplied workbook are enough:</p>
<p>- `A1` (dynamic array formula, ref `A1:A1`): `_xlfn.ANCHORARRAY($B$1)`
- `B1` (dynamic array formula, ref `B1:B1`): `_xlfn.ANCHORARRAY($A$1)`</p>
<p>→ `CalcCellValue → calcCellValue → evalInfixExp → parseReference → cellResolver → … → ANCHORARRAY → CalcCellValue → …` forever, ending in a **fatal, unrecoverable** Go runtime error: `runtime: goroutine stack exceeds …-byte limit / fatal error: stack overflow`. Go stack overflows cannot be recovered — the whole process aborts.</p>
<p>### Details</p>
<p>- The terminating edge the iterations gate is supposed to provide does not exist across contexts: there is no in-flight tracking shared between nested `CalcCellValue` calls.
- Both formulas are ordina…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-wp2g-vpjj-g53r"/>
  </entry>
</feed>
