CVE-2026-115943 in Spreadsheet::XLSX
Summary
by MITRE • 10/30/2026
Spreadsheet::XLSX versions before 0.19 for Perl allow code execution via string eval of number format conditions in ExcelFmt.
When a number format has a condition such as [>100], ExcelFmt chooses the format section by passing the condition and the cell value to a string eval. Both come from the workbook, and the eval runs while Spreadsheet::XLSX->new parses it.
An attacker who supplies an XLSX file can run arbitrary Perl code.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Spreadsheet::XLSX versions prior to 0.19 represents a critical server-side code execution flaw rooted in the improper handling of user-supplied data within Excel workbook files. This module, widely used for parsing XLSX formats in Perl environments, fails to sanitize or restrict the evaluation context when processing number format conditions embedded in spreadsheet cells. Specifically, the library utilizes string eval operations on condition strings derived directly from the workbook structure without adequate validation. When an attacker crafts a malicious XLSX file containing specific formatting rules, such as conditional expressions like [>100], the internal ExcelFmt component passes both the condition and cell values to Perl's eval function during the parsing phase initiated by Spreadsheet::XLSX->new. This mechanism allows for arbitrary code execution because string eval in Perl executes any valid Perl code contained within the evaluated string, effectively bypassing standard security boundaries if input is not strictly controlled.
From a technical perspective, this flaw aligns with CWE-94 Improper Control of Generation of Code or Script and CWE-78 OS Command Injection principles, as it involves the injection of executable content into an interpreter context through untrusted data sources. The attack vector relies on the initial parsing stage where the library attempts to interpret formatting rules for display purposes rather than security validation. By embedding malicious Perl syntax within the conditional format strings, such as system calls or file operations disguised as part of a number condition, an attacker can trigger arbitrary code execution upon opening the file in any application utilizing this vulnerable version of the module. This is particularly dangerous because XLSX files are commonly exchanged between users and systems, making them a frequent target for social engineering attacks where victims are tricked into processing malicious documents.
The operational impact of this vulnerability is severe, potentially leading to full system compromise depending on the privileges under which the Perl script runs. If the vulnerable module is used in a web application or server-side process with elevated permissions, an attacker could gain remote code execution capabilities, access sensitive data stored on the host machine, modify system configurations, or use the compromised system as part of a larger botnet. The risk is amplified by the fact that many organizations rely on automated scripts to parse incoming spreadsheet files for data integration purposes, meaning they may inadvertently process untrusted external inputs without realizing the security implications. This lack of input validation violates fundamental secure coding practices and exposes downstream systems to significant risk whenever such files are ingested into processing pipelines.
To mitigate this vulnerability, immediate action is required by upgrading Spreadsheet::XLSX to version 0.19 or later, where these unsafe eval operations have been addressed through stricter parsing logic that avoids executing arbitrary code during format interpretation. Organizations should also implement input validation strategies for all incoming file types, ensuring that only expected data structures are processed and rejecting malformed or suspiciously formatted files at the ingestion layer. Additionally, adopting defense-in-depth measures such as running processing scripts in sandboxed environments with minimal privileges can limit the blast radius of any potential exploitation attempts. Security teams should also monitor ATT&CK techniques related to command and script interpretation via file execution events to detect anomalous behavior that might indicate an attempt to exploit this or similar vulnerabilities within their infrastructure.