Vulnerability Database

383,304

Total vulnerabilities in the database

CVE-2025-24979 — github.com/lf-edge/ekuiper/v2

Server-Side Request Forgery (SSRF)

Summary

Server-side request forgery (SSRF) vulnerability in eKuiper allows an attacker with permissions to register external services or create rules to induce the eKuiper server to make requests to unintended network locations, such as internal services, loopback interfaces (localhost), or cloud metadata endpoints.

Details

Prior to v2.4.0, eKuiper external service registrations and HTTP invocations did not validate destination IP addresses. An attacker with access to the eKuiper management API could register an external service pointing to an internal address (such as http://127.0.0.1:9081 or other internal network services) and trigger queries using service functions (e.g. SELECT tsschemaless(...) FROM demo). This allows probing internal networks, leaking sensitive information (such as internal endpoints/credentials), or interacting with internal APIs accessible to the eKuiper host.

PoC

  1. Create an external service with an address pointing to an internal network / localhost:
{ "interfaces": { "tsschemaless": { "address": "http://127.0.0.1:9081", "protocol": "rest", "options": { "insecureSkipVerify": true, "headers": { "Accept-Charset": "utf-8" } }, "schemaless": true } } }
  1. Load it to eKuiper and create a rule invoking it, e.g.: SELECT tsschemaless("get", "/metadata/sources/yaml/mqtt", *) FROM demo.
  2. Run the rule. When data flows through the stream, the response from the internal service is retrieved and can be routed to an external sink or inspected.

Impact

Server-Side Request Forgery (SSRF) allowing unauthorized access / probing of internal network services.

Remediation & Patches

  • Upgrade to eKuiper >= 2.4.0: Starting with v2.4.0, SSRF protection (httpx.GetSSRFDialContext) is enabled by default across HTTP clients, blocking requests to private, loopback, link-local, multicast, and unspecified IP addresses.

Workarounds (for versions < 2.4.0)

If unable to upgrade immediately:

  1. Restrict Management API Access: Restrict access to the eKuiper REST API (port 9081) and CLI using network firewalls, reverse proxies, and authentication so only trusted administrators can create or update services and rules.
  2. Egress Network Filtering: Use firewall / iptables rules or container network isolation to block outbound requests from eKuiper to private subnets, loopback addresses, and cloud metadata endpoints (169.254.169.254).
  3. Audit Service Definitions: Regularly review registered external services (GET /services or bin/kuiper show services) to verify target hosts.

Notes for Users Upgrading to >= 2.4.0

  • In v2.4.0 and later, basic.enablePrivateNet in kuiper.yaml defaults to false (blocking private network access).
  • If a developer's deployment legitimately requires eKuiper to communicate with internal REST services or private networks, they can explicitly opt in by setting basic.enablePrivateNet: true (or via environment variable KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

CVSS v3:

  • Severity: Medium
  • Score: 5.5
  • AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N

CWEs:

Software Affected versions
Go icon github.com/lf-edge/ekuiper/v2 < 2.4.0

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.