CVE-2026-63641 in MagicMirror
Summary
by MITRE • 08/18/2026
MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, MagicMirror applies ipWhitelist only as Express middleware, while the Socket.IO server in js/server.js is attached directly to the HTTP server without equivalent IP allowlist, origin, or namespace authentication checks. In a documented non-loopback deployment that relies on ipWhitelist, an unauthenticated adjacent-network client can connect directly to module Socket.IO namespaces, and js/node_helper.js dispatches arbitrary events and payloads to socketNotificationReceived. The default newsfeed and calendar helpers can make server-side requests to attacker-selected URLs, while the default updatenotification helper can reach child_process.exec when a third-party module update is pending and the attacker supplies an update command through the socket CONFIG path. This can expose internal services, manipulate module-helper state, and conditionally execute commands. This issue is fixed in version 2.37.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
MagicMirror² serves as a prominent open-source modular smart mirror platform designed to display information on reflective surfaces via connected displays. The architecture relies heavily on Node.js for server-side logic, utilizing Express for HTTP handling and Socket.IO for real-time bidirectional communication between the client interface and the backend modules. In deployments prior to version 2.37.0, a critical architectural flaw existed in how network-level access control was implemented across different layers of the application stack. Specifically, while the primary web server utilized an IP whitelist middleware provided by Express to restrict access based on source addresses, this security measure was not applied uniformly to all communication channels. The Socket.IO server instance, which is attached directly to the underlying HTTP server in the core js/server.js file, operated without equivalent IP allowlist checks or origin validation mechanisms. This discrepancy created a significant bypass vector for attackers operating within the same local network segment as the MagicMirror device.
The technical flaw stems from the separation of concerns between the Express middleware layer and the Socket.IO connection handler. When an unauthenticated client connects to the WebSocket endpoint used by Socket.IO, it does not pass through the ipWhitelist middleware that protects standard HTTP routes. Consequently, any device on the adjacent network can establish a persistent socket connection without providing credentials or passing IP-based filters. Once connected, this attacker gains access to module-specific namespaces and event channels. The js/node_helper.js file is responsible for receiving these events via the socketNotificationReceived method, which acts as an entry point for executing logic within individual modules. Because there was no authentication or authorization check at the Socket.IO level, any client could dispatch arbitrary events and payloads directly into this processing pipeline, effectively bypassing the intended network isolation policies.
The operational impact of this vulnerability is severe due to the nature of the default modules included in MagicMirror² installations. The newsfeed module helper processes incoming data by making server-side HTTP requests to URLs specified within the feed configuration or dynamically through socket notifications. An attacker exploiting this flaw can manipulate these helpers to force the MagicMirror device to make outbound connections to maliciously controlled servers, potentially facilitating data exfiltration from internal services accessed via SSRF-like patterns if internal endpoints are reachable. Furthermore, the updatenotification helper introduces a risk of command injection under specific conditions. If a third-party module update is pending and triggered by socket events, an attacker can supply a crafted update command through the CONFIG path associated with the Socket.IO connection. This payload could be passed to child_process.exec, leading to arbitrary code execution on the host system running MagicMirror².
This vulnerability aligns with CWE-284 Improper Access Control, as it involves failing to enforce proper restrictions on authenticated users or actors within a given security context. Additionally, the ability of an unauthenticated adjacent network client to interact directly with internal services and execute commands maps closely to MITRE ATT&CK techniques such as T1076 Remote Desktop Protocol Abuse if used for lateral movement in broader contexts, but more accurately reflects T1534 Internal Spearphishing or direct exploitation patterns like T1203 Exploitation for Client Execution. The lack of origin validation also relates to CWE-942 Improper Control of Performance during Decoding and Decompression when considering the potential for resource exhaustion through malformed payloads, though the primary concern remains unauthorized access and command injection.
Mitigation requires immediate upgrading to MagicMirror² version 2.37.0 or later, where these authentication checks have been implemented across all communication channels including Socket.IO connections. For environments that cannot immediately upgrade, administrators should consider deploying a reverse proxy in front of the application to enforce IP filtering at the network edge before requests reach either the Express server or the WebSocket endpoint. Additionally, restricting the binding address of the MagicMirror service to localhost and using SSH tunneling for remote access can isolate the vulnerable components from direct adjacent-network exposure until patches are applied. It is also advisable to audit third-party modules for similar vulnerabilities in their socket handling logic, as custom modules may not inherit these fixes automatically if they implement their own connection handlers outside the core framework updates.