Claroty’s threat research team, Team82, uncovered two vulnerabilities in EnOcean’s SmartServer IoT platform affecting version 4.60.009 and earlier. One of the flaws, tracked as CVE-2026-20761, allows remote attackers to send specially crafted LON IP-852 messages that can result in arbitrary command execution on targeted devices and carries a CVSS v3 score of 8.1. A second vulnerability, CVE-2026-22885, enables attackers to send crafted IP-852 messages that bypass ASLR memory protections and leak memory, and has been assigned a CVSS v3 score of 3.7.
If successfully exploited, these vulnerabilities could allow attackers to gain control over building management and automation systems running affected versions of the platform, as well as legacy i.LON devices. EnOcean has issued mitigations for both vulnerabilities and recommends that users update the SmartServer platform to version 4.60.023, also known as SmartServer 4.6 Update 2.
Amir Zaltzman wrote in a Claroty blog post that the team identified two vulnerabilities in the implementation of the CEA-852 standard, which can enable attackers to execute code with root-level privileges. “Successful exploits of these vulnerabilities could allow an attacker to gain full root access to the controllers, control BMS logic, and move laterally toward field devices, disrupting HVAC, power, and environmental systems.”
He added that EnOcean addressed both vulnerabilities in a recent update. Users are advised to upgrade the SmartServer platform software to version 4.6 Update 2 (v4.60.023) or later.
“One of the most critical vulnerabilities we discovered is the ability to remotely execute arbitrary code on EnOcean devices as root, and this can be done without prior authentication (pre-auth),” Zaltzman detailed. “This is extremely dangerous; any EnOcean device exposed to the Internet with IP-852 packets enabled is a straightforward target. The attack we developed abuses a severe vulnerability we identified (CVE-2026-20761) in the handling of an Echelon proprietary IP-852 packet used for timezone setting.”
He added that by exploiting improper validation of packet input, an attacker can control an argument passed to the device’s built-in system call and achieve full takeover of the Linux-based device, gaining root privileges and arbitrary code execution.
Team82 discovered that LtSetTimeZone in libLonStack[dot]so constructs a shell command from a supplied timezone string and executes it via system with root privileges. The research shows that a portion of the LtSetTimeZone function is responsible for configuring the device’s timezone. The function accepts a single input parameter, which is a string representing the timezone value. It includes a validation step that checks whether the binary used to set the timezone, named set-timezone, exists on the device by invoking the Linux which command.
The function then constructs a shell command that will be executed on the device. While most elements of this command are hardcoded, the timezone value is passed as a variable input. This design introduces risk, as a crafted timezone string can alter the final command structure. The constructed command is ultimately passed to the system function for execution. The analysis demonstrates that an attacker can exploit this behavior by bypassing input quoting and injecting malicious shell commands through a specially crafted timezone string, leading to arbitrary command execution on the device.
“It is worth noting that the LtSetTimeZone function is not implemented in the LtIpPlatform.cpp source file published on EnOcean’s official GitHub repository,” according to Zaltzman. “This means the vulnerability is not visible in the open-source code and can only be identified through binary analysis of the library stored on the device.”
Based on the preceding analysis, the focus is on determining whether the timezone value can be modified by an attacker and what access vectors or privilege levels would be required to do so.
Three conditions can satisfy the validation check, and meeting any one of them is sufficient. The first is when the configuration server IP address is not set, indicated by m_ipAddrCfgServer = 0. The second is when the message originates from the configured server’s IP address and port, matching ipSrcAddr to m_ipAddrCfgServer and ipSrcPort to m_ipPortCfgServer. The third condition is when the CNIP header includes the extended header feature, allowing the configuration server’s IP address and port to be explicitly defined.
Team82 leveraged the third condition by enabling the extended header feature in the CNIP header, making it possible to specify the configuration server’s IP address and port directly. The CNIP header can include an extended header when the size field is set to 0x03, indicating the presence of 12 additional bytes. These extended fields contain the local IP address of the configuration server, the device’s NAT IP address if applicable, and the port associated with the configuration server’s IP address.
The configuration server’s IP address and port, along with the NAT address if present, can be retrieved by sending a PKTTYPE_REQDEVCONFIG (0x63) request. The device responds with a PKTTYPE_DEVCONFIG (0x71) packet that includes this information, with both messages using standard IP-852 packet formats and a vendor code of 0x01.
With these details, it becomes possible to construct a valid extended header that satisfies the validation check, indicating the message originated from the configuration server. As a result, the system sets the bFromCfgServer flag to true.
Claroty outlined the message flow between an attacker and the SmartServer, organized into two primary stages. In the first stage, configuration server details are obtained by sending a PKTTYPE_REQDEVCONFIG (0x63) request. The SmartServer responds with a PKTTYPE_DEVCONFIG (0x71) packet containing key information, including the configuration server’s IP address, its port, and the NAT IP address if present.
In the second stage, this information is used to construct a malicious message. The attacker embeds the retrieved data into the extended header of a specially crafted PKTTYPE_ECHCONFIG (0xF3) packet, which is then transmitted to the server to advance the exploit.
The post detailed crafted malicious PKTTYPE_ECHCONFIG packet with five key elements. The extended header size is set to 0x03, enabling parsing of the 12-byte extended header appended to the CNIP header. The vendor code is set to 0x01, identifying the message as an Echelon proprietary packet. The appended 12-byte extended header includes the configuration server’s IP address, its port, and the device’s NAT IP address if present.
Within the payload, the bUseTZ flag is set to 1, ensuring the timezone value is applied during parsing. The timezone field itself contains a carefully crafted string designed to inject arbitrary shell commands, followed by zero-byte padding to reach the required 128-byte length. When the server processes this malicious PKTTYPE_ECHCONFIG message, it executes the injected payload with root privileges, leading to remote code execution.
Team82 discovered that insufficient boundary checking on user-controlled data can lead to a stack memory disclosure (CVE-2026-22885). “This allows an attacker to leak arbitrary values or pointers that are located on the program’s stack, leaking any data that resides there. This primitive could be used to leak a pointer which could be used to determine the base address of the running program, bypassing ASLR (Address Space Layout Randomization) enforced by the operating system. It exists alongside the previous vulnerability and is independently exploitable for information disclosure.”
The post added that “To understand where and how the data buffer for incoming packets is allocated and stored in memory, we examined the CIpLink::receiveTask function (in IpLink.cpp), which is responsible for receiving incoming IP-852 packets over IP traffic. Each received packet is stored in a stack-based buffer with a maximum size of 576 bytes.”
Claroty noted that an attacker can craft a malicious PKTTYPE_TIMESYNCHREQ packet by setting a nonstandard extndHdrSize value that differs from 0x03. In this scenario, the packet advertises an extended header of 4×X bytes, where X is not equal to 0x03, but in reality includes only the fixed CNIP header. This inconsistency forces the controller to parse the payload from an offset of 4×X bytes beyond the end of the fixed CNIP header in stack memory.
The issue is compounded by the controller’s handling, which echoes back the parsed data. Instead of returning the actual payload, the controller reads from the incorrect 4×X-byte offset in stack memory and includes that data in the response. This behavior results in unintended stack memory disclosure over IP-852, exposing arbitrary memory contents to the client.
In the crafted packet, the extended header size field is deliberately set to a value greater than 0x03, causing the controller to assume the presence of a larger, nonstandard extended header and skip ahead by 4×X bytes when locating the payload. The vendor code is set to 0x01 to indicate an Echelon proprietary packet type. Although the packet may include a 16-byte dummy payload, the controller does not actually process this data. Instead, it reads from the misaligned offset in stack memory, enabling the leakage of sensitive information.
Team82 demonstrated how the STACK DATA 1 and STACK DATA 3 fields can be leaked from stack memory. “By selecting an appropriate X value, these leaked fields may contain a runtime function pointer, which can then be used to derive the base address of libLonStack.so as loaded in memory, effectively bypassing the ASLR mechanism.”
In closing, Zaltzman said Team82 identified two vulnerabilities in EnOcean’s SmartServer IoT platform and i.LON devices, which are used to connect building management systems to the internet. “An attacker exploiting these vulnerabilities can bypass memory protections on the device, leak memory, and execute arbitrary OS commands.”
He added that as more BMS come online through these platforms, these critical systems will be exposed to new risks that must be addressed. “This is especially relevant in sensitive facilities such as manufacturing, defense, and data centers. EnOcean has addressed both vulnerabilities in a recent update and users are advised to update the SmartServer platform software to SmartServer 4.6 Update 2 (v4.60.023) or a later release.”
