CVE-2026-63640 in MagicMirror
Summary
by MITRE • 08/18/2026
MagicMirror² is an open source modular smart mirror platform. Prior to 2.37.0, when hideConfigSecrets is enabled, the catch-all socket dispatcher in js/node_helper.js passes every inbound object payload through replaceSecretPlaceholder in js/server_functions.js before invoking socketNotificationReceived. A client connected to a loaded module namespace can submit a SECRET_API_KEY placeholder, causing the server to replace it with the corresponding process environment value. The default weather helper accepts INIT_WEATHER, copies the attacker-controlled instanceId, and returns it in WEATHER_ERROR, providing an echo path for the expanded secret. This reverses the intended one-way redaction boundary and can disclose API tokens, credentials, or service keys stored in SECRET_ variables. This issue is fixed in version 2.37.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in MagicMirror² prior to version 2.37.0 represents a critical failure in the application's input validation and data redaction mechanisms, specifically within its socket communication layer. The platform relies on a configuration option named hideConfigSecrets to prevent sensitive environment variables from being exposed to client-side modules or external users. This security control is designed to act as a one-way filter, ensuring that any placeholder strings designated for secrets are replaced with their actual values only in server-side contexts where they can be safely utilized by backend processes, while remaining masked on the client side. However, the implementation of this safeguard contained a logical flaw within the catch-all socket dispatcher located in js/node_helper.js. This dispatcher was responsible for routing incoming messages to appropriate handlers and included a pre-processing step that invoked replaceSecretPlaceholder from js/server_functions.js on every inbound object payload before passing it to the specific module notification receiver.
The core technical flaw arises because this redaction process is bidirectional rather than strictly server-side only. When hideConfigSecrets is enabled, the system attempts to mask secret placeholders in data sent back to clients. However, an attacker who has established a connection within a loaded module namespace can exploit the replaceSecretPlaceholder function by submitting a payload containing a SECRET_API_KEY placeholder string. Instead of treating this as untrusted input that should be ignored or rejected if it appears in client-bound responses, the server processes this input and replaces the placeholder with the actual value retrieved from the process environment variables. This effectively allows an authenticated module to inject secret values into its own request stream, which are then processed by the server's redaction logic as if they were legitimate configuration data needing masking for return transmission.
This mechanism creates a direct information disclosure channel through the weather helper module, which serves as a convenient echo path for the expanded secrets. The vulnerability is exacerbated by how the INIT_WEATHER command operates within this module. When an attacker sends a request to initialize the weather service with an instanceId parameter that contains the SECRET_API_KEY placeholder, the server processes it and subsequently returns a WEATHER_ERROR response. Crucially, this error message includes the value of the instanceId parameter. Because the server has already performed the secret replacement on the inbound payload before processing the notification, the returned error message contains the actual API key or credential rather than the masked placeholder string. This behavior effectively reverses the intended security boundary, allowing an attacker to retrieve sensitive credentials such as API tokens, database passwords, or service keys that were stored in environment variables prefixed with SECRET_.
From a classification perspective, this vulnerability aligns closely with CWE-209, which describes the generation of error messages containing sensitive information. It also relates to CWE-798, concerning the use of hardcoded credentials, although in this case, the issue is not hardcoding but rather improper handling of dynamically loaded secrets during runtime processing. In terms of the MITRE ATT&CK framework, this exploit leverages techniques associated with T1504, specifically Weak or Compromised Authentication Credentials, as it allows an attacker to harvest valid authentication tokens from a module that may have legitimate access rights. The attack vector is classified under T1213, Data from Information Repositories, where the attacker extracts data directly from system configuration sources via application logic flaws rather than through direct file system access or database queries.
The operational impact of this vulnerability is severe for any deployment of MagicMirror² that utilizes sensitive integrations such as weather services, calendar APIs, or other modules requiring external authentication keys. Since many users store these API keys in environment variables to avoid committing them to version control systems, the assumption was that they were protected from client-side exposure. The flaw undermines this security model entirely, potentially leading to unauthorized access to third-party services, data breaches of user information tied to those accounts, and broader compromise if the same credentials are reused across other platforms. For organizations or individuals relying on MagicMirror² for smart home automation or personal dashboards, this represents a significant risk to both privacy and account security.
The recommended mitigation is straightforward: upgrade immediately to version 2.37.0 of MagicMirror², where this logic error has been corrected. The fix ensures that secret placeholders are not processed through the redaction function when they originate from client-side inputs in contexts where they might be echoed back. Additionally, administrators should audit their module configurations to ensure no sensitive data is passed as parameters in ways that could trigger similar echo-based leaks if other modules exhibit comparable behavior. It is also advisable to rotate any API keys or credentials that may have been exposed during the period when this vulnerability was present and active in production environments. Implementing strict input validation policies that distinguish between server-side configuration needs and client-side data requirements will further harden future implementations against similar logical flaws.