CVE-2026-63643 in MagicMirrorinfo

Summary

by MITRE • 08/18/2026

MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, the ADD_CALENDAR handler in defaultmodules/calendar/node_helper.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, CALENDAR_EVENTS 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.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 08/18/2026

The vulnerability identified within MagicMirror² prior to version 2.37.0 represents a critical server-side request forgery flaw rooted in the improper validation of user-supplied input within the calendar module's backend logic. The core issue resides in the ADD_CALENDAR handler located in defaultmodules/calendar/node_helper.js, which is exposed through an unauthenticated Socket.IO namespace designated as /calendar. This architectural design choice allows any client with network access to the MagicMirror² instance to interact directly with this endpoint without requiring prior authentication or authorization checks. The handler accepts three primary parameters from the attacker: a target URL, optional authentication credentials for the remote service, and a boolean flag controlling self-signed certificate verification. By accepting these inputs directly from an untrusted source, the system fails to enforce strict allow-listing of permitted domains or protocols, thereby creating a direct pathway for malicious actors to manipulate outbound network requests initiated by the server itself.

From a technical perspective, the vulnerability manifests when the ADD_CALENDAR handler passes the attacker-controlled URL and configuration settings directly to the CalendarFetcher component. This component is responsible for retrieving calendar data in iCal format from remote servers. Crucially, there are no security checks implemented before making these HTTP requests. The system does not validate whether the target domain belongs to an internal network range or a trusted external entity. Furthermore, the ability to disable TLS certificate verification via the selfSignedCert setting significantly lowers the barrier for exploitation against services using invalid or self-signed certificates, which is common in many internal corporate environments and development setups. This combination of unvalidated URLs and optional SSL bypass creates a potent vector for Server-Side Request Forgery, allowing an attacker to force the MagicMirror² server to act as a proxy for arbitrary requests.

The operational impact of this vulnerability extends beyond simple network reconnaissance. When the remote service returns a valid iCal response, the handler parses the data and subsequently broadcasts it back to all connected clients via the CALENDAR_EVENTS event. This mechanism effectively transforms the blind SSRF into a reflective or exfiltrative attack vector. An attacker can craft requests targeting internal services such as database administration interfaces, cloud metadata endpoints, or internal API gateways that return structured calendar-like data. By observing the returned events, an adversary can extract sensitive information including user schedules, organizational structures, and potentially authentication tokens embedded within the payload. Even if the target service does not return iCal-formatted data, the vulnerability still provides a blind SSRF primitive with timing side-channels. Attackers can utilize time-based techniques to infer the existence of internal resources or determine whether specific requests resulted in success or failure based on response latency, facilitating further exploitation and network mapping within protected environments.

This flaw aligns closely with CWE-918, which defines Server-Side Request Forgery (SSRF), specifically highlighting the lack of validation for user-supplied URLs that lead to unauthorized access to internal resources. Additionally, the ability to disable TLS verification corresponds to CWE-295, Improper Certificate Validation, while the exposure through an unauthenticated Socket.IO namespace relates to CWE-306, Missing Authentication for Critical Function. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1187, which covers Forced Client-Side Proxy Usage and SSRF. The exploitation path involves initial access via the network interface followed by lateral movement or data exfiltration through internal service interaction, making it a significant risk in environments where MagicMirror² is deployed behind firewalls that trust local traffic but do not inspect outbound requests from IoT devices.

To mitigate this vulnerability, organizations must immediately upgrade to version 2.37.0 of MagicMirror², which implements the necessary fixes for input validation and request handling. In scenarios where upgrading is not immediately feasible, defensive measures should include restricting network access to the Socket.IO endpoints through firewall rules or reverse proxy configurations that limit exposure to trusted IP ranges only. Additionally, implementing strict egress filtering on the host running MagicMirror² can prevent outbound connections to unauthorized internal subnets. It is also critical to ensure that TLS certificate validation cannot be disabled by untrusted users and to implement allow-listing of permitted domains for calendar sources within the application configuration rather than relying solely on runtime input parameters. Regular security audits of IoT device configurations are essential to identify similar misconfigurations in other modules or services exposed via WebSocket interfaces.

Responsible

GitHub M

Reservation

07/17/2026

Disclosure

08/18/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Want to know what is going to be exploited?

We predict KEV entries!