GHSA-8jjq-8j9w-m2v6

`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 left the slice on the rune index, and `git tag --contains` gives v2.10.1 and v2.11.0 only. 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-index family as GHSA-fx5j-qcqg-grpf and GHSA-48hm-4h8j-58fg, though those are shared-string lookups in the reader rather than a unit mismatch in the formula library.