• Posted by: Eng. Donya Bino
• February 14, 2026

motionEye 0.43.1b4 RCE via Config File Injection

The open-source webcam security software, MotionEye, is vulnerable to remote code execution, identified as CVE-2025-60787 (motionEye <= 0.43.1b4). Authenticated users with access to the web UI may inject arbitrary shell meta-characters into the config fields; primarily the image_file_name config option under Still Images. 

Subsequently, when the daemon reloads the config (on restart or camera reload), it parses these values as shell commands, resulting in execution of arbitrary commands with the permission of the motion daemon user (usually root or some privileged container user in Docker).

Root Cause
The frontend for motionEye does perform basic validation of some filename fields when entering data using JavaScript, but this validation can easily be bypassed by overriding the validation function from the browser's console. The backend takes the unsanitized filename value that the user provides and saves it directly into the configuration file for the camera (e.g., camera-0.conf). Later, the motion daemon reads the configuration files and uses the filename values in shell contexts without proper escaping or whitelisting, which is a classic so-called command injection vulnerability.

Real-world impact
1. MotionEye is commonly used for home or office security applications, typically on either a Raspberry Pi or in Docker.
2. Most motionEye installations run either as root or use broad host access (e.g., --privileged Docker flag).
3. MotionEye installations that are exposed to the Internet or are part of a shared network are susceptible to unauthenticated attackers using phishing techniques to obtain credentials or to exploit weak or default logins.
4. Authenticated users, even if their user accounts have limited privileges, can use this vulnerability to escalate their access to the host system.

Mitigation Strategies 
1. To mitigate filename injection attacks you must upgrade to motionEye version 0.43.2 or later (or simply keep up with the latest edge release recommended after Sept 2025) as it adds support for filename sanitization/whitelisting capabilities that provide better security controls. 

2. Do not allow user-controlled passing of event-handlers/custom configurations. It is suggested that you either disable the event-handlers or disable option to pass user-controlled values depending on how you prefer to review them. 

3. Run your motionEye containers as the least privileged users possible (drop capabilities, create non-root users, do not run with the ' -- privileged ' option) in order to reduce the overall impact of an intrusion attempting to use your motionEye instance as a place to perform other activities. 

4. Do not expose motionEye directly to the Internet without utilizing some form of strong authentication (e.g. VPN, reverse proxy, multiple forms of user verification) to protect against unauthorized access from outside your network perimeter. 

5. It is important to routinely check your MotionEye container for files created in an 'abnormal' manner and anything else that may be out of the ordinary compared to typical motionEye directores (for instance, files created in /tmp or /var/lib/motion would be considered 'abnormal' files).

Additionally, this serves to remind you that many surveillance software programs utilize high-level privileges and have exposed ports, making them an attractive target for lateral movement and persistence within IoT and OT environments.

For complete advisory and upstream fix information, please reference the GitHub motioneye-project/motioneye releases and security advisories published after September 2025, as well as NVD entry CVE-2025-60787.

Source: Exploit DB