Attackers can backdoor CODESYS applications by chaining three flaws

Researchers have shown how attackers can chain three CODESYS Control runtime vulnerabilities to replace a legitimate industrial control application with a backdoored one. The attack requires valid Service-level credentials, but once attackers have that access, they can move from limited privileges to full control of the affected device.

Nozomi Networks Labs says the flaws affect how CODESYS handles default permissions, cryptographic material, and boot application restoration. In a real industrial environment, that matters because CODESYS-powered PLCs control physical processes such as pumps, motors, valves, HVAC systems, manufacturing lines, and water treatment equipment.

The three vulnerabilities are tracked as CVE-2025-41658, CVE-2025-41659, and CVE-2025-41660. CODESYS lists related advisories for insecure default permissions, exposed PKI folders, and untrusted boot applications in its security advisory portal.

Why this CODESYS attack matters

CODESYS Control is a software-based programmable logic controller runtime used across industrial automation. It runs the control application that tells machinery what to do, when to do it, and how to respond to changing physical conditions.

Nozomi’s research focuses on what can happen after attackers gain Service-level access. That access should not allow full device takeover, but the vulnerability chain lets attackers abuse legitimate backup and restore workflows to alter the deployed control application.

The impact can go beyond IT compromise. A backdoored PLC application could change setpoints, override safety logic, manipulate actuator behavior, falsify sensor readings, or stop production. Nozomi maps the risk to MITRE ATT&CK for ICS techniques such as Module Firmware, Manipulation of Control, and Theft of Operational Information.

The three flaws behind the attack chain

The first issue, CVE-2025-41658, involves insecure default permissions. Nozomi says it can expose the file containing CODESYS password hashes to any local user on the Soft PLC, which may help attackers extract credentials offline.

The second flaw, CVE-2025-41659, lets a low-privileged attacker remotely access the PKI folder of the CODESYS Control runtime. NVD says this can expose certificates and keys, allow sensitive data extraction, and let attackers accept certificates as trusted.

The third issue, CVE-2025-41660, affects boot application restoration. Nozomi says attackers can use it to restore a tampered boot application to the device, overwriting the legitimate application through the backup functionality.

At a glance

Item	What current reporting shows
Product area	CODESYS Control runtime
Research team	Nozomi Networks Labs
Main risk	Backdoored industrial control application
Required access	Valid Service-level credentials
CVE-2025-41658	Exposes password hashes through insecure default permissions
CVE-2025-41659	Exposes PKI folder, certificates, and keys
CVE-2025-41660	Allows restoration of a tampered boot application
Result	Code execution as root after restart
Final attacker goal	Full Administrator control of the device
Affected environments	Soft PLCs used in industrial automation

How the attack works

The attack starts when an attacker obtains Service-level credentials for the CODESYS runtime. Nozomi says this can happen through weak or default passwords, a compromised engineering workstation, or local access that lets the attacker read password hashes through CVE-2025-41658.

After authentication, the attacker uses the CODESYS Development System backup function to download the active boot application from the PLC. That gives the attacker a copy of the deployed application, including the code that controls the physical process.

The attacker then uses CVE-2025-41659 to access cryptographic material on the Soft PLC. That material can help bypass optional protections such as code encryption and code signing, which means the attacker can modify the application and make it appear acceptable to the deployment workflow.

How the backdoor reaches root access

Once the attacker modifies the compiled application binary, CVE-2025-41660 becomes the key step. The attacker restores the tampered boot application to the device through backup functionality, replacing the legitimate application.

The Service user cannot restart the application directly. Instead, the attacker waits for an operator to restart it or for the device to reboot. When the application starts again, the injected code runs with the same privilege level as the CODESYS Control runtime, which Nozomi says means root on the underlying system.

After gaining root access, the attacker can modify the CODESYS runtime user database and grant themselves Administrator rights. That turns a limited authenticated foothold into full control of the PLC runtime and host device.

Vulnerability summary

CVE	Severity	Issue	Why it matters
CVE-2025-41658	5.5 Medium	Insecure default permissions	Can expose CODESYS password hashes to local low-privileged users
CVE-2025-41659	8.3 High	Exposed PKI folder	Can expose certificates and keys used in trust and protection workflows
CVE-2025-41660	8.8 High	Untrusted boot application restore	Can allow a tampered boot application to replace the legitimate one

What changed after disclosure

CODESYS has published security advisories for the affected issue areas, including insecure default permissions, exposed PKI folders, and untrusted boot applications. Its advisory portal says device manufacturers decide how and when to adopt recommended updates for devices programmable with CODESYS.

Nozomi says the vulnerability chain shows why Service-level users should not have enough authority to alter deployed control logic in a way that leads to root execution. The issue sits at the boundary between normal engineering workflows and runtime trust enforcement.

The broader lesson is that backup and restore features in industrial systems need strict integrity checks. If attackers can restore modified control logic after stealing or abusing credentials, they can turn a legitimate maintenance function into a backdoor delivery path.

What defenders should do now

Security teams should start by identifying CODESYS Control runtimes in their environments and checking whether vendors have issued updated firmware or runtime packages for affected devices. CODESYS notes that adoption timelines can depend on each device manufacturer, so asset owners may need to check both CODESYS and OEM advisories.

Teams should also review who has Service-level access. The attack depends on authenticated access, so weak passwords, shared accounts, unused engineering accounts, and stored credentials on engineering workstations increase the risk.

Industrial defenders should monitor for unusual backup downloads, restore operations, PKI folder access, certificate changes, and unexpected application restarts. Those events can help expose attempts to prepare or deploy a tampered boot application.

Recommended protections

• Update CODESYS Control runtime and vendor-supplied device firmware when patches become available.
• Remove weak, default, shared, and stale Service-level accounts.
• Restrict engineering workstation access and protect stored credentials.
• Segment PLC networks from corporate IT and general user networks.
• Monitor CODESYS backup and restore activity.
• Alert on unexpected access to PKI folders and certificate stores.
• Track application restarts and reboots after engineering activity.
• Require change approval before uploading or restoring control applications.
• Review logs for failed or unusual Service-level authentication attempts.
• Use network monitoring to detect suspicious CODESYS protocol activity.

Why industrial operators should care

This attack chain shows how attackers can use normal industrial workflows against operators. They do not need to destroy a PLC directly. They can replace the logic that the PLC trusts.

That makes detection harder because the device may still appear to run a valid control application. The dangerous change sits inside the deployed code, where it can quietly alter behavior after a restart.

For operators in manufacturing, energy, water, building automation, and other OT environments, the priority is clear. Patch where possible, restrict engineering access, and watch for changes to control applications with the same seriousness as firmware changes.

FAQ