During an analysis of the source code of MagicMirror², an open-source platform used to turn a semi-transparent mirror into a smart display, the Yokai Research Team from Hakai Security identified two recent Server-Side Request Forgery (SSRF) vulnerabilities: CVE-2026-63642 and CVE-2026-63643.
The vulnerabilities affect different MagicMirror² modules and allow externally controlled requests to be processed by the server. CVE-2026-63642 affects the newsfeed module and allows server-side HTTP requests through its URL-checking functionality. CVE-2026-63643 affects the calendar module, allowing attacker-controlled URLs to be used in requests made by the server.
What is MagicMirror²?
MagicMirror² is an open-source application that turns a monitor or TV into an interactive smart mirror. It can display useful information such as weather forecasts, news headlines, calendars, and much more, all while you look at yourself in the mirror.
It is commonly used to build high-tech mirrors for bathrooms, closets, and even commercial and retail environments.
Reference: MagicMirror²

What is SSRF?
SSRF (Server-Side Request Forgery) is a vulnerability that occurs when an application allows a user to control a request made by the server itself.
Normally, a server only accesses the resources required for the application to operate. However, when an SSRF vulnerability exists, an attacker can cause the server to make requests to other destinations.
This can allow access to internal services, administrative APIs, or resources that are not directly exposed to the Internet.
In short, the attacker uses the vulnerable server as an intermediary to reach resources that would otherwise be inaccessible to them.
For a more detailed explanation of SSRF and its impact, we recommend reading the Hacking Club article about SSRF, which provides practical explanations and exploitation examples.
Blind Server-Side Request Forgery (SSRF) CVE-2026-63642
The checkArticleUrl() function, located in newsfeed/node_helper.js, performs an HTTP request using the HEAD method against the supplied URL without applying adequate validation to the destination.
This behavior allows an externally controlled URL to be processed by the MagicMirror² server. Because the request uses the HEAD method, the response body is not returned.
Although the content of the accessed resource is not directly exposed, this behavior can be used to construct a Blind SSRF scenario. Differences in responses and request processing times can provide information about the existence or availability of services accessible from the server.
Code analyzed: defaultmodules/newsfeed/node_helper.js

Server-Side Request Forgery (SSRF) in Calendar.js CVE-2026-63643
The ADD_CALENDAR handler, located in calendar/node_helper.js, forwards the received payload directly to the component responsible for fetching calendar data without applying adequate validation or restrictions to the destination URL.
This behavior creates an additional SSRF attack surface because the server can make requests to externally defined destinations.
An important point is the difference between this functionality and the project's /cors endpoint. The /cors component already includes protection mechanisms designed to restrict this type of request. The absence of equivalent controls in the ADD_CALENDAR handler demonstrates an inconsistency in the implementation of different features that perform HTTP requests.
Code analyzed: modules/calendar/node_helper.js

Exploiting the Blind SSRF Vulnerability CVE-2026-63642
To demonstrate the exploitation of CVE-2026-63642, a Proof of Concept (PoC) was developed using Socket.IO to connect to the /newsfeed namespace of MagicMirror² and send the CHECK_ARTICLE_URL event.
The event receives a user-controlled URL and is processed by the checkArticleUrl() function located in newsfeed/node_helper.js. The function performs an HTTP request using the HEAD method against the supplied URL without adequately validating the destination.
As a result, the MagicMirror² server performs the request on behalf of the attacker, demonstrating a Blind Server-Side Request Forgery (Blind SSRF).
The exploit is publicly available in the Hakai Security GitHub repository.

Exploiting the SSRF Vulnerability CVE-2026-63643
CVE-2026-63643 affects the Calendar module of MagicMirror² and can be exploited through communication with the /calendar namespace using Socket.IO.
To reproduce the vulnerability, the PoC establishes a connection to the server and sends the ADD_CALENDAR event containing the URL to be processed by the application.
After receiving the event, MagicMirror² uses the supplied URL to perform a request from the server itself. Because the destination is not adequately validated, the request can be directed toward resources that should not be externally accessible.
In addition to demonstrating that the request is performed by the server, the PoC allows the content returned by the destination to be observed. This distinguishes this vulnerability from CVE-2026-63642, which is classified as Blind SSRF, because the response obtained by the server can be retrieved through the Calendar module's event flow.
The exploit is publicly available in the Hakai Security GitHub repository.

Responsible Disclosure
Both vulnerabilities were identified by the Yokai Research Team at Hakai Security during an analysis of the MagicMirror² source code and were subsequently reported directly to the project through GitHub Security Advisories.
Following the analysis and communication period with the maintainer, the issues were acknowledged and officially published through the project's security advisories.
The vulnerabilities received the identifiers CVE-2026-63642 and CVE-2026-63643, corresponding respectively to the Blind SSRF vulnerability in the newsfeed module and the SSRF vulnerability in the calendar module.
Both vulnerabilities affect version 2.36.0 and were fixed in version 2.37.0 or later.
Fixes Implemented
The vulnerabilities CVE-2026-63642 and CVE-2026-63643 were fixed in commit 58c2a5e, which was subsequently included in version 2.37.0 of MagicMirror².
The fix introduced a new access-control mechanism for Socket.IO connections, making them respect the ipWhitelist configuration used by the server.
In js/ip_access_control.js, the socketIpAccessControl() function was implemented to validate the IP address during the Socket.IO connection process:
function socketIpAccessControl (whitelist) {
The function is then used in js/server.js through the allowRequest option:
allowRequest: socketIpAccessControl(config.ipWhitelist),With this change, connections to the Socket.IO namespaces used by the newsfeed and calendar modules are subject to the same IP-based access control mechanism.
This change prevents unauthorized clients from directly accessing the namespaces used to exploit the functionality associated with CVE-2026-63642 and CVE-2026-63643.
The modified files can be reviewed below:
Mitigation
The primary mitigation for CVE-2026-63642 and CVE-2026-63643 is to update MagicMirror² to version 2.37.0 or later, which includes the fixes implemented by the project.
For installations that cannot be updated immediately, access to the MagicMirror² interface should be restricted to trusted users and networks, avoiding direct exposure to the Internet whenever possible. The ipWhitelist configuration should also be reviewed, and access from the server to sensitive internal services should be limited.
Because these vulnerabilities exploit functionality exposed through Socket.IO, restricting access to the server reduces the possibility of unauthorized users reaching the namespaces used by the newsfeed and calendar modules.
References
Where to Practice?
Hacking Club is a cybersecurity training platform focused on developing practical skills for security professionals.
The Lumen lab simulates a scenario based on the vulnerabilities CVE-2026-63643 and CVE-2026-63642 discussed in this article. It provides an environment where readers can apply the concepts covered throughout the article and reinforce their understanding through hands-on practice.