Listen to this Post
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.
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.
The vulnerability exists because the eKuiper server does not validate or restrict outbound HTTP requests made via external service registrations. When an attacker registers a service with an internal or loopback address and then invokes it through a rule, the server blindly makes the request to that address, treating it as a legitimate external service call.
The attack requires the attacker to have permissions to register external services or create rules within eKuiper. This is typically achievable through the management API or CLI if proper access controls are not enforced.
Once the malicious service is registered, the attacker can craft SQL-like queries using service functions (e.g., tsschemaless) to trigger HTTP requests to internal endpoints. The responses from these internal services can then be routed to external sinks or inspected, potentially exposing sensitive data.
This SSRF vector can be used to scan internal network topologies, access cloud metadata services (e.g., 169.254.169.254), interact with internal APIs, or retrieve credentials stored in internal services.
The vulnerability affects all eKuiper versions prior to 2.4.0. The fix was introduced in v2.4.0 with the `httpx.GetSSRFDialContext` function, which blocks requests to private, loopback, link-local, multicast, and unspecified IP addresses by default.
DailyCVE Form:
Platform: eKuiper
Version: < 2.4.0
Vulnerability: SSRF
Severity: Moderate
date: 2025-07-03
Prediction: Already Patched
What Undercode Say:
Analytics:
- SSRF protection (
httpx.GetSSRFDialContext) enabled by default in v2.4.0
– `basic.enablePrivateNet` defaults to `false` blocking private network access - Requests to private, loopback, link-local, multicast, and unspecified IPs are blocked
- Cloud metadata endpoints (169.254.169.254) are blocked by egress filtering
Bash commands and codes related to the blog
Check eKuiper version
bin/kuiper --version
List registered external services (audit)
curl -X GET http://localhost:9081/services
or
bin/kuiper show services
Example malicious service registration (PoC)
curl -X POST http://localhost:9081/services \
-H "Content-Type: application/json" \
-d '{
"interfaces": {
"tsschemaless": {
"address": "http://127.0.0.1:9081",
"protocol": "rest",
"options": {
"insecureSkipVerify": true,
"headers": {
"Accept-Charset": "utf-8"
}
},
"schemaless": true
}
}
}'
Example rule invoking the service
SELECT tsschemaless("get", "/metadata/sources/yaml/mqtt", ) FROM demo;
Upgrade to patched version
For Docker:
docker pull lfedge/ekuiper:2.4.0
For binary installation:
Download and install eKuiper >= 2.4.0 from https://github.com/lf-edge/ekuiper/releases
Exploit: (Educational Purposes!)
- Attacker registers external service pointing to internal address (e.g., http://127.0.0.1:9081 or cloud metadata endpoint)
- Attacker creates a rule invoking the service function (e.g.,
SELECT tsschemaless("get", "/internal/api", ) FROM demo) - When data flows through the stream, eKuiper makes an HTTP request to the internal address
- Response from internal service is retrieved and can be routed to an external sink or inspected
Protection:
- Upgrade to eKuiper >= 2.4.0 (SSRF protection enabled by default)
- Restrict Management API access using firewalls, reverse proxies, and authentication
- Implement egress network filtering (iptables/container isolation) to block private subnets and loopback
- Regularly audit registered external services (
GET /servicesorbin/kuiper show services) - Set `basic.enablePrivateNet: false` in kuiper.yaml (default in v2.4.0+)
- If internal communication is required, explicitly opt in with `basic.enablePrivateNet: true` and ensure API is protected
Impact:
- Unauthorized access to internal network services and APIs
- Probing of internal network topology and service enumeration
- Leakage of sensitive information (internal endpoints, credentials, cloud metadata)
- Potential interaction with internal APIs accessible to the eKuiper host
- Cloud metadata endpoint exposure (169.254.169.254)
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
