The AutomationDirect CLICK PLUS family of PLCs has been placed squarely in the spotlight after a U.S. government advisory detailing multiple, high-impact vulnerabilities was released on September 23, 2025, warning operators that the devices are remotely exploitable with low attack complexity and that combined weaknesses could allow credential theft, cryptographic compromise, privilege escalation, and denial-of-service across affected installations. The advisory lists a bundle of related CVEs and explicitly recommends updating CLICK PLUS firmware and software to version v3.80 as the primary remediation; it also names the reporting researchers and provides a clear risk evaluation for critical manufacturing operators worldwide. This feature unpacks the technical findings, explains what the vulnerabilities mean in real-world industrial environments, evaluates mitigation options for Windows-centric and OT operations teams, and lays out practical detection, patching, and risk-management advice you can act on now.
The affected product family is AutomationDirect CLICK PLUS (various C0 and C2 CPU models). The advisory identifies multiple vulnerability classes discovered in firmware and programming software version 3.60 and prior. The most consequential issues include:
Because immediate patching may not always be feasible in production OT environments, the advisory — and standard ICS best practices — recommend compensating controls until the patch can be tested and deployed:
The advisory also reinforces the need for cross-domain collaboration between IT security, OT engineering, and procurement teams. Patch testing, vendor coordination, and segment-aware deployment plans should be standard operating procedure for any organization deploying low-cost PLCs that now come with network features (Wi‑Fi, MQTT, Ethernet).
Key takeaways:
Source: CISA AutomationDirect CLICK PLUS | CISA
Background / Overview
The affected product family is AutomationDirect CLICK PLUS (various C0 and C2 CPU models). The advisory identifies multiple vulnerability classes discovered in firmware and programming software version 3.60 and prior. The most consequential issues include:- Cleartext storage of sensitive information in the Click Programming Software (local disclosure of credentials).
- Hard-coded cryptographic key embedded in firmware (AES key protecting initial session messages).
- Broken or risky cryptographic algorithm use — an insecure RSA implementation.
- Predictable seed in the pseudo-random number generator, undermining key generation and key secrecy.
- Improper resource shutdown or release, permitting session exhaustion denial-of-service.
- Missing authorization that allows authenticated low-privilege users to read/modify variables beyond intended scope via the KOPR/KOPS protocol.
Technical breakdown: what was found and why it matters
The advisory groups the findings into discrete vulnerability types. Below is a technical breakdown that explains the practical implications for operators, engineers, and IT/OT security teams.Cleartext storage of sensitive information (CWE-312)
- What it is: The Click Programming Software (v3.60) stores administrative credentials in clear text on the file system when an administrative session is active.
- Why it matters: Any local user or attacker who can access the engineering workstation’s file system — whether via credentialed remote access, a compromised laptop, removable media, or a shared folder — can read plaintext credentials. In OT environments where engineering workstations often have elevated privileges and broad network reach to programmable logic controllers (PLCs), this is a fast path to credential theft and subsequent lateral movement.
- Practical impact: Stolen credentials can permit reprogramming PLC logic, changing I/O mapping, or exfiltrating sensitive configuration data.
Hard-coded cryptographic key (CWE-321)
- What it is: Firmware v3.60 contains an embedded AES key used to protect initial messages in a session protocol (the advisory identifies this as part of KOPS session initialization).
- Why it matters: Hard-coded keys defeat any meaningful forward secrecy or per-session confidentiality. Once the key is extracted by anyone with firmware access or by reverse engineering the device binaries, an attacker can decrypt or spoof session initialization messages and potentially impersonate a legitimate controller or programming client.
- Practical impact: Session-level authentication and confidentiality are undermined, making man-in-the-middle or replay-style attacks practical in exposed networks.
Broken or risky cryptographic algorithm (CWE-327) — RSA implementation weaknesses
- What it is: The device uses an insecure RSA implementation or parameters that make cryptographic protection ineffective (implementation bugs, poor padding, or inadequate key sizes).
- Why it matters: Weak or incorrect RSA usage can allow adaptive chosen-ciphertext or signature forgery attacks, rendering encryption or authenticity checks unreliable.
- Practical impact: Attackers can manipulate firmware update validation, impersonate servers/clients, or bypass cryptographic protections intended to preserve integrity of command and configuration flows.
Predictable seed in pseudo-random number generator (CWE-337)
- What it is: The device’s RNG initialization uses a predictable seed, meaning private keys generated on-device are effectively guessable or reproducible.
- Why it matters: Cryptographic keys derived from predictable RNG seeds are unsafe — an attacker can reconstruct private keys, decrypt traffic, or sign messages fraudulently.
- Practical impact: Long-lived device keys and certificates become brittle, exposing devices to impersonation and persistent compromise.
Improper resource shutdown / session exhaustion (CWE-404)
- What it is: The Click Programming Software and Remote PLC application fail to correctly release sessions, allowing unauthenticated attackers to exhaust available session slots.
- Why it matters: Resource exhaustion leads to denial-of-service (DoS) — legitimate maintenance or automation tasks may be blocked, and recovery in production may require manual intervention (power cycle, local reset).
- Practical impact: Availability of automation systems — especially those with limited session capacity — can be impacted, affecting process throughput and, in the worst case, safety-critical controls.
Missing authorization / privilege escalation via KOPR/KOPS (CWE-862)
- What it is: Through the KOPR protocol used by the Remote PLC application, authenticated users with low-level access can read and modify PLC variables beyond their authorization.
- Why it matters: Authorization boundaries are fundamental to safe operations; when they fail, even a nominally restricted operator account can change setpoints, manipulate control logic, or access otherwise protected variables.
- Practical impact: Tampering with process variables can lead to incorrect process behavior, data integrity loss, or cascading safety incidents.
Risk evaluation — practical scenarios and threat models
The advisory’s assessment that these issues are remotely exploitable with low attack complexity is important: it means moderately skilled adversaries, or even opportunistic attackers, can realistically chain exploits in many environments. Here are several likely attack chains to consider:- Credential theft + lateral movement
- An attacker gains foothold on a corporate workstation (phishing or supply-chain).
- They access the engineering workstation (file shares, USB), read cleartext credentials, and use them to connect to CLICK PLUS devices.
- With valid credentials, they reprogram PLC logic or exfiltrate data.
- Cryptographic compromise + session spoofing
- An attacker extracts the hard-coded AES key or reproduces device private keys (predictable RNG).
- They intercept or spoof KOPS/KOPR sessions, sending forged commands that appear legitimate to the device or the programming software.
- Privilege escalation via KOPR + process manipulation
- A low-privileged authenticated user leverages the missing authorization flaw to modify critical PLC variables, e.g., changing actuator setpoints or bypassing safety interlocks.
- Denial-of-service via resource exhaustion
- An unauthenticated attacker floods session creation requests, exhausting available sessions and preventing legitimate engineering operations.
Vendor response and mitigation guidance
AutomationDirect’s recommended remediation from the advisory is clear: update CLICK PLUS firmware and the Click Programming Software to v3.80. That upgrade is the authoritative fix path the vendor provided.Because immediate patching may not always be feasible in production OT environments, the advisory — and standard ICS best practices — recommend compensating controls until the patch can be tested and deployed:
- Network isolation: Remove CLICK PLUS devices from the Internet and untrusted networks; place them on segregated OT VLANs or physically air-gapped networks where practical.
- Segmentation: Enforce strict firewalling with deny-by-default rules between IT and OT zones; only allow minimal management flows from trusted engineering workstations.
- Secure remote access: If remote access is required, use hardened jump hosts, up-to-date VPN appliances, multi-factor authentication, and strict session logging and monitoring. Treat remote access paths like any high-value asset.
- Access control: Limit both physical and logical access to authorized personnel; enforce least-privilege accounts; rotate any shared credentials.
- Application whitelisting / endpoint hardening: Ensure engineering workstations run only approved software; use host firewalls and EDR/AV to reduce the risk of local compromise.
- Logging & monitoring: Centralize logs, monitor for unexpected KOPR/KOPS session patterns, failed authentication, or session-count anomalies.
- Backup & recovery: Maintain tested backups of PLC projects and device configs; have clear recovery-runbooks for manual restoration if devices need reprogramming.
- Operational testing: Plan firmware rollouts with staged testing, validation in a lab environment, and rollback procedures.
Action checklist for Windows and OT teams (prioritized)
- Inventory
- Identify all CLICK PLUS devices and engineering workstations that use Click Programming Software. Verify firmware versions (devices with firmware prior to v3.71 and programming software v3.60 are highlighted as affected).
- Isolate
- Immediately remove any internet-exposed CLICK PLUS devices. Block suspected management ports and protocols between corporate and OT networks.
- Patch planning
- Schedule an internal test of firmware/software v3.80 in an offline lab. Validate I/O behavior and automation sequences before production deployment.
- Short-term controls
- Implement host-level application whitelisting on engineering workstations; block USB mass storage where possible; enforce role-based access for programming tools.
- Logging and detection
- Enable and centralize logs from engineering workstations, VPN gateways, jump hosts, and PLC communication points. Create alerts for high session counts, odd KOPR traffic, and unexpected configuration changes.
- Credentials hygiene
- Rotate admin-level passwords and keys after patching. If cleartext credentials were suspected to be exposed, treat them as compromised and rotate them immediately.
- Incident readiness
- Prepare a response playbook: containment (isolate affected devices), eradication (firmware upgrade and credential rotation), recovery (restore validated configs), and postmortem.
- External reporting
- If you detect suspicious activity consistent with exploitation, follow internal procedures and report through appropriate national cyber incident channels.
Detection guidance and indicators of compromise (IoCs)
Because these vulnerabilities affect both device cryptography and communication/session handling, detection should span host and network telemetry.- Network indicators
- Unusual or high-volume traffic on PLC management ports and UDP/KOP protocol ports.
- Unexpected new hosts initiating KOPS/KOPR sessions or session initialization failures.
- Repeated session creation attempts that coincide with session exhaustion on devices.
- Host indicators (engineering workstations)
- Unauthorized reads of local configuration files, creation of suspicious archives, or exfiltration to cloud storage or remote endpoints.
- Presence of files that appear to contain plaintext credentials (search for typical project or backup file names used by Click Programming Software).
- Unexpected process launches of Click software from non-standard locations.
- Cryptographic indicators
- Certificates or private keys exported from devices; duplicate key material across multiple devices (suggests hard-coded or reproducible keys).
- Signatures that fail validation or messages that decrypt with known shared key material.
- Operational indicators
- Abnormal variable changes on PLCs (unexpected setpoint changes, unauthorized logic edits).
- Sudden unresponsiveness or errors in PLC control modules following a communication flood.
Patching considerations and recommended rollout plan
Patching PLCs in production requires careful orchestration:- Test first: Validate v3.80 in a representative lab simulating I/O, networking, and existing HMI/SCADA integrations. Confirm that motion, safety interlocks, and data logging function as expected.
- Backup configurations: Before upgrading, export and store PLC projects, module configurations, and firmware images in immutable, access-controlled storage.
- Staged deployment: Roll out patches in small batches (single cell or zone), validate for 24–72 hours, then expand to the rest of the site.
- Change control: Use formal change-control windows with production sign-off; plan for fallback to previous firmware only after you’ve validated that you can restore from backups.
- Post-patch validation: Re-run security checks (iconfig, certificate validation, session behavior), and rotate all credentials and keys that may have been exposed prior to patching.
Broader implications for ICS security and vendor responsibilities
This advisory underlines two persistent themes in industrial cybersecurity:- Cryptography is often implemented incorrectly in embedded systems. Hard-coded keys, weak RNGs, and malformed algorithm usage are recurring mistakes that convert cryptographic claims into operational liabilities.
- Engineering workstations and remote programming tools remain critical pivot points. A compromise at the workstation level frequently enables the attacker to reach deeply into OT assets.
The advisory also reinforces the need for cross-domain collaboration between IT security, OT engineering, and procurement teams. Patch testing, vendor coordination, and segment-aware deployment plans should be standard operating procedure for any organization deploying low-cost PLCs that now come with network features (Wi‑Fi, MQTT, Ethernet).
Practical recommendations for Windows administrators supporting OT
Windows administrators play a central role because engineering workstations typically run Windows and are the bridge between corporate IT and OT. Recommended, practical steps:- Harden engineering workstations: Apply the latest Windows updates, enable Defender/EDR policies tuned for OT, and restrict administrative privileges.
- Control peripheral use: Use group policies or endpoint controls to block unauthorized USB storage and enforce BitLocker where workstations may be moved between networks.
- Restrict network flows: Implement host-based firewall rules that only allow the Click Programming Software to communicate with known PLC IP addresses and ports.
- Enforce application control: Use Windows AppLocker or similar to allow only vendor-signed binaries for Click software and approved tooling.
- Centralize logging: Forward Windows event logs and Click software logs to your SIEM. Create OT-tailored dashboards for session anomalies and file-read anomalies.
- Coordinate with OT: Maintain a clear channel with OT engineers for scheduled firmware updates and emergency patches.
What to watch for next and closing assessment
The advisory paints a clear landscape: a widely deployed PLC series with multiple cryptographic and authorization weaknesses that, when chained, become operationally dangerous. The vendor-provided upgrade to v3.80 is the authoritative remediation, and operators should treat the advisory as urgent — but also as requiring careful operational planning to avoid avoidable downtime.Key takeaways:
- Prioritize inventory and isolation now; assume the vulnerabilities are exploitable in exposed environments.
- Test and deploy firmware v3.80 per controlled change processes.
- Treat engineering workstations as crown jewels; harden, restrict, and monitor them aggressively.
- Rotate any credentials or keys that may have been exposed and confirm cryptographic integrity after patching.
- Prepare detection and incident response plans that include forensic captures of network traffic and host images.
Source: CISA AutomationDirect CLICK PLUS | CISA
