{"id":"CVE-2026-107218","aliases":["EUVD-2026-94548","GHSA-8jjq-8j9w-m2v6","GO-2026-6675"],"status":"published","title":"Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics","description":"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.","severity":{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00309,"percentile":0.24061,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-129"],"published":"2026-10-07T18:29:38Z","modified":"2026-11-05T23:26:05Z","fixes":[{"ecosystem":"Go","package":"github.com/xuri/excelize/v2","fixed_in":["2.11.1-0.20260908032718-ecd99d761fe0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/xuri/excelize/v2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.10.1"},{"fixed":"2.11.1-0.20260908032718-ecd99d761fe0"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/xuri/excelize/v2","ranges":[{"type":"SEMVER","events":[{"introduced":"2.10.1"},{"fixed":"2.11.1-0.20260908032718-ecd99d761fe0"}]}]}],"products":[{"vendor":"excelize","product":"excelize"},{"vendor":"qax-os","product":"excelize"}],"references":[{"url":"https://github.com/qax-os/excelize/security/advisories/GHSA-8jjq-8j9w-m2v6","tags":["x_refsource_CONFIRM","Exploit","Vendor Advisory","advisory","web"]},{"url":"https://github.com/qax-os/excelize/pull/2390","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/qax-os/excelize/commit/ecd99d761fe0489f1ed308e2f7dc2e0502d1a396","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/advisories/GHSA-8jjq-8j9w-m2v6"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/107xxx/CVE-2026-107218.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-107218","tags":["advisory"]},{"url":"https://github.com/qax-os/excelize","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-107218","title":"Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics","description":"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.","status":"published","published":"2026-10-07T18:29:38.606Z","modified":"2026-10-07T22:05:36.155Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-129"],"updated_at":"2026-11-02T13:45:14.072357Z"}],"euvd":[{"id":"EUVD-2026-94548","description":"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.","status":"published","published":"2026-10-07T18:29:38Z","modified":"2026-10-07T22:05:36Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T17:27:33.555595Z"}],"ghsa":[{"id":"GHSA-8jjq-8j9w-m2v6","title":"Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics","description":"`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 \u003c 0` check at 14216 does not help, since the value that gets through is positive.\n\nWhat 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`.\n\nA 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:\n\n```\nv2.9.1    ok\nv2.10.0   ok\nv2.10.1   panic: slice bounds out of range [-1:]\nv2.11.0   panic: slice bounds out of range [-1:]\n```\n\nSo 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.\n\nRIGHT 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.","status":"published","published":"2026-10-07T20:23:26Z","modified":"2026-10-07T20:23:27Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-129"],"updated_at":"2026-11-02T14:41:28.013673Z"}],"nvd":[{"id":"CVE-2026-107218","description":"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.","status":"published","published":"2026-10-07T19:17:34.12Z","modified":"2026-10-13T14:23:29.317Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-129"],"updated_at":"2026-11-02T14:12:54.809359Z"}],"osv":[{"id":"CVE-2026-107218","title":"Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics","description":"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.","status":"published","published":"2026-10-07T18:29:38.606Z","modified":"2026-11-05T23:26:05.817251679Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-129"],"updated_at":"2026-11-06T00:02:13.631839Z"},{"id":"GHSA-8jjq-8j9w-m2v6","title":"Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics","description":"`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 \u003c 0` check at 14216 does not help, since the value that gets through is positive.\n\nWhat 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`.\n\nA 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:\n\n```\nv2.9.1    ok\nv2.10.0   ok\nv2.10.1   panic: slice bounds out of range [-1:]\nv2.11.0   panic: slice bounds out of range [-1:]\n```\n\nSo 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.\n\nRIGHT 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.","status":"published","published":"2026-10-07T20:23:26Z","modified":"2026-11-05T23:26:05.817251679Z","cvss":[{"version":"3.1","score":5.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L","level":"medium"}],"cwes":["CWE-129"],"updated_at":"2026-11-06T00:02:13.631839Z"}]}}