EUVD-2026-78930
GHSA-r3cw-c95m-wfh9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessRead world-readable motion.conf locally
-
DeliveryExtract admin username and password hash
-
ExploitSet meye_username and meye_password_hash cookies
-
ExecutionRefresh page to gain authenticated session
-
ImpactChange password / exfiltrate or destroy data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V6 - Authentication Credential storage protection
|
| Exploitation Conditions | Exploitation requires the attacker to possess a valid |
| Impact | The CVSS 4.0 base score of 9.1 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N) captures network-reachable, unauthenticated abuse but importantly includes AT:P - an attack requirement - because exploitation is not self-contained: the attacker must first obtain a valid username and password hash. In practice that hash comes either from a compromised secondary source or, most realistically, from local shell access to the world-readable |
| Exploit ScenarioDerived | A low-privileged local user on a shared MotionEye host reads the world-readable |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 16, 2026
Authentication bypass in MotionEye (Python/pip package motioneye) before 0.44.0 lets an attacker impersonate any user, including admin, by setting the client-controlled cookies meye_username and meye_password_hash rather than proving knowledge of a plaintext password. The server trusts these cookies as sufficient authentication material without validating them against server-side session state, so anyone who obtains a valid username/hash pair gains a fully authenticated session. The admin hash is trivially recoverable because it is stored in the world-readable /etc/motioneye/motion.conf; a vendor patch exists (0.44.0) and no public exploit beyond the reporter's PoC has been identified at time of analysis.
RemediationAI
Vendor-released patch: upgrade to MotionEye 0.44.0, which is the fixed release (commit 0d5cb9c238a87447dae29812e5bf2ccf323cf3dc via PR https://github.com/motioneye-project/motioneye/pull/3332); it replaces the SHA-1 cookie-hash scheme with Argon2, adds server-side session-invalidation on password change, and introduces relay/client secrets. See the advisory at https://github.com/advisories/GHSA-r3cw-c95m-wfh9. If immediate upgrade is not possible, tighten filesystem permissions on /etc/motioneye/motion.conf so it is not world-readable (chmod 640 and restrict to the service account) to block the local hash-disclosure path - note this does not fix the underlying cookie-trust bug and any pre-existing hash exposure or off-host username/hash knowledge still permits impersonation. Additionally restrict network access to the MotionEye web port to trusted management networks/VPN, and after patching force a password reset for all accounts since existing hashes may already be compromised.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MotionEye is an open-source web frontend for the Motion video-surveillance daemon, commonly self-hosted on Raspberry Pi and Linux NVR/homelab setups and distributed via the pip/motioneye package. The flaw is a design failure in its session model: instead of issuing and validating an opaque server-side session token, the application accepts the client-supplied cookies meye_username and a SHA-1 password-hash-derived value (meye_password_hash) as proof of identity. These cookies are legitimately produced by the 'switch user' feature but can be injected before login via browser dev tools or by submitting blank credentials. CWE-256 (unprotected storage of credentials) captures the aggravating factor - the admin username and password hash sit in globally-readable /etc/motioneye/motion.conf - though the core root cause is reliance on unvalidated client-controlled authentication cookies (a CWE-287/CWE-565-class defect). The 0.44.0 fix replaces SHA-1 hashing with Argon2 (PasswordHasher), adds relay/client secrets, and introduces server-side session invalidation on password change.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
App-side auth needs no credentials (PR:N), but exploitation depends on first obtaining a valid username/hash (typically local file read), so AC:H; high C/I from full account takeover, no direct availability impact.
Primary rating from Vendor (https://github.com/motioneye-project/motioneye).
CVSS VectorVendor: https://github.com/motioneye-project/motioneye
Lifecycle Timeline
3DescriptionCVE.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
Executive ViewAI
MotionEye surveillance systems are vulnerable to administrative impersonation through a cookie-based authentication bypass, allowing attackers to gain full control without possessing passwords. Attackers can trivially extract valid administrative credentials from standard configuration files, enabling unauthorized surveillance access and system takeover. Immediate patching is critical to prevent compromise of physical security infrastructure.
Apply vendor patch: MotionEye 0.44.0
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB