Apache Qpid Broker-J CVE-2026-68077

Exploitation requires an authenticated AMQP 1.0 connection to the broker - the attacker must possess valid credentials (username/password, SASL token, or equivalent) and the ability to open a session and send link-level frames. The vulnerability is confined to the AMQP 1.0 protocol plugin; deployments that only expose older AMQP protocol versions (0-8, 0-9, 0-10) are not exposed via this specific code path. No non-default broker configuration is described as a prerequisite - any authenticated AMQP 1.0 session with the ability to send disposition frames appears sufficient. Limiting factors: authentication is required, excluding unauthenticated remote attackers; the impact is CPU-based denial of service only, with no code execution, privilege escalation, or data exfiltration possible through this vector; and exploitation requires the AMQP 1.0 protocol endpoint to be accessible to the attacker.

No CVSS vector was provided with this advisory, so metric-level comparison is unavailable - risk assessment is derived from the description and severity rating ('important' per Apache Security Team). The authentication requirement (valid AMQP credentials must be held by the attacker) is the most significant limiting factor, constraining the realistic attack surface to malicious insiders, compromised service accounts, or tenant-isolation failures in multi-tenant broker deployments. The impact is purely availability - no confidentiality or integrity compromise is described or implied. EPSS data is not available at time of analysis. The absence of KEV listing and no known public proof-of-concept reduce urgency for most operators. Real-world priority is moderate: a CPU exhaustion attack against a central message broker can cascade into availability failures across all downstream services in event-driven architectures, making patch application a near-term priority rather than an emergency. The availability of a direct fix (10.1.0) makes upgrade the straightforward resolution path.

An authenticated AMQP 1.0 client - such as a compromised application service account or a malicious insider with broker credentials - establishes a session with the Broker-J instance and sends a sequence of disposition frames specifying artificially large or structurally illegal delivery-ID ranges. The broker's unguarded iteration logic enters a resource-intensive processing loop for each such frame, consuming CPU until the broker becomes unresponsive to legitimate producers and consumers. No public proof-of-concept code is known, but the attack primitive is conceptually simple to implement once the target code path is identified.