CVE-2026-67240 in RabbitMQ
Riassunto
di VulDB • 23/09/2026
RabbitMQ è un broker di messaggistica e streaming. Prima delle versioni 4.2.7 e 4.3.1, pattern_to_regex mappa % -> .*? e _ -> ., quindi compila ^...$ con solo [unicode]; re:run viene chiamato con solo [{capture, none}] - nessun match_limit esplicito. Un pattern come %_%_..._%X diventa ^.*?..*?.....*?.X$ con quantificatori lazy sovrapposti. Il limite per l'intera espressione è ?MAX_EXPRESSION_LENGTH=4096 caratteri / ?MAX_TOKENS=200; una stringa letterale LIKE è un token, quindi ~2000 coppie %_ si adattano. I filtri SQL sono accettati incondizionatamente in rabbit_amqp_session.erl:3264 (nessun flag di funzionalità). Valutati per messaggio in rabbit_stream_queue.erl:1439. Il match_limit predefinito di OTP, pari a 10M, limita ogni corrispondenza a ~100-200 ms (non secondi), e la NIF re cede al scheduler. Un consumer AMQP 1.0 autenticato con permessi read+write su una stream queue può causare ~100-200 ms di CPU per messaggio consegnato tramite un filtro LIKE manipolato, moltiplicato attraverso migliaia di messaggi e sessioni parallele - un'importante amplificazione della CPU guidata dal backtracking. I prerequisiti includono AMQP 1.0 con stream queues in uso. L'attaccante può allegare un receiver con un filtro (permesso read) e pubblicare messaggi con valori delle proprietà lunghi (permesso write). Questo problema è risolto nelle versioni 4.2.7 e 4.3.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.