Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When hideConfigSecrets: true is enabled, MagicMirror redacts SECRET environment placeholders in the HTTP /config response, but the shared node-helper socket dispatcher expands SECRETNAME placeholders in every inbound socket payload before passing it to module helpers. Any client that can connect to a loaded module namespace can send a placeholder such as SECRETAPIKEY and cause the server to substitute the real environment variable into the helper payload. Helpers that echo attacker-controlled payload fields, such as the default weather helper error path, can return the secret value to the socket client. 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. The secret-redaction feature is implemented during config loading: - js/utils.js:117-123 loads a config.env file next to the config file into process.env when present. -…
Recommended action: Upgrade to 2.37.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability — SSRF via ADDCALENDAR (MagicMirror² calendar) Analysis of the PoC exploit-ssrf-calendar.js. Target: calendar/nodehelper.js of MagicMirror², socket.io namespace /calendar. --- Identification | Field | Value | |-------|-------| | PoC file | exploit-ssrf-calendar.js | | Endpoint | socket.io namespace /calendar, notification ADDCALENDAR | | Precondition | reach the mirror's HTTP port (no authentication required) | --- Description The ADDCALENDAR handler in calendar/nodehelper.js performs a server-side HTTP request to a URL that is fully attacker-controlled, with no SSRF protection whatsoever — unlike the project's hardened /cors endpoint. Worse, the attacker also controls: - the authentication headers the server attaches to the request (auth: { method: "bearer", pass: "..." }); - the selfSignedCert flag, which disables TLS verification of the server-side request. When the target's response is valid iCal, the server parses the events and sends them back to the attacker via…
Recommended action: Upgrade to 2.37.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability — Blind SSRF via CHECKARTICLEURL (MagicMirror² newsfeed) Analysis of the PoC exploit-ssrf-newsfeed.js. Target: newsfeed/nodehelper.js of MagicMirror², socket.io namespace /newsfeed. --- Identification | Field | Value | |-------|-------| | PoC file | exploit-ssrf-newsfeed.js | | Endpoint | socket.io namespace /newsfeed, notification CHECKARTICLEURL | | Precondition | reach the mirror's HTTP port (no authentication required) | --- Description The checkArticleUrl() function in newsfeed/nodehelper.js runs fetch(url, { method: "HEAD" }) with zero validation of the URL and returns ARTICLEURLSTATUS { url, canFrame }. This gives the attacker a boolean + timing oracle to map internal hosts and ports: presence, absence, and response time reveal which internal services are alive. It is a "blind-ish" SSRF — the attacker doesn't see the body, but forces the server-side request and observes the effect on the target. The actual proof is observed on the target side (the server-side…
Recommended action: Upgrade to 2.37.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.37.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An unauthenticated Server-Side Request Forgery (SSRF) vulnerability in the /cors endpoint allows any remote attacker to force the MagicMirror² server to perform arbitrary HTTP requests to internal networks, cloud metadata services, and localhost services. The endpoint also expands environment variable placeholders (VARNAME), enabling exfiltration of server-side secrets. Details The /cors endpoint in js/serverfunctions.js (function cors(), lines 37-78) acts as an open HTTP proxy with no authentication and no URL validation. Any user-supplied URL is fetched server-side via fetch() and the full response is returned to the caller. Additionally, the replaceSecretPlaceholder() function (lines 21-25) expands any VARIABLENAME pattern in the URL with the corresponding process.env value before the request is made, allowing an attacker to exfiltrate environment variables (e.g. API keys, tokens, database credentials). Vulnerable code path: Key issues: - No authentication required - No…
Recommended action: Upgrade to 2.36.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.