Executive Summary

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.

Useful 0 Not Useful 0

Impact Analysis

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.

Useful 0 Not Useful 0

Detection Guidance

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]

Useful 0 Not Useful 0

Mitigation Strategies

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]

Useful 0 Not Useful 0