CVE-2024-8998 Overview
CVE-2024-8998 is a Regular Expression Denial of Service (ReDoS) vulnerability in lunary-ai/lunary, an open-source observability platform for large language model (LLM) applications. The flaw affects the server-side regex pattern /{.*?}/, which is applied to user-controlled input. Under the default JavaScript regex engine, this pattern exhibits polynomial-time complexity against crafted strings. Attackers can submit specially designed payloads over the network to cause the server to hang for an arbitrary duration, exhausting CPU resources. The issue is tracked under [CWE-1333] (Inefficient Regular Expression Complexity) and is resolved in Lunary version 1.4.26.
Critical Impact
An unauthenticated remote attacker can stall the Lunary server indefinitely with a single crafted HTTP payload, denying service to all users.
Affected Products
- lunary-ai/lunary at commit f07a845
- All Lunary versions prior to 1.4.26
- Lunary self-hosted deployments using the default regex engine
Discovery Timeline
- 2025-03-20 - CVE-2024-8998 published to NVD
- 2025-04-04 - Last updated in NVD database
Technical Details for CVE-2024-8998
Vulnerability Analysis
The vulnerability resides in a server-side handler that applies the regular expression /{.*?}/ to strings supplied by the client. The pattern uses a lazy quantifier inside curly brace delimiters, intended to locate template-style placeholders within user content. While the pattern appears benign, the default V8 regex engine used by Node.js exhibits non-linear matching behavior when the input contains many opening braces without matching closing braces, or other adversarial sequences. Each additional character in the malicious payload amplifies CPU time spent in backtracking and lazy-match expansion. The Lunary server, running a single-threaded Node.js event loop, becomes unresponsive to all concurrent requests during this matching. Refer to the Huntr Bounty Details for the published proof-of-concept and matching benchmarks.
Root Cause
The root cause is the use of an inefficient regex pattern against unbounded, untrusted input without size limits, timeout enforcement, or use of a linear-time regex engine. Input validation and length capping are absent on the affected endpoint.
Attack Vector
The attack is network-reachable and requires no authentication or user interaction. An adversary sends an HTTP request containing a crafted string designed to maximize regex backtracking. The Lunary server applies the vulnerable regex during request processing and blocks the event loop, halting all incoming traffic until matching completes or the process is terminated.
No public exploit code is referenced in the CVE record. The vulnerability mechanism is described in prose because no verified proof-of-concept payload is published in the available references beyond the Huntr report.
Detection Methods for CVE-2024-8998
Indicators of Compromise
- Sustained 100% CPU utilization on the Node.js process hosting Lunary while inbound traffic volume remains low.
- HTTP requests to Lunary endpoints containing unusually long strings with repeated { characters or unbalanced brace sequences.
- Application logs showing request handlers that never return or time out on inputs to fields parsed by the template regex.
Detection Strategies
- Inspect web access logs for POST or query parameters exceeding expected length thresholds on Lunary API routes.
- Correlate process-level CPU spikes with specific inbound request IDs to isolate offending payloads.
- Deploy a Web Application Firewall (WAF) rule that flags request bodies containing more than a configurable number of unmatched { characters.
Monitoring Recommendations
- Track event loop lag metrics for the Lunary Node.js process and alert on sustained latency above 500ms.
- Monitor HTTP request duration percentiles; alert when the p99 latency on Lunary endpoints exceeds normal baselines.
- Forward Lunary application and reverse-proxy logs to a centralized SIEM for retroactive payload analysis.
How to Mitigate CVE-2024-8998
Immediate Actions Required
- Upgrade lunary-ai/lunary to version 1.4.26 or later, which replaces the vulnerable regex with a safe implementation.
- Restrict network exposure of self-hosted Lunary instances to trusted networks until the patch is applied.
- Apply request size limits at the reverse proxy or load balancer in front of Lunary.
Patch Information
The maintainers fixed the issue in the upstream commit referenced in the GitHub Commit Update. The fix is included in Lunary 1.4.26. Operators running container images should rebuild from the patched release tag.
Workarounds
- Place a reverse proxy such as NGINX in front of Lunary and cap request body size with client_max_body_size to limit payload length.
- Add a WAF rule that rejects requests containing more than a small number of { characters in body or query parameters.
- Run the Lunary process behind a watchdog that restarts the service when CPU saturation persists beyond a defined threshold.
# NGINX example: cap request body and reject suspicious payloads
http {
client_max_body_size 64k;
client_body_timeout 5s;
map $request_body $redos_payload {
"~*\{{20,}" 1;
default 0;
}
server {
location /api/ {
if ($redos_payload) { return 400; }
proxy_pass http://lunary_upstream;
proxy_read_timeout 10s;
}
}
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


