Disclosure summary
`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 < 0` check at 14216 does not help, since the value that gets through is positive. 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`. 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: ``` 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:] ``` So it is a regression, not an old defect. Commit a880146 (2026-01-16) moved the guard to `countUTF16String` and
Source-specific records & product guidance
Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.
GitHub Reviewed Security Advisories · GHSA-8jjq-8j9w-m2v6
Open original source · Updated Oct 07, 2026
Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics
Source severity: MEDIUM / 0
| Ecosystem | Package | Affected range | First patched |
|---|---|---|---|
| go | github.com/xuri/excelize/v2 | >= 2.10.1, < 2.11.1-0.20260908032718-ecd99d761fe0 | 2.11.1-0.20260908032718-ecd99d761fe0 |
Original records & references
- NIST NVD record
- CVE Program record
- github.com — Reviewed advisory
PUBLISHED 2026-10-07T16:23:26-04:00
MODIFIED 2026-10-07T16:23:27-04:00
INGESTED 2026-10-08T12:30:38-04:00