motionEye: Authentication possible via password hashGHSA-r3cw-c95m-wfh9
GHSA-r3cw-c95m-wfh9 is a CWE-256 vulnerability in motioneye. A fix is available for motioneye — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-r3cw-c95m-wfh9.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
motioneyeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | motioneye | all versions | 0.44.0pip install --upgrade 'motioneye==0.44.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for motioneye, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update motioneye to 0.44.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r3cw-c95m-wfh9 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-r3cw-c95m-wfh9 in your dependencies?
Find it across PyPI, including transitive dependencies.