github.com/lf-edge/ekuiper/v2

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

eKuiper API endpoints handling SQL queries with user-controlled table names. in github.com/lf-edge/ekuiper

LF Edge eKuiper vulnerable to File Path Traversal leading to file replacement in github.com/lf-edge/ekuiper

eKuiper /config/uploads API arbitrary file writing may lead to RCE in github.com/lf-edge/ekuiper

Summary

A path traversal vulnerability in eKuiper's administrative management endpoints allows privileged users or attackers with access to management APIs to delete arbitrary files or directories on the host system.

Details

In internal/plugin/native/manager.go, the plugin installation endpoint (POST /plugins/*) constructs a temporary directory path by directly joining user-supplied resource names (name) without sufficient sanitization. Supplying path traversal sequences (such as ../../...) causes the deferred cleanup operation (os.RemoveAll) to target arbitrary directories outside the intended plugin directory.

A related issue in configuration and rule lifecycle management where unvalidated rule identifiers could influence file deletion paths was also addressed by introducing unified identifier and file name validation.

PoC

1. Target file deletion via plugin installation endpoint:

POST /plugins/sources HTTP/1.1
Host: 127.0.0.1:9081
Content-Type: application/json

{
  "name": "../../../../../tmp/target.txt",
  "file": "http://example.com/plugin.zip",
  "shellParas": [],
  "functions": []
}

2. When the request finishes, /tmp/target.txt is removed by os.RemoveAll.

Impact

An attacker with access to eKuiper management APIs can cause arbitrary file or directory deletion, potentially leading to denial of service or disruption of the host environment. This vulnerability provides a delete-only capability and does not permit arbitrary file creation, modification, or code execution.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.1: Input validation (validate.ValidateID) and file path validation (path.VerifyFileName) have been enforced across management endpoints.

Workarounds

• Restrict network access to eKuiper management port (9081) via authentication, reverse proxies, and firewall rules.
• Run eKuiper with a dedicated non-root user account to limit file system deletion permissions.

Credits

• @kosmosec
• @arpitjain099

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
    }
  }
}

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 KUIPER__BASIC__ENABLEPRIVATENET=true). Ensure eKuiper's API is protected before enabling this setting.

Reported by Alexey Kosmachev, Bi.Zone

Summary

A Cross-Site Scripting (XSS) vulnerability in external service creation allows an authenticated attacker to inject HTML/script payloads into external service names, which may execute in a user's browser when rendered by administrative web interfaces.

Details

Prior to v2.4.0, external service registration endpoints did not strictly enforce alphanumeric character restrictions on service names. An operator or attacker with API access could register a service using a crafted name containing HTML elements (such as <iframe src="...">). If an administrative web UI rendered the unescaped service name, arbitrary script execution could occur in the context of the user's browser session.

PoC

1. Create an external service JSON definition with a filename containing an XSS payload, e.g. <iframe src="javascript:alert1337">.json inside a ZIP archive.
2. In external service creation, upload the ZIP and provide the matching service name: <iframe src="javascript:alert1337">.
3. Upon service registration, the unescaped name executes when rendered in the UI context.

Impact

Self-XSS / Stored XSS leading to potential session token leakage or unauthorized actions in the context of the affected user's browser session.

Remediation & Patches

• Upgrade to eKuiper >= 2.4.0: Strict alphanumeric identifier validation (validate.ValidateID) is now enforced on all external service creation and update endpoints, rejecting invalid characters.

Workarounds

• Protect eKuiper management endpoints (POST /services) with authentication and network-level firewalls.

Credits

• Reported by Alexey Kosmachev, Bi.Zone (@TheMostKnown)

LF Edge eKuiper is vulnerable to Arbitrary File Read/Write via unsanitized names and zip extraction in github.com/lf-edge/ekuiper

eKuiper API endpoints handling SQL queries with user-controlled table names. in github.com/lf-edge/ekuiper