CVE-2026-71279 in Zigbee2MQTT
Summary
by MITRE • 08/05/2026
Zigbee2MQTT's ExternalJSExtension.getFilePath() (lib/extension/externalJS.ts) joins a `name` parameter received via an MQTT message (topic zigbee2mqtt/bridge/request/extension/save) into the extensions base path using path.join(basePath, name) with no sanitization. Because path.join() resolves `../` sequences, a name such as `../../tmp/evil.js` escapes the intended extensions directory. The extension handler only validates that the name ends in .js/.mjs/.cjs, writes the file, and then dynamically imports it via Node.js import(), achieving remote code execution. Requires the `enable_external_js` config option (off by default, but commonly enabled in legacy installs) and MQTT broker access, which is frequently unauthenticated in real deployments. The identical unsanitized getFilePath() is also used by the extension-removal handler, enabling arbitrary file deletion.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability exists within Zigbee2MQTT's external JavaScript extension handling mechanism where the ExternalJSExtension.getFilePath() function fails to sanitize user-provided input when constructing file paths. The flaw occurs in the lib/extension/externalJS.ts file where a name parameter received via MQTT message is directly concatenated with the extensions base path using Node.js path.join() function without any validation or sanitization of the input. This design pattern creates a classic path traversal vulnerability that allows attackers to escape the intended directory boundaries through relative path sequences.
The technical implementation of this vulnerability leverages the behavior of Node.js path.join() which resolves parent directory references such as ../ and ../../ within file paths. When an attacker crafts a malicious name parameter like '../../tmp/evil.js', the path.join() function processes these sequences and results in a path that traverses outside the designated extensions directory. The system only validates that the filename ends with valid JavaScript extensions .js, .mjs, or .cjs but does not prevent directory traversal attacks. This validation is insufficient because it operates on the final filename portion without considering potential path manipulation within that name.
The operational impact of this vulnerability is severe as it enables remote code execution when combined with the proper configuration settings. The vulnerability requires two conditions to be exploitable: first, the enable_external_js configuration option must be enabled, which is typically off by default but commonly activated in legacy installations; second, attackers must have access to the MQTT broker, which frequently operates without authentication in real-world deployments. Once these prerequisites are met, an attacker can upload malicious JavaScript files that get dynamically imported via Node.js import() function, effectively achieving full code execution on the Zigbee2MQTT host system.
The attack surface extends beyond just file creation to include arbitrary file deletion through the same unsanitized getFilePath() method used in the extension removal handler. This dual functionality means attackers can not only execute code but also delete arbitrary files on the system, potentially compromising the entire Zigbee2MQTT installation or causing denial of service conditions. The vulnerability maps directly to CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (External Control of File Name or Path), both of which address path traversal and file manipulation vulnerabilities. From an ATT&CK perspective, this represents a privilege escalation technique through code injection that could be classified under T1059.007 (Command and Scripting Interpreter: JavaScript) and T1486 (Data Encrypted for Impact).
Mitigation strategies must focus on both configuration management and input validation. System administrators should immediately disable the enable_external_js option unless absolutely required for specific use cases, as this effectively neutralizes the attack vector. Additionally, implementing proper input sanitization that strips or validates directory traversal sequences before path construction would eliminate the vulnerability at its root cause. Network-level controls such as MQTT broker authentication and access control lists should be enforced to prevent unauthorized access to the messaging system. Regular security audits of Zigbee2MQTT configurations and monitoring for unusual file creation patterns can help detect potential exploitation attempts. Organizations should also consider implementing a principle of least privilege model where the Zigbee2MQTT process runs with minimal required permissions, limiting the impact of successful exploitation attempts.