Summary
- The issues affect SOEM up to version 2.0.0, with a correction identified in 2.0.1.
- Affected routines include configuration-table processing, mailbox errors and frame handling.
- The records do not demonstrate remote internet exploitation or a direct bypass of machinery safety systems.
Three vulnerabilities in software used to communicate with industrial equipment could allow malicious connected devices to crash control applications or corrupt memory, exposing weaknesses in the way automation software processes information returned by field devices.
The flaws affect Simple Open EtherCAT Master, or SOEM, an open-source implementation developed by Swedish engineering company RT-Labs. Vulnerability records issued on 26 October 2026 identify releases up to and including version 2.0.0 as affected.
SOEM provides the master side of EtherCAT, a protocol used in industrial automation, robotics, motion control and machinery requiring predictable communication between controllers and connected devices.
The master exchanges structured information with drives, sensors and input/output modules. It must process configuration and diagnostic data supplied by those devices, creating opportunities for a defective or compromised device to influence control software.
CVE-2026-82945 concerns configuration information associated with Fieldbus Memory Management Units, known as FMMUs. These components map process data between the master's internal representation and memory areas used by EtherCAT devices.
Affected code can write configuration information into an array without adequately checking that the supplied index remains within its allocated range. A malicious device providing excess configuration information may cause an out-of-bounds write and corrupt neighbouring memory.
Another issue, CVE-2026-82946, concerns mailbox error handling. Under affected conditions, a particular response can clear an internal pointer while subsequent processing continues. The software may then use the invalid pointer and terminate unexpectedly.
The third vulnerability, CVE-2026-82947, affects frame parsing. Crafted length or offset values returned through the device communication path may cause access beyond the intended buffer, creating possible crashes or disclosure of information from process memory.
Each vulnerability depends on information delivered through the relevant EtherCAT path. The records do not establish that an unauthenticated internet user can directly exploit the issues against an otherwise isolated factory installation.
An attacker would need to control or impersonate a relevant connected device, manipulate its responses or obtain another position from which malicious information could enter the master's protocol processing.
That prerequisite does not eliminate operational risk. Industrial networks may be isolated from ordinary business traffic yet remain connected to engineering workstations, remote maintenance facilities and gateways that provide legitimate access to the equipment.
The consequences of a software crash also depend on the role of the affected application. An interruption during laboratory testing differs from loss of a communication process supporting production machinery or automated materials handling.
Whether equipment stops safely, continues operating or requires manual recovery depends on the system design and its independent safety functions. A crash in SOEM does not by itself demonstrate a bypass of a machine's safety controller or an ability to cause uncontrolled physical movement.
RT-Labs' published advisory identifies version 2.0.1 as the corrected release boundary. However, organisations may use SOEM as a library embedded within third-party equipment or internally maintained applications rather than as an independently managed software installation.
Those deployments may need a supplier-built update and technical validation before the revised software can be incorporated. Simply identifying the upstream correction does not prove that every downstream product has adopted it.
The findings illustrate a recurring industrial software assurance problem: field-device information may be treated as structurally reliable because it arrives through an expected protocol from equipment on an operational network.
Malformed configuration data and error responses nevertheless need defensive validation, even where the connected device would normally be trusted. Hardware faults, compromised devices and unexpected operating conditions can all challenge those assumptions.
The disclosures do not identify confirmed exploitation in production industrial environments. They establish software vulnerabilities with a defined correction path, while practical exposure depends on the incorporated SOEM version, connected devices and the surrounding industrial network architecture.
