CVE-2026-100564 in OpenClaw
Summary
by MITRE • 09/26/2026
OpenClaw versions before 2026.8.1 fail to neutralize spreadsheet formula characters in participant display names within attendance CSV exports. Attackers can inject formula-like cells that execute with spreadsheet user permissions when the export is opened in formula-enabled applications.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in OpenClaw versions prior to 2026.8.1 represents a classic instance of insecure data handling during file generation, specifically affecting CSV exports related to attendance records. The core technical flaw lies in the application's failure to sanitize or escape special characters within participant display names before they are written into comma-separated values files. In spreadsheet formats such as CSV, certain prefixes like equals signs, plus signs, minus signs, and at symbols trigger formula interpretation when the file is opened in applications that support dynamic content calculation, including Microsoft Excel, Google Sheets, and LibreOffice Calc. By embedding these characters directly into user-supplied display names without proper escaping or quoting mechanisms, OpenClaw inadvertently allows arbitrary data to be interpreted as executable code within the spreadsheet environment.
This behavior aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and is often categorized under CSV Injection or Formula Injection vulnerabilities. The attack vector relies on social engineering or automated scraping where an attacker controls the display name of a participant, such as setting it to =1+1 or =cmd|' /C calc' /F. When another user exports this data from OpenClaw and opens the resulting CSV file in a formula-enabled spreadsheet application, the embedded string is parsed not as plain text but as a command. This leads to unintended execution of formulas that can perform calculations, access cell contents, or potentially execute system commands depending on the specific capabilities of the host application and its security configuration.
The operational impact of this vulnerability extends beyond simple data corruption. While many modern spreadsheet applications have implemented mitigations such as blocking formula execution by default for files downloaded from the internet, legacy systems or users with macro-enabled settings remain highly susceptible. Successful exploitation can lead to information disclosure if formulas are crafted to read and display sensitive cell contents in adjacent cells. Furthermore, advanced attacks could potentially facilitate drive-by downloads or remote code execution through complex formula chains that leverage application vulnerabilities, although this requires specific environmental conditions. The primary risk remains the compromise of user trust and potential data leakage within organizational environments where spreadsheet tools are standard productivity software with elevated privileges relative to plain text editors.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For OpenClaw administrators, upgrading to version 2026.8.1 or later is the primary solution as it corrects the sanitization logic for CSV exports. In interim scenarios where upgrade is not immediately feasible, implementing server-side validation that strips or escapes special characters like equals signs and plus signs from display names before export can reduce risk. Additionally, organizations should enforce security policies within their spreadsheet applications to disable automatic formula execution for external files. Educating users about the risks of opening untrusted CSV files and configuring default application settings to treat all incoming data as plain text are critical complementary measures. This vulnerability underscores the importance of treating user input with strict validation rules even when generating standard file formats, ensuring that data intended for display is never interpreted as executable logic by downstream consumers.