CVE-2026-67591 in Apache Qpid ProtonJ2 is a flow control validation gap — the library accepts incoming window state without bounds, allowing an authenticated peer to exhaust receiver resources. The CVSS 6.5 paired with an EPSS of 0.00173 creates an apparent disparity worth understanding before you deprioritize this based on the exploitation score alone.
The 'authenticated attacker' qualifier warrants scrutiny in AMQP contexts specifically. In enterprise deployments, authentication enforcement varies significantly — some brokers use SASL with strong credentials, others rely on network segmentation with permissive intra-network access, and legacy environments often run anonymized. The real exploitation barrier in many organizations is network adjacency to the broker, not credential acquisition. If an attacker compromises a co-located service or obtains internal network access, they may trigger this without needing AMQP credentials at all, depending on broker configuration.
Once inside the broker, the blast radius matters more than the entry barrier. AMQP brokers are rarely single-tenant — a Qpid ProtonJ2 instance handling session flow control typically aggregates connections from multiple producers and consumers across the infrastructure. An authenticated attacker achieving DoS doesn't just disrupt their own session; they can cascade failures into every queue, every consumer, and every downstream process depending on that broker. The authenticated barrier reduces exploitation probability but not blast radius.
The dependency inheritance angle is where this CVE becomes more insidious. Qpid ProtonJ2 is frequently a transitive dependency — buried in integration frameworks, ESB layers, and Spring Boot starters. Your application may not directly depend on it; you're inheriting it from upstream. This means the 'authenticated' protection depends on broker configuration you may not control, maintained by a team that may not be yours. The authentication posture that made 'authenticated attacker' meaningful at disclosure erodes over time through configuration drift, vendor bundle customizations, and broker config changes made during incidents — without any code change that would surface a new CVE.
The practical question: does the low EPSS justify deprioritizing? I'd argue no. The fix in version 1.2.0 adds bounds validation — application logic fixes like this carry low regression risk compared to memory corruption patches. The interconnectedness of message broker infrastructure means the blast radius of a successful DoS likely exceeds what the Medium severity implies. And because this lives in a transitive dependency, the window between upstream fix and your deployment is quarters, not weeks — a timeline that the EPSS score doesn't capture but that leaves you exposed far longer than the raw numbers suggest.
If you're using Qpid ProtonJ2, verify your direct and transitive dependency trees, confirm your broker enforces authentication (don't assume it's default), and treat this as a library update priority rather than a backburner item — not because active exploitation is imminent, but because the combination of multi-tenant blast radius, transitive dependency decay, and slow remediation velocity creates a compounding risk that the EPSS figure obscures.