CVE-2026-67242: RabbitMQ: OAuth2 is_integer(Exp) guard skips token-expiry checks for float exp
RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, OAuth2 isinteger(Exp) guard skips token-expiry checks for float exp. validatetokenexpiry/1 (lines 208-214) and expirytimestamp/1 (138-144) both guard with 'when isinteger(Exp)' and fall through to ok/never for float values. josejwt:verify validates only the signature, not exp. With float exp, no expiry validation occurs anywhere in the If the IdP emits exp as a JSON float (RFC 7519 permits fractional NumericDate), both the login-time expiry check and the mid-connection disconnect timer are silently skipped , an already-expired token is accepted, and connections never time OAuth2 backend enabled IdP emits float exp (uncommon; mainstream IdPs emit integers) Attacker possesses a previously-valid signed. This issue is fixed in versions 4.2.9 and 4.3.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.9 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.3
Event History
Frequently Asked Questions
Which deployments are realistically exposed?
Deployments using the OAuth2 backend are affected only if their identity provider emits the JWT exp claim as a JSON floating-point value. The data notes that this is uncommon because mainstream identity providers typically emit integer exp values.
What does an attacker need to exploit this issue?
An attacker needs a previously valid, correctly signed OAuth2 token whose exp claim is a float. The vulnerable code accepts the token even after its expiration time because signature verification does not validate exp.
What is the impact after an expired float-exp token is accepted?
Both the login-time expiry check and the mid-connection disconnect timer are skipped. As a result, an expired token can establish a connection and that connection will not be timed out based on token expiry.
How can I determine whether my environment is affected?
Confirm whether the RabbitMQ OAuth2 backend is enabled, whether the deployed version is from 4.2.0 through 4.2.9 or is 4.3.3, and inspect tokens issued by the identity provider to determine whether exp is encoded as a JSON float rather than an integer.
What versions contain the fix?
The issue is fixed in RabbitMQ versions 4.2.9 and 4.3.3.