> ## Content Index
> Fetch the complete content index at: https://yokai.hakaisecurity.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# [EN] Behind the Mirror: Investigating Vulnerabilities in MagicMirror² (CVE-2026-63642, CVE-2026-63643)
- URL: https://yokai.hakaisecurity.io/magic-mirror-vulnerabilities-cve-2026-63642-cve-2026-63643-2/
- Published: 2026-10-01T19:57:34.000Z
- Updated: 2026-10-01T19:57:34.000Z
- Author: Gabriel Alves
- Tags: en, #pair-64643, Research Blog

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**](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=yokai.hakaisecurity.io) and [**CVE-2026-63643**](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=yokai.hakaisecurity.io).

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²](https://magicmirror.builders/?utm%5Fsource=chatgpt.com)

![](https://yokai.hakaisecurity.io/content/images/2026/09/image-3.png)

## 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](https://blog.hackingclub.com/?utm%5Fsource=chatgpt.com), which provides practical explanations and exploitation examples.

## Blind Server-Side Request Forgery (SSRF) [CVE-2026-63642](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=blog.hackingclub.com)

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](https://github.com/MagicMirrorOrg/MagicMirror/blob/d203fefed18ebe2827bcda7fc0b35072056ab769/defaultmodules/newsfeed/node%5Fhelper.js?ref=yokai.hakaisecurity.io)

![](https://yokai.hakaisecurity.io/content/images/2026/09/image-4.png)

### Server-Side Request Forgery (SSRF) in Calendar.js [CVE-2026-63643](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=blog.hackingclub.com)

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](https://github.com/MagicMirrorOrg/MagicMirror/blob/900ba886edd306610918551d0dd2e7cc29bda7e4/modules/calendar/node%5Fhelper.js?ref=yokai.hakaisecurity.io)

![](https://yokai.hakaisecurity.io/content/images/2026/09/image-5.png)

## Exploiting the Blind SSRF Vulnerability [CVE-2026-63642](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=blog.hackingclub.com)

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**](https://github.com/hakaioffsec/CVE-2026-63642?ref=yokai.hakaisecurity.io).

![](https://yokai.hakaisecurity.io/content/images/2026/09/image-6.png)

## Exploiting the SSRF Vulnerability [CVE-2026-63643](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=blog.hackingclub.com)

**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**](https://github.com/hakaioffsec/CVE-2026-63642?ref=yokai.hakaisecurity.io).

![](https://yokai.hakaisecurity.io/content/images/2026/09/image-7.png)

## 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**.

- [CVE-2026-63642 — GitHub Security Advisory](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=yokai.hakaisecurity.io)
- [CVE-2026-63643 — GitHub Security Advisory](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=yokai.hakaisecurity.io)

## 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) {
```

![](https://yokai.hakaisecurity.io/content/images/2026/10/image-2.png)

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:

- [js/ip\_access\_control.js — lines 90–107](https://github.com/MagicMirrorOrg/MagicMirror/blob/58c2a5e/js/ip%5Faccess%5Fcontrol.js?utm%5Fsource=chatgpt.com#L90-L107)
- [js/server.js — line 44](https://github.com/MagicMirrorOrg/MagicMirror/blob/58c2a5e/js/server.js?utm%5Fsource=chatgpt.com#L44)

## 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

- [Hakai Security — GitHub Exploit](https://github.com/hakaioffsec/CVE-2026-63642?ref=yokai.hakaisecurity.io)
- [CVE-2026-63642](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=yokai.hakaisecurity.io)
- [CVE-2026-63643](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=yokai.hakaisecurity.io)

### Where to Practice?

[**Hacking Club**](https://app.hackingclub.com/?ref=blog.hackingclub.com) is a cybersecurity training platform focused on developing practical skills for security professionals.

The [**Lumen**](https://app.hackingclub.com/training/challenges/151?ref=blog.hackingclub.com) lab simulates a scenario based on the vulnerabilities [CVE-2026-63643](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-w6x9-28jw-hq7j?ref=blog.hackingclub.com) and [CVE-2026-63642](https://github.com/MagicMirrorOrg/MagicMirror/security/advisories/GHSA-998g-7v5w-cr7g?ref=blog.hackingclub.com) 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.