Zigbee2MQTT CVE-2026-71279

Two conditions must both be met: (1) enable_external_js must be set to true in the Zigbee2MQTT configuration - this option defaults to false, meaning default-configured deployments are not reachable through this code path, but the description explicitly characterizes it as commonly enabled in legacy installations; (2) the attacker must have publish access to the MQTT broker on topic zigbee2mqtt/bridge/request/extension/save - CVSS AV:A/PR:L reflects adjacent-network low-privilege access, but the description states that real-world Zigbee2MQTT MQTT brokers are frequently unauthenticated, effectively making this condition trivially satisfiable in a large fraction of deployments. Exploitation is further limited to the fact that the extension name must terminate in .js, .mjs, or .cjs, which is trivially satisfied by path traversal payloads (e.g., ../../tmp/evil.js). No specific platform, OS version, or Zigbee hardware configuration is required beyond the two conditions above.

The CVSS 8.0 base score (AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) correctly reflects the adjacent-network requirement: the attacker must publish to the MQTT broker, which is nominally a PR:L condition. However, the CVE description explicitly states that MQTT brokers in real Zigbee2MQTT deployments are frequently unauthenticated, effectively collapsing PR:L toward PR:N in a significant portion of real-world targets and elevating practical risk above what the CVSS score alone implies. The second gating condition - enable_external_js must be true - is off by default, which is a meaningful mitigation; however, the description characterizes it as commonly enabled in legacy installations, so this is not a strong deterrent for the installed base. No KEV listing, EPSS score, or confirmed POC was provided in the input data, so active exploitation cannot be confirmed at this time. The dual-impact nature of the flaw (RCE plus arbitrary file deletion via the same vulnerable function) is atypical and increases the overall risk surface beyond what a single-primitive vulnerability would carry. Real-world priority should be elevated for any deployment where enable_external_js is true and the MQTT broker is unauthenticated.

An attacker with network access to an unauthenticated MQTT broker publishes a message to zigbee2mqtt/bridge/request/extension/save with a JSON body where the name field is set to ../../tmp/evil.js and the content field contains arbitrary JavaScript (for example, a reverse shell). Zigbee2MQTT's getFilePath() resolves the traversal, writes the payload to /tmp/evil.js outside the extensions directory, and immediately imports it via Node.js import(), executing the attacker's code as the Zigbee2MQTT process user. No publicly confirmed POC was identified in the provided data, but the exploitation path requires no specialized knowledge beyond crafting an MQTT publish message.