motionEye: Authentication possible via password hash
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:
After manually adding or submitting blank credentials to get the cookies loaded:
Adding the credentials and refreshing the page gives us a valid session:
version information and session interaction validation
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
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected packages
Versions sourced from the GitHub Security Advisory.
| Package | Affected versions | Patched versions |
|---|---|---|
motioneyePyPI | < 0.44.0 | 0.44.0 |
Affected products
1Patches
Vulnerability mechanics
Root cause
"The application trusts client-supplied cookie values (`meye_username` and `meye_password_hash`) as sufficient authentication material without server-side validation. [CWE-287]"
Attack vector
An unauthenticated attacker can set the client-controlled cookies `meye_username` and `meye_password_hash` using browser developer tools or by submitting blank credentials [ref_id=2]. The server accepts these cookie values as sufficient authentication material without validating them against a server-side session, bypassing the intended login flow [CWE-287]. If the attacker knows a target username and the corresponding password hash (e.g., from the world-readable `/etc/motioneye/motion.conf` file), they can impersonate that user without knowing the plaintext password [CWE-836].
What the fix does
The advisory does not include a patch diff. The recommended remediation would require the server to stop trusting client-supplied cookie values as authentication material and instead enforce server-side session validation [ref_id=2]. Without a patch, the fix would involve validating the supplied hash against a server-side store and ensuring that authentication state is established only through the proper login flow, not by simply reading cookie values.
Preconditions
- inputAttacker must know a valid username and the corresponding password hash for that user.
- authNo prior authentication or session is required; the cookies can be set before login.
- inputThe attacker can set arbitrary cookie values via browser tools or by submitting blank credentials.
Reproduction
1. Open the motionEye web interface in an unauthenticated browser session. 2. Use browser developer tools to set the cookies `meye_username` to a target username (e.g., `admin`) and `meye_password_hash` to the corresponding password hash. 3. Refresh the page; the application authenticates the attacker as the specified user without requiring the plaintext password [ref_id=2].
Generated on Jun 23, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
2News mentions
0No linked articles in our index yet.