Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Partial Authentication Bypass: Unauthenticated Admin Credential Theft via Path Traversal Summary 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 normal (surveillance) user password is left empty (the default), an unauthenticated attacker can exploit a path traversal vulnerability to read the motionEye configuration file from disk. This file contains the admin password as a SHA-1 hash, and that hash is accepted directly as a signing key for admin API requests — no cracking required. The result is full admin access from zero credentials. This is a realistic scenario: many installations set an admin password to protect the settings UI but leave the…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A multi‑stage chain in motionEye leads to remote code execution. The chain combines: 1. Arbitrary file read (LFI) via the picture download endpoint for local motion cameras using absolute paths. 2. Pass‑the‑hash admin auth due to accepting request signatures computed with password hashes. 3. Unsafe config restore that extracts attacker‑controlled tarballs into CONFPATH. 4. Unauthenticated action execution via /action/<id/<action. If the normal user password is unset, the chain becomes unauthenticated RCE. If a normal password exists, a normal user can still achieve admin escalation and RCE. --- Affected Code (motionEye repo) 1) LFI (absolute path) — picture/<id/download Files: - motioneye/motioneye/handlers/picture.py → download() (local motion camera branch) - motioneye/motioneye/mediafiles.py → getmediacontent() Issue: getmediacontent() only blocks .. and then joins targetdir with path. Absolute paths (e.g. /etc/hosts) bypass the join and are read directly. 2) Pass‑the‑hash…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.). Vulnerability Details File: motioneye/handlers/action.py — ActionHandler.post() line 36 CWE: CWE-862 — Missing Authorization CVSS: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3 Medium Vulnerable Code Compare with other handlers that correctly require authentication: Steps to Reproduce 1. Deploy motionEye with at least one camera configured 2. Send unauthenticated POST: 3. Observe {} (HTTP 200) response — snapshot triggered without any credentials For action scripts (lock, unlock, alarmon, alarmoff, lighton, etc.): Impact - Unauthenticated attacker can trigger camera snapshots on demand - Unauthenticated attacker can start/stop video recording - If action scripts are configured by admin: attacker can trigger PTZ movement,…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 result, an attacker can access files outside of the configured camera media directory, subject to the permissions of the motionEye process. Details The issue exists in the media playback and download functionality. The filename parameter is passed to mediafiles.getmediapath(): When path is an absolute path (e.g. /etc/motioneye/motion.conf), Python's os.path.join() discards targetdir entirely and returns the absolute path as-is. This would normally be caught by…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Details The vulnerability arises because the application accepts the client-supplied cookies named meyepasswordhash and meyeusername as sufficient authentication material. The server does not validate these values against a server-side session or enforce proper authentication checks before establishing an authenticated state. As a result, an unauthenticated attacker can set or modify these cookies to impersonate another user if the target…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Security Advisory: World-Readable Configuration File Exposes Admin Password Hash in motionEye Summary 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. Affected Versions - motionEye <= 0.43.1b4 - Fixed in motionEye 0.44.0b1 (applies 0600 mode to motion.conf and camera-.conf files) Vulnerability Details World-Readable Configuration File (CWE-732) When motionEye writes its configuration, the file /etc/motioneye/motion.conf is created with 644 permissions regardless of the installation method. This file contains the admin password hash in the @adminpassword field: Any local user can read this hash without elevated privileges: Additionally, per-camera configuration files (camera-.conf) are also created with the same 644…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 getmediapreview() check for .. sequences in the filename parameter, except getmediacontent() which does. This allows an authenticated user with normal (non-admin) privileges to read arbitrary files from the filesystem as the motionEye process user. Details The getmediacontent() function properly validates the path: But getmediapreview() does NOT: Similarly, delmediacontent() at line ~865 is also missing the check. This is a classic inconsistent fix pattern. The exploit requires %2F-encoded slashes (..%2F..%2F) which Tornado's URL router does NOT normalize — it passes the raw ../ through to os.path.join(). PoC Step 1: Authenticate as any user (normal or admin). Step 2: Compute the request signature. motionEye uses HMAC-style signatures for API authentication. The signature…
Recommended action: Upgrade to 0.44.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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). Details Root Cause: MotionEye accepts arbitrary strings from fields such as imagefilename and moviefilename in the Web UI. These are written directly into /etc/motioneye/camera-.conf. When MotionEye restarts the Motion service (motionctl.start), the Motion binary reads this configuration. Because Motion treats these fields as shell-expandable, injected characters (e.g. $(), backticks) are interpreted as shell commands. Vulnerability flow: Dashboard (Web UI) ↓…
Recommended action: Upgrade to 0.43.1b5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using a constructed (camera) device path with the config/add/addcamera 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. function call stack 1. post 2. addcamera 3. config.addcamera 4. v4l2ctl.listresolutions 5. utils.callsubprocess 6. subprocess.run PoC build reproduce Run: Now, run the following script to attack motionEye: <img width="1187" alt="Image" src="https://github.com/user-attachments/assets/8e0a9bfe-8de3-4023-96d6-0e888bfe3c62" / <img width="324" alt="Image" src="https://github.com/user-attachments/assets/04c73349-694a-4531-993e-eea765b87d0e" / Discussion It is obvious that callsubprocess was used to execute the incoming data, resulting in a vulnerability Impact RCE Patches The vulnerability has been patch with motionEye v0.43.1b4: https://github.com/motioneye-project/motioneye/pull/3143 Workarounds Applying the…
Recommended action: Upgrade to 0.43.1b4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.43.1b1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.