Excelize EUVD-2026-94530

Exploitation requires ALL of: (1) the application uses Excelize version 2.9.0 through 2.11.0; (2) the application calls File.GetSlicers on a worksheet whose content is attacker-influenced; (3) the crafted worksheet XML contains a worksheet extLst element while the independently optional worksheet drawing element is absent (so ws.ExtLst is non-nil but ws.Drawing is nil); and (4) the hosting process is 'unprotected' - i.e. it does not wrap the call in a recover(), so the panic terminates it. Limiting factors: GetSlicers is not part of the default file-open/parse path, so an application that never calls it is not exposed; impact is limited to a crash (no code execution, data disclosure, or integrity loss); and any panic-recovery middleware neutralizes the DoS.

The signals are consistent but point to a moderate, impact-limited risk rather than a top priority. The provided CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N) with VA:H and VC:N/VI:N yields a high score (8.7) driven ENTIRELY by availability - this is a pure denial-of-service nil-pointer dereference (CWE-476), with no confidentiality or integrity impact. No EPSS score was provided, and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis' (the GitHub artifacts are the vendor fix PR and a regression test, not weaponized exploit code). A key caveat on the CVSS vector: the AV:N / PR:N / UI:N rating assumes the vulnerable function is reachable with attacker-controlled input over a network without interaction, but the flaw is only triggered when an application explicitly calls File.GetSlicers on an attacker-supplied spreadsheet - real-world reachability is therefore application-dependent and narrower than AV:N/UI:N implies; verify against actual deployment. The single most aggravating factor is that, per the advisory, NO fixed version is available as of this review, so no clean upgrade path exists yet. Net: a legitimate DoS bug worth patching when a release lands, but not a drop-everything emergency given DoS-only impact, no known exploitation, and conditional reachability.

A Go backend service built on Excelize 2.9.0-2.11.0 accepts user-uploaded .xlsx files and calls File.GetSlicers to enumerate slicers. An attacker uploads a crafted workbook whose worksheet contains an extLst element but no drawing element; when GetSlicers dereferences the nil ws.Drawing pointer, the process panics and the unprotected service crashes. No public exploit code was identified, but the trigger is trivial to construct and the fix PR/test publicly demonstrate the exact malformed structure.