W silniku wnioskowania vLLM przed wersją 0.24.0 parametr API structured_outputs.regex przekazuje wyrażenie regularne dostarczone przez użytkownika bezpośrednio do kompilatorów gramatyki bez żadnego limitu czasu kompilacji. Umożliwia to przeprowadzenie ataku ReDoS (Regular Expression Denial of Service) za pomocą jednego złośliwego żądania, co może całkowicie zablokować pracownika wnioskowania.
▸ Pokaż oryginał (EN)
vLLM is a high-throughput and memory-efficient inference and serving engine for LLMs. Prior to 0.24.0, the structured_outputs.regex API parameter passes a user-supplied regular expression string directly to the grammar compiler backends with no compilation timeout; in the xgrammar backend the string reaches the regex compiler with no guard, and in the outlines backend the validation step blocks structural issues such as lookarounds and backreferences but performs no complexity analysis, so a pattern with nested quantifiers passes all checks and causes exponential state-space expansion, allowing a single request containing an adversarial regex to hang an inference worker indefinitely and deny service. This issue is fixed in version 0.24.0.
W backendzie xgrammar wyrażenie regularne trafia do kompilatora bez żadnej ochrony. W backendzie outlines etap walidacji blokuje co prawda pewne konstrukcje składniowe (np. lookarounds i backreferences), jednak nie przeprowadza analizy złożoności obliczeniowej. W konsekwencji wzorzec zawierający zagnieżdżone kwantyfikatory przechodzi wszystkie kontrole, a jego przetwarzanie prowadzi do wykładniczej ekspansji przestrzeni stanów (CWE-1333). Wystarczy wysłanie jednego żądania z odpowiednio skonstruowanym wyrażeniem regularnym, aby zawiesić wątek roboczy wnioskowania na czas nieokreślony i odmówić usługi innym użytkownikom.
Atakujący nieuwierzytelniony zdalnie może doprowadzić do trwałej niedostępności pracownika wnioskowania (Denial of Service), blokując przetwarzanie żądań dla wszystkich użytkowników serwisu LLM.
Należy zaktualizować vLLM do wersji 0.24.0 lub nowszej, w której problem został naprawiony (commit 2b3006076c5e9bc4cda9e03e3641388de3c5c286). Do czasu aktualizacji należy rozważyć ograniczenie dostępu do parametru structured_outputs.regex wyłącznie do zaufanych klientów lub całkowite jego wyłączenie na poziomie konfiguracji.
vLLM (vllm-project/vllm) w wersjach przed 0.24.0, korzystające z backendu xgrammar lub outlines z włączoną funkcją structured_outputs.regex.
Podatność zgłoszona i naprawiona w ramach GitHub Security Advisory GHSA-rwxx-mrjm-wc2m; fix dostępny w pull request #45118.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XVllm
APPVllm< 0.24.0
Powiązane podatności
Pominięcie uwierzytelnienia w vLLM — bypass klucza API OpenAI
vLLM: wyciek adresu sterty umożliwiający RCE przez endpoint multimodalny
vLLM: niezamierzone nasłuchiwanie TCPStore na wszystkich interfejsach sieciowych
RCE w vLLM poprzez deserializację pickle na niezabezpieczonych gniazdach ZeroMQ
RCE przez niebezpieczną deserializację w vllm MessageQueue.dequeue()