CVE-2026-9852 in MicroSCADA SYS600
Summary
by MITRE • 09/03/2026
A CSV injection vulnerability exists in SYS600. Injected malicious formulas can add or modify data to the spreadsheet, insert links, exfiltrate data, and in some cases, depending on how the user has their environment configured, execute malicious code on the user’s machine. To exploit this issue attackers would need a way to create arbitrary log messages. This could be achieved through normal functionality via SCIL scripts, a log injection vulnerability, or via the SYS600 broker. This vulnerability affects all Windows users regardless of their privilege level who can run the Notify service and export the log.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The identified vulnerability in SYS600 represents a classic instance of CSV Injection, also known as Formula Injection, which falls under the Common Weakness Enumeration category CWE-74 for Improper Neutralization of Special Elements used in an Export Function within Open XML Documents and related formats. This flaw arises when user-controllable or attacker-influenced data is inserted into a comma-separated values file without adequate sanitization or escaping before being opened by spreadsheet applications such as Microsoft Excel, LibreOffice Calc, or Google Sheets. The core technical failure lies in the application's inability to distinguish between plain text and executable formula syntax within the exported log files. When these logs are subsequently processed by end-user software, the injected content is interpreted not merely as data but as active commands, allowing for a wide range of malicious activities including arbitrary data modification, insertion of hyperlinks that can lead to phishing sites or drive-by downloads, and potential remote code execution depending on the victim's configuration.
The operational impact of this vulnerability extends beyond simple data corruption because it leverages the trust relationship between the application generating the logs and the user opening them. Attackers who gain the ability to inject arbitrary log messages through SCIL scripts, a separate log injection flaw, or via the SYS600 broker can craft payloads that exploit specific features of spreadsheet parsers. For instance, using prefixes such as equals signs followed by functions like HYPERLINK or VLOOKUP allows attackers to redirect users to malicious domains or trigger external data queries against internal resources. In more severe scenarios involving dynamic data exchange capabilities enabled in modern office suites, this vector can facilitate Remote Code Execution, effectively compromising the integrity and confidentiality of the user's system. This is particularly dangerous because it targets all Windows users capable of running the Notify service and exporting logs, regardless of their administrative privilege level, thereby expanding the attack surface significantly across enterprise environments.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Command and Scripting Interpreter execution as well as Data from Information Repositories if used for exfiltration. The exploitation chain typically begins with initial access or code injection via one of the mentioned entry points, followed by persistence through crafted log entries that remain dormant until a user manually opens the exported file. This reliance on social engineering elements, such as convincing users to open seemingly legitimate log files, makes detection difficult without strict monitoring of outbound data flows and endpoint behavior analysis. The vulnerability highlights critical gaps in input validation processes where external data sources are assumed safe simply because they originate from internal system components like brokers or scripts.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Immediate actions should include patching the SYS600 software to versions that properly sanitize special characters within exported CSV files, specifically ensuring that fields containing potentially dangerous prefixes are either escaped or quoted correctly so they are treated as literal text rather than executable formulas. Organizations should also enforce strict policies regarding which users have permission to export logs and run the Notify service, applying the principle of least privilege to limit exposure. Furthermore, security awareness training is essential to educate staff on the risks associated with opening unsolicited files from internal systems that may be compromised. Long-term solutions involve implementing Content Security Policies for exported data formats and utilizing automated testing tools during development cycles to detect CSV injection flaws before deployment. Regular audits of log generation processes and integration points like SCIL scripts will help identify similar weaknesses in other modules, ensuring a more robust security posture against this class of application-layer attacks.