CVE-2026-121936 in easyVoice
Summary
by MITRE • 11/04/2026
easyVoice before 0.0.23 contains a server-side request forgery vulnerability that allows unauthenticated attackers to make the server send POST requests by supplying openaiBaseUrl with useLLM enabled. Attackers can target loopback and internal services through /api/v1/tts endpoints, using reflected error messages in the x-generate-tts-warning header to probe internal hosts and ports.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in easyVoice versions prior to 0.0.23 represents a critical server-side request forgery flaw that stems from improper validation of user-supplied input within the application's text-to-speech functionality. Specifically, when the useLLM configuration flag is enabled, the system accepts an openaiBaseUrl parameter without sufficient sanitization or restriction on allowed destinations. This architectural oversight allows unauthenticated actors to manipulate the server into initiating HTTP POST requests to arbitrary external endpoints controlled by the attacker. The core technical failure lies in the lack of strict allowlisting for URL schemes and hostnames, which is a common deficiency in applications that dynamically construct API calls based on user input. By exploiting this misconfiguration, an adversary can force the vulnerable application to act as a proxy or relay, effectively bypassing network-level access controls that would normally restrict direct external connections from the server environment.
The operational impact of this vulnerability extends beyond simple data exfiltration, primarily due to its utility in internal network reconnaissance and pivoting. Attackers leverage the /api/v1/tts endpoint to target loopback addresses such as 127.0.0.1 or localhost, as well as other private IP ranges accessible within the server's network segment. This capability transforms a standard web application vulnerability into a powerful tool for mapping internal infrastructure. The exploitation is further amplified by the presence of reflected error messages in the x-generate-tts-warning header. When the forged request encounters an unreachable host or port, the resulting error details are returned to the attacker within this HTTP response header. This feedback mechanism provides precise timing and connectivity confirmation, enabling blind server-side request forgery techniques where the attacker can systematically probe internal hosts and ports based on variations in response time or specific error signatures contained in the warning header.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws allowing an attacker to cause the server-side application to make requests to arbitrary URLs. The exploitation technique closely mirrors ATT&CK Tactic TA0043 Reconnaissance and Technique T1561.002 Web Scraping, as well as aspects of T1078 Valid Accounts if authentication were required, though in this case it is unauthenticated. The use of reflected headers for probing also relates to CWE-209 Generation of Error Message Containing Sensitive Information, although the primary severity driver here is the SSRF capability rather than just information disclosure. This combination allows attackers not only to access internal services but potentially to interact with them if those services lack their own authentication mechanisms or rely solely on IP-based restrictions that are bypassed by originating from within the trusted server network.
Mitigation strategies must focus on strict input validation and secure configuration defaults. The most effective remediation is to implement a robust allowlist for the openaiBaseUrl parameter, restricting it exclusively to known legitimate domains required for LLM integration. If dynamic URL construction is necessary, developers should enforce protocol restrictions (e.g., HTTPS only) and block requests to private IP ranges using RFC 1918 address filtering at both the application layer and network perimeter. Additionally, disabling the useLLM feature by default or requiring administrative authentication before enabling it would significantly reduce the attack surface for unauthenticated users. Removing sensitive error details from response headers is also recommended to prevent information leakage that aids in further exploitation. Upgrading to version 0.0.23 or later resolves this issue as these patches typically include such hardening measures, ensuring that user-supplied URLs are validated against a whitelist and that internal network access is restricted by default.