Whoogle Search Server Side Request Forgery vulnerability

The SSRF vulnerability in Whoogle Search allows an attacker to craft arbitrary GET requests through the window endpoint. This means an attacker can potentially access internal network resources that the Whoogle Search server has access to, even if those resources are not directly accessible from the internet. This could include accessing internal APIs, databases, or other sensitive services. The impact is particularly severe because the attacker is essentially leveraging the server's credentials and network access to perform these requests. A successful attack could lead to data exfiltration, privilege escalation, or even complete compromise of the underlying server, depending on the internal resources accessed.

Self-hosted Whoogle Search deployments are at direct risk. Users who have not implemented network segmentation or access controls on their Whoogle Search servers are particularly vulnerable, as an attacker could potentially leverage the SSRF to access a wide range of internal resources. Those using older, unpatched versions of Whoogle Search are most exposed.

• linux / server:

journalctl -u whoogle_search -f | grep -i "request: GET"

• generic web:

curl -I http://your-whoogle-instance/window?location=http://169.254.169.254/ | grep -i "Server"

1. 2024-01-23Disclosure

   disclosure

1. Reserviert2024-01-08
2. Veröffentlicht2024-01-23
3. Geändert2025-06-17
4. EPSS aktualisiert2026-04-02

The primary mitigation for CVE-2024-22205 is to immediately upgrade Whoogle Search to version 0.8.4 or later, which contains the necessary fix. If upgrading is not immediately feasible, consider implementing a Web Application Firewall (WAF) or reverse proxy to filter outbound requests from the window endpoint, specifically blocking requests to internal IP ranges or sensitive internal services. Additionally, restrict network access to the Whoogle Search server to only the necessary ports and services to minimize the potential blast radius of a successful SSRF attack. After upgrading, confirm the fix by attempting to access an internal resource via the window endpoint and verifying that the request is denied or properly sanitized.