CVE-2026-85608 in Douyin_TikTok_Download_API
Summary
by MITRE • 09/04/2026
Douyin_TikTok_Download_API through 4.1.2 contains a server-side request forgery vulnerability in the /api/download and /api/hybrid/video_data endpoints that allows unauthenticated attackers to fetch arbitrary URLs by supplying a url query parameter. Attackers can request internal services including cloud metadata endpoints and retrieve response bodies containing sensitive credentials through error messages.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The identified server-side request forgery vulnerability in Douyin_TikTok_Download_API versions up to 4.1.2 represents a critical security flaw within the application's core download functionality. This weakness is specifically located in the /api/download and /api/hybrid/video_data endpoints, which are designed to process user-supplied URLs for media retrieval. The fundamental technical error lies in the server-side handling of these requests without adequate validation or sanitization of the provided url query parameter. By accepting arbitrary input directly from unauthenticated users, the application allows attackers to manipulate the destination address that the backend service will request on their behalf. This lack of restriction enables an attacker to bypass intended access controls and force the vulnerable server to initiate HTTP connections to internal network resources or external domains controlled by the adversary.
The operational impact of this vulnerability is severe due to its potential for data exfiltration and reconnaissance against internal infrastructure. Because the application processes these forged requests on behalf of itself, it can reach services that are not exposed to the public internet, such as cloud metadata endpoints like AWS EC2 Instance Metadata Service or Azure Managed Identity endpoints. These internal APIs often contain sensitive authentication credentials, access keys, and configuration details necessary for the application's operation. When an attacker successfully crafts a request targeting these internal endpoints, the server retrieves the data but may inadvertently expose it through error messages returned to the client. This mechanism transforms what might otherwise be a blind SSRF into a reflective or exploitable vector where sensitive information is leaked back to the unauthenticated attacker via HTTP response bodies containing stack traces, debug output, or specific error descriptions that reveal the content of the internal request.
From an industry standards perspective, this vulnerability aligns with CWE-918, which defines Server-Side Request Forgery as a class of vulnerabilities where a web application fetches a remote resource without validating the user-supplied URL. The exploitation technique leverages ATT&CK tactic T1557, specifically subtechnique T1557.002 for Adversary-in-the-Middle or credential harvesting via internal service interaction. Furthermore, it relates to CWE-209, which concerns the generation of error messages that contain sensitive information, as the leakage occurs through these diagnostic outputs rather than direct data access in successful responses. The combination of SSRF and subsequent information disclosure creates a high-severity risk profile that can lead to full compromise of cloud infrastructure or backend systems dependent on stored credentials.
Mitigation strategies must focus on strict input validation and network-level controls. Developers should implement an allowlist approach for the url parameter, restricting it exclusively to known external domains required for video downloading functionality rather than accepting arbitrary hostnames. Additionally, implementing a deny list that blocks requests to private IP ranges (such as 10.x.x.x, 172.16-31.x.x, and 192.168.x.x) and loopback addresses can prevent access to internal services. It is also critical to disable or restrict HTTP methods like PUT and DELETE if they are not required, though GET-based SSRF remains the primary concern here. On the infrastructure side, deploying a Web Application Firewall with rules specifically targeting SSRF patterns and ensuring that cloud metadata endpoints require instance-level authentication tokens can provide defense in depth. Finally, application code must be audited to ensure that error handling routines do not expose raw response bodies or stack traces from internal requests to end users, thereby neutralizing the information leakage vector inherent in this specific exploitation chain.