Stored XSS Vulnerability in Anybus-CompactCom 30 (CVE-2024-6558)

During a VAPT on a client’s hybrid infrastructure, I stumbled upon a small, almost forgotten web application running quietly on the network. At first glance it looked like just another embedded management panel, the kind you expect to see on industrial devices. But a few minutes into exploring it, things started to get interesting.

The interface belonged to an Anybus-CompactCom 30 module, and, as it turned out, it had a story to tell.

The vulnerable page is the network configuration form located at:

/netconfig.htm

The page included several network and SMTP configuration fields, all seemingly harmless.

While testing input handling, it quickly became evident that these fields accepted practically anything. There were no sanitization checks, no encoding, no defensive mechanisms of any kind. Whatever was submitted was stored as is and then reinserted in the HTML source of the page upon reload. This behavior instantly created a classic stored XSS condition, where a single malicious input becomes persistent and executes in the browser of anyone who visits the page.

The underlying issue was straightforward. The device stored input without any form of validation, injected it directly into the HTML template, and provided no escaping or filtering.

The browser, doing exactly what browsers do, simply interpreted the stored content as part of the DOM. Even the 64-character limit on some fields was not enough to mitigate the impact, since short payloads or remotely referenced scripts were more than sufficient to achieve code execution.

As an example, inserting the payload:

"><p>PWNED+WITH+STORED+XSS!</p><!--"

into the SMTP Server field immediately broke the structure of the page on reload. Fields such as SMTP User and SMTP Password disappeared, replaced by injected markup rendered inside the form.

A slightly modified payload showed the full potential of the flaw. Using a URL shortener to bypass the 64 character limit it is also possible to embed Javascript code or run it via a remote server, causing the device to execute it on the next page load.

Even a simple alert was enough to demonstrate the issue, though in a real attack scenario this could easily be replaced with credential theft attempts, session manipulation, or remote script loading.

The persistence of the payload made it especially dangerous, since every user accessing the page would unknowingly trigger the execution.

I initially discovered this behavior in May 2024 while analyzing an embedded device used within a customer’s hybrid infrastructure. A simple test on input handling quickly escalated into a confirmed, reproducible vulnerability with real operational impact. The issue was reported through the client’s disclosure procedure, then validated by the vendor, and finally coordinated with CISA for public release.

The vulnerability was later formalized as CVE-2024-6558 and published by CISA under advisory ICSA-24-193-20. The vendor assigned a CVSS v4.0 score of 6.3 with the vector:

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:N/VA:N/SC:H/SI:H/SA:N

Interpretation:

• Remote network exploitation is possible.
• No authentication required to insert a payload, depending on device configuration.
• User interaction required, a user must load the page for execution.
• High integrity and confidentiality impact at the system level.
• Persistence makes the issue more dangerous than reflected XSS.

This reflects the nature of the flaw, remotely exploitable, potentially accessible without authentication depending on configuration, requiring only that a user loads the affected page, and carrying high integrity and confidentiality impacts at the system level. The persistent aspect makes it significantly more severe than a typical reflected XSS.

In an industrial environment, where embedded web interfaces are often trusted implicitly by operators, the implications can be substantial. A stored XSS payload can alter the appearance of configuration screens, hide or falsify parameters, steal sensitive information, compromise engineering workstations, or even act as an entry point for lateral movement within the network. Since CompactCom modules are often integrated into products by multiple vendors, the same vulnerability may appear widely without any single vendor realizing it.

CVE-2024-6558 is a reminder that even vulnerabilities considered simple by traditional web standards can have meaningful consequences in OT and ICS ecosystems, where interfaces are not designed with strong threat models in mind and where operators depend heavily on the accuracy and reliability of what is displayed. Stored XSS on an industrial configuration panel is not just an aesthetic problem, it can mislead human operators, impact engineering workstations, and weaken the security posture of an entire environment.

One final consideration from this engagement is worth highlighting. The client had no idea that this web service was even exposed on the network. It was not documented, not monitored, and not intentionally published. This is far more common than it should be. Always keep track of what is deployed, what is reachable, and what is unintentionally exposed. Understanding your own attack surface is the first real step toward protecting it.

If you are interested in methodology, testing approaches, or exploring broader ICS vulnerability patterns, feel free to reach out.