MagicMirror² EUVD-2026-61072

The attacker must be able to reach the MagicMirror² HTTP port (default 8080) over the network - no authentication, credentials, or session token of any kind are required. Prior to v2.37.0, the IP whitelist (config.ipWhitelist) enforced access control only on Express HTTP routes, not on Socket.IO WebSocket upgrade handshakes, so even a correctly configured whitelist did not block this attack path. Exploitation is constrained by the following factors: (1) MagicMirror devices are typically deployed on home or private LAN segments and are not internet-facing - attackers must be on a network-adjacent segment or exploit a separate vulnerability to gain that position; (2) the oracle returns only boolean (canFrame) and timing data, not response bodies - restricting the attacker to host/port enumeration and side-effect observation rather than direct data reading; (3) side effects on internal services depend on those services responding meaningfully to unauthenticated HEAD requests.

The CVSS 4.0 score of 6.3 with AT:P (attack requirement: the attacker must reach the mirror's HTTP port) appropriately moderates the theoretical network-vector severity. The subsequent-system confidentiality impact (SC:L) reflects that the attacker gains a timing and boolean oracle - enough to enumerate live internal hosts and open ports - but not full response bodies, limiting this to reconnaissance rather than direct data exfiltration. No CISA KEV entry exists, and EPSS data was not supplied, preventing probabilistic exploitation-likelihood assessment. A functioning proof-of-concept is documented in the GHSA advisory, which materially lowers the skill threshold for exploitation and warrants treating this as higher priority than a comparable no-POC finding. The most realistic risk scenario is a network-adjacent attacker (e.g., on the same LAN as a home or office mirror deployment) using the mirror as a pivot to fingerprint internal services that respond to HEAD requests. Deployments where the mirror port is inadvertently exposed to broader segments - such as a flat corporate guest network - represent a higher-risk configuration. The bounded impact (no body exfiltration, no write capability on internal services) and niche deployment footprint keep real-world severity manageable, but the zero-authentication entry point and available POC make patching straightforward and urgent.

An attacker on the same local network as a MagicMirror² instance connects to its Socket.IO /newsfeed namespace (no credentials required) using the documented POC client exploit-ssrf-newsfeed.js and emits CHECK_ARTICLE_URL with a target such as http://10.0.0.1:8080/. The mirror's Node.js process issues a server-side HEAD request to that internal address and returns ARTICLE_URL_STATUS with timing data, allowing the attacker to determine whether the internal host and port are alive and infer service type from response headers observable in subsequent probes. By iterating over IP ranges and ports the attacker can produce a map of live internal services without ever touching those services directly.