- A researcher says a Mosquitto bug, filed publicly in August 2026 as a session-drop, allows remote code execution before login inside the Home Assistant add-on container.
- The researcher's advisory lists Mosquitto 2.1.x with its WebSocket listener exposed. It says the add-on is fixed in 7.1.2 and Eclipse expects upstream releases before November 18.
- Find where Mosquitto runs, including inside appliances. Firewall or disable the WebSocket listener if it is not needed, and update the Home Assistant add-on.
A safety label is only a claim
In August 2026, a bug in the Eclipse Mosquitto message broker was reported publicly as a session-drop problem. The reporter ruled out a memory-safety issue and used the public tracker, not the security process. A researcher now says the same bug allows remote code execution before any login, inside the Home Assistant Mosquitto add-on container on a Home Assistant Green. That is the researcher's claim. The full exploit walk-through is not part of the material WebPulse reviewed, so we cannot verify it.
The researcher says full-device compromise is a separate step. It belongs to a second post in the series, which has not been published and which WebPulse has not reviewed.
The lesson is about how risk gets labelled. A bug is as dangerous as its worst use, not as its first description.
What the public report said
Mosquitto is an open-source broker. It relays messages between devices and is widely used in smart-home and industrial setups. It can carry those messages over WebSockets, a standard way to keep a web connection open.
The August report is GitHub issue #3704. Its author found that one empty WebSocket frame breaks a working session. After the frame, the connection stops answering and is torn down. The author called this deterministic and reproducible with a short Python script.
The author wrote that this was "not a memory-safety issue in a normal glibc build". For that reason the report went to the public tracker, not the security process. The author added that any WebSocket peer sending an empty binary frame loses its session. A fix was proposed in a commit dated August 24, 2026. The issue will close once that commit is merged into the master branch.
How the flaw works
An empty WebSocket frame is legal under RFC 6455. It simply carries no data. The Mosquitto code is meant to treat it as nothing and wait for more.
The issue traces what happens instead. In the file lib/net_ws.c, a function called net__read_ws() reports how many message bytes it produced. For an empty frame it reads a one-byte length field and a four-byte masking key. It then returns a count of 4, although it wrote no data.
The calling code trusts that count. It reads four old bytes left in its buffer from the previous frame and parses them as a new MQTT packet header. That explains the session failures.
The issue's author says those stale bytes sit inside a fixed buffer. The researcher at born0monday.me disagrees. The researcher says a fuzzing harness, built with AI help, found an out-of-bounds write on the heap that is reachable before login. The material WebPulse reviewed does not include the researcher's explanation of how a stale-byte parse becomes a write.
Who is affected, and what to do
The researcher's advisory lists two groups. The first is Mosquitto 2.1.x, from 2.1.0 onward, built with the built-in WebSocket listener and reachable over the network. There is no fixed upstream release yet. An update dated November 5 says Eclipse is working on fixed releases, expected before November 18.
Until then, the advisory says to restrict or firewall the WebSocket port. It also says to disable the listener if MQTT over WebSocket is not needed. The issue's author tested the built-in WebSocket code. The author says the other WebSocket backend, which uses the libwebsockets library, takes a different code path and does not have this flaw.
The second group is the Home Assistant Mosquitto add-on, versions up to 7.1.1 in the default configuration. Version 7.1.2, released October 19, 2026, fixes it. The researcher says the add-on exposes tcp/1884 for WebSocket traffic. The researcher found the flaw while researching the Home Assistant Green hub for Pwn2Own Ireland 2026.
What this shows about triage
The researcher also checked whether a machine could find the bug by reading code alone. The researcher had Opus 4.8 and GPT-5.6 Sol review the relevant source file for flaws. By the researcher's account, both flagged the bug among a long list of small issues. Both still concluded that memory safety was not at stake. That matches the GitHub issue. It is one case, not a trend. It still shows that agreement between the issue's author and two AI models is not proof.
The researcher also says the bug sat in a gap in the project's OSS-Fuzz coverage. OSS-Fuzz is a Google service that fuzzes open-source software continuously. In that account, fuzzing found what reading the code did not.
The timeline adds a second point. A fix was proposed in August. The add-on shipped it in October. The upstream release is still pending in November. Each gap is time in which the bug is public and the fix is not in everyone's hands.
Questions to put to your team
Ask your team where Mosquitto runs. It can sit inside appliances, gateways and add-ons, as it does in Home Assistant. Ask whether the WebSocket listener is on and reachable from untrusted networks. If it is not needed, turn it off or firewall it.
If you use Home Assistant, ask which Mosquitto add-on version is installed, and update to 7.1.2 or later. Ask vendors how they handle bugs first labelled as reliability problems. Do they reclassify when a researcher shows more? Watch for the upstream release expected before November 18.
A bug report tells you what its author tested. It does not set a ceiling on what an attacker can try.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Eclipse Mosquitto project (Eclipse Foundation), via GitHub issue #3704.
