CVE-2026-107215 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, extractPart allocates a byte slice directly from an attacker-controlled CFB directory-entry size before validating the sector chain or size domain. extractPart trusts the CFB directory entry streamSize for EncryptionInfo and EncryptedPackage allocations before validating the stream. When a crafted OLE compound file declares a negative or extremely large EncryptionInfo or EncryptedPackage stream size, the declared size reaches make with a negative length or forces a multi-gigabyte allocation, allowing an attacker to panic or exhaust process memory. 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 the Excelize library represents a critical resource exhaustion flaw rooted in improper input validation during the parsing of Microsoft Compound File Binary (CFB) structures. Excelize, widely used for its ability to read and write Excel spreadsheets within Go applications, processes OLE compound files which utilize a specific directory entry format to describe streams and storage objects. The core technical defect lies within the extractPart function, where memory allocation is performed before critical security checks are executed. Specifically, when processing EncryptionInfo or EncryptedPackage streams, the library trusts the streamSize field provided in the CFB directory entry without first validating whether this size falls within a legitimate domain or if it corresponds to a valid sector chain. This inversion of validation logic allows an attacker to craft a malicious OLE compound file that declares negative values or extremely large integers for these specific stream sizes.
From a technical perspective, the flaw exploits how Go handles slice allocations based on input parameters. When make is called with a length derived from an untrusted source such as the CFB directory entry size, and that value is negative, it results in a panic due to invalid memory operations. Conversely, if the declared size is excessively large but positive, the application attempts to allocate multi-gigabyte blocks of RAM. This behavior directly leads to either immediate denial of service through process termination or gradual resource exhaustion as the system struggles to satisfy massive allocation requests. The lack of bounds checking on the streamSize field before memory commitment creates a straightforward path for remote attackers to destabilize any service relying on Excelize for document processing, particularly in scenarios where untrusted files are uploaded and processed automatically.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition against applications that ingest user-supplied spreadsheet data. In cloud environments or web services that process Excel documents, an attacker can trigger high CPU usage due to allocation failures or consume all available memory on the host server, causing crashes for other tenants or processes sharing the same resources. This aligns with CWE-789, which classifies improper control of resource consumption, and specifically relates to CWE-400 regarding uncontrolled resource consumption. The attack vector is typically remote via file upload mechanisms, making it a significant risk for any application that accepts Excel files from external sources without rigorous sanitization or size limits prior to parsing.
Mitigation strategies must focus on implementing strict input validation before invoking memory allocation routines. Developers should enforce maximum allowable sizes for stream entries and validate that the declared sector chain is consistent with the file structure before attempting to read data into memory buffers. Additionally, applying resource quotas at the application level can limit the impact of such attacks by capping total memory usage per request or process. Since no fixed version was available during the review period, immediate remediation requires patching the extractPart function locally within the dependent project’s codebase to ensure that size validation precedes any make calls involving attacker-controlled data. Long-term resolution involves monitoring for upstream releases from the Excelize maintainers and updating dependencies once a patched version is published to restore secure processing of compound file formats.