Remote Code Execution in MagicMirror²

Executive Summary

MagicMirror² before version 2.37.0 only enforced IP whitelist restrictions on HTTP routes via Express middleware. The Socket.IO server, attached directly to the HTTP server, lacked equivalent IP allowlist checks. This allowed unauthenticated adjacent-network clients to connect to module Socket.IO namespaces and trigger arbitrary events in js/node_helper.js. Default modules like newsfeed and calendar could make server-side requests to attacker-selected URLs, while updatenotification could execute commands via child_process.exec if a third-party module update was pending.

Useful 0 Not Useful 0

Detection Guidance

Check if MagicMirror is running on a non-loopback interface with ipWhitelist enabled. Inspect network traffic for unauthorized Socket.IO connections to module namespaces. Review logs for unexpected module-helper events or SSRF attempts.

Useful 0 Not Useful 0

Impact Analysis

An attacker on the same network could exploit this to access internal services, manipulate module state, or execute commands. Default modules may perform SSRF by fetching data from attacker-controlled URLs. If a third-party module update is pending, the attacker can supply a malicious update command to execute arbitrary code via child_process.exec.

Useful 0 Not Useful 0

Mitigation Strategies

Upgrade MagicMirror to version 2.37.0 or later. Ensure ipWhitelist is properly configured and enforced for both HTTP and Socket.IO connections. Restrict network access to non-loopback interfaces if not required.

Useful 0 Not Useful 0