CVE-2026-107216: Excelize ANCHORARRAY: mutually-referencing array formulas recurse unboundedly via re-entrant CalcCellValue, causing a fatal stack overflow
Summary
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.
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:
- A1 (dynamic array formula, ref A1:A1): xlfn.ANCHORARRAY($B$1) - B1 (dynamic array formula, ref B1:B1): xlfn.ANCHORARRAY($A$1)
→ 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.
Details
- 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 ordinary Excel-legal constructs; no exotic XML is required. - Excelize's own APIs reach formula evaluation on untrusted cells implicitly (e.g. pivotTable.go:538, picture.go:985/1141, col.go:892), so a service that merely adds a pivot table or a picture over such a workbook dies. - No option value prevents it: MaxCalcIterations is irrelevant because every hop gets a fresh budget. - Measured: a 64 MB stack budget is exhausted in ~0.09 s; the ~1 GB default in ~1–2 s.
PoC
A standalone program (public API only) was provided to the maintainer by email (4-anchorarray-recursion): NewFile + SetCellFormula with FormulaOpts{Type: array, Ref: A1:A1 / B1:B1}, then CalcCellValue("Sheet1","A1"). On master ecd99d761fe0 (2026-09-08) the process aborts with fatal error: stack overflow; with the proposed patch the cycle terminates normally (CYCLETERMINATED) and existing calc tests pass.
Impact
An attacker ships a workbook containing the two formulas; any service that evaluates a formula over those cells — directly via CalcCellValue, or implicitly via AddPivotTable / AddPicture / auto-fit — aborts. Remote, unauthenticated, process-fatal, no configuration prevents it.
Proposed fix
Evaluate spill-range cells through the current calculation context — fn.f.cellResolver(fn.ctx, …) instead of the exported CalcCellValue — so the entry check and iterations gate of the running calculation apply. cellResolver returns the typed value directly (dropping a string round-trip); an ArgEmpty → "" shim preserves the existing ToNumber behavior for empty spill cells, and a fresh-context fallback covers the legacy nil-ctx test paths. A complete patch has been provided to the maintainer.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/xuri/excelize/v2to a version that resolves this vulnerability.Fixed in 2.11.1-0.20260911060113-ea12859e43c6 - Compensating control
Modify ANCHORARRAY to evaluate spill-range cells through the current calculation context using fn.f.cellResolver(fn.ctx, …) instead of the exported CalcCellValue, so the running calculation's entry check and iteration gate apply.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using Excelize versions 2.8.1 through 2.11.0 are exposed when they evaluate attacker-controlled or otherwise untrusted workbooks containing mutually referencing dynamic-array formulas. The impact is process termination from a fatal Go stack overflow.
What must an attacker provide to trigger the crash?
The attacker needs a workbook with mutually referencing dynamic-array formulas involving ANCHORARRAY, and the application must evaluate those formulas directly or through a formula-evaluating API. No authentication or user interaction is required according to the supplied severity vector.
Are standard calculation cycle controls sufficient mitigation?
No. Each recursive ANCHORARRAY evaluation creates a new calculation context, losing cycle state and resetting the cycle budget; completion-based caches also do not break the cycle.
What can be done while no fixed version is available?
Avoid evaluating untrusted workbooks or formulas that may contain mutually referencing dynamic-array formulas. If formula evaluation is required, isolate it so that a crash does not abort the primary application process.