CVE-2026-63643

Executive Summary

CVE-2026-63643 is a critical Server-Side Request Forgery (SSRF) vulnerability in MagicMirror², an open-source modular smart mirror platform, affecting all versions prior to 2.37.0. The flaw resides in the ADD_CALENDAR handler within defaultmodules/calendar/node_helper.js, which is exposed through the unauthenticated Socket.IO namespace /calendar. An unauthenticated remote attacker can supply arbitrary URLs, authentication data, and a selfSignedCert setting, causing the server to make outbound requests to internal services without SSRF validation — and optionally disabling TLS certificate verification in the process. Successful exploitation enables exfiltration of parsed iCal event data from internal services and, even in failed parsing cases, provides a blind request and timing oracle for network reconnaissance. No CVSS score, EPSS score, or public exploit code is available at the time of this report; the patch is available in version 2.37.0.

Technical Analysis

The vulnerability exists in the MagicMirror² calendar module's backend helper, specifically in the ADD_CALENDAR handler located at defaultmodules/calendar/node_helper.js. This handler is accessible through the Socket.IO namespace /calendar, which requires no authentication. The handler accepts three attacker-controlled parameters: a URL, authentication data (credentials), and a selfSignedCert boolean setting.

The core issue is that these parameters are passed directly to CalendarFetcher without any SSRF validation on the destination host or IP range. This allows the server-side module to make requests to arbitrary destinations, including loopback addresses, internal RFC 1918 networks, cloud metadata endpoints (e.g., 169.254.169.254), or any other internal service reachable from the smart mirror host. The selfSignedCert parameter effectively allows the attacker to toggle the TLS verification behavior of the outbound connection; when set to true, the fetcher will accept self-signed certificates, thereby lowering the security barrier for connections to internal services that use such certificates.

The attack mechanism produces two distinct observable outcomes:

1. Successful iCal response: If the target URL returns a valid iCalendar (iCal) payload, the server parses the data and emits a CALENDAR_EVENTS response back to the attacker over the same unauthenticated Socket.IO channel. This enables direct exfiltration of internal service response data (e.g., calendar contents from internal Exchange servers, internal scheduling systems, or proprietary time-management services).

2. Non-iCal response: If the target does not return valid iCal data, the handler still performs the request. While no parsed data is returned, the attacker gains a blind request primitive and a timing oracle. By observing response times and connection behaviors, the attacker can map the internal network, identify open ports, and infer service types based on response latency and error patterns.

The lack of authentication on the /calendar Socket.IO namespace is the critical enabler. Since no session or API key is required, any client capable of establishing a Socket.IO connection can invoke the vulnerable handler. The vulnerability is classified under CWE-441 (Unintended Proxy or Intermediary), which accurately reflects that the server is being abused as an unintended proxy/intermediary to access internal resources.

Exploitation Scenarios

Step 1: Reconnaissance / Target Identification
An attacker first identifies a MagicMirror² instance exposed to the internet. MagicMirror² typically runs on port 8080 by default and exposes a web-based interface. The attacker can fingerprint the application via its default UI title ("MagicMirror") or by probing the Socket.IO endpoint. Shodan and other internet scanning services can enumerate such devices. Given that MagicMirror² is often deployed on Raspberry Pi devices on home networks or in office environments, the reachable device may be within the internal network boundary, making it a valuable pivot point.

