CVE-2026-71246 in Pixelfed
Summary
by MITRE • 08/05/2026
Pixelfed's SearchController (behind the auth middleware) accepts a URL via its remote-search parameters and fetches it server-side through ActivityPubFetchService, whose validateUrl() only blocks the literal hosts 127.0.0.1, localhost, and ::1 and requires https, without checking the resolved IP against private, internal, or link-local ranges (e.g. 169.254.169.254). Optional DNS validation is disabled by default and, when enabled, only confirms a DNS record exists without filtering by IP range. The fetch response body is returned to the requester only when the Content-Type matches an ActivityPub content type, making this a semi-blind but authenticated SSRF primitive reachable by any logged-in user.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability in Pixelfed's SearchController represents a significant server-side request forgery flaw that enables authenticated users to perform unauthorized network requests to internal services. The core issue stems from inadequate URL validation within the ActivityPubFetchService component which only blocks specific literal hostnames while permitting any other domain or IP address to be fetched. The validation logic fails to implement proper IP range filtering against private networks such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and link-local addresses like 169.254.169.254, creating a pathway for attackers to target internal infrastructure that should remain protected from external access. The vulnerability is classified as a semi-blind SSRF because while the attacker cannot directly read responses from internal services, they can still trigger requests and observe behavior changes in the application's response handling when successful fetches occur.
The technical implementation flaw arises from the absence of comprehensive network validation checks within the remote-search functionality. Although HTTPS enforcement is present, this alone does not prevent attackers from leveraging DNS rebinding techniques or direct IP address targeting to bypass the protocol restriction. The default configuration disables DNS validation entirely, removing an additional layer of protection that could have prevented resolution of malicious domains to internal IP addresses. When DNS validation is enabled, it only verifies DNS record existence without implementing IP range filtering, leaving the system vulnerable to attacks that utilize DNS resolution to point to internal network resources. This design flaw aligns with CWE-918, Server-Side Request Forgery, and represents a common pattern where insufficient input validation allows attackers to manipulate service requests to target unintended destinations.
The operational impact of this vulnerability is substantial for Pixelfed deployments, as any authenticated user can potentially access internal services that should be protected from external network access. The ability to perform SSRF attacks against internal infrastructure could lead to information disclosure, internal service enumeration, or even privilege escalation if internal services are misconfigured or vulnerable themselves. Attackers could target cloud metadata services, internal APIs, or other sensitive internal endpoints that might not be properly secured. This vulnerability creates a persistent threat vector that remains active as long as users can authenticate to the application, making it particularly dangerous in multi-tenant environments where different user groups may have varying access levels and security requirements. The authentication requirement provides some protection against unauthenticated exploitation but does not eliminate the risk of privilege escalation or insider threats.
Mitigation strategies should focus on implementing comprehensive IP address validation that blocks private, internal, and link-local network ranges while allowing legitimate external requests to proceed normally. The system should enforce strict DNS resolution validation that includes IP range filtering in addition to basic DNS record verification. Network-level restrictions should be implemented using firewall rules or network segmentation to prevent outbound requests to internal services from the application servers. Input validation should be enhanced to include thorough URL parsing and validation that considers both hostname and resolved IP address ranges before initiating any external network requests. The default configuration should enable DNS validation with proper IP filtering rather than disabling it entirely, ensuring that all remote requests undergo appropriate security checks. Organizations should also implement monitoring and logging of external requests to detect and alert on suspicious network activity patterns that may indicate exploitation attempts. This vulnerability demonstrates the critical importance of defense-in-depth approaches and the necessity of validating network requests at multiple layers of the application architecture, aligning with ATT&CK technique T1190 for Server-Side Request Forgery and emphasizing the need for proper network segmentation and access controls to prevent unauthorized internal service access.