GHSA-J828-28RJ-HFHP

A recent review identified several regular expressions in the vllm codebase that are susceptible to Regular Expression Denial of Service (ReDoS) attacks. These patterns, if fed with crafted or malicious input, may cause severe performance degradation due to catastrophic backtracking.

1. vllm/lora/utils.py Line 173

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/lora/utils.py#L173
Risk Description:

• The regex r"\((.*?)\)\$?$" matches content inside parentheses. If input such as ((((a|)+)+)+) is passed in, it can cause catastrophic backtracking, leading to a ReDoS vulnerability.
• Using .*? (non-greedy match) inside group parentheses can be highly sensitive to input length and nesting complexity.

Remediation Suggestions:

• Limit the input string length.
• Use a non-recursive matching approach, or write a regex with stricter content constraints.
• Consider using possessive quantifiers or atomic groups (not supported in Python yet), or split and process before regex matching.

2. vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py Line 52

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/tool_parsers/phi4mini_tool_parser.py#L52

Risk Description:

• The regex r'functools\[(.*?)\]' uses .*? to match content inside brackets, together with re.DOTALL. If the input contains a large number of nested or crafted brackets, it can cause backtracking and ReDoS.

Remediation Suggestions:

• Limit the length of model_output.
• Use a stricter, non-greedy pattern (avoid matching across extraneous nesting).
• Prefer re.finditer() and enforce a length constraint on each match.

3. vllm/entrypoints/openai/serving_chat.py Line 351

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/vllm/entrypoints/openai/serving_chat.py#L351

Risk Description:

• The regex r'.*"parameters":\s*(.*)' can trigger backtracking if current_text is very long and contains repeated structures.
• Especially when processing strings from unknown sources, .* matching any content is high risk.

Remediation Suggestions:

• Use a more specific pattern (e.g., via JSON parsing).
• Impose limits on current_text length.
• Avoid using .* to capture large blocks of text; prefer structured parsing when possible.

4. benchmarks/benchmark_serving_structured_output.py Line 650

https://github.com/vllm-project/vllm/blob/2858830c39da0ae153bc1328dbba7680f5fbebe1/benchmarks/benchmark_serving_structured_output.py#L650

Risk Description:

• The regex r'\{.*\}' is used to extract JSON inside curly braces. If the actual string is very long with unbalanced braces, it can cause backtracking, leading to a ReDoS vulnerability.
• Although this is used for benchmark correctness checking, it should still handle abnormal inputs carefully.

Remediation Suggestions:

• Limit the length of actual.
• Prefer stepwise search for { and } or use a robust JSON extraction tool.
• Recommend first locating the range with simple string search, then applying regex.

A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use. Typical impact: denial of service when input is crafted to trigger backtracking.

GHSA-J828-28RJ-HFHP has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.9.0); upgrading removes the vulnerable code path.

Kodem intelligence

• https://github.com/vllm-project/vllm/pull/18454

1. What is GHSA-J828-28RJ-HFHP? GHSA-J828-28RJ-HFHP is a medium-severity inefficient regular expression (ReDoS) vulnerability in vllm (pip), affecting versions >= 0.6.3, < 0.9.0. It is fixed in 0.9.0. A regular expression with worst-case exponential or polynomial matching time is applied to untrusted input, causing excessive CPU use.
2. How severe is GHSA-J828-28RJ-HFHP? GHSA-J828-28RJ-HFHP has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of vllm are affected by GHSA-J828-28RJ-HFHP? vllm (pip) versions >= 0.6.3, < 0.9.0 is affected.
4. Is there a fix for GHSA-J828-28RJ-HFHP? Yes. GHSA-J828-28RJ-HFHP is fixed in 0.9.0. Upgrade to this version or later.
5. Is GHSA-J828-28RJ-HFHP exploitable, and should I be worried? Whether GHSA-J828-28RJ-HFHP is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-J828-28RJ-HFHP is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-J828-28RJ-HFHP? Upgrade vllm to 0.9.0 or later.