Kestra EUVD-2026-57013

Exploitation requires that the attacker can import and execute a flow containing a http() Pebble template call against the target Kestra instance. Per the CVE description, this is achievable by an unauthenticated attacker - meaning the Kestra API endpoint for flow creation or import must be accessible without authentication. This is the single most important condition to verify per deployment: Kestra instances with authentication enforced at the API layer require valid credentials before a flow can be submitted, which materially constrains the attacker pool. No non-default Kestra configuration, plugin, or feature flag is required - the http() function is a built-in Pebble extension present in default Kestra installations prior to 2.0.0. Exploitation is limited by: (1) network reachability to the Kestra API from the attacker's position, (2) whether the deployment permits unauthenticated flow submission (deployment-dependent), and (3) what internal services or cloud IMDS endpoints are network-reachable from the Kestra host's egress path.

The CVSS 3.1 score of 8.6 with vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N accurately characterizes the exploitation barrier: no authentication, no special preconditions, single network-reachable API call. The scope change is the critical amplifier - in cloud environments, the link-local IMDS endpoint at 169.254.169.254 vends short-lived IAM role credentials, meaning a successful SSRF can pivot into broad AWS/GCP/Azure privilege escalation far beyond Kestra's own blast radius. No EPSS score was included in the provided intelligence data, and the vulnerability is absent from the CISA KEV catalog, so there is no confirmed evidence of active exploitation. The primary real-world risk moderator is whether a given Kestra deployment truly permits unauthenticated flow import and execution - the PR:N metric is stated in the advisory but should be verified per deployment, since production instances with authentication enforced would require valid credentials as a prerequisite, materially reducing exploitability. The I:N and A:N metrics are consistent with pure SSRF: no write path or denial-of-service vector is introduced by the http() function alone.

An attacker with network access to a Kestra instance crafts a YAML or JSON flow definition that invokes the Pebble http() function with the URI http://169.254.169.254/latest/meta-data/iam/security-credentials/ and imports it via the Kestra flow API without credentials. Kestra's server-side HTTP client fetches the AWS IMDS endpoint, and the response - containing temporary IAM role credentials including access key, secret, and session token - is returned to the attacker through the flow execution output, enabling lateral movement and privilege escalation across the cloud environment. No public proof-of-concept code has been identified, but the attack requires only a standard HTTP client and a crafted flow definition.