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.

Affected: Maven: io.kestra:core, Maven: io.kestra:kestra-core

### 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:** ```bash docker run -d --name kestra-ssrf -p 8080:8080 kestra/kestra:latest server local sleep 30 ```

**Step 1: Create malicious Flow YAML** ```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/me…