CVE-2026-107214 in Excelize
Summary
by MITRE • 10/07/2026
Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.3.1 to 2.11.0, the decryption dispatch performs insufficient structural and parameter validation before standard and agile decryptors slice, index, allocate, and divide using attacker-controlled values. Decrypt passes attacker-controlled EncryptionInfo and EncryptedPackage data into standardDecrypt or agileDecrypt before validating the structures used by those routines. When a malformed OLE compound file with a version-valid EncryptionInfo stream is opened or passed to Decrypt, nine malformed-input classes reach unrecovered Go runtime panics instead of the documented error path, allowing an attacker to terminate the calling process. No fixed version is available as of this review.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in Excelize versions 2.3.1 through 2.11.0 represents a critical flaw in the library's handling of encrypted Microsoft Office Open XML documents, specifically within its decryption dispatch logic. As a widely used Go language library for reading and writing spreadsheets, Excelize is frequently integrated into backend services that process user-uploaded files or ingest data from external sources. The core issue stems from an incorrect order of operations during the processing of OLE compound file structures containing encryption metadata. When a document with EncryptionInfo streams is processed, the software attempts to route the decryption task to either standardDecrypt or agileDecrypt routines before performing necessary structural and parameter validation on those inputs. This architectural oversight means that attacker-controlled values within malformed files are passed directly into low-level memory operations such as slicing, indexing, allocating, and dividing without prior sanitization checks.
This lack of input validation leads to a class of nine distinct malformed-input scenarios where the Go runtime encounters unrecoverable panics rather than returning standard error codes. In normal operation, software should validate file structures against expected schemas before attempting complex memory manipulations. However, in this case, the decryption routines assume that the EncryptionInfo and EncryptedPackage data are well-formed. When an attacker provides a crafted OLE compound file with a version-valid but structurally malformed EncryptionInfo stream, the library proceeds to execute operations on invalid indices or sizes. Because Go does not have built-in bounds checking for all memory access patterns in every context, these invalid accesses trigger runtime panics that crash the calling process immediately. This behavior transforms what should be a recoverable parsing error into a Denial of Service condition.
The operational impact of this vulnerability is significant for any service relying on Excelize to handle untrusted input. An attacker can exploit this flaw by submitting specially crafted Excel files via file upload endpoints, API inputs, or data ingestion pipelines. The successful exploitation results in the termination of the application process hosting the vulnerable library instance. In a web server context, this manifests as an HTTP 500 Internal Server Error and potentially causes thread exhaustion if the service attempts to restart automatically without proper health checks. For long-running background workers processing batch files, each malicious file can consume system resources before crashing the worker, leading to degraded performance or complete unavailability of the service depending on the deployment architecture. This is not a remote code execution vulnerability in this specific instance, but rather a robust Denial of Service vector that undermines availability guarantees.
From a classification perspective, this flaw aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write or Access, as the root cause involves accessing memory structures based on unverified external data. The attack pattern corresponds to ATT&CK technique T1499 Endpoint Denial of Service, where an adversary uses malformed inputs to disrupt service availability. Since no fixed version is currently available as of this review, mitigation strategies must focus on defensive programming practices and infrastructure-level controls. Organizations should implement strict file type validation at the network perimeter or load balancer level before files reach the application layer using libraries like Excelize. Additionally, implementing a watchdog process that monitors for unexpected exits in services utilizing this library can help mitigate availability impacts by automatically restarting crashed instances. Developers integrating older versions of Excelize are advised to isolate processing tasks within sandboxed environments or goroutines with deferred recovery mechanisms to catch panics and prevent them from terminating the entire application context until an official patch is released.