CVE-2026-107218: Excelize RIGHT() On Supplementary-plane Text Slices Vulnerability
MODERATECVE-2026-107218 is a MODERATE (CVSS 5.3) right() on supplementary-plane text slices vulnerability (CWE-129: Improper Validation of Array Index) affecting Excelize libraries in the Go ecosystem. The issue involves right() on supplementary-plane text slices with a negative index and panics. Remediation is available by upgrading affected packages to version 2.11.1-0.20260908032718-ecd99d761fe0.
CVE-2026-107218 at a Glance
Security Impact
CVSS: 5.3
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).
How to Fix CVE-2026-107218
To remediate this vulnerability, upgrade all affected Excelize dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
Upgrade github.com/xuri/excelize/v2 to 2.11.1-0.20260908032718-ecd99d761fe0Run the following command in your project directory to verify that all resolved dependencies use the patched release:
inspect dependencies for github.com/xuri/excelize/v2How to Check if You Are Affected
To determine whether your application is affected by CVE-2026-107218, inspect your project dependencies for Excelize:
inspect dependencies for github.com/xuri/excelize/v2Analyze the terminal output to locate any version of Excelize in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.11.1-0.20260908032718-ecd99d761fe0), your application is affected.
Note: Verify declared build manifests and deployed runtime container environments.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-129: Improper Validation of Array Index, where the product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array. In Excelize, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-107218 Affected Excelize Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
github.com/xuri/excelize/v2
|
Go |
≥ 2.10.1
< 2.11.1-0.20260908032718-ecd99d761fe0
|
2.11.1-0.20260908032718-ecd99d761fe0
|
References
Frequently Asked Questions
What is CVE-2026-107218?
Which Excelize versions are affected?
What version fixes CVE-2026-107218?
Is github.com/xuri/excelize/v2 affected?
What is the CVSS score of CVE-2026-107218?
What CWE is associated with CVE-2026-107218?
How can I check Go dependencies for CVE-2026-107218?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-8jjq-8j9w-m2v6",
"modified" : "2026-10-07T20:23:27Z",
"published" : "2026-10-07T20:23:26Z",
"aliases" : [ "CVE-2026-107218" ],
"summary" : "Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics",
"details" : "`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.\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.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "Go",
"name" : "github.com/xuri/excelize/v2"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "2.10.1"
}, {
"fixed" : "2.11.1-0.20260908032718-ecd99d761fe0"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/qax-os/excelize/security/advisories/GHSA-8jjq-8j9w-m2v6"
}, {
"type" : "WEB",
"url" : "https://github.com/qax-os/excelize/pull/2390"
}, {
"type" : "WEB",
"url" : "https://github.com/qax-os/excelize/commit/ecd99d761fe0489f1ed308e2f7dc2e0502d1a396"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/qax-os/excelize"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-129" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-10-07T20:23:26Z",
"nvd_published_at" : null
}
}