Summary
Excelize ANCHORARRAY: mutually-referencing array formulas recurse unboundedly via re-entrant CalcCellValue, causing a fatal stack overflow
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, refA1:A1):_xlfn.ANCHORARRAY($B$1)B1(dynamic array formula, refB1: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
CalcCellValuecalls. - 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:
MaxCalcIterationsis 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 (CYCLE_TERMINATED) and existing calc tests pass.
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.
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.
CVE-2026-107216 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.11.1-0.20260911060113-ea12859e43c6); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-107216? CVE-2026-107216 is a high-severity security vulnerability in github.com/xuri/excelize/v2 (go), affecting versions >= 2.8.1, < 2.11.1-0.20260911060113-ea12859e43c6. It is fixed in 2.11.1-0.20260911060113-ea12859e43c6.
- How severe is CVE-2026-107216? CVE-2026-107216 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/xuri/excelize/v2 are affected by CVE-2026-107216? github.com/xuri/excelize/v2 (go) versions >= 2.8.1, < 2.11.1-0.20260911060113-ea12859e43c6 is affected.
- Is there a fix for CVE-2026-107216? Yes. CVE-2026-107216 is fixed in 2.11.1-0.20260911060113-ea12859e43c6. Upgrade to this version or later.
- Is CVE-2026-107216 exploitable, and should I be worried? Whether CVE-2026-107216 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-107216 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-107216? Upgrade
github.com/xuri/excelize/v2to 2.11.1-0.20260911060113-ea12859e43c6 or later.