CVE-2026-30867
Received Received - Intake
Persistent DoS via Malformed Packet in CocoaMQTT Client

Publication date: 2026-04-02

Last updated on: 2026-04-07

Assigner: GitHub, Inc.

Description
CocoaMQTT is a MQTT 5.0 client library for iOS and macOS written in Swift. Prior to version 2.2.2, a vulnerability exists in the packet parsing logic of CocoaMQTT that allows an attacker (or a compromised/malicious MQTT broker) to remotely crash the host iOS/macOS/tvOS application. If an attacker publishes the 4-byte malformed payload to a shared topic with the RETAIN flag set to true, the MQTT broker will persist the payload. Any time a vulnerable client connects and subscribes to that topic, the broker will automatically push the malformed packet. The app will instantly crash in the background before the user can even interact with it. This effectively "bricks" the mobile application (a persistent DoS) until the retained message is manually wiped from the broker database. This issue has been patched in version 2.2.2.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-02
Last Modified
2026-04-07
Generated
2026-05-06
AI Q&A
2026-04-02
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
emqx cocoamqtt to 2.2.2 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-617 The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The provided information does not include any details about how CVE-2026-30867 affects compliance with common standards and regulations such as GDPR or HIPAA.


Can you explain this vulnerability to me?

CVE-2026-30867 is a vulnerability in the CocoaMQTT library, a MQTT 5.0 client for iOS and macOS. The issue arises from improper handling of malformed MQTT PUBLISH packets with zero-length topics during packet parsing. Specifically, when a malformed 4-byte payload with a zero-length topic is published to a shared topic with the RETAIN flag set, the MQTT broker stores this malformed message. Any vulnerable client subscribing to that topic receives the malformed packet and crashes immediately due to a runtime error caused by invalid bounds checking in Swift.

This crash happens before the user can interact with the app, effectively 'bricking' the application and causing a persistent denial of service until the retained malformed message is manually removed from the broker. The root cause is a 'Range requires lowerBound <= upperBound' runtime trap triggered by slicing a byte array with an invalid range.

The vulnerability was fixed in CocoaMQTT version 2.2.2 by adding strict bounds checking, rejecting zero-length topics in MQTT 3.1.1, allowing zero-length topics only with a topic alias in MQTT 5.0, and improving protocol error handling by disconnecting the socket immediately upon detecting malformed frames.


How can this vulnerability impact me? :

This vulnerability can cause a remote denial of service (DoS) on applications using the CocoaMQTT library. An attacker or a compromised MQTT broker can publish a specially crafted malformed message with a zero-length topic and the RETAIN flag set. This message is stored by the broker and delivered to any vulnerable client subscribing to the topic.

When the vulnerable client receives this malformed message, it crashes immediately in the background before the user can interact with it, effectively 'bricking' the app. This persistent crash continues until the malformed retained message is manually removed from the broker, causing significant disruption to the application's availability.

  • Remote exploitation over the network (no physical access needed).
  • Low attack complexity and low privileges required.
  • High availability impact due to application crashes causing denial of service.

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring MQTT traffic for malformed PUBLISH packets, specifically those with zero-length topics and a retained flag set. Such packets are 4 bytes long and cause the CocoaMQTT client to crash upon receipt.

To detect this on your network or system, you can use MQTT client tools or network packet analyzers (e.g., Wireshark) to filter MQTT PUBLISH messages with retained flag set and inspect the topic length field.

Example commands or approaches include:

  • Using Wireshark, apply a display filter for MQTT PUBLISH messages with the RETAIN flag set: `mqtt.msgtype == 3 && mqtt.retain == 1`.
  • Inspect the topic length field in the Variable Header of these packets; a zero-length topic (topic length = 0) indicates a malformed packet that can trigger the vulnerability.
  • Use MQTT client scripts or tools to subscribe to retained topics and log or alert on receipt of messages with empty or malformed topics.

Since the vulnerability causes the client application to crash immediately upon receiving such malformed retained messages, monitoring client crash logs or reports can also help detect exploitation attempts.


What immediate steps should I take to mitigate this vulnerability?

The immediate and most effective mitigation is to upgrade the CocoaMQTT library to version 2.2.2 or later, where the vulnerability has been fixed by adding strict bounds checking and improved protocol error handling.

If upgrading immediately is not possible, the following steps can help mitigate the risk:

  • Manually remove any retained MQTT messages with zero-length topics from the MQTT broker database to prevent vulnerable clients from receiving them and crashing.
  • Configure MQTT brokers to reject or clean malformed retained messages that have zero-length topics.
  • Monitor and restrict MQTT broker access to trusted clients and brokers to reduce the risk of malicious retained messages being published.

Additionally, ensure that client applications handle protocol errors safely by disconnecting on malformed packets, as implemented in the patched version.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart