Aedes MQTT Broker CVE-2026-63341

The attacker must be able to establish an MQTT session to the broker's listener (default TCP 1883) and then either (a) send a PUBLISH or SUBSCRIBE whose topic exceeds qlobber's hard-coded max_words limit of 100 '/'-separated levels (the PoC uses topics like 'a/' repeated ~30000 times), or (b) register a Will message with such a deeply nested topic, which crashes the broker on ungraceful disconnect because the Will publish path calls broker.publish directly and bypasses the PUBLISH handler. The key LIMITING factor is reachability and authentication: PR:N applies to default/open brokers (e.g. the official moscajs/aedes Docker image, which is unauthenticated), whereas a broker configured to require authentication forces the attacker to hold valid credentials first. All stable versions through 1.1.0 are affected; 1.1.1 rejects over-deep topics via the new maxTopicLevels guard (default 100).

This is a genuine, easy-to-trigger availability risk rather than a high-CVSS-but-low-real-risk issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5) is internally consistent with the evidence: a single malformed MQTT packet over the network, with no user interaction and low complexity, crashes the whole broker - the GHSA advisory states the broker 'dies instantly on the very first packet.' Impact is availability-only (C:N/I:N), so this is not a data-breach or RCE issue; it is a service-kill. A complete working Python PoC is published directly in the GitHub Security Advisory, so publicly available exploit code exists, but the vulnerability is NOT listed in CISA KEV and NO EPSS score was provided in the input, so there is no signal of active, widespread exploitation at time of analysis - treat exploitation as feasible and demonstrated, not confirmed in-the-wild. The vuln.today decision label is 'this_week', consistent with a trivially exploitable DoS that is not an emergency-level RCE. One caveat requiring verification: the CVSS carries PR:N (unauthenticated), but the description and PoC note that authentication is 'authenticated or unauthenticated according to broker configuration' - PR:N reflects the default/open deployment (e.g. the official Docker image), while a broker that enforces authentication raises the bar to a client holding valid credentials. SSVC-style automatable judgement: the trigger is a single stateless packet, so exploitation is highly automatable against reachable brokers.

An attacker who can reach the broker's MQTT listener (default TCP 1883) connects - unauthenticated against a default/open broker such as the official Docker image, or with valid credentials where authentication is enforced - and sends one PUBLISH or SUBSCRIBE whose topic contains tens of thousands of '/' delimiters (or registers a deeply nested Will topic that fires on ungraceful disconnect). A full working Python PoC is published in the GHSA advisory, and the broker crashes on the first packet, disconnecting every legitimate IoT device/application until the process is restarted.