motionEye CVE-2026-46488
CRITICAL
GHSA-r3cw-c95m-wfh9
Severity by source
Network-exploitable with no auth or UI, but requires prior knowledge of the password hash (local file read or leak), so AC:H; full admin takeover yields high C/I/A.
Lifecycle Timeline
2DescriptionCVE.org
Summary
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 meye_password_hash and meye_username 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 username and corresponding hash are known.
These cookies normally appear after using the "switch user" functionality; however, they can be added manually prior to authentication using standard browser tools (e.g., developer tools or cookie editors) or dynamically loaded by submitting blank credentials. When supplied, the server accepts them and authenticates the attacker as the specified user bypassing the intended authentication flow
Additionally, the password-hash value and username for the admin account used by the application is stored in /etc/motioneye/motion.conf which is globally readable by default on the local system. This means any local user with shell access can obtain a valid hash and values and use them to impersonate the admin via the cookie manipulation described above. While local access is required to retrieve the hash, this significantly lowers the barrier to exploitation in multi-user environments.
PoC
Starting state unauthenticated with no cookies: <img width="644" height="475" alt="start state" src="https://github.com/user-attachments/assets/cf4aff78-65f7-4f67-99e2-9134c8f04277" />
After manually adding or submitting blank credentials to get the cookies loaded: <img width="643" height="470" alt="empty cookies" src="https://github.com/user-attachments/assets/223878eb-f085-4ac5-a92a-2ac21831c594" />
Adding the credentials and refreshing the page gives us a valid session: <img width="641" height="466" alt="admin login with hash" src="https://github.com/user-attachments/assets/94b350ef-dd32-4cae-8bd8-e48841873f79" />
version information and session interaction validation <img width="643" height="468" alt="verison" src="https://github.com/user-attachments/assets/94290ad6-4e82-4026-8e27-5374e2f3a631" />
Impact
Authentication bypass
Who is impacted?
Any MotionEye deployment where attackers have access to a username and hash, and/or the /etc/motioneye/motion.conf file with the admin username and hash.
Potential consequences:
- Account lockouts
- Attacker persistence by changing the password
- Enumeration of data
- Destruction of data
- Exfiltration of data
AnalysisAI
Authentication bypass in motionEye versions prior to 0.44.0 allows remote attackers to impersonate any user, including the administrator, by setting the client-controlled cookies meye_password_hash and meye_username without ever knowing the plaintext password. The server treats these attacker-controlled values as sufficient authentication material, and because the admin hash is stored in a world-readable file (/etc/motioneye/motion.conf), any local shell user can trivially escalate to admin via the web UI. Publicly available exploit code exists in the GitHub Security Advisory GHSA-r3cw-c95m-wfh9, but there is no public exploit identified beyond the PoC and the issue is not in CISA KEV.
Technical ContextAI
motionEye is a Python (pip-distributed) web frontend for the motion video surveillance daemon, commonly deployed on Linux hosts and single-board computers (Raspberry Pi etc.) to manage IP/USB cameras. The flaw is a classic CWE-256 (plaintext/unsalted credential equivalent stored and trusted) combined with broken authentication: the server treats the password-hash value from a client cookie as proof of identity rather than verifying a server-issued session token. Because the same hash is persisted in /etc/motioneye/motion.conf with world-readable permissions, the hash itself functions as a password-equivalent secret, and the 'switch user' feature normalizes the presence of these cookies in the trust path.
RemediationAI
Vendor-released patch: upgrade motionEye to version 0.44.0 or later (pip install --upgrade motioneye) as published in GHSA-r3cw-c95m-wfh9 (https://github.com/motioneye-project/motioneye/security/advisories/GHSA-r3cw-c95m-wfh9). Until the upgrade can be applied, restrict network exposure of the motionEye web interface to trusted management networks or behind a reverse proxy that enforces its own authentication (note: this breaks any expected direct-from-internet access), and tighten filesystem permissions on /etc/motioneye/motion.conf to root-only (chmod 600, chown root:root) to block the local hash-disclosure path - be aware this may break daemon startup or features that expect the file to be readable by the motion service user, so test before deploying. Audit existing admin accounts for password rotation after upgrade, since any previously leaked hash remains a valid credential equivalent on unpatched instances.
Same weakness CWE-256 – Plaintext Storage of a Password
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today