OTPulse Bi-Weekly Briefing - June 1, 2026

The most urgent item from the past two weeks is a KEV-listed advisory on Moxa industrial edge hardware - specifically a Linux kernel local privilege escalation chain called CopyFail and DirtyFrag. CISA published ICSA-26-148-08 on May 28, added it to the Known Exploited Vulnerabilities catalog the same day, and the underlying flaws have been confirmed in active attacks since early May.

The chain involves two separate research disclosures: CopyFail (CVE-2026-31431), a flaw in the Linux kernel's cryptographic template handling, and DirtyFrag (CVE-2026-43284, CVE-2026-43500), a related bug in the IPsec ESP and rxrpc in-place decryption path. Microsoft confirmed active attacks exploiting DirtyFrag on May 8. Elastic Security Labs published detection guidance and IOCs the following day. By May 28, Moxa had an ICS advisory out.

Beyond the Moxa KEV, this window also produced CVSS 9.8 advisories for an Eppendorf bioreactor controller, XCharge EV charging stations, and a PUSR RS-232/485-to-WiFi serial converter that shows up in water and manufacturing environments.

Both vulnerabilities are local privilege escalation flaws - an attacker who already has a low-privileged account on a Linux system can use them to become root. That "already local" precondition sounds limiting. In OT environments, it is much less of a barrier than it sounds.

Moxa hardware sits at the OT/IT boundary. Their edge devices - cellular gateways, serial-to-IP converters, remote I/O units - run hardened Linux and manage RS-232/485 communications to PLCs and RTUs. They are also the devices most likely to have a vendor support account, a shared service credential, or a USB port that someone used during a site visit. Any of those gives an attacker the unprivileged foothold needed to trigger this chain.

CopyFail (CVE-2026-31431) was disclosed by researchers at Theori and Xint in late April 2026. A 732-byte Python proof-of-concept achieves root on unpatched systems. About a week later, researcher Hyunwoo Kim published DirtyFrag, targeting the IPsec ESP and rxrpc decryption paths. That proof-of-concept achieves root in a single command.

Microsoft's May 8 rapid-response post confirmed active exploitation in the wild, targeting DirtyFrag specifically. Elastic Security Labs published IOCs and detection rules the next day. The CISA ICS advisory for Moxa hardware came on May 28 - three weeks after confirmed active attacks.

Moxa is not the only exposure here. Any Linux-based industrial device running an unpatched kernel is potentially in scope: HMI terminals, historian servers, remote access gateways, industrial routers. The VicOne team documented the same risk in automotive OT contexts. If your fleet includes Linux-based devices from any vendor, check the kernel version against the CVE patch levels - not just the Moxa advisory.

For containerized environments - and some industrial gateways do use container isolation - DirtyFrag enables container escape, putting the host OS in scope even if an attacker only gained access to an isolated workload.

1. Patch Moxa hardware covered by ICSA-26-148-08. Check otpulse.io/feed/e487dbee-ff16-4e22-9877-581b5eb8cd7e for affected models and the vendor's patched firmware versions.

2. Audit shared and vendor accounts on Moxa devices. Remove any accounts that are not actively needed. Vendor remote access accounts that persist after a service visit are a common entry point for LPE chains like this one.

3. Audit Linux kernel versions across your fleet. This is not just a Moxa problem. Any industrial Linux device running kernel versions below the CopyFail and DirtyFrag patch levels is exposed. Build a list of kernel versions across your edge hardware and historians, then cross-reference against the CVE advisories.

4. Apply Elastic detection rules if you have endpoint visibility on Linux assets. The Elastic Security Labs analysis published IOCs and detection guidance on May 9. If you have any Linux endpoint visibility in your environment, use them.

5. For the PUSR USR-W610 advisory (CVE-2026-7786): if you cannot patch immediately, take the device off the network or restrict access to the engineering VLAN only. A serial converter that allows arbitrary command execution should not be reachable from a corporate segment.