CVE-2026-57942 Overview
CVE-2026-57942 is an IP spoofing vulnerability in LibreTranslate through version 1.9.7. The flaw resides in the get_remote_address() function within libretranslate/app.py. This function trusts the X-Forwarded-For HTTP header without verifying that the request originates from a trusted proxy. Unauthenticated attackers can inject arbitrary IP addresses into the header to impersonate any client. The vulnerability is categorized under [CWE-348] Use of Less Trusted Source and is fixed in commit 397fd22.
Critical Impact
Attackers can bypass per-IP rate limiting and flood ban controls by supplying forged addresses in the X-Forwarded-For header, enabling unlimited API abuse against LibreTranslate instances.
Affected Products
- LibreTranslate versions through 1.9.7
- LibreTranslate deployments exposed directly to the internet without a trusted reverse proxy
- LibreTranslate instances relying on built-in per-IP rate limiting or flood ban features
Discovery Timeline
- 2026-06-29 - CVE-2026-57942 published to NVD
- 2026-06-29 - Last updated in NVD database
Technical Details for CVE-2026-57942
Vulnerability Analysis
LibreTranslate uses get_remote_address() to identify the client IP for rate limiting and flood ban enforcement. The pre-patch implementation unconditionally reads the first value from any X-Forwarded-For header supplied by the client. Because the application performs no trusted proxy validation, any HTTP client can dictate the IP address LibreTranslate associates with the request. Attackers rotate the forged header value across requests to evade per-IP throttling. This exposes the translation API to abuse such as resource exhaustion, quota theft, and cost inflation on paid backends.
Root Cause
The root cause is unconditional trust in a client-controlled HTTP header. The function assumed a reverse proxy was always present and sanitizing X-Forwarded-For. When LibreTranslate is deployed directly on a network interface, the header is attacker-controlled input rather than proxy metadata. The patch introduces a TRUST_FORWARDED_FOR configuration flag defaulting to False, requiring operators to explicitly opt in.
Attack Vector
An unauthenticated remote attacker sends HTTP requests to the LibreTranslate API with a spoofed X-Forwarded-For header. Each request carries a different forged IP, causing the rate limiter to treat every request as originating from a new client. This defeats both request-per-minute limits and long-term flood bans.
# Pre-patch vulnerable code from libretranslate/app.py
def get_remote_address():
if request.headers.getlist("X-Forwarded-For"):
ip = request.headers.getlist("X-Forwarded-For")[0].split(",")[0]
else:
ip = request.remote_addr or "127.0.0.1"
return ip
# Source: https://github.com/LibreTranslate/LibreTranslate/commit/397fd224080515d4001a1bc60c8fed53e3c56b6f
Detection Methods for CVE-2026-57942
Indicators of Compromise
- High volume of translation API requests carrying varied or sequential X-Forwarded-For values from a single TCP source.
- Rate limiter logs showing thousands of distinct client IPs but few underlying TCP peers in web server access logs.
- Requests where X-Forwarded-For contains private, reserved, or malformed IP ranges reaching the LibreTranslate application layer.
Detection Strategies
- Correlate the TCP source address (remote_addr) with the value of X-Forwarded-For in access logs and alert on high cardinality mismatches.
- Inspect LibreTranslate logs for rate-limit counters that reset unexpectedly across requests from the same session or User-Agent.
- Baseline the ratio of unique X-Forwarded-For values per upstream socket and alert on statistical outliers.
Monitoring Recommendations
- Enable request logging on the reverse proxy or WAF fronting LibreTranslate and forward events to centralized analytics.
- Track translation API volume per underlying source IP rather than per header-supplied IP.
- Alert on repeated requests where X-Forwarded-For contains reserved ranges such as 127.0.0.0/8, 10.0.0.0/8, or 169.254.0.0/16.
How to Mitigate CVE-2026-57942
Immediate Actions Required
- Upgrade LibreTranslate to a build that includes commit 397fd22 or later.
- Deploy LibreTranslate behind a trusted reverse proxy that overwrites or strips inbound X-Forwarded-For headers.
- Leave the new TRUST_FORWARDED_FOR flag at its default value of False unless a validated proxy chain is in place.
- Review recent API usage for evidence of spoofing-driven abuse and rotate any quota-bound API keys.
Patch Information
The fix is available in LibreTranslate commit 397fd22, merged via Pull Request #987 and tracked in Issue #986. Additional context is available in the VulnCheck Advisory on Spoofing. The patch removes unconditional trust in X-Forwarded-For and introduces a TRUST_FORWARDED_FOR boolean setting (default False) in libretranslate/default_values.py.
Workarounds
- Configure the fronting reverse proxy (nginx, HAProxy, Traefik) to remove any client-supplied X-Forwarded-For and set it based on the observed TCP source.
- Apply WAF rules that reject requests containing multiple X-Forwarded-For headers or values matching reserved IP ranges.
- Restrict LibreTranslate network exposure to internal networks until the patched version is deployed.
# nginx example: overwrite X-Forwarded-For with the real client IP
location / {
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://libretranslate_backend;
}
# LibreTranslate configuration (post-patch): keep default unless trusted proxy exists
# TRUST_FORWARDED_FOR=false
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

