CVE-2025-53114: CometD Denial-of-Service via Unacknowledged Message Queue Overflow

Technical summary

The vulnerability stems from improper handling of batch acknowledgement logic in CometD's acknowledgement extension. When a client repeatedly sends HTTP requests with an identical batch value instead of incrementing it as expected, the server's queue management fails to recognize and release acknowledged messages. This allows an attacker to craft a simple exploit: send a request with a static batch ID, forcing the server to queue every message sent to that client without ever removing them from memory. Over time, the unacknowledged message queue grows unbounded, leading to an OutOfMemoryError (CWE-400: Uncontrolled Resource Consumption). The attack requires no authentication or special privilege and can be triggered remotely by a single client, making it a trivial denial of service.

Business impact

A successful exploitation results in complete unavailability of the CometD server. Any organization relying on CometD for real-time notifications, messaging, or push updates will experience service disruption. Since a single unauthenticated client can trigger the condition, malicious actors can launch attacks from public networks without special access. Recovery requires manual server restart, causing data loss if unsaved messages are in flight and operational delay for critical applications that depend on the messaging layer. For SaaS providers or organizations offering CometD-based services, this vulnerability presents a reputational and availability risk.

Affected systems

All CometD deployments in the following version ranges are vulnerable: 5.0.0 through 5.0.22 (legacy LTS branch), 6.0.0 through 6.0.18 (prior stable release), 7.0.0 through 7.0.18 (current stable series), and 8.0.0 through 8.0.8 (latest development branch). Organizations must audit their environment to determine which CometD branch is deployed and cross-reference against the patched versions listed above. Vulnerability only manifests when the acknowledgement extension is explicitly enabled in the server configuration; deployments using alternative message handling strategies are unaffected.

Exploitability

Exploitability is high. The attack requires no authentication, no special client capabilities, and no prior system knowledge. An attacker can craft a minimal HTTP client that sends a single batch ID repeatedly to any publicly accessible CometD endpoint. No user interaction is needed. The barrier to weaponization is extremely low; a proof-of-concept would be trivial to assemble. However, the attack is noisy and detectable: the server logs will show repeated requests from the same source, making it easier to identify and block the attacker once monitoring is in place. The vulnerability does not appear on the CISA Known Exploited Vulnerabilities catalog, but the simplicity of the attack vector suggests exploitation in the wild is plausible if CometD is internet-facing.

Remediation

Immediate action: If you are running CometD with the acknowledgement extension enabled, upgrade to a patched version immediately. Patched versions are 5.0.23, 6.0.19, 7.0.19, and 8.0.9. If you cannot patch immediately, disable the acknowledgement extension in your server configuration as a workaround, though this may require changes to client-side logic. Verify with your CometD documentation or vendor advisory for version-specific upgrade and configuration instructions. After patching, perform a test deployment in a staging environment before rolling out to production.

Patch guidance

CometD has released fixes across all supported branches: upgrade to version 5.0.23 (for the 5.0.x line), 6.0.19 (for 6.0.x), 7.0.19 (for 7.0.x), or 8.0.9 (for 8.0.x). Each patched version addresses the batch acknowledgement handling to prevent unbounded queue growth. Consult the official CometD release notes and security advisories to confirm the exact patch version for your deployment and any breaking changes or dependencies. Test thoroughly in a non-production environment before deploying patches to production systems, especially if CometD is critical to your service availability.

Detection guidance

Monitor CometD server logs for repeated requests from the same source IP with identical or near-identical batch identifiers over short time windows. Set alerts on OutOfMemoryError exceptions and server restarts tied to heap exhaustion. Network monitoring tools can flag high-frequency requests to CometD endpoints that spike unexpectedly. Heap memory consumption graphs are also useful: a sudden, sustained increase in the unacknowledged message queue size is a clear sign of exploitation. Implement rate limiting on the CometD endpoint to throttle clients that send excessive requests, which will mitigate the attack even on unpatched servers.

Why prioritize this

Despite being unpatched, this vulnerability warrants immediate attention due to its high CVSS score (7.5), unauthenticated attack vector, and trivial exploitability. Any internet-facing or untrusted-network CometD instance should be treated as critical. Even internal deployments present operational risk due to the simplicity of the attack. The fix is low-risk and straightforward, making this an easy win for security teams to deploy with minimal testing overhead. Given the absence of complex exploitation barriers, prioritize this alongside other high-severity remote denial-of-service issues.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible denial-of-service vulnerability with no authentication required and no user interaction. The attack vector is unauthenticated (AV:N, AC:L, PR:N, UI:N), making it broadly accessible. The impact is severe availability loss (A:H) but does not compromise confidentiality or integrity. The score appropriately penalizes the ease of exploitation and widespread impact on service availability. Organizations should treat this as a priority fix for any CometD instances exposed to untrusted networks.

Frequently asked questions