CVE-2026-107213 in Excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.9.0 to 2.11.0, GetSlicers checks for ExtLst but dereferences ws.Drawing without checking whether the independently optional drawing element exists. File.GetSlicers reads ws.Drawing.RID after seeing a worksheet extLst element even when the independently optional worksheet drawing element is absent. When a crafted worksheet contains an extLst element without a drawing element and the application calls GetSlicers, the nil ws.Drawing pointer is dereferenced while resolving the drawing relationship, allowing an attacker to panic and terminate an unprotected process. No fixed version is available as of this review.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Excelize versions 2.9.0 through 2.11.0 represents a critical logic error within the library's handling of Microsoft Excel spreadsheet structures, specifically concerning the retrieval of slicer objects. Excelize serves as a widely adopted Go language library for programmatically reading and writing Microsoft Excel files, making its robustness essential for applications that process financial data, reports, or any structured information stored in XLSX formats. The core issue resides within the GetSlicers function, which is designed to extract slicer definitions from a worksheet. Slicers are interactive filtering controls used in Excel dashboards and pivot tables, and their proper parsing requires accurate interpretation of the underlying XML structure defined by the Office Open XML standard.
The technical flaw stems from an incorrect assumption regarding the presence of dependent elements within the spreadsheet's internal package structure. In the OOXML specification, worksheet extensions listed under extLst are optional features that may reference external resources such as drawings or charts. The vulnerable code path checks for the existence of an extLst element to determine if slicers might be present. However, upon finding this extension list, the function proceeds to dereference the ws.Drawing pointer without verifying whether the corresponding drawing relationship actually exists in the workbook's relationships file. This creates a scenario where the presence of an extLst entry triggers access to a nil object reference because the independent optional drawing element is absent from the crafted input file.
This logic error results in a nil pointer dereference when the application attempts to resolve the drawing relationship associated with the slicer definition. In Go, such an operation causes a runtime panic that terminates the executing process unless explicitly recovered by higher-level code. For applications relying on Excelize to parse user-uploaded or untrusted spreadsheet files, this vulnerability allows for a Denial of Service attack. An attacker can craft a malicious XLSX file containing specific extLst entries without accompanying drawing relationships. When an unprotected service processes this file and invokes GetSlicers, the resulting panic crashes the server or application instance, leading to significant operational disruption and potential data loss if state is not persisted safely before termination.
From a classification perspective, this vulnerability aligns with CWE-476, which denotes a nil pointer dereference error. This type of flaw occurs when software attempts to use an object reference that has not been properly initialized or validated for existence prior to access. Furthermore, the attack vector relates to ATT&CK technique T1505.003, Server Software Component: Web Shell, in contexts where web services process uploaded files, although more accurately it falls under general service disruption via malformed input processing rather than persistent backdoor installation. The lack of defensive programming practices in handling optional XML components highlights a gap in validation logic that is common in libraries parsing complex binary or structured text formats like OOXML.
Mitigation strategies for this vulnerability are currently limited by the absence of an official patch from the maintainers as of the review period. Organizations using affected versions must implement immediate workarounds to prevent exploitation. The primary recommendation is to upgrade Excelize to a version where this logic error has been corrected, once such a release becomes available. In the interim, developers should wrap calls to GetSlicers and similar functions that interact with worksheet drawing elements within panic recovery blocks using Go's defer and recover mechanisms. This ensures that even if a nil pointer dereference occurs due to malformed input, the application can catch the exception, log the error appropriately, and continue operating without crashing. Additionally, implementing strict validation of incoming XLSX files against expected schema constraints before processing them through Excelize functions can reduce the attack surface by filtering out structurally invalid documents that trigger these edge cases.