GHSA-PQQC-8V73-9GG2
Vulnerability from github – Published: 2026-09-09 17:56 – Updated: 2026-09-09 17:56Summary
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
- 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
}
}
}
- Load it to eKuiper and create a rule invoking it, e.g.:
SELECT tsschemaless("get", "/metadata/sources/yaml/mqtt", *) FROM demo. - 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.enablePrivateNetinkuiper.yamldefaults tofalse(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 variableKUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.
Reported by Alexey Kosmachev, Bi.Zone
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lf-edge/ekuiper/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24979"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-09T17:56:32Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nServer-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.\n\n### Details\nPrior 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.\n\n### PoC\n1. Create an external service with an address pointing to an internal network / localhost:\n\n```json\n{\n \"interfaces\": {\n \"tsschemaless\": {\n \"address\": \"http://127.0.0.1:9081\",\n \"protocol\": \"rest\",\n \"options\": {\n \"insecureSkipVerify\": true,\n \"headers\": {\n \"Accept-Charset\": \"utf-8\"\n }\n },\n \"schemaless\": true\n }\n }\n}\n```\n2. Load it to eKuiper and create a rule invoking it, e.g.: `SELECT tsschemaless(\"get\", \"/metadata/sources/yaml/mqtt\", *) FROM demo`.\n3. 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.\n\n### Impact\nServer-Side Request Forgery (SSRF) allowing unauthorized access / probing of internal network services.\n\n### Remediation \u0026 Patches\n- **Upgrade to eKuiper \u003e= 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.\n\n### Workarounds (for versions \u003c 2.4.0)\nIf unable to upgrade immediately:\n1. **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.\n2. **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`).\n3. **Audit Service Definitions**: Regularly review registered external services (`GET /services` or `bin/kuiper show services`) to verify target hosts.\n\n### Notes for Users Upgrading to \u003e= 2.4.0\n- In v2.4.0 and later, `basic.enablePrivateNet` in `kuiper.yaml` defaults to `false` (blocking private network access).\n- If a developer\u0027s 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\u0027s API is protected before enabling this setting.\n\nReported by Alexey Kosmachev, Bi.Zone",
"id": "GHSA-pqqc-8v73-9gg2",
"modified": "2026-09-09T17:56:32Z",
"published": "2026-09-09T17:56:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lf-edge/ekuiper/security/advisories/GHSA-pqqc-8v73-9gg2"
},
{
"type": "PACKAGE",
"url": "https://github.com/lf-edge/ekuiper"
},
{
"type": "WEB",
"url": "https://github.com/lf-edge/ekuiper/releases/tag/v2.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "LF Edge eKuiper: SSRF in External Service"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.