A newly discovered vulnerability, CVE-2025-41688, allows a highly privileged remote attacker to bypass all sandbox restrictions in a widely used OT remote access device. The device is trusted in European industrial environments for maintaining PLCs (programmable logic controllers), HMIs (human-machine Interface), and field equipment. The flaw can be exploited through an undocumented Lua runtime command that enables execution of arbitrary operating system commands as root.
“Under the hood, it runs embedded Linux, exposes a web interface, and offers Lua scripting for automation and diagnostics,” Marcel Rick-Cen, an OT and IIoT security consultant, wrote in a Medium post last week. “A critical vulnerability in the device’s Lua runtime — an undocumented function —bypasses all sandboxing restrictions and allows arbitrary OS command execution as root. What should have been a controlled automation feature is, in reality, a direct pipeline to full device takeover.”
Rick-Cen explained that the affected device family, particularly the end-of-life mbNet HW1, remains widely deployed across multiple sectors. Although the vendor has recommended replacing the hardware, he noted that replacements will take years to implement in many environments.
The flaw combines a sandbox escape with command injection through an undocumented Lua function, allowing arbitrary root command execution through the web interface. While web login is required, default credentials were still accepted in several tested configurations. Even though the devices are end-of-life, their continued use poses a significant risk.
He advised operators of mbNet HW1 devices running firmware earlier than version 5.1.11 to segment them immediately, audit scripting access, and assume that any exposed Lua interface can be exploited for escalation.
The disclosure timeline shows that the vulnerability was discovered on July 6, this year, and reported to the manufacturer the following day. On July 7, the manufacturer confirmed receipt of the report. CVE IDs were assigned by the manufacturer on July 22, and the vulnerability was publicly disclosed on July 31, 2025.
The post detailed that the vendor provides a cloud portal that facilitates the management of devices and the creation of initial configuration files. Users generate these config files through the portal and then transfer them onto a USB pen drive. To set up a device, this USB drive is plugged into the device’s USB socket while it is powered off. Upon powering the device on, it reads the config file from the USB drive, which enables it to connect to the internet and register itself with the cloud portal.
“Once registered, all device management tasks can be conducted remotely via the cloud portal,” Rick-Cen wrote. “For local management, the device’s embedded web server can be accessed, providing an alternative means of configuration and monitoring directly at the device level.”
He added that the web-based interface offers a range of tools, including diagnostics, logging, and scripting. One such feature is a Lua-based scripting environment, originally designed for data aggregation (e.g., pulling values from PLCs or sensors and pushing them to a cloud portal).
“Upon initial inspection, the Lua environment appeared sandboxed,” according to Rick-Cen. “Standard system functions like os[dot]execute, io[dot]open, and io[dot]popen returned no results or were entirely absent.”
To assess what remained accessible, he then dumped the Lua global registry and inspected nested tables, which yielded a non-standard result. Testing the function directly produced an output that confirmed that the function was executing arbitrary OS-level shell commands, execution was occurring as the root user, and that the standard Lua sandbox was trivially bypassed through an undocumented internal binding.
To streamline command execution, Rick-Cen developed a ‘python’ script, shell[dot]py, which transforms the Lua interface into a pseudo-interactive shell. The tool automates the submission of a Lua payload by simulating a ‘Save’ action. It then executes the script by triggering ‘Run’ or ‘Reload’ through a second POST request. Finally, it retrieves and cleans the Lua output HTML via a GET request. The Lua field introduces a 2~3-second execution delay, but the approach remains stable and effective.
Once a foothold is gained, an attacker can execute reverse shell commands. They can also traverse the full filesystem using commands like ls, cat, cp, or wget. Configuration files can be exfiltrated, services can be restarted or modified, and additional binaries such as BusyBox can be leveraged if present.
Rick-Cen said that “given the device’s placement in industrial environments, compromise of this interface risks persistent remote code execution, pivoting to other hosts, and tampering with VPN or PLC routing logic.”
“The vulnerability was disclosed to MB Connect Line and acknowledged. However, the MDH849 is officially end-of-life,” he pointed out, adding that the problem is that “OT environments do not sunset hardware at the same pace as IT. Devices like this remain deployed for 10+ years, often without updates, segmentation, or patch visibility. In other words: this exploit remains viable in the wild.”
While IT security standards assume regular product upgrades and patch cycles, OT systems operate under entirely different constraints, with hardware lifecycles often extending beyond 20 years, and change or patch windows limited because of operational criticality. Many systems also depend on vendor-specific certifications or regulatory requirements that restrict rapid updates.
Rick-Cen called upon organizations to recognize that embedded scripting interfaces in industrial systems are often under-tested and over-privileged. Undocumented native bindings such as misc_exec represent latent backdoors, whether intentional or not. Devices that are considered ‘secure by design’ frequently expose administrative features that undermine the very security controls they are meant to enforce.
“If you’re operating or managing mbNet HW 1 (FW <5.1.11) devices — segment them now,” he pointed out. “Audit scripting access. And assume any exposed interface can be escalated.”
