CVE-2026-49186: Critical MQTT Broker Wildcard ACL Bypass

Executive Summary

CVE-2026-49186 is a critical ACL bypass vulnerability in a local MQTT broker implementation. The broker fails to enforce topic-level Access Control Lists (ACLs), allowing any connected client to subscribe using wildcard characters (# or +) to all topics — including those intended to be private or restricted.

CVSS Score: 9.8 (Critical)

An attacker with network access to the MQTT broker can enumerate every device, sensor, and control channel on the network, and inject rogue command messages targeting any topic — including industrial control, building automation, or IoT device management channels.

Vulnerability Overview

Affected Products

Technical Analysis

MQTT Topic ACL Model

The MQTT protocol supports topic-based publish/subscribe messaging. In properly secured deployments, brokers enforce Access Control Lists that restrict which clients can subscribe to or publish on specific topics. These ACLs are the primary authorization boundary in MQTT architectures.

The affected broker implementation fails to enforce these ACLs, allowing any authenticated or unauthenticated client to bypass topic restrictions.

Wildcard Subscription Attack

MQTT supports two wildcard characters:

• # (multi-level wildcard) — matches all topics at any depth
• + (single-level wildcard) — matches exactly one topic level

An attacker subscribing to # receives every message published to any topic across the entire broker, regardless of configured ACLs:

Attack Scenario:
1. Attacker connects to MQTT broker (no credentials required or bypass)
2. Attacker subscribes: SUBSCRIBE #  ← wildcard catch-all
3. Broker accepts subscription without ACL enforcement
4. Attacker receives ALL messages on ALL topics:
   - building/floor2/hvac/temperature
   - industrial/machine01/control/command
   - security/camera/motion/alert
   - /internal/admin/config/update
5. Attacker can also PUBLISH to any topic:
   - PUBLISH industrial/machine01/control/command "STOP_ALL"

Device Enumeration

By monitoring all topics with # subscription, an attacker can:

1. Map the entire device topology — every device publishing to the broker reveals its existence, location, and function
2. Intercept sensitive telemetry — temperature readings, occupancy data, security events, health metrics
3. Capture authentication tokens or credentials transmitted over MQTT topics
4. Identify control channels for later rogue command injection

Rogue Command Injection

Publishing to control topics allows attackers to:

• Send unauthorized commands to industrial controllers
• Trigger actuators (door locks, HVAC systems, industrial machinery)
• Modify device configuration via admin topics
• Disrupt sensor reporting by publishing spoofed values

This is particularly severe in environments using MQTT for operational technology (OT) or building automation where command channels directly affect physical systems.

Impact Assessment

Who Is at Risk

Deployments at risk include:

• Industrial IoT environments using MQTT for machine-to-machine communication
• Building Automation Systems — HVAC, lighting, access control
• Smart home hubs and local home automation brokers
• Energy management systems publishing metering data over MQTT
• Healthcare IoT — patient monitoring, medical device telemetry
• Any deployment where the broker is on a network accessible to untrusted parties

Immediate Remediation

Step 1: Verify ACL Enforcement

# Test if ACLs are enforced (substitute your broker host and port)
mosquitto_sub -h <broker-host> -p 1883 -t '#' -v
 
# If you receive messages you shouldn't have access to, ACLs are not enforced

Step 2: Apply Vendor Patch

Apply the patch or upgrade provided by the broker vendor. Consult the NVD advisory at CVE-2026-49186 for specific patch versions.

Step 3: Enforce ACLs via Configuration

Most MQTT brokers (Mosquitto, EMQX, HiveMQ) support ACL configuration files:

# Example Mosquitto ACL configuration
# /etc/mosquitto/acl.conf
 
# Deny all by default
# Only allow specific users to specific topics
 
user sensor_device_01
topic read sensors/floor1/#
 
user controller_app
topic readwrite industrial/machine01/control/#
 
# Deny wildcard subscriptions from untrusted clients
user anonymous
topic deny #

Step 4: Network Isolation

# Restrict broker to trusted network segments via firewall
# Block port 1883 (MQTT) and 8883 (MQTT/TLS) from untrusted networks
iptables -A INPUT -p tcp --dport 1883 -s <trusted-subnet> -j ACCEPT
iptables -A INPUT -p tcp --dport 1883 -j DROP

Step 5: Enable TLS and Authentication

# Mosquitto TLS configuration
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
require_certificate true
 
# Require password authentication
password_file /etc/mosquitto/passwd
allow_anonymous false

Detection Indicators

Security Best Practices for MQTT Deployments

1. Always enforce ACLs — deny all by default, whitelist required topic access
2. Require authentication — disable anonymous connections (allow_anonymous false)
3. Use TLS — encrypt all MQTT traffic to prevent credential interception
4. Network segmentation — place MQTT brokers on isolated VLANs
5. Monitor subscriptions — alert on wildcard subscription attempts
6. Audit client permissions regularly — remove unused device credentials

References

• NVD — CVE-2026-49186
• MQTT Security Fundamentals — HiveMQ
• OWASP IoT Attack Surface Areas