CVE-2026-3664
Out-of-Bounds Read in xlnt Encrypted XLSX File Parser
Publication date: 2026-03-07
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| xlnt-community | xlnt | to 1.6.1 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-125 | The product reads data past the end, or before the beginning, of the intended buffer. |
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-3664 is an out-of-bounds read vulnerability in the xlnt library, specifically in the function xlnt::detail::compound_document::read_directory. This function parses the directory structure of encrypted XLSX files using the OLE Compound Document format. The vulnerability arises because the function reads directory entry indices directly from the file without proper validation. If a malicious or corrupted XLSX file contains invalid or excessively large indices, the function accesses memory outside the valid bounds, causing a segmentation fault or crash.
This issue is classified under CWE-125 (Out-of-bounds Read) and CWE-129 (Improper Validation of Array Index). The vulnerability can be triggered by loading a crafted XLSX file locally, leading to a crash due to invalid memory access.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to apply the official patch (patch 147) released by the xlnt-community to fix the out-of-bounds read vulnerability in the xlnt library versions up to 1.6.1.
If immediate patching is not possible, restrict local access to systems running vulnerable versions of xlnt to prevent exploitation, as the attack requires local execution.
Additionally, avoid opening or processing untrusted or suspicious encrypted XLSX files with affected versions of the xlnt library.
Monitoring for crashes or abnormal behavior in applications using xlnt can help detect exploitation attempts until the patch is applied.
How can this vulnerability impact me? :
The vulnerability can cause applications using the xlnt library to crash or experience undefined behavior when processing specially crafted encrypted XLSX files. This leads to a denial of service condition due to segmentation faults triggered by out-of-bounds memory reads.
Since the attack vector is local, an attacker must have local access to exploit this vulnerability. Exploitation is considered easy, and proof-of-concept exploits are publicly available.
Overall, the impact is primarily on system availability and stability, potentially disrupting services or applications that rely on the xlnt library for handling encrypted XLSX files.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a segmentation fault caused by an out-of-bounds read when parsing a malicious or corrupted encrypted XLSX file using the xlnt library. Detection involves identifying crashes or segmentation faults in applications that use xlnt to load XLSX files, especially when processing encrypted files.
Since the attack vector is local and triggered by loading a crafted XLSX file, detection can be performed by monitoring application logs for crashes or by running test loads of suspicious XLSX files in a controlled environment.
Suggested commands to detect the vulnerability include running the application or test harness with AddressSanitizer (ASAN) enabled to catch invalid memory accesses. For example, on Linux with Clang and ASAN enabled, you can run:
- clang++ -fsanitize=address -g -O1 your_test_program.cpp -o test_program
- ./test_program malicious_file.xlsx
Monitoring system logs (e.g., dmesg or journalctl) for segmentation faults related to the application loading XLSX files can also help detect exploitation attempts.