CVE-2025-24979: 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:
json { "interfaces": { "tsschemaless": { "address": "http://127.0.0.1:9081", "protocol": "rest", "options": { "insecureSkipVerify": true, "headers": { "Accept-Charset": "utf-8" } }, "schemaless": true } } } 2. Load it to eKuiper and create a rule invoking it, e.g.: SELECT tsschemaless("get", "/metadata/sources/yaml/mqtt", ) FROM demo. 3. 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 KUIPERBASICENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.
Reported by Alexey Kosmachev, Bi.Zone
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/lf-edge/ekuiper/v2to a version that resolves this vulnerability.Fixed in 2.4.0 - Upgrade
Upgrade
eKuiperto a version that resolves this vulnerability.Fixed in >= 2.4.0 - Configuration
In kuiper.yaml, ensure basic.enablePrivateNet is set to false (or do not enable it) to keep SSRF protection enabled by default in v2.4.0 and later.
eKuiper (basic) basic.enablePrivateNet = false - Configuration
Only if the deployment requires eKuiper to communicate with internal REST/private networks, explicitly opt in by setting basic.enablePrivateNet: true (or KUIPER__BASIC__ENABLEPRIVATENET=true). Otherwise leave it disabled.
eKuiper (basic) basic.enablePrivateNet = true - Compensating control
Restrict access to the eKuiper management API (port 9081) and CLI using network firewalls, reverse proxies, and authentication so only trusted administrators can create or update services and rules.
- Compensating control
Use firewall/iptables rules or container network isolation to block eKuiper outbound requests to private subnets, loopback addresses, and cloud metadata endpoints (169.254.169.254).
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs access to the eKuiper management API and permissions to register external services or create rules. It is not exploitable by an unauthenticated user based on the provided information.
Which deployments are affected?
eKuiper versions before v2.4.0 are affected because external-service registrations and HTTP invocations did not validate destination IP addresses. The provided information does not state whether any particular default configuration exposes the required management API permissions.
How can I identify potentially unsafe existing configurations?
Review external-service registrations for addresses targeting loopback, internal-network, or cloud metadata endpoints, such as 127.0.0.1. Also review rules that invoke service functions, since those rules can trigger requests through registered external services.
What should be done to remediate the issue?
Upgrade to eKuiper v2.4.0 or later, where destination IP validation is present. Until upgraded, restrict management API access and limit permissions to create rules or register external services to trusted administrators.