CVE-2026-46488: motionEye Authentication Bypass Vulnerability

CVE-2026-46488 Overview

motionEye (mEye) is a web-based frontend for the motion video surveillance daemon. Versions prior to 0.44.0 accept the client-controlled meye_username and meye_password_hash cookies as authentication material without any server-side session validation. An unauthenticated attacker who knows a target username and its corresponding password hash can set these cookies directly or trigger them through the switch-user flow with blank credentials. The server then treats the attacker as that user. Because the administrator username and password hash are stored in /etc/motioneye/motion.conf with world-readable permissions, any local shell user can extract reusable administrator credential material [CWE-256].

Critical Impact

Unauthenticated attackers who obtain a valid username and stored password hash can impersonate any motionEye user, including administrators, enabling account lockout, credential rotation, data enumeration, destruction, and exfiltration.

Affected Products

• motionEye (mEye) versions prior to 0.44.0
• Deployments where /etc/motioneye/motion.conf retains default world-readable permissions
• Docker and bare-metal motionEye installations exposing the web interface

Discovery Timeline

• 2026-09-15 - CVE-2026-46488 published to NVD
• 2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-46488

Vulnerability Analysis

The flaw is an authentication design defect classified as insecure credential storage combined with client-side authentication trust [CWE-256]. motionEye derives session identity from two cookies sent by the client: meye_username and meye_password_hash. The server compares the cookie hash to the stored hash and, if they match, grants access without any additional server-side session state, token binding, or nonce validation.

The stored administrator password hash in /etc/motioneye/motion.conf is world-readable by default. This turns the hash into a reusable credential rather than a verification artifact. Any local user, low-privileged service account, or container process with read access to the config file can lift the hash and authenticate remotely.

Root Cause

motionEye stores the administrator credential hash in plaintext-readable form and treats that hash as a bearer token when supplied via cookie. There is no server-issued session identifier, no HMAC-signed session, and no per-login nonce. Possession of the hash is equivalent to knowledge of the password.

Attack Vector

An attacker with local read access to /etc/motioneye/motion.conf extracts the admin username and password hash. The attacker then sets meye_username and meye_password_hash cookies in a browser or HTTP client and issues a request to the motionEye web interface. Alternatively, submitting blank credentials through the switch-user authentication flow causes the server to load the cookies and authenticate the attacker as that user.

// Patch scope indicator from the fix commit
// Source: https://github.com/motioneye-project/motioneye/commit/0d5cb9c238a87447dae29812e5bf2ccf323cf3dc
// Title: "Replace URL signature auth with sessions and HMAC peer authentication (#3332)"
+* text=auto
+*.sh text eol=lf
+linux_init text eol=lf
+po2json text eol=lf
+*.py text eol=lf

The fix in pull request #3332 replaces the cookie-hash scheme with server-side sessions and HMAC-based peer authentication.

Detection Methods for CVE-2026-46488

Indicators of Compromise

• HTTP requests to motionEye endpoints containing meye_username and meye_password_hash cookies originating from unexpected source IP addresses.
• Authentication events for the admin account from hosts that have never previously interacted with the motionEye console.
• Local read access to /etc/motioneye/motion.conf by processes or users outside the motioneye service account.
• Sudden password changes, new administrator accounts, or camera configuration deletions in motionEye audit logs.

Detection Strategies

• Alert on any HTTP request presenting meye_password_hash cookies from IP ranges outside the operational baseline.
• Monitor file access telemetry for reads of /etc/motioneye/motion.conf by unexpected UIDs or container processes.
• Correlate switch-user requests submitted with empty credential fields against subsequent authenticated sessions.

Monitoring Recommendations

• Ingest motionEye web server access logs into a centralized logging platform and retain cookie header metadata for authentication events.
• Track filesystem audit events (auditd watch on /etc/motioneye/motion.conf) for read operations outside the service context.
• Baseline administrator login source IPs and alert on deviations.

How to Mitigate CVE-2026-46488

Immediate Actions Required

• Upgrade motionEye to version 0.44.0 or later.
• Rotate all motionEye user passwords after upgrading, because previously stored hashes may already have been harvested.
• Restrict permissions on /etc/motioneye/motion.conf to the motionEye service account only (for example, chmod 600 and chown motioneye:motioneye).
• Review motionEye access logs for anomalous authenticated sessions dating back to deployment.

Patch Information

The fix is delivered in motionEye 0.44.0 via commit 0d5cb9c, which replaces URL signature and cookie-hash authentication with server-side sessions and HMAC peer authentication. See GHSA-r3cw-c95m-wfh9 for the full advisory.

Workarounds

• Place motionEye behind a reverse proxy that enforces its own authentication (for example, HTTP basic auth, OAuth2 proxy, or mTLS) until the upgrade is applied.
• Block network access to the motionEye web interface from untrusted networks using host or perimeter firewall rules.
• Tighten filesystem ACLs on /etc/motioneye/motion.conf to prevent non-service local users from reading the stored hash.

# Restrict motionEye configuration file permissions
sudo chown motioneye:motioneye /etc/motioneye/motion.conf
sudo chmod 600 /etc/motioneye/motion.conf

# Verify version after upgrade
motioneye --version