CVE-2026-10583

An attacker with administrative privileges, or any user in default single-user setups, can send a POST request to the /v1/tts/config endpoint with a malicious api_base URL. This URL is then stored without validation in the system_configs persistent store. Subsequently, when a TTS synthesis request is triggered, the backend uses the stored malicious URL, leading to Server-Side Request Forgery [ref_id=2]. The advisory notes that a similar check is performed for testing provider connections but was omitted from the save functionality [ref_id=2].

The vulnerability resides in the `handleSave` method of the `TTSConfigHandler` within the file `internal/http/tts_config.go`. Specifically, the code directly applies custom `api_base` entries without proper validation, as indicated by the comment `// [VULNERABILITY] `resolvedAPIBase()` does not run validateProviderURL() against internal IPs` [ref_id=2].

The patch ensures that the `resolvedAPIBase()` function, used when saving TTS configurations, now calls `validateProviderURL()`. This helper function preemptively rejects private IP addresses and other potentially harmful internal endpoints, preventing the persistence of malicious URLs. By enforcing this validation during the save operation, the vulnerability that allowed SSRF is remediated [ref_id=2].

Start up the vulnerable topology context utilizing a simplified compose configuration alongside PostgreSQL. Use the provided Python script to inject a malicious AWS instance metadata address (http://169.254.169.254/latest/meta-data) and subsequently ping the server to trigger a synthesis. A supplementary control script demonstrates that the corresponding connection-checking methodology properly filters out the injected payload. Execute python3 poc_tts_config_ssrf.py to view the timeout behavior reflecting a successful invocation upon the target internal network [ref_id=2].