CVE-2021-3351

OpenPLC's web runtime stores whatever you type into the Device Name field on the Add New Device page and renders it back without neutralizing it, so a script payload placed there persists and executes in the browser of anyone who later views it. It's stored XSS, but the setting is what gives it weight — this is the web management interface of a programmable logic controller runtime, the software layer that drives industrial process logic.

The preconditions keep this at medium rather than higher. An attacker needs at least a low-privileged authenticated account to add a device, and a victim with access to the runtime UI has to view the poisoned entry for the payload to fire. So the realistic story is one operator (or a compromised low-tier account) planting script that runs in a higher-privileged operator's session — a way to pivot within the OT management plane, not a remote takeover of the PLC itself. In an ICS context even browser-session compromise of an engineering interface is unwelcome, but the bar to reach it is real.

Our angle here is exposure isolation, because OT web interfaces should never be casually reachable. We'd confirm any OpenPLC runtime is confined to a segmented control network with tight access, which shrinks both who can inject and who can be hit. Given the ICS setting we treat the stored-XSS as a management-plane integrity issue to fix on the runtime's update path, and rank it by how tightly the interface is walled off rather than by the 5.4 alone.