CVE-2026-44090: MQTT Broker Authentication Bypass Flaw

CVE-2026-44090 Overview

CVE-2026-44090 is a missing authentication vulnerability [CWE-306] affecting a device that exposes an MQTT (Message Queuing Telemetry Transport) broker without any authentication controls. The broker relies solely on an external firewall for protection. An unauthenticated remote attacker who reaches the broker network path can interact with it directly and take full control of the affected device. The issue was published by CERT-VDE on July 30, 2026 with a CVSS 4.0 base score of 9.3.

Critical Impact
An unauthenticated remote attacker with network access to the MQTT broker can fully compromise the affected device, impacting confidentiality, integrity, and availability.

Affected Products

Device exposing an unauthenticated MQTT broker (specific product not disclosed in the NVD entry)
See the CERT-VDE Security Advisory for vendor and model details
Deployments where the broker is reachable beyond the perimeter firewall

Discovery Timeline

2026-07-30 - CVE-2026-44090 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-44090

Vulnerability Analysis

The affected device runs an MQTT broker that accepts client connections without requiring credentials. MQTT is a lightweight publish/subscribe protocol commonly used in industrial control, IoT, and building automation environments. The broker typically listens on TCP port 1883, or 8883 when TLS is used.

Because the broker performs no client authentication, any endpoint that can reach the listening port can subscribe to any topic, publish arbitrary messages, and interact with control topics exposed by the firmware. This behavior maps to Missing Authentication for Critical Function [CWE-306].

The vendor documents that the broker is intended to be protected only by an external firewall. A misconfigured firewall rule, a flat network segment, a compromised adjacent host, or exposure through a VPN pivot removes that single control and grants an attacker direct broker access.

Root Cause

The root cause is the absence of an authentication layer on the MQTT broker. MQTT supports username and password authentication in the CONNECT packet and TLS client certificate authentication, but neither is enforced. Authorization on topics is therefore also absent, since there is no verified identity to bind an access control list to.

Attack Vector

The attack is remote and requires no privileges or user interaction. An attacker with network reachability to the broker connects using any standard MQTT client, issues a CONNECT packet with an arbitrary client ID, and is granted a session. From there the attacker can enumerate topics with wildcard subscriptions such as # or $SYS/#, publish commands to control topics, and pivot into device functions that the firmware exposes over MQTT. Full device compromise follows because the broker is trusted by internal device services.

No public proof-of-concept exploit is listed for this CVE. Refer to the CERT-VDE Security Advisory for vendor-specific exploitation context.

Detection Methods for CVE-2026-44090

Indicators of Compromise

Unexpected MQTT CONNECT packets on TCP 1883 or 8883 from client IDs not present in a known asset inventory.
Wildcard subscription attempts to #, +/#, or $SYS/# from external or non-management hosts.
Publishes to device control topics from source addresses outside the documented operational network.
Firewall logs showing inbound sessions to broker ports from untrusted zones.

Detection Strategies

Inspect broker logs for connections that do not present a username or client certificate.
Deploy network intrusion identification signatures for anonymous MQTT CONNECT packets on non-management interfaces.
Baseline expected publisher and subscriber client IDs and alert on deviations.
Correlate MQTT session events with device state changes to spot unauthorized command flows.

Monitoring Recommendations

Forward broker and firewall logs to a centralized SIEM for correlation and long-term retention.
Monitor TCP 1883 and 8883 traffic between network segments that should be isolated.
Alert on new MQTT client IDs, high-rate subscribe activity, and publishes to administrative topics.

How to Mitigate CVE-2026-44090

Immediate Actions Required

Restrict inbound access to the MQTT broker to a narrow allow-list of management hosts on the firewall.
Place affected devices in a dedicated network segment with no direct exposure to user or internet zones.
Audit firewall rules and VPN routes for any path that permits reaching TCP 1883 or 8883 from untrusted networks.
Review broker logs for anomalous connections since deployment.

Patch Information

Refer to the CERT-VDE Security Advisory for vendor-supplied remediation guidance, firmware updates, and configuration hardening steps. No patch metadata is included in the NVD record at time of publication.

Workarounds

Enforce strict network segmentation so the broker is unreachable from any zone other than a trusted management VLAN.
Terminate MQTT traffic through a TLS-enabled reverse proxy that enforces client certificate authentication where the device firmware allows it.
Disable the MQTT broker on devices that do not require it for operation.
Continuously validate firewall rules and monitor for configuration drift that could re-expose the broker.

bash

# Example firewall restriction (iptables) - allow MQTT only from a management host
iptables -A INPUT -p tcp --dport 1883 -s 10.10.5.20 -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP
iptables -A INPUT -p tcp --dport 8883 -s 10.10.5.20 -j ACCEPT
iptables -A INPUT -p tcp --dport 8883 -j DROP