CVE-2026-107218 in excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.10.1 to 2.11.0, RIGHT validates the requested length with UTF-16 code-unit counts but slices a rune array using Unicode code-point counts. RIGHT reaches leftRight through CalcCellValue, where countUTF16String validates one unit but utf8.RuneCountInString supplies the slice index in another. When RIGHT evaluates supplementary-plane text with a requested character count between the rune count and UTF-16 code-unit count, the inconsistent units produce a negative rune-slice index, allowing an attacker to panic during formula evaluation. No fixed version is available as of this review.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in the Excelize library affects versions ranging from 2.10.1 through 2.11.0 and involves a critical type confusion error within the implementation of the RIGHT string function used for parsing Microsoft Excel formulas. Excelize is widely utilized by developers to programmatically read and write Excel spreadsheets, making it a common component in enterprise data processing pipelines where untrusted or semi-trusted spreadsheet files are processed automatically. The core issue lies in how the library handles character counting when slicing strings during formula evaluation. Specifically, the RIGHT function relies on an internal calculation path that validates input length using UTF-16 code-unit counts but subsequently attempts to slice a rune array based on Unicode code-point counts. This discrepancy creates a fundamental mismatch between the validation logic and the actual memory access operation.
The technical flaw manifests when processing supplementary-plane text, which consists of characters represented by surrogate pairs in UTF-16 encoding. In such cases, one Unicode character corresponds to two UTF-16 code units. The function rightRight invokes CalcCellValue, which calls countUTF16String to determine the length of the string based on UTF-16 metrics. However, when performing the actual slice operation via utf8.RuneCountInString, the library calculates indices using rune counts, where each character is treated as a single unit regardless of its encoding size. When an attacker provides input with supplementary-plane characters and requests a count that falls between the total number of runes and the total number of UTF-16 code units, the validation passes because the UTF-16 length appears sufficient. However, the subsequent slice operation calculates a negative index due to the arithmetic mismatch between these two counting methods.
This inconsistency leads directly to an out-of-bounds read or write condition that triggers a panic during formula evaluation rather than returning a controlled error message. In Go applications utilizing Excelize, such panics can cause the entire application process to crash if not properly recovered from at a higher level in the call stack. For services processing uploaded spreadsheet files with complex formulas containing special characters, this vulnerability allows for denial of service attacks against the hosting infrastructure. An attacker does not need authentication or high privileges; they merely need to supply a crafted Excel file containing specific formulaic structures that exploit this encoding discrepancy. The impact is severe in environments where automated report generation or data import processes are performed without rigorous input sanitization layers above the library level.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-824 Access of Memory Location After End of Heap-Allocated Buffer, as the negative index results in invalid memory access patterns that destabilize the runtime environment. In terms of adversary behavior, this flaw facilitates exploitation consistent with ATT&CK technique T1499 Endpoint Denial of Service, where an attacker leverages software vulnerabilities to disrupt availability rather than compromising confidentiality or integrity directly. The lack of a fixed version as of the review period indicates that users must rely on workarounds such as implementing strict input validation before passing strings to Excelize functions, restricting the types of formulas allowed in processed files, or deploying panic recovery mechanisms within their Go applications to mitigate immediate risks until an official patch is released by the maintainers.