MagicMirror² CVE-2026-63640

Exploitation requires: (1) hideConfigSecrets must be set to true in the MagicMirror configuration - this is the feature that establishes the SECRET_* variable naming convention the attacker exploits; (2) the attacker must have Socket.IO connectivity to the MagicMirror server, which by default listens on the local network (AV:A); (3) at least one module namespace must be loaded that echoes attacker-controlled payload fields - the default weather module provides a confirmed echo path via INIT_WEATHER/WEATHER_ERROR, but other custom modules may also qualify. No authentication is required (PR:N per CVSS). Exploitation is limited by the adjacent-network constraint - the attacker must reach the Socket.IO port, typically TCP 8080, from the same subnet or via a forwarded port. The cors: allowAll configuration paradoxically blocks exploitation in the unpatched code because that branch skips secret expansion, but it introduces separate security concerns.

The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:L) scores 4.3, reflecting adjacent-network access without authentication - consistent with MagicMirror's typical LAN/home-network deployment model. While the CVSS score is moderate, the actual data sensitivity is higher than the C:L metric implies: SECRET_* variables are explicitly API tokens and service credentials, not generic low-value data. EPSS and KEV data are not provided in the intelligence feed; no confirmed active exploitation is noted. POC availability is not confirmed, though the GHSA advisory provides sufficient technical detail for a skilled attacker to construct a working exploit. The adjacent-network (AV:A) constraint meaningfully reduces internet-scale risk - exploitation requires a client already connected to the same local network or WebSocket endpoint. However, MagicMirror instances occasionally expose their Socket.IO interface beyond the local subnet when misconfigured or port-forwarded, which elevates practical risk in those deployments. The fix in 2.37.0 introduces a principled allow-list approach - per-module secret permissions derived from the redacted config - rather than blocking expansion wholesale, which is the correct architectural fix. Overall this is a genuine credential-disclosure risk worth patching promptly, but not an emergency requiring immediate compensating controls for air-gapped home deployments.

An attacker on the same LAN as a MagicMirror instance connects to the Socket.IO weather module namespace and emits an INIT_WEATHER event with a payload where instanceId is set to SECRET_OPENWEATHERMAP_API_KEY (or any known SECRET_* variable name). The server-side dispatcher expands the placeholder before passing the payload to the weather helper, which copies the expanded instanceId and returns it in a WEATHER_ERROR notification - delivering the live API key directly to the attacker's socket listener. No authentication is required for this interaction.