MagicMirror² CVE-2026-63641

Exploitation requires MagicMirror to be configured with a non-loopback address setting (e.g., 0.0.0.0, ::, or a specific LAN IP as documented in config/config.js.sample lines 11-20) - the default configuration in js/defaults.js binds only to loopback, making default installations unexploitable remotely. The ipWhitelist feature must be in use, because this vulnerability specifically bypasses that control; deployments without ipWhitelist have no network restriction regardless of this flaw and represent a different (broader) exposure model. The attacker must occupy an adjacent network position (same LAN or directly routed segment) - internet-sourced exploitation is not possible. For SSRF, the newsfeed or calendar default module must be active, which is the case for most deployments. For the conditional command execution path, a third-party module update must be pending at the time of the attack, and the attacker must successfully inject an update command through the socket CONFIG path - a time-dependent and state-dependent condition that substantially raises practical difficulty. Exploitation is definitively not possible against default loopback-only MagicMirror installations.

The official CVSS 4.0 score of 2.3 (AV:A/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L) accurately reflects the multi-layered prerequisite structure of this vulnerability. AV:A constrains exploitation to adjacent-network clients, immediately excluding internet-facing scenarios. AT:P captures the non-default but documented configuration requirement (non-loopback binding with ipWhitelist active). The SSRF path through newsfeed and calendar is the broadest reachable impact and requires only an active adjacent-network position plus the non-loopback deployment condition. The child_process.exec path additionally requires a pending third-party module update and attacker control of the update command payload through the socket CONFIG path - a materially higher bar that raises practical complexity well beyond the AC:L rating suggests for the simpler SSRF path. No EPSS data was provided, and no CISA KEV entry exists, indicating no confirmed widespread exploitation. The product's deployment profile - primarily DIY home and hobbyist smart mirror installations on residential or lab LANs - significantly constrains real-world blast radius. This is a genuine access-control design flaw warranting patching, but the combination of adjacent-network-only access, non-default configuration requirement, and conditional RCE path means it does not represent broad critical risk for most environments.

An attacker on the same LAN as a MagicMirror installation bound to 0.0.0.0 with ipWhitelist configured connects directly to a Socket.IO module namespace on the MagicMirror port, bypassing the Express ipWhitelist check entirely. The attacker sends a CHECK_ARTICLE_URL notification to the newsfeed helper specifying an internal network service URL, causing the MagicMirror server to issue an HTTP request to that endpoint and return results through the socket - achieving SSRF against internal infrastructure. If a third-party module update happens to be pending, the attacker additionally delivers a crafted update command through the CONFIG socket path, triggering child_process.exec on the host. No public exploit code has been identified at time of analysis.