Cross-site Scripting (XSS)

Vulnerability

Analysis

The vulnerability exists in whoogle-search versions prior to 0.7.2. The application takes the user-supplied q query string parameter and, if it does not contain the substring http, uses it to construct an error_message. This message is then passed to the error.html template via Flask's render_template function [2]. Crucially, the template renders this string using Jinja2's | safe filter, which disables automatic HTML escaping and allows arbitrary HTML/JavaScript to be injected [1][3].

Exploitation

Scenario

An attacker can craft a malicious URL containing a q parameter with a JavaScript payload, such as http://localhost:5000/url?q= [3]. Any user who visits this link will have the script executed in their browser context. No authentication is required to trigger the vulnerability, and the attack surface is the public-facing search interface. The exploit does not require the attacker to be logged in or have any special network position beyond being able to deliver the crafted link to a victim.

Impact

Successful exploitation allows an attacker to execute arbitrary JavaScript in the victim's browser, leading to cross-site scripting (XSS) attacks. This can enable session hijacking, credential theft, defacement, or redirection to malicious sites. Since whoogle-search is a privacy-respecting metasearch engine often self-hosted, an XSS could compromise the security of the host instance and any users relying on it.

Mitigation

The vulnerability is fixed in whoogle-search version 0.7.2 [1][3]. Users should upgrade to this version or later. As of 2022, the advisory databases have marked the issue as resolved [4]. There is no indication that this CVE is listed in CISA's Known Exploited Vulnerabilities catalog.