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.

Affected: npm: magicmirror

### Summary MagicMirror applies `ipWhitelist` only as Express middleware, but the Socket.IO server is attached directly to the HTTP server without equivalent IP allowlist, origin, or namespace authentication checks. In a documented common deployment where MagicMirror listens on a non-loopback interface but expects `ipWhitelist` to restrict access, an untrusted network client can connect directly to module Socket.IO namespaces and send arbitrary module-helper notifications. This allows unauthenticated server-side requests through default modules and can reach command execution in the default `updatenotification` helper when a third-party module update is pending and the attacker supplies the update command through the trusted socket configuration path.

### Details The affected product is the npm package/application `magicmirror` at version `2.36.0`, tested at commit `fb41d24ef522e91e802e2a623ff6afbddeb3c9d8` from `https://github.com/MagicMirrorOrg/MagicMirror.git`.

Default committed settings bind to loopback and allow loopback only (`js/defaults.js:8-13`), so the remote network impact requires a documented common configuration where the server is reachable beyond loopback. The shipped sample explicitly documents non-loopback binding and IP allowlist behavior: `config/config.js.sample:11-20` says `address` may be another interface or `0.0.0.0`/`::`, and `ipWhitelist` controls allowed clients.

The trust-boundary issue is that Socket.IO is configured before and outside the Ex…