CVE-2025-7105
Denial of Service via Unrestricted Fork in librechat API
Publication date: 2026-02-02
Last updated on: 2026-02-02
Assigner: huntr.dev
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| danny_avila | librechat | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in danny-avila/librechat allows attackers to exploit the unrestricted Fork Function at the endpoint `/api/convos/fork` to rapidly fork numerous contents. If the forked content contains a Mermaid graph with a large number of nodes, it can cause a JavaScript heap out of memory error when the service restarts, leading to a denial of service condition.
How can this vulnerability impact me? :
The vulnerability can impact you by causing a denial of service (DoS) on the affected service. Attackers can abuse the fork function to create many forked contents with complex Mermaid graphs, which exhausts the JavaScript heap memory upon service restart, making the service unavailable or unstable.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection can focus on monitoring the rate of requests to the `/api/convos/fork` endpoint to identify excessive forking activity. Since the vulnerability involves rapid forking of content, especially Mermaid graphs with many nodes, you can detect potential exploitation by checking for a high number of POST requests to this endpoint within a short time frame. For example, using command-line tools like `grep` and `awk` on web server logs to count requests per IP or user within a time window. Example commands: 1. `grep '/api/convos/fork' access.log | awk '{print $1}' | sort | uniq -c | sort -nr` to count requests per IP. 2. Use tools like `fail2ban` or custom scripts to alert on high request rates to this endpoint. Additionally, monitoring for HTTP 429 responses (Too Many Requests) can indicate that rate limiting is triggered, which is a sign of attempted exploitation. [1]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves implementing rate limiting on the `/api/convos/fork` endpoint to prevent rapid and excessive forking requests. The patch introduces middleware using `express-rate-limit` with configurable limits per IP and per authenticated user. Recommended steps: 1. Deploy rate limiting middleware similar to the one described, with defaults such as 30 requests per IP per minute and 7 requests per user per minute. 2. Configure logging for violations to monitor abuse attempts. 3. Ensure the client-side handles HTTP 429 responses gracefully to inform users about rate limits. These steps will reduce the risk of denial of service caused by memory exhaustion from excessive forking. [1]