RabbitMQ EUVD-2026-87158

Requires the RabbitMQ OAuth2 auth backend (rabbitmq_auth_backend_oauth2) to be enabled AND the configured identity provider to emit the JWT 'exp' claim as a JSON float (fractional NumericDate) rather than an integer - an uncommon configuration, as mainstream IdPs emit integer exp values. The attacker must also possess a previously-valid, correctly signed token, since jose_jwt:verify still validates the signature. These preconditions (non-default float-exp IdP behavior plus possession of a signed token) sharply limit real-world exploitability despite the network-reachable vector; brokers on default integer-exp IdPs or without the OAuth2 backend are unaffected.

This is a genuine but conditional authentication weakness that is overstated by its raw score in most real deployments. The provided CVSS 4.0 vector (6.3, AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N) correctly encodes the core limiter as AT:P (attack requirement present) rather than baking it into complexity - that requirement is the linchpin, because the description states the IdP must emit 'exp' as a JSON float, which is uncommon since mainstream identity providers emit integer NumericDate values. No EPSS score, no CISA KEV listing, and no public POC were supplied, so exploitation signals are absent; per policy this is treated as 'no public exploit identified at time of analysis.' The technical impact is limited (VC:L/VI:L, no availability impact): a stale-but-signed token is accepted and connections never time out, yielding continued messaging access rather than a fresh privilege gain. Net: a real correctness/session-expiration bug worth patching on OAuth2-backed brokers, but low practical priority given the non-default float-exp precondition and the requirement that the attacker already hold a previously-valid signed token. Note the tag 'Information Disclosure' is a loose fit - the flaw is fundamentally CWE-613 insufficient session expiration / expired-credential acceptance, though a stale token does grant read access, so the C:L component is defensible.

In an environment where RabbitMQ uses the OAuth2 auth backend and the configured IdP issues tokens with a fractional (float) 'exp' claim, a user whose token has expired - or an attacker who captured that previously-valid signed token - presents it to the broker. Because the is_integer(Exp) guard falls through for float values, both the login-time expiry check and the mid-connection disconnect timer are skipped, so the expired token is accepted and the session never times out. No public exploit code is known; exploitation hinges on the uncommon float-exp IdP behavior and possession of a valid signed token.