Description

LibreTV before v2.21.2 contains a server-side request forgery vulnerability that allows authenticated users to bypass checkUpstreamAllowed() by exploiting unpinned DNS resolution in fetchWithSafeRedirects(). Attackers controlling authoritative DNS can return public addresses during validation and internal addresses at connection time via /api/source/test, /api/proxy, /api/search or /api/detail to reach loopback services, private hosts or cloud metadata endpoints.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.1",
  "pubDate": "2026-11-05T19:17:20.217Z",
  "pubdate": "2026-11-05T19:17:20.217Z",
  "executiveSummary": "LibreTV versions prior to 2.21.2 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability due to improper input validation during upstream resource fetching.\nThe vulnerability originates from a race condition in the DNS resolution process, specifically when utilizing the fetchWithSafeRedirects() function.\nAn authenticated attacker can bypass the checkUpstreamAllowed() security mechanism by orchestrating a DNS rebinding attack.\nBy controlling an authoritative DNS server, an attacker can manipulate the resolution process to provide a safe public IP during the validation phase and subsequently switch to a sensitive internal IP address during the actual connection phase.\nThis exploit allows an authenticated user to perform unauthorized requests against loopback services, private network infrastructure, or cloud provider metadata services (e.g., IMDS).\nThe impact is significant, potentially leading to unauthorized data exfiltration, internal network reconnaissance, or remote execution on local services accessible from the application host.\nSuccessful exploitation requires the ability to configure an attacker-controlled DNS server and access to the LibreTV API endpoints: /api/source/test, /api/proxy, /api/search, or /api/detail.",
  "technicalDetails": "The core of the vulnerability resides in the fetchWithSafeRedirects() function within the LibreTV application. While the application implements a validation function named checkUpstreamAllowed() to enforce allow-lists or block-lists for outbound requests, the implementation suffers from a time-of-check to time-of-use (TOCTOU) flaw regarding DNS resolution.\nIn a standard execution flow, the application resolves a hostname to an IP address to verify if the destination is permitted. However, because the application performs separate lookups for the validation check and the actual connection, it is vulnerable to DNS rebinding.\nThe attack flow begins when an attacker provides a malicious domain that points to a controlled authoritative DNS server. When the application calls checkUpstreamAllowed(), the DNS server returns a benign, public-facing IP address. The validation check passes because the public IP is not explicitly blocked.\nImmediately following the validation, the application proceeds to the connection phase using the same hostname. The attacker-controlled DNS server detects the second request—or relies on a low time-to-live (TTL) value—to return a private or loopback IP address (such as 127.0.0.1 or 169.254.169.254) in the subsequent lookup.\nThe application then establishes a connection to the newly resolved, prohibited internal address, effectively bypassing the initial security check. This behavior affects multiple endpoints, including /api/source/test, /api/proxy, /api/search, and /api/detail, which rely on the vulnerable fetching logic to retrieve content or perform connectivity tests.\nThis SSRF vulnerability is exacerbated by the lack of DNS pinning or 'stickiness' in the application's underlying HTTP client library. By forcing the application to connect to internal services, an attacker can interact with restricted management interfaces, extract sensitive environment variables from metadata services, or perform port scanning on the internal network.\nThe requirement for authentication means the vulnerability is not exploitable by unauthenticated remote users, but it poses a severe risk in multi-user environments or instances where user accounts may be compromised or provisioned for untrusted parties. The exposure is limited only by the outbound connectivity of the server and the internal service surface area reachable from the LibreTV container or host."
}