CVE-2026-30867: CocoaMQTT Denial of Service Vulnerability

CVE-2026-30867 Overview

CVE-2026-30867 is a denial of service vulnerability in CocoaMQTT, a popular MQTT 5.0 client library for iOS, macOS, and tvOS applications written in Swift. The vulnerability exists in the packet parsing logic of CocoaMQTT that allows an attacker or a compromised MQTT broker to remotely crash host applications. Prior to version 2.2.2, the library fails to properly validate MQTT packet data, enabling a persistent denial of service attack that can effectively "brick" mobile applications.

Critical Impact

Attackers can publish a 4-byte malformed payload with the RETAIN flag to persistently crash any vulnerable iOS/macOS/tvOS application that subscribes to the affected topic, rendering the application unusable until the retained message is manually removed from the broker database.

Affected Products

• CocoaMQTT versions prior to 2.2.2
• iOS applications using vulnerable CocoaMQTT library
• macOS applications using vulnerable CocoaMQTT library
• tvOS applications using vulnerable CocoaMQTT library

Discovery Timeline

• 2026-04-02 - CVE CVE-2026-30867 published to NVD
• 2026-04-02 - Last updated in NVD database

Technical Details for CVE-2026-30867

Vulnerability Analysis

This vulnerability is classified under CWE-617 (Reachable Assertion), indicating that the CocoaMQTT library contains an assertion or error-handling mechanism that can be triggered through malformed input, causing the application to crash. The flaw resides in how the library processes incoming MQTT packets from the broker.

The attack is particularly severe due to the persistent nature of MQTT retained messages. When an attacker publishes a malformed 4-byte payload to a shared topic with the RETAIN flag set to true, the MQTT broker stores this payload. Subsequently, any time a vulnerable client connects and subscribes to that topic, the broker automatically delivers the malformed packet to the client. The application crashes in the background before the user can interact with it, and this cycle repeats every time the app attempts to reconnect.

Root Cause

The root cause of this vulnerability lies in improper input validation within the packet parsing logic of the CocoaMQTT library. The library does not adequately validate the structure and content of incoming MQTT packets before processing them. When a malformed 4-byte payload is received, the parsing routine encounters unexpected data that triggers an assertion failure or unhandled exception, causing the application to terminate abruptly.

This represents a classic case of insufficient boundary checking and input sanitization in network protocol parsing code, where the library assumes all incoming data from the broker is well-formed and conforms to the MQTT specification.

Attack Vector

The attack vector for CVE-2026-30867 operates through the network layer and requires an attacker to have authenticated access to an MQTT broker (low privileges required) while also requiring some user interaction for full exploitation. The attack chain works as follows:

The attacker crafts a specific 4-byte malformed MQTT payload designed to trigger the parsing vulnerability in CocoaMQTT. This payload is then published to a topic on an MQTT broker with the RETAIN flag enabled. The broker persists this message as a retained message for the topic.

When any iOS, macOS, or tvOS application using a vulnerable version of CocoaMQTT connects to the broker and subscribes to the affected topic, the broker immediately delivers the retained malformed message. The CocoaMQTT library attempts to parse this message, encounters the malformed data, and crashes the host application. Because the message is retained, this crash occurs every time the application attempts to reconnect, creating a persistent denial of service condition.

Detection Methods for CVE-2026-30867

Indicators of Compromise

• Repeated application crashes immediately after connecting to an MQTT broker
• Application crash logs showing exceptions or assertions in CocoaMQTT packet parsing code
• MQTT broker logs showing retained messages with unusual 4-byte payloads on subscribed topics
• User reports of applications becoming unusable after broker connection attempts

Detection Strategies

• Monitor application crash analytics for patterns indicating CocoaMQTT-related crashes during MQTT connection establishment
• Implement broker-side monitoring to detect and flag suspicious retained messages with abnormally small payloads
• Review MQTT broker access logs for unauthorized publish operations with RETAIN flags enabled
• Deploy application-level telemetry to track connection lifecycle events and identify crash loops

Monitoring Recommendations

• Configure crash reporting tools to alert on CocoaMQTT library exceptions
• Implement MQTT broker audit logging for all retained message publications
• Monitor for unusual patterns of client disconnections and reconnections
• Set up automated alerts for repeated application crashes on iOS/macOS/tvOS devices

How to Mitigate CVE-2026-30867

Immediate Actions Required

• Upgrade CocoaMQTT to version 2.2.2 or later immediately
• Review MQTT broker topic configurations for any suspicious retained messages
• Audit broker access controls to limit who can publish retained messages
• Consider temporarily disabling retained message functionality on sensitive topics until patching is complete

Patch Information

The vulnerability has been addressed in CocoaMQTT version 2.2.2. The fix improves input validation in the packet parsing logic to properly handle malformed payloads without crashing the host application. The patch is available through the CocoaMQTT Release 2.2.2.

For detailed information about the fix implementation, refer to the GitHub Commit Update and GitHub Pull Request #659. Additional security context is available in the GitHub Security Advisory GHSA-r3fr-7m74-q7g2.

Workarounds

• Implement broker-side message filtering to reject or quarantine abnormally small payloads before they reach clients
• Clear all retained messages from affected topics on the MQTT broker to break the persistent crash loop
• Deploy network-level filtering to inspect and validate MQTT traffic before it reaches vulnerable applications
• Consider implementing application-level crash recovery logic that detects repeated crashes and skips problematic topic subscriptions

# Clear retained messages from a topic (broker-specific command example)
# Consult your MQTT broker documentation for exact syntax
mosquitto_pub -h broker.example.com -t "affected/topic" -n -r -d