What is the CVSS score of CVE-2025-53114?

CVE-2025-53114 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Which versions of CometD are affected by CVE-2025-53114?

Organizations deploying CometD Java server for real-time messaging face immediate availability risk from unauthenticated, remote denial-of-service attacks that require minimal technical…. A patch is available.

How to fix or mitigate CVE-2025-53114?

24 hours: Identify all systems running CometD Java server and determine which versions are deployed against the vulnerable range (5.0.0-5.0.22, 6.0.0-6.0.18, 7.0.0-7.0.18, 8.0.0-8.0.8). 7 days: Apply vendor patches to update all affected instances to patched versions per GHSA-cqgj-h8vf-4w59 security advisory. 30 days: Deploy monitoring for exploitation attempts and verify post-patch stability.

CometD CVE-2025-53114

EUVD-2025-210284 HIGH

Uncontrolled Resource Consumption (CWE-400)

2026-06-10 https://github.com/cometd/cometd

GHSA-cqgj-h8vf-4w59

Denial Of Service

7.5

CVSS 3.1 · Vendor: https://github.com/cometd/cometd

Severity by source

Vendor (https://github.com/cometd/cometd) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from Vendor (https://github.com/cometd/cometd) · only source for this CVE.

CVSS VectorVendor: https://github.com/cometd/cometd

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 17:20 vuln.today

Analysis Generated

Jun 10, 2026 - 17:20 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

9 maven packages depend on org.cometd.java:cometd-java-server-common (6 direct, 3 indirect)

Ecosystem-wide dependent count for version 5.0.0.

DescriptionCVE.org

Impact

Bad clients that always send a fixed batch value while the server is using the acknowledgement extension can cause the unacknowledged message queue to grow indefinitely, eventually resulting in an OutOfMemoryError.

Such bad clients would always send:

json

{
  "channel": "/meta/connect",
  ...
  "ext": { "ack": 1 }
}

The server would never clear the unacknowledged message queue, and one bad client can cause a server outage.

Patches

5.0.x - https://github.com/cometd/cometd/pull/2168 6.0.x - https://github.com/cometd/cometd/pull/2169 8.0.x - https://github.com/cometd/cometd/pull/2118

Workarounds

Disable the acknowledgement extension.

Resources

https://github.com/cometd/cometd/discussions/2116 https://github.com/cometd/cometd/issues/2117

AnalysisAI

Denial of service in CometD Java server (versions 5.0.0-5.0.22, 6.0.0-6.0.18, 7.0.0-7.0.18, 8.0.0-8.0.8) allows a single remote unauthenticated client to exhaust server memory by repeatedly sending /meta/connect messages with a fixed ack value while the acknowledgement extension is enabled, causing the unacknowledged message queue to grow without bound and triggering an OutOfMemoryError. The CVSS 7.5 score reflects high availability impact with no confidentiality or integrity impact, and no public exploit identified at time of analysis, though the GitHub Security Advisory GHSA-cqgj-h8vf-4w59 provides clear protocol-level reproduction details.

Technical ContextAI

CometD is a Java-based scalable web messaging framework implementing the Bayeux protocol over HTTP for server-to-client push communications, packaged as Maven artifact org.cometd.java:cometd-java-server-common. The acknowledgement extension (AcknowledgedMessagesExtension) tracks per-session message delivery by maintaining an unacknowledged message queue that is normally drained when a client confirms receipt of a higher batch number via the 'ext.ack' field on /meta/connect responses. The root cause is CWE-400 (Uncontrolled Resource Consumption): the server clears queued messages based on the client-supplied ack value, so a client that always sends the same fixed ack value (e.g., 'ack: 1') never advances the acknowledgement watermark, leaving every server-pushed message stuck in the per-session queue indefinitely. The patch (PRs 2118/2168/2169) introduces a configurable maxQueueSize on the extension plus a listener pattern so applications can detect and respond to runaway queues.

RemediationAI

Vendor-released patches are available: upgrade to cometd-java-server-common 5.0.23, 6.0.19, 7.0.19, or 8.0.9 depending on your branch, as published in the GitHub Security Advisory at https://github.com/cometd/cometd/security/advisories/GHSA-cqgj-h8vf-4w59 with patch PRs https://github.com/cometd/cometd/pull/2168, https://github.com/cometd/cometd/pull/2169, and https://github.com/cometd/cometd/pull/2118. The vendor-documented workaround when patching is not immediately possible is to disable the acknowledgement extension entirely, which removes the vulnerable code path but also removes guaranteed message-delivery semantics so applications relying on at-least-once delivery over unreliable transports will see message loss on transient disconnects. After upgrading, operators should also configure AcknowledgedMessagesExtension.setMaxQueueSize(...) and register an AcknowledgedMessagesExtension.Listener (or a ServerSession.QueueMaxedListener for the general session queue) to actively cap and disconnect runaway sessions, as illustrated in the new security.adoc documentation shipped with the fix.