Is there a public PoC exploit available for CVE-2026-5417?

Yes, a public proof-of-concept exploit is available for CVE-2026-5417. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-5417?

Yes, a patch is available for CVE-2026-5417. Update the affected software to the latest version immediately.

Dataease CVE-2026-5417

Q: What is the CVSS score of CVE-2026-5417?

CVE-2026-5417 has a CVSS 4.0 base score of 2.0 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-18515 LOW

Server-Side Request Forgery (SSRF) (CWE-918)

2026-04-02 VulDB

GHSA-2v29-2pv7-f546

SSRF Elastic Dataease Sqlbot

2.0

CVSS 4.0 · Vendor: VulDB

Severity by source

Vendor (VulDB) PRIMARY

2.0 LOW

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (VulDB) · only source for this CVE.

CVSS VectorVendor: VulDB

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Lifecycle Timeline

Severity Changed

Apr 29, 2026 - 01:11 NVD

MEDIUM LOW

CVSS changed

Apr 29, 2026 - 01:11 NVD

5.1 (MEDIUM) 2.0 (LOW)

PoC Detected

Apr 03, 2026 - 16:10 vuln.today

Public exploit code

EUVD ID Assigned

Apr 02, 2026 - 19:01 euvd

EUVD-2026-18515

Analysis Generated

Apr 02, 2026 - 19:01 vuln.today

Patch released

Apr 02, 2026 - 19:01 nvd

Patch available

CVE Published

Apr 02, 2026 - 18:15 nvd

MEDIUM 5.1

DescriptionCVE.org

A vulnerability was determined in Dataease SQLbot up to 1.6.0. This issue affects the function get_es_data_by_http of the file backend/apps/db/es_engine.py of the component Elasticsearch Handler. This manipulation of the argument address causes server-side request forgery. The attack may be initiated remotely. The exploit has been publicly disclosed and may be utilized. Upgrading to version 1.7.0 is capable of addressing this issue. You should upgrade the affected component. The vendor was contacted early about this disclosure.

AnalysisAI

Server-side request forgery (SSRF) in Dataease SQLBot up to version 1.6.0 allows high-privileged remote attackers to manipulate the 'address' argument in the Elasticsearch Handler component (get_es_data_by_http function), enabling unauthorized HTTP requests to internal or external systems. The vulnerability has publicly available exploit code and vendor-released patch version 1.7.0 addresses the issue.

Technical ContextAI

The vulnerability exists in the Elasticsearch Handler component of Dataease SQLBot, specifically in the get_es_data_by_http function located at backend/apps/db/es_engine.py. This function handles HTTP communication with Elasticsearch clusters but fails to properly validate the 'address' parameter before using it in server-side HTTP requests. CWE-918 (Server-Side Request Forgery) indicates the root cause is inadequate input validation on user-controlled URLs, allowing attackers to craft malicious address parameters that force the server to make unintended HTTP requests to arbitrary internal or external targets. The Elasticsearch integration component is designed to facilitate data queries but becomes a vector for SSRF when address validation is insufficient.

RemediationAI

Vendor-released patch: upgrade to Dataease SQLBot version 1.7.0 or later. Organizations running SQLBot 1.6.0 or earlier should prioritize this upgrade, particularly if the deployment has high-privilege user accounts or operates in network segments with sensitive internal systems. The patch is available at https://github.com/dataease/SQLBot/releases/tag/v1.7.0. Pending upgrade, restrict network access to the SQLBot instance using firewall rules to limit outbound HTTP/HTTPS requests to known and necessary Elasticsearch endpoints, and audit Elasticsearch Handler logs for suspicious address parameters. Apply principle of least privilege by restricting high-privilege account creation and access to the affected component.