CVE-2026-76166: Modcluster-core: mod_cluster advertise listener: unauthenticated dos via crafted multicast datagram
A flaw was found in modcluster's AdvertiseListenerImpl (org.jboss.modcluster core module). A single crafted UDP multicast datagram with a valid HTTP status line and a "Server:" header but without the "Date:", "Digest:", and "Sequence:" headers triggers a NullPointerException in verifyDigest() that is not caught by the worker thread's exception handler. This causes the advertise listener thread to terminate permanently. The failure is silent (isListening() continues to return true) and persists until the node is restarted. The crash occurs before the AdvertiseSecurityKey comparison, so deployments with a configured security key are still affected.
Other sources
Reported via PSIRTSUPT-20286 by Ta Duc Thien from Ninh Thanh Cyber Security (NTCS).
Vulnerability in org.jboss.modcluster core module, class AdvertiseListenerImpl. A crafted UDP multicast datagram (missing Date/Digest/Sequence headers) triggers an uncaught NullPointerException in verifyDigest() that kills the advertise worker thread permanently. Works even with AdvertiseSecurityKey configured (NPE fires before key comparison). Silent failure — isListening() keeps returning true.
Upstream: https://github.com/modcluster/modcluster Affected version: 2.1.0.Final (confirmed by reporter, same code on current main branch) Reporter's PoC and full write-up attached to PSIRTSUPT-20286.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
org.jboss.modcluster mod_cluster (org.jboss.modcluster core module) - AdvertiseListenerImplto a version that resolves this vulnerability.Fixed in 2.1.0.FinalPatch PSIRTSUPT-20286
Event History
Frequently Asked Questions
What network access does an attacker need to trigger the denial of service?
An attacker needs the ability to send a crafted UDP multicast datagram to the mod_cluster advertise listener. No authentication or user interaction is required.
Does configuring an AdvertiseSecurityKey protect against this issue?
No. The listener fails before it compares the AdvertiseSecurityKey, so deployments with a configured security key are still affected.
What is the operational impact after exploitation?
The advertise listener worker thread terminates permanently, preventing it from processing further advertise traffic until the node is restarted. The failure is silent because isListening() continues to report true.
How can an administrator tell whether the listener has failed?
Do not rely solely on isListening(), as it remains true after the worker thread terminates. The available data indicates that recovery requires restarting the affected node.