Unbounded Decryption SpinCount Denial of Service in Excelize

The Excelize Go library (versions 2.3.1 through 2.11.0) contains a denial-of-service vulnerability triggered by the lack of bounds checking on the spinCount parameter during the agile decryption process. The library branches into the decryption routine based solely on the first eight bytes of a file (the OLE magic number), regardless of whether the file is legitimately encrypted or if the application supports encrypted workbooks.

The crypt.go module reads the spinCount value directly from the XML-unmarshaled EncryptionInfo stream without validation. An attacker can supply an arbitrarily large integer for spinCount, forcing the convertPasswdToKey function to perform a CPU-intensive key derivation loop for that many iterations. Because the operation does not accept a context.Context, it cannot be canceled by the caller, leading to prolonged CPU exhaustion that persists even after the calling application hits request timeouts. The vulnerability impacts any application using Excelize to parse untrusted OLE files.

Attack Chain

1. Attacker crafts a malicious file, ensuring the first eight bytes match the OLE magic number to trigger the Excelize file-parsing routine.
2. Attacker embeds a crafted EncryptionInfo stream within the file structure.
3. Attacker sets the spinCount element in the XML stream to a high integer value (e.g., 100,000,000+).
4. Victim application attempts to open the file using excelize.OpenFile.
5. openReaderAt detects the OLE header and invokes agileDecrypt without verifying if the file requires decryption.
6. agileDecrypt calls convertPasswdToKey, which initiates a long-running loop based on the attacker-controlled spinCount.
7. The process consumes CPU resources linearly, causing high load and blocking the goroutine from returning, resulting in an effective Denial of Service for the application instance.

Impact

Successful exploitation results in a Denial of Service (DoS) for the application processing the file. Since the operations run independently of the caller context, resources remain locked until the loop finishes, potentially exhausting server CPU resources if multiple malicious files are submitted concurrently. This vulnerability primarily affects applications that process user-uploaded Excel files (e.g., web-based document converters, data analysis tools, or enterprise reporting portals).

Recommendation

Prioritized actions for development and security teams:

• Upgrade the Excelize library to version 2.11.1-0.20260906004932-2badfcd5841d or later to implement proper bounds checking on the spinCount value.
• Implement file-size or process-time limits at the application layer for all file parsing routines that utilize Excelize, as the library does not natively support context-based cancellation.
• Scan incoming files for the OLE magic number (first 8 bytes) and validate the EncryptionInfo stream structure before passing the file to the excelize library in high-exposure environments.