https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 08 Oct 2026 13:11:59 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-107218 <p>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.</p> <p>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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-107218 https://vulnerability.circl.lu/vuln/ghsa-8jjq-8j9w-m2v6 <p><strong>Affected:</strong> Go: github.com/xuri/excelize/v2</p> <p>`leftRight` (calc.go:14236) tests the length with `countUTF16String`, which counts a rune above U+FFFF as 2. The RIGHT branch on 14241 then slices `[]rune(text)` at `utf8.RuneCountInString(text)-numChars`, which counts it as 1. For text with N such runes the two measures are 2N and N, so any `numChars` between them passes the guard and gives a negative index. The `numChars &lt; 0` check at 14216 does not help, since the value that gets through is positive.</p> <p>What makes it worth reporting is `AutoFitColWidth`, which evaluates formulas without looking like it does, so normalising an uploaded sheet is enough to reach it. One scoping correction to my own wording there: `AutoFitColWidth` was added in v2.11.0 and does not exist at v2.10.1, so on v2.10.1 the only reachable path is an explicit `CalcCellValue`.</p> <p>A 6,077-byte file containing two U+1D7D9 characters in A1 and  RIGHT(A1,3)  in B1 was created and then opened in a separate program without recovery enabled:</p> <p>``` v2.9.1 ok v2.10.0 ok v2.10.1 panic: slice bounds out of range [-1:] v2.11.0 panic: slice bounds out of range [-1:] ```</p> <p>So it is a regression, not an old defect. Commit a880146 (2026-01-16) moved the guard to `countUTF16String` and left the slice on the rune index, and `git tag --contains` gives v2.10.1 and v2.11.0 only.</p> <p>RIGHT only. RIGHTB reaches the same function but takes the byte branch at 14225, which is internally consistent, and I probed MID and MIDB from 1 to 5 with no panic. It is the same negative-in…</p> <p><strong>Affected:</strong> Go: github.com/xuri/excelize/v2</p> <p>`leftRight` (calc.go:14236) tests the length with `countUTF16String`, which counts a rune above U+FFFF as 2. The RIGHT branch on 14241 then slices `[]rune(text)` at `utf8.RuneCountInString(text)-numChars`, which counts it as 1. For text with N such runes the two measures are 2N and N, so any `numChars` between them passes the guard and gives a negative index. The `numChars &lt; 0` check at 14216 does not help, since the value that gets through is positive.</p> <p>What makes it worth reporting is `AutoFitColWidth`, which evaluates formulas without looking like it does, so normalising an uploaded sheet is enough to reach it. One scoping correction to my own wording there: `AutoFitColWidth` was added in v2.11.0 and does not exist at v2.10.1, so on v2.10.1 the only reachable path is an explicit `CalcCellValue`.</p> <p>A 6,077-byte file containing two U+1D7D9 characters in A1 and  RIGHT(A1,3)  in B1 was created and then opened in a separate program without recovery enabled:</p> <p>``` v2.9.1 ok v2.10.0 ok v2.10.1 panic: slice bounds out of range [-1:] v2.11.0 panic: slice bounds out of range [-1:] ```</p> <p>So it is a regression, not an old defect. Commit a880146 (2026-01-16) moved the guard to `countUTF16String` and left the slice on the rune index, and `git tag --contains` gives v2.10.1 and v2.11.0 only.</p> <p>RIGHT only. RIGHTB reaches the same function but takes the byte branch at 14225, which is internally consistent, and I probed MID and MIDB from 1 to 5 with no panic. It is the same negative-in…</p> https://vulnerability.circl.lu/vuln/ghsa-8jjq-8j9w-m2v6