CODESYS Under Attack: Three Chained Flaws to Plant a Backdoor in a PLC

CODESYS is one of the most widely deployed runtimes in the world for programming industrial controllers: in rebranded OEM form, it can be found in PLCs and automation devices from hundreds of manufacturers. Precisely because of this pervasiveness, a vulnerability chain recently disclosed by OT security research deserves attention: it demonstrates how an account with seemingly limited privileges can reach total control of the device.

The weak point: "Service" privileges more powerful than expected

In the CODESYS architecture, code written to the IEC 61131-3 standard is compiled into machine code and loaded into the same process as the runtime, which runs as root. Anyone who manages to replace the PLC application is effectively executing native code with the highest privileges on the device.

The Service access level, historically considered a low-criticality service role, nonetheless holds write permission on the application folders, required for the backup and restore function. That is where it all begins.

Three vulnerabilities that reinforce one another

The attack does not exploit a single flaw, but chains them together. The three CVEs involved:

CVE	Type	CVSS	In short
CVE-2025-41658	Incorrect default permissions	5.5	Access to the file holding the CODESYS password hashes
CVE-2025-41659	Incorrect permissions on a critical resource	8.3	Access to sensitive cryptographic material
CVE-2025-41660	Unvalidated resource transfer	8.8	Restore of tampered applications without checks

The detail that makes the model fragile is structural: backups (.tbf files) are plain ZIP archives that contain the compiled application (Application.app), its checksum and the metadata. That checksum is a CRC32, designed to detect transmission errors, not to resist deliberate tampering.

The exploitation chain

With valid Service credentials, but without any local access to the operating system, an attacker can proceed as follows:

1. Exfiltrate the boot application through the backup function.
2. Retrieve the cryptographic material by abusing CVE-2025-41659, bypassing code encryption and signing where present.
3. Tamper with the compiled binary, injecting malicious code.
4. Restore the altered application by exploiting CVE-2025-41660, which does not validate the integrity of the package.
5. Wait for the reboot: at the next startup the injected code runs as root.
6. Escalate privileges by modifying the CODESYS user database until obtaining the Administrator role.

What it means for a plant

Translated into MITRE ATT&CK for ICS language, the scenario touches heavy techniques: replacement of the legitimate application (T0839), control manipulation with setpoint alteration and interlock override (T0831), theft of operational information such as control logic and embedded credentials (T0882).

In a real-world context (a production line, a substation, a water treatment plant) the consequences range from production downtime to physical damage, all the way to unsafe operating conditions that are hard to diagnose, because the PLC keeps appearing formally intact.

Mitigations

CODESYS has released coordinated patches. The priority actions:

• Update the CODESYS Control runtime to version 4.21.0.0 or higher.
• Make code signing mandatory before deployment: in the new version it is enabled by default.
• Segment the network to reduce the exposure of programming interfaces.
• Harden credential management, treating Service accounts as privileged for all intents and purposes.

The MON5 angle

In many plants the problem, even before the patch, is knowing where CODESYS is present: it is often nested inside devices from different vendors and does not appear in any up-to-date inventory. Accurate OT asset visibility makes it possible to map which controllers expose the vulnerable runtime and to correlate each CVE with its real context (criticality of the line served, network exposure, available maintenance windows).

Where immediate updating is not feasible (a frequent case when machine downtime is costly), passive anomaly monitoring offers a safety net: unexpected application restores, anomalous access to backup functions or changes to the user database become detectable signals without interrupting production, narrowing the window in which a backdoor can stay silent.

Analysis and commentary by MON5 based on public-domain research and data from the OT/ICS sector.