CVE-2026-92719 in Quickwit
Summary
by MITRE • 09/16/2026
Quickwit through 0.9.0 fails to validate the host and scheme of the queue_url parameter in SQS file sources, allowing attackers to make the node issue requests to arbitrary internal addresses. Attackers can supply a malicious queue_url to the create-source API to scan internal networks and fingerprint services based on connection response differences.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in Quickwit versions through 0.9.0 represents a critical server-side request forgery flaw within the SQS file source implementation. This security defect stems from an insufficient validation of user-supplied input, specifically the queue_url parameter used when configuring data sources via the create-source API endpoint. In secure application design, external inputs that dictate network destinations must undergo rigorous sanitization to ensure they conform to expected protocols and target domains. However, in this instance, the software fails to enforce strict constraints on the host component or the scheme of the provided URL. This oversight allows an authenticated attacker who has access to the indexing API to inject arbitrary Uniform Resource Locators that point toward internal network resources rather than legitimate Amazon Simple Queue Service endpoints.
From a technical perspective, the flaw lies in the parsing logic responsible for handling the queue_url configuration. When a user submits a source definition containing a malicious URL, Quickwit proceeds to initiate connection attempts using this unvalidated address without verifying whether it resolves to an external public service or an internal private IP range. The application does not check if the scheme is strictly limited to https and if the host belongs to an allowed whitelist of AWS SQS domains. Consequently, the node acting as the client will attempt to establish network connections to any specified destination provided by the attacker. This behavior effectively turns the Quickwit indexer into a proxy or scanner that can be directed to probe internal infrastructure components such as databases, administrative panels, or other microservices residing within the same virtual private cloud or local network segment.
The operational impact of this vulnerability is significant, primarily enabling unauthorized network reconnaissance and potential data exfiltration through side-channel analysis. An attacker with write access to the indexing API can leverage this flaw to perform internal port scanning and service fingerprinting. By submitting a series of queue_urls pointing to different ports or services on internal hosts, the attacker can observe variations in connection response times, error messages, or HTTP status codes returned by the Quickwit node. These differences allow the attacker to determine which internal services are active, identify their versions based on specific handshake behaviors or error payloads, and map out the topology of the protected network environment. This capability is particularly dangerous because it bypasses traditional perimeter defenses that might otherwise restrict direct access from external users to internal assets.
This vulnerability aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF) flaws where a web application fetches a remote resource without validating the user-supplied URL. Furthermore, in terms of offensive security tactics, this behavior maps directly to ATT&CK technique T1560.001, Archive Collected Data via Local Archiving, and more specifically T1046 Network Service Discovery, as it facilitates the enumeration of services within a network segment. The ability to scan internal networks is often a precursor to further exploitation, such as exploiting known vulnerabilities in discovered services or using them for lateral movement if additional credentials are compromised.
To mitigate this risk, organizations running Quickwit versions prior to 0.9.1 must immediately upgrade to the patched release where input validation has been strengthened. For environments that cannot be upgraded instantly, network-level controls should be implemented to restrict outbound traffic from Quickwit nodes to only known and necessary external endpoints. This can be achieved through firewall rules or security group configurations that whitelist specific AWS SQS domain names and block access to private IP ranges such as 10.x.x.x, 172.16.x.x-172.31.x.x, and 192.168.x.x. Additionally, implementing strict API gateway policies or WAF rules that validate the structure of incoming requests can provide an additional layer of defense by rejecting malformed URLs before they reach the application logic. Regular security audits focusing on input validation practices are recommended to prevent similar SSRF vulnerabilities in other components of the system.