CVE-2026-5417: Dataease SQLbot SSRF Vulnerability

CVE-2026-5417 Overview

CVE-2026-5417 is a Server-Side Request Forgery (SSRF) vulnerability affecting Dataease SQLbot versions up to and including 1.6.0. The flaw resides in the get_es_data_by_http function inside backend/apps/db/es_engine.py, which is part of the Elasticsearch Handler component. An authenticated attacker can manipulate the address argument to coerce the server into issuing arbitrary HTTP requests to attacker-chosen destinations. The exploit has been publicly disclosed. Dataease addressed the issue in SQLbot version 1.7.0. The weakness is categorized under CWE-918.

Critical Impact

Authenticated attackers can abuse the Elasticsearch handler to reach internal services, query cloud metadata endpoints, or pivot to systems otherwise unreachable from the public network.

Affected Products

• Dataease SQLbot versions up to and including 1.6.0
• Component: Elasticsearch Handler (backend/apps/db/es_engine.py)
• Function: get_es_data_by_http

Discovery Timeline

• 2026-04-02 - CVE-2026-5417 published to NVD
• 2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-5417

Vulnerability Analysis

The vulnerability exists in the SQLbot backend code responsible for proxying HTTP requests to Elasticsearch clusters. The get_es_data_by_http function accepts an address argument that is incorporated into an outbound HTTP request without sufficient validation. Because the destination is controlled by user-supplied input, an attacker can substitute any URL the SQLbot server can reach. The result is a classic SSRF condition where the server acts as an unwitting proxy for attacker-issued requests.

Exploitation requires authentication and high privileges, which limits the population of potential abusers. However, in multi-tenant or analyst-shared deployments, any user able to configure an Elasticsearch data source can trigger the request. The flaw is reachable over the network, and the public disclosure of the exploit increases the likelihood of opportunistic abuse.

Root Cause

The root cause is missing validation of the address parameter passed to the Elasticsearch HTTP fetch routine. The function trusts caller-supplied destination metadata and forwards requests without enforcing an allowlist of permissible hosts, port restrictions, or scheme constraints. No URL parsing logic prevents redirection to internal IP ranges, link-local addresses, or non-HTTP schemes that may be supported by underlying request libraries.

Attack Vector

An authenticated attacker with permission to define or modify an Elasticsearch data source submits a crafted address value pointing at an internal resource. The SQLbot server then issues an HTTP request to that target. Useful targets include cloud instance metadata services (for example 169.254.169.254), internal admin interfaces, and other backend services on the trusted network segment. Response data may be reflected to the attacker through the SQLbot interface, depending on how Elasticsearch responses are rendered.

No verified proof-of-concept code is referenced in the advisory. Refer to the Notion analysis of SQLbot SSRF and the VulDB vulnerability entry for additional technical context.

Detection Methods for CVE-2026-5417

Indicators of Compromise

• Outbound HTTP requests from the SQLbot server to internal RFC1918 ranges, link-local addresses such as 169.254.169.254, or localhost.
• Elasticsearch data source configurations containing non-Elasticsearch URLs, unusual ports, or unexpected hostnames.
• Anomalous spikes in egress traffic originating from the SQLbot application process.

Detection Strategies

• Inspect SQLbot application logs for invocations of get_es_data_by_http with address values that do not correspond to approved Elasticsearch endpoints.
• Deploy egress network monitoring to flag requests from SQLbot hosts to cloud metadata services and internal management interfaces.
• Audit data source creation and modification events to identify users supplying arbitrary URLs.

Monitoring Recommendations

• Forward SQLbot application and reverse proxy logs to a centralized analytics platform and alert on outbound connections to internal subnets.
• Track authenticated user activity for high-privilege accounts that configure Elasticsearch connectors.
• Correlate cloud provider audit logs for unexpected metadata API hits originating from the SQLbot workload identity.

How to Mitigate CVE-2026-5417

Immediate Actions Required

• Upgrade Dataease SQLbot to version 1.7.0 or later using the official release from the SQLBot v1.7.0 release page.
• Review existing Elasticsearch data source configurations and remove any entries with unexpected or internal addresses.
• Restrict the population of accounts authorized to create or modify data sources to a minimal set of trusted administrators.

Patch Information

Dataease released SQLbot version 1.7.0, which addresses the SSRF in the get_es_data_by_http function. Operators running version 1.6.0 or earlier should plan an upgrade as the primary remediation. Release artifacts are available on the official GitHub release page.

Workarounds

• Place the SQLbot server behind an egress proxy that enforces a strict allowlist of permitted Elasticsearch endpoints.
• Block outbound access from the SQLbot host to cloud metadata addresses such as 169.254.169.254 and to internal management subnets.
• Disable or limit the Elasticsearch handler feature for non-administrative users until the upgrade is applied.

# Example egress firewall rule to block metadata endpoint access from SQLbot host
iptables -A OUTPUT -d 169.254.169.254 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -p tcp -j DROP