The ActionHandler.post() method in motionEye has no authentication decorator, allowing any unauthenticated attacker to trigger camera actions including snapshots, recording start/stop, and configured action scripts (PTZ controls, alarm triggers, etc.).
mEye contains an absolute path traversal vulnerability in multiple media file handlers that allows an attacker to read arbitrary files from the filesystem. The affected handlers accept a user-controlled filename parameter and construct filesystem paths using os.path.join(). When an absolute path is supplied, Python discards the configured media directory and returns the attacker-supplied path directly. The application then bypasses Tornado's built-in path validation by overriding the relevant safety checks. As …
A multi‑stage chain in motionEye leads to remote code execution. The chain combines: Arbitrary file read (LFI) via the picture download endpoint for local motion cameras using absolute paths. Pass‑the‑hash admin auth due to accepting request signatures computed with password hashes. Unsafe config restore that extracts attacker‑controlled tarballs into CONF_PATH. Unauthenticated action execution via /action/<id>/<action>. If the normal user password is unset, the chain becomes unauthenticated RCE. If a normal …
Myself and others have reported several RCE vulnerabilities to this project. However, due to the nature of the app, these are largely not of all that much value, as there is built-in functionality to run commands upon certain actions — i.e. RCE is by design. With that in mind, I endeavored to find some sort of auth bypass, and was slightly successful. When the admin password is set but the …
motionEye v0.43.1 and prior versions create the configuration file /etc/motioneye/motion.conf with 644 permissions (-rw-r–r–), making it readable by any local user on the system. This file contains sensitive data including the admin password hash, which can be leveraged by other vulnerabilities to escalate privileges.
An authentication bypass vulnerability exists due to improper trust in client-controlled cookies. The application accepts user-supplied cookie values containing a username and password-hash-derived value as sufficient authentication material. These cookies can be set or modified prior to login, allowing an unauthenticated attacker to impersonate arbitrary users without knowledge of the plaintext password. This issue stems from the absence of server-side validation of authentication state and reliance on attacker-controlled cookie data
motionEye v0.43.1 (latest stable) is vulnerable to path traversal in the picture and movie API endpoints, like /picture/{id}/preview/{filename}. Neither the API handlers, nor the mediafiles.py functions like get_media_preview() check for .. sequences in the filename parameter, except get_media_content() which does. This allows an authenticated user with normal (non-admin) privileges to read arbitrary files from the filesystem as the motionEye process user.
A command injection vulnerability in MotionEye allows attackers to achieve Remote Code Execution (RCE) by supplying malicious values in configuration fields exposed via the Web UI. Because MotionEye writes user-supplied values directly into Motion configuration files without sanitization, attackers can inject shell syntax that is executed when the Motion process restarts. This issue enables full takeover of the MotionEye container and potentially the host environment (depending on container privileges).
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-j945-qm58-4gjx. This link is maintained to preserve external references. Original Description MotionEye v0.43.1b4 and before is vulnerable to OS Command Injection in configuration parameters such as image_file_name. Unsanitized user input is written to Motion configuration files, allowing remote authenticated attackers with admin access to achieve code execution when Motion is restarted.
Using a constructed (camera) device path with the config/add/add_camera motionEye web API allows an attacker with motionEye admin user credentials to execute any UNIX shell code within a non-interactive shell as executing user of the motionEye instance, motion by default.
MotionEye v0.42.1 and below allows attackers to access sensitive information via a GET request to /config/list. To exploit this vulnerability, a regular user password must be unconfigured.
Authenticated remote code execution in MotionEye and MotioneEyeOS allows a remote attacker to upload a configuration backup file containing a malicious python pickle file which will execute arbitrary code on the server.