CVE-2026-67991 in RubyLLM
Summary
by MITRE • 08/13/2026
crmne/ruby_llm at commit fa6f279847d6d7027814539d9c0dfc3bbdfd2a83 contains a polynomial-time regular expression denial-of-service condition in RubyLLM::Utils.underscore on Ruby 3.1.x. A very long crafted class, agent, or tool name can cause excessive CPU consumption and a denial of service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The vulnerability exists within the crmne/ruby_llm gem at commit fa6f279847d6d7027814539d9c0dfc3bbdfd2a83 where the RubyLLM::Utils.underscore method exhibits polynomial-time regular expression behavior that can be exploited for denial-of-service attacks. This flaw specifically affects Ruby 3.1.x versions and stems from improper handling of input strings during the underscore conversion process. The vulnerability manifests when processing extremely long crafted class, agent, or tool names that trigger catastrophic backtracking in the regular expressions used for string transformation.
The technical implementation of this vulnerability relies on the regular expression patterns used within the underscore method to convert camelCase or other naming conventions into snake_case format. When attackers provide exceptionally long input strings containing specific character sequences, the regular expressions can exhibit exponential time complexity due to nested quantifiers and backtracking mechanisms. This creates a condition where the processing time grows polynomially with input length rather than remaining constant or logarithmic as expected. The vulnerability is categorized under CWE-400 as a Regular Expression Denial of Service (ReDoS) attack vector, which specifically targets inefficient regular expression implementations that can be manipulated to cause excessive CPU consumption.
The operational impact of this vulnerability extends beyond simple resource exhaustion, as it can be leveraged by malicious actors to disrupt service availability within applications that utilize the ruby_llm gem. Attackers can craft specially designed class, agent, or tool names that when processed through the underscore method will consume disproportionate CPU cycles and potentially lead to application instability or complete service unavailability. This makes the vulnerability particularly dangerous in multi-tenant environments or systems where input validation is insufficient, as a single malicious request could affect overall system performance. The attack can be executed with minimal resources while causing significant computational overhead, making it an attractive vector for resource exhaustion attacks within Ruby applications.
Mitigation strategies should focus on both immediate defensive measures and long-term architectural improvements. Immediate protection involves implementing input length validation and sanitization to prevent excessively long strings from reaching the vulnerable underscore method. Organizations should also consider upgrading to patched versions of the ruby_llm gem or applying custom regular expression optimizations that eliminate the backtracking vulnerability. The implementation of rate limiting and circuit breaker patterns around the affected functionality can help prevent cascading failures while more comprehensive solutions involve replacing problematic regular expressions with iterative string processing algorithms that maintain predictable time complexity. Additionally, implementing proper input validation frameworks and conducting regular security assessments of third-party dependencies can help identify similar vulnerabilities before they can be exploited in production environments.