ruby_llm EUVD-2026-91753

Requires that the host application using ruby_llm routes untrusted, attacker-influenced model-identifier strings into the Mistral provider's modalities_for/capabilities_for code path, which applies the vulnerable /voxtral.*tts/ and /voxtral.*transcribe/ regexes. Additionally the process must run on Ruby 3.1.x, where the regex engine lacks the linear-time ReDoS optimization - the description explicitly limits the condition to Ruby 3.1.x, so deployments on later Ruby versions are a strong limiting factor. No authentication is enforced by the library itself, but the practical limiter is whether model selection is exposed to untrusted input at all; many deployments hardcode or whitelist model ids, which neutralizes the vector. Impact is availability-only CPU exhaustion; no data confidentiality or integrity effect.

This is a polynomial-time ReDoS (CWE-1333) in the crmne/ruby_llm gem's Mistral capability matching, affecting availability only (CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5, confirmed in input). The signals point to real-but-conditional risk rather than an urgent crisis. SSVC states Exploitation: none (no observed exploitation) and Technical Impact: partial, but Automatable: yes - meaning that where the preconditions exist, an attacker can script the trigger reliably. No EPSS score, KEV listing, or POC was provided, so exploitation status is 'no public exploit identified at time of analysis.' A key tension: the CVSS vector claims network, unauthenticated reach (AV:N/PR:N), but this is a LIBRARY vulnerability - the vulnerable code only executes if the consuming application passes attacker-controllable model-id strings into modalities_for/capabilities_for, AND the runtime is Ruby 3.1.x (the description explicitly scopes the condition to Ruby 3.1.x; later Ruby regex engines with the linear-time ReDoS mitigations are not affected). So the headline AV:N/PR:N reflects the worst-case integration, not a universal truth - verify whether your application exposes model selection to untrusted input. Because the pattern is polynomial (not exponential/catastrophic), the impact is CPU exhaustion/thread stalling proportional to a large crafted input, degrading or hanging a worker rather than instantly crashing it.

An application built on ruby_llm (running Ruby 3.1.x) lets users specify or influence the Mistral model identifier. An attacker submits a model id such as a very long repetition of 'voxtral' (the fix test uses 'voxtral' * 50,000), causing the /voxtral.*tts/ and /voxtral.*transcribe/ regexes to consume excessive CPU and stall the request thread, degrading service availability. No public exploit is identified, but the trigger is trivial to reproduce and SSVC marks it Automatable: yes.