EUVD-2026-40160
GHSA-4rjg-9qq9-25m8
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable, no authentication needed, no complexity; impact is limited to low availability via API resource exhaustion, no confidentiality or integrity loss.
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
Lifecycle Timeline
1DescriptionCVE.org
LibreTranslate through 1.9.7, fixed in commit 397fd22, contains an IP spoofing vulnerability in the get_remote_address() function that allows unauthenticated attackers to spoof client IP addresses by injecting arbitrary values into the X-Forwarded-For header without trusted proxy validation. Attackers can bypass per-IP rate limiting and flood bans by supplying forged addresses in the X-Forwarded-For header to enable unlimited API abuse.
AnalysisAI
IP spoofing in LibreTranslate through 1.9.7 allows unauthenticated remote attackers to bypass per-IP rate limiting and flood bans by injecting arbitrary values into the X-Forwarded-For HTTP header. The get_remote_address() function accepts client-supplied header values without validating that the request originated from a trusted proxy, enabling any attacker to present a rotating set of forged IP addresses and evade API abuse controls entirely. No public exploit code has been identified at time of analysis, but the technique requires no authentication and trivially low technical skill given the well-known nature of X-Forwarded-For abuse.
Technical ContextAI
LibreTranslate is a self-hosted, open-source machine translation API server. The vulnerable component is the get_remote_address() helper function, which is responsible for resolving the originating client IP used to enforce per-IP rate limits and ban lists. CWE-348 (Use of Less Trusted Source for IP Address) precisely describes the root cause: the function trusts the client-supplied X-Forwarded-For header unconditionally rather than validating that the forwarding chain originates from a configured set of trusted reverse proxies. In legitimate deployments behind a reverse proxy (nginx, Caddy, etc.), the X-Forwarded-For header is set by the proxy and should be treated as authoritative only when the direct connection comes from a known trusted proxy address. Without this validation, any direct HTTP client can inject arbitrary IP strings into the header, causing the server to rate-limit a spoofed address rather than the attacker's real one. The affected CPE covers LibreTranslate versions through 1.9.7.
RemediationAI
Upstream fix available via commit 397fd22 (https://github.com/LibreTranslate/LibreTranslate/commit/397fd224080515d4001a1bc60c8fed53e3c56b6f); a patched tagged release version has not been independently confirmed from available data - operators should pull the latest commit from the main branch or monitor the GitHub repository for a formal release. As a compensating control, deploy LibreTranslate exclusively behind a reverse proxy (such as nginx) configured to unconditionally overwrite or strip the X-Forwarded-For header before the request reaches LibreTranslate, replacing it with the connecting client's real IP - this prevents client-supplied header injection regardless of application-layer trust logic. Trade-off: this requires accurate proxy configuration; misconfiguration could cause legitimate clients behind NAT or corporate proxies to share a single rate-limit bucket. Additionally, restrict access to the LibreTranslate API at the network layer to known client IP ranges where feasible, reducing the pool of potential abusers without relying solely on application-layer rate limiting.
Same weakness CWE-348 – Use of Less Trusted Source
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today