Step 2: Vulnerability Triggering
The attacker establishes a Socket.IO connection to the /calendar namespace. No authentication handshake is required. The attacker then emits an ADD_CALENDAR event with a payload containing: (a) a URL pointing to an internal resource (e.g., http://127.0.0.1:8081/calendar.ics, http://192.168.1.50/private-calendar.ics, or http://169.254.169.254/latest/meta-data/ for cloud environments), (b) optional authentication data if the internal service requires credentials, and (c) the selfSignedCert flag set to true to bypass TLS certificate validation for internal HTTPS endpoints.

Step 3: Payload / Execution Method
The payload is delivered purely via the Socket.IO event structure; no code injection is required. The vulnerable handler passes the attacker-controlled URL and options to CalendarFetcher, which executes the server-side request. If the target responds with valid iCal data, the response is parsed and returned via CALENDAR_EVENTS to the attacker's connected socket.

Step 4: Post-Exploitation Impact
The attacker can enumerate internal services that respond with iCal data, exfiltrating sensitive scheduling and calendar information. For non-iCal endpoints, the attacker gains a blind SSRF primitive usable for port scanning, internal topology mapping, and timing-based side-channel analysis of internal services. In cloud environments, the attacker could target the instance metadata service (169.254.169.254) to retrieve IAM credentials if the service returns iCal-like content or if the blind oracle yields useful timing/error data. No public PoC is available; this attack chain is inferred from the vulnerability class and NVD description details.

Impact Assessment

Business Impact: High for organizations operating MagicMirror² instances on internal networks. The vulnerability provides an unauthenticated entry point for accessing internal HTTP/HTTPS services that were not intended to be externally reachable. The confidentiality impact is high when iCal data is exfiltrated, as calendar data often includes sensitive operational information — meeting schedules, personnel availability, locations, and project timelines. The blind request and timing primitive further increases the risk profile by enabling internal network reconnaissance.

Affected Systems: All MagicMirror² deployments running versions prior to 2.37.0 with the calendar module (defaultmodules/calendar) enabled and network exposure. By default, the calendar module is part of the standard module set, so most installations are affected unless specifically disabled or firewalled.

Blast Radius: The attack surface extends beyond the MagicMirror² device itself to any service reachable from it. Since smart mirrors are frequently deployed on the same network as other IoT devices, printers, network storage, or even guest WiFi segments, the blast radius includes the entire internal network. The ability to disable TLS verification (selfSignedCert) further broadens the reach to internal HTTPS services using non-standard certificates.

CVSS Note: No CVSS vector or score is available from NVD (N/A). Given the unauthenticated network attack vector, high confidentiality impact (iCal data exfiltration), and high integrity/availability impacts possible through blind request behavior, a typical SSRF CVSSv3.1 score would land in the range of 7.0–9.3; however, we do not substitute a computed score for the official NVD value.

Detection Guidance

Detection of this vulnerability requires monitoring both network-level traffic to the MagicMirror² host and application-level logs within the Socket.IO communication layer.

Sigma Rule

title: MagicMirror2 ADD_CALENDAR SSRF - Suspicious URL Patterns
status: experimental
description: Detects attempts to exploit CVE-2026-63643 by observing ADD_CALENDAR events with internal or non-standard URL targets in MagicMirror2 Socket.IO traffic.
logsource:
  category: webserver
  product: magicmirror
detection:
  selection_socket:
    event_name: 'ADD_CALENDAR'
  selection_urls:
    url|contains:
      - '127.0.0.1'
      - 'localhost'
      - '169.254.169.254'
      - '10.0.0.0/8'
      - '192.168.'
      - '172.16.'
    url|endswith:
      - '.internal'
      - '.local'
  selection_tls:
    selfSignedCert: 'true'
  condition: selection_socket and (selection_urls or selection_tls)
level: high

YARA Rule

rule MagicMirror2_SSRF_Calendar {
    meta:
        author = "Valters IT Security"
        description = "Detects payloads targeting the ADD_CALENDAR handler SSRF in MagicMirror2 node_helper.js"
        cve = "CVE-2026-63643"
        date = "2026-04-01"
    strings:
        $sock_event = "ADD_CALENDAR" ascii wide
        $ssl_setting = "selfSignedCert" ascii wide nocase
        $auth_field = "auth" ascii wide nocase
        $url_field = "url" ascii wide nocase
        $internal_ip1 = "127.0.0.1" ascii
        $internal_ip2 = "169.254.169.254" ascii
        $internal_range = "192.168." ascii
        $internal_range2 = "10." ascii
        $internal_range3 = "172.16." ascii
    condition:
        all of ($sock_event, $ssl_setting) and
        (any of ($internal_ip1, $internal_ip2, $internal_range, $internal_range2, $internal_range3) or
         ($url_field and $auth_field))
}

Suricata IDS Rule

alert tcp any any -> $MAGICMIRROR_SERVERS 8080 (msg:"ET EXPLOIT MagicMirror2 ADD_CALENDAR SSRF Attempt (CVE-2026-63643)"; flow:established,to_server; content:"ADD_CALENDAR"; nocase; http.uri; content:"selfSignedCert"; nocase; http.uri; content:"url"; nocase; http.uri; content:"127.0.0.1"; http.uri; classtype:attempted-recon; sid:20260401; rev:1; metadata:created_at 2026-04-01, cve CVE-2026-63643;)

Note: This rule assumes Socket.IO traffic traverses HTTP with the event data visible in the URI or request body. If traffic is WebSocket-based, use the websocket keyword in Suricata 7+ or deploy at layer-7 proxy.

Elastic Detection

sequence by process.entity_id with maxspan=10s
  [ network where process.name == "node" and destination.ip != "0.0.0.0" and destination.port != 8080 and
    (destination.ip startsWith "127." or destination.ip startsWith "10." or destination.ip startsWith "192.168." or destination.ip == "169.254.169.254") ]

Note: This EQL rule assumes network egress monitoring at the host level. The rule detects the outbound server-side request made by the Node.js process when it fetches the attacker-supplied URL.

Splunk SPL Query

index=network sourcetype=stream:http dest_host=*magicmirror*
| search "ADD_CALENDAR"
| rex field=uri "(?<target_url>https?://[^\"]+)"
| rex field=uri "selfSignedCert(?<tls_bypass>=[^&]*)"
| where match(target_url, "(127\.0\.0\.1|localhost|169\.254\.169\.254|10\..*|192\.168\..*|172\.1[6-9]\..*|172\.2[0-9]\..*|172\.3[0-1]\..*)")
| stats count by src_ip, dest_ip, target_url, tls_bypass
| where count > 1

Wazuh OSSEC Rule

<group name="magicmirror,">
  <rule id="100620" level="12">
    <decoded_as>json</decoded_as>
    <field name="module">calendar</field>
    <field name="event">ADD_CALENDAR</field>
    <match>127.0.0.1|localhost|169.254.169.254|192.168.|10\.</match>
    <description>MagicMirror2 SSRF attempt via ADD_CALENDAR targeting internal addresses (CVE-2026-63643)</description>
    <group>ssrf,attack,reconnaissance,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED (no patch evidence from tracked sources). The NVD description states the issue is fixed in version 2.37.0; however, no patch commit, changelog entry, or advisory confirmation was found in tracked patch sources at the time of this report. Treat the fix as pending verification.

Immediate Mitigations (within 24–48 hours):

1. Restrict network exposure: Block inbound access to the MagicMirror² web interface (default port 8080) from untrusted networks. Implement firewall rules or reverse-proxy ACLs to allow only trusted LAN sources.
2. Disable the calendar module: If the calendar functionality is not essential, remove or rename the defaultmodules/calendar directory or disable it in the config.js file.
3. Network segmentation: If the MagicMirror² device cannot be isolated, segment it behind a strict egress firewall that blocks outbound requests to RFC 1918 ranges and loopback addresses.
4. Monitor egress traffic: Implement alerting on outbound requests from the MagicMirror² host to unusual destinations, particularly internal IPs.

Patch/Upgrade Steps (within 30 days):

1. Upgrade MagicMirror² to version 2.37.0 or later once the vendor confirms the fix. Verify the upgrade via the project's official changelog.
2. After upgrading, re-test the /calendar Socket.IO endpoint to confirm ADD_CALENDAR no longer accepts arbitrary URLs or that SSRF validation is enforced.
3. Subscribe to the MagicMirror² GitHub releases feed for patch confirmation.

Long-Term Hardening:

1. Implement authentication for Socket.IO namespaces — apply a reverse-proxy authentication layer (e.g., HTTP Basic Auth, OAuth) in front of the MagicMirror² web server.
2. Run MagicMirror² in a sandboxed container or VM with network policy limiting outbound flows.
3. Implement SSRF-protection patterns in all future code: validate URLs against allowlists/denylists, resolve DNS and block private IP ranges, and enforce TLS verification by default.
4. For firmware/IoT-style deployments, establish a vendor-supported update channel and automated patch management.

References

1. NVD Entry: CVE-2026-63643 — https://nvd.nist.gov/vuln/detail/CVE-2026-63643 (accessed 2026-04-01)
2. MagicMirror² Official Repository: https://github.com/MagicMirrorOrg/MagicMirror — monitor for 2.37.0 release notes and patch commit.
3. CWE-441 Reference: https://cwe.mitre.org/data/definitions/441.html — Unintended Proxy or Intermediary.
4. Socket.IO Security Best Practices: https://socket.io/docs/v4/server-api/ — guidance on namespace authentication (general reference).
5. CISA KEV: Not listed in CISA Known Exploited Vulnerabilities catalog as of 2026-04-01. No evidence of exploits in the wild or threat actor campaigns has been publicly documented for this CVE.