Kestra EUVD-2026-39917

Exploitation requires that the attacker first obtains READ access to the PostgreSQL database backing Kestra in order to retrieve the stored administrator SHA-512 password hash - this is the explicit, concrete prerequisite. The full privilege-escalation impact additionally requires a Kubernetes deployment, where a cracked admin login can read the cluster ServiceAccount token and K8s Secrets; in non-Kubernetes deployments the outcome is limited to Kestra admin takeover. Limiting factors: the attacker must already have database read access (a meaningful prior-compromise hurdle, reflected in CVSS AC:H), the admin password must be weak enough to be recovered offline against fast SHA-512, and only versions prior to 1.3.24 are affected. Despite the CVSS PR:N marking, this is not remote-unauthenticated exploitation against a default install - the database-access precondition gates the entire chain.

The signals are mixed and the headline CVSS of 8.7 likely overstates standalone risk. The NVD vector (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N) records PR:N, but the description makes clear the real precondition is that the attacker has already gained READ ACCESS to the PostgreSQL database - a substantial prior compromise, which is consistent with the AC:H rating. CVSS indicates a network vector with no privileges, yet the description implies the attacker must already reach the database - verify framing with vendor. This is therefore largely a post-compromise privilege-escalation and defense-in-depth weakness rather than a remotely reachable unauthenticated flaw against a default install. The scope change (S:C) is justified because, in Kubernetes, success pivots from the application into the cluster (ServiceAccount token, all Secrets). There is no public exploit identified at time of analysis and no KEV listing, and no EPSS score was supplied, so there is no evidence of active or widespread exploitation. Practical severity is highest specifically in Kubernetes deployments where a cracked admin password yields cluster Secrets; in non-K8s deployments impact is confined to Kestra admin takeover.

An attacker who has already compromised a read-only path to Kestra's PostgreSQL backend (e.g., via a misconfigured database account, a backup, or an adjacent service) dumps the admin credential and runs an offline GPU cracking session against the fast SHA-512 hash. Once the password is recovered they authenticate to Kestra as administrator and, in a Kubernetes deployment, read the pod's ServiceAccount token and all accessible K8s Secrets to pivot deeper into the cluster. No public exploit code has been identified, and the high attack complexity reflects the required prior database access.