EUVD-2026-28838Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Network-reachable crash requiring only low-privilege retained publish rights; no confidentiality or integrity impact, sole consequence is full broker availability loss.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
FlashMQ is a MQTT broker/server, designed for multi-CPU environments. Prior to version 1.26.1, a remote client with retained publish permission can crash the FlashMQ broker when both set_retained_message_defer_timeout and set_retained_message_defer_timeout_spread are configured to non-default values, resulting in denial of service. If anonymous retained publishing is allowed, no authentication is required; otherwise, the attacker needs the corresponding publish permission. This issue has been patched in version 1.26.1.
AnalysisAI
FlashMQ MQTT broker versions prior to 1.26.1 crashes with a divide-by-zero fault when a client with retained publish permission sends a retained message while both the set_retained_message_defer_timeout and set_retained_message_defer_timeout_spread settings are configured to non-default values, resulting in full denial of service and disconnection of all active MQTT sessions. Publicly available exploit code exists per SSVC classification, though EPSS sits at 0.11% (30th percentile) and no active exploitation is confirmed via the CISA KEV catalog. The vulnerable configuration requires explicit operator action to trigger, meaningfully narrowing real-world exposure.
Technical ContextAI
FlashMQ is a high-performance C++ MQTT broker designed for multi-CPU environments (affected versions: FlashMQ < 1.26.1, per EUVD-2026-28838). The root cause is CWE-369 (Divide By Zero), located in subscriptionstore.cpp within the trySetRetainedMessages function. When retained message deferral is enabled, the original code unconditionally executed td->randomish() % settings->setRetainedMessageDeferTimeoutSpread.count() to compute a randomized timeout spread. If setRetainedMessageDeferTimeoutSpread.count() evaluates to zero under specific non-default configuration combinations, the modulo operation triggers a divide-by-zero, crashing the broker process. The fix in commit 193b6e7 introduces a guard (if (spread != std::chrono::milliseconds::zero())) that skips the modulo calculation entirely when the spread is zero, eliminating the crash path.
RemediationAI
Upgrade FlashMQ to version 1.26.1, which resolves the issue via commit 193b6e7 (https://github.com/halfgaar/FlashMQ/commit/193b6e7767889511cfa8e933908ea5e6a1077a1f). Full vendor advisory details are at https://github.com/halfgaar/FlashMQ/security/advisories/GHSA-2789-vfcg-5922. For deployments that cannot immediately upgrade, a targeted compensating control is to remove or reset the set_retained_message_defer_timeout_spread configuration directive to its default (zero or unset); this prevents the vulnerable modulo code path from being reached entirely. Note that removing this setting changes timing randomization behavior for retained message deferral, which may affect throughput smoothing under high retained-message load. As a secondary hardening measure, disable anonymous retained publishing if it is not operationally required, which eliminates the unauthenticated attack vector even on vulnerable versions.
Same weakness CWE-369 – Divide By Zero
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today