CVE-2026-63641: MagicMirror² RCE Vulnerability

CVE-2026-63641 Overview

CVE-2026-63641 affects MagicMirror², an open source modular smart mirror platform. Prior to version 2.37.0, the ipWhitelist control is applied only as Express middleware. The Socket.IO server in js/server.js is attached directly to the HTTP server without an equivalent IP allowlist, origin, or namespace authentication check. An unauthenticated adjacent-network client can connect directly to module Socket.IO namespaces and dispatch arbitrary events through js/node_helper.js to socketNotificationReceived. This weakness is classified under [CWE-284] Improper Access Control.

Critical Impact
Adjacent-network attackers can trigger server-side requests through newsfeed and calendar helpers, and conditionally reach child_process.exec via the updatenotification helper when a third-party module update is pending.

Affected Products

MagicMirror² versions prior to 2.37.0
Deployments relying on ipWhitelist in non-loopback configurations
Third-party modules using the default node_helper.js dispatch pattern

Discovery Timeline

2026-08-18 - CVE CVE-2026-63641 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-63641

Vulnerability Analysis

MagicMirror² enforces client IP restrictions using Express middleware. The Socket.IO server, however, is attached directly to the underlying HTTP server and bypasses that middleware chain. As a result, connections to Socket.IO namespaces skip the ipWhitelist check entirely.

Once connected, a client can invoke socketNotificationReceived in any loaded module helper. The default newsfeed and calendar helpers perform server-side HTTP fetches against attacker-supplied URLs, enabling Server-Side Request Forgery against internal services. The updatenotification helper can reach child_process.exec when a third-party module update is pending and the attacker provides an update command through the socket CONFIG path, producing conditional command execution.

Root Cause

The root cause is inconsistent access control between transport layers. The ipAccessControl middleware guarded Express routes only. The Socket.IO server, its namespaces, and its handshake path had no equivalent IP, origin, or namespace-level authentication.

Attack Vector

Exploitation requires adjacent-network access to the MagicMirror² host. The attacker opens a Socket.IO connection, joins a module namespace, and emits crafted notification events. No authentication, credentials, or user interaction are required.

javascript

// Security patch in js/ip_access_control.js
// fix(server): enforce ipWhitelist for Socket.IO too (#4169)

/**
 * Resolves a client IP for both Express and Socket.IO requests.
 * If the direct peer is loopback, trust the first X-Forwarded-For value (local reverse proxy case).
 * Otherwise ignore X-Forwarded-For to prevent spoofing.
 * @param {object} req - Incoming request object (Express request or Socket.IO handshake request)
 * @returns {string} The resolved client IP address
 */
function resolveClientIp (req) {
	const directIp = req.socket?.remoteAddress || req.connection?.remoteAddress || req.ip;
	const LOOPBACK_WHITELIST = ["127.0.0.1", "::ffff:127.0.0.1", "::1"];

	if (isAllowed(directIp, LOOPBACK_WHITELIST)) {
		const forwardedFor = req.headers?.["x-forwarded-for"];
		if (typeof forwardedFor === "string" && forwardedFor.trim().length > 0) {
			return forwardedFor.split(",")[0].trim();
		}
	}

	return directIp;
}

Source: GitHub Commit 58c2a5e

The accompanying change in js/server.js imports and applies the new socketIpAccessControl handler so that Socket.IO handshakes enforce the same allowlist as Express.

Detection Methods for CVE-2026-63641

Indicators of Compromise

Socket.IO handshake requests from non-loopback, non-whitelisted IP addresses on the MagicMirror² port
Outbound HTTP requests from the MagicMirror² host to unexpected URLs sourced from the newsfeed or calendar helpers
Unexpected child_process executions spawned by the updatenotification module helper

Detection Strategies

Monitor MagicMirror² process network telemetry for outbound connections to arbitrary internal or external URLs not defined in the local config.js.
Alert on Socket.IO connections whose source IP is not present in the configured ipWhitelist.
Inspect logs for socketNotificationReceived events referencing CONFIG payloads from non-loopback peers.

Monitoring Recommendations

Baseline outbound egress from smart-mirror hosts and flag deviations, particularly requests targeting RFC1918 ranges.
Track child process creation under the Node.js runtime hosting MagicMirror² and correlate with the updatenotification code path.
Capture Socket.IO handshake headers and peer IPs at a reverse proxy for retrospective review.

How to Mitigate CVE-2026-63641

Immediate Actions Required

Upgrade MagicMirror² to version 2.37.0 or later, which enforces ipWhitelist on Socket.IO handshakes.
Restrict MagicMirror² network exposure to loopback or a trusted management segment until patching is complete.
Audit installed third-party modules for update pending states that could satisfy the updatenotification command execution precondition.

Patch Information

The fix is delivered in MagicMirror² v2.37.0 via Pull Request #4169 and commit 58c2a5e. Details are published in GitHub Security Advisory GHSA-w26r-fwg8-rcp3.

Workarounds

Bind MagicMirror² to 127.0.0.1 only and place it behind a reverse proxy that terminates authenticated connections.
Block inbound connections to the MagicMirror² TCP port at the host firewall from all non-trusted adjacent hosts.
Remove or disable third-party modules that are not required, reducing the exposed set of node_helper.js handlers.

bash

# Host firewall example: restrict MagicMirror² port 8080 to loopback
sudo iptables -A INPUT -p tcp --dport 8080 ! -s 127.0.0.1 -j DROP
sudo iptables -A INPUT -p tcp --dport 8080 -s 127.0.0.1 -j ACCEPT