CVE-2026-55069: Kestra Privilege Escalation Vulnerability

CVE-2026-55069 Overview

CVE-2026-55069 affects the Kestra open-source event-driven workflow orchestration platform in versions prior to 1.3.24. The vulnerability resides in the BasicAuth authentication component, which stores administrator credentials using SHA-512 hashing. An attacker with read access to the backing PostgreSQL database can exploit SHA-512's high computation speed to perform offline password cracking against the administrator hash. In Kubernetes deployments, recovering the administrator password enables access to the cluster ServiceAccount Token and all Kubernetes Secrets, resulting in vertical privilege escalation. The issue is tracked under [CWE-916] (Use of Password Hash With Insufficient Computational Effort) and is fixed in Kestra 1.3.24.

Critical Impact
Offline recovery of administrator credentials leads to full workflow orchestrator compromise and Kubernetes cluster-wide privilege escalation.

Affected Products

Kestra OSS versions prior to 1.3.24
Kestra deployments backed by PostgreSQL with BasicAuth enabled
Kubernetes-hosted Kestra instances with mounted ServiceAccount tokens and Secrets

Discovery Timeline

2026-06-26 - CVE-2026-55069 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-55069

Vulnerability Analysis

Kestra's BasicAuth component hashes administrator passwords using SHA-512, a fast general-purpose cryptographic hash function. SHA-512 is designed for throughput, not for password storage, and lacks the deliberate computational cost provided by adaptive key-derivation functions such as bcrypt, scrypt, Argon2, or PBKDF2. An attacker who obtains read access to the PostgreSQL database, whether through misconfigured network exposure, credential leakage, or a secondary vulnerability, can extract the stored hash. Standard GPU-accelerated cracking tools can then compute billions of SHA-512 candidate hashes per second, making offline recovery of weak or moderate-strength administrator passwords feasible within practical timeframes.

Root Cause

The root cause is the use of a computationally cheap hash function to protect authentication credentials. [CWE-916] describes this class of weakness: a hash algorithm suitable for data integrity is used where a slow, memory-hard function is required. The absence of algorithmic cost prevents the hash from resisting offline brute-force and dictionary attacks.

Attack Vector

An attacker first obtains read access to the PostgreSQL database that stores Kestra credentials. The attacker exports the SHA-512 administrator hash and runs an offline cracking campaign using tools such as hashcat or John the Ripper. Once the plaintext password is recovered, the attacker authenticates to the Kestra web interface as administrator. On Kubernetes deployments, the attacker then reads the mounted ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token and enumerates cluster Secrets, pivoting from application-tier compromise to cluster-tier control.

// No verified public exploit code is available for CVE-2026-55069.
// Refer to the vendor advisory GHSA-m727-pcjm-j28h for technical details.

Detection Methods for CVE-2026-55069

Indicators of Compromise

Unexpected read queries against Kestra credential tables in PostgreSQL originating from non-application hosts
Successful administrator logins to Kestra from unfamiliar source IP addresses or user agents
Anomalous Kubernetes API calls using the Kestra ServiceAccount token, particularly get/list operations against secrets resources
New or modified Kestra workflows that execute reconnaissance or data exfiltration steps

Detection Strategies

Audit PostgreSQL logs for SELECT statements referencing Kestra user or credential tables from unauthorized clients
Enable and review Kestra authentication logs for administrator sessions initiated outside expected maintenance windows
Correlate Kubernetes audit logs with Kestra pod identity to identify Secret enumeration performed via the mounted ServiceAccount token
Inventory Kestra deployments and confirm the running version is 1.3.24 or later

Monitoring Recommendations

Alert on direct database connections to the Kestra PostgreSQL instance from any source outside the application subnet
Monitor for Kubernetes secrets API access spikes attributable to workflow orchestrator pods
Track administrator role activity within Kestra and alert on privilege changes or credential resets

How to Mitigate CVE-2026-55069

Immediate Actions Required

Upgrade Kestra to version 1.3.24 or later, which replaces the weak hashing scheme in BasicAuth
Rotate all Kestra administrator passwords after upgrading, using long high-entropy values
Rotate the Kubernetes ServiceAccount token and any Secrets that may have been exposed to a compromised Kestra instance
Restrict PostgreSQL network access to only the Kestra application tier using firewall rules or network policies

Patch Information

The vulnerability is remediated in Kestra 1.3.24. See the Kestra GitHub Security Advisory GHSA-m727-pcjm-j28h for release details and upgrade guidance.

Workarounds

Front Kestra with an external identity provider or reverse-proxy authentication instead of relying on the built-in BasicAuth component
Apply strict database access controls and enforce TLS plus mutual authentication between Kestra and PostgreSQL
Scope the Kestra Kubernetes ServiceAccount to the minimum permissions required and disable automatic token mounting where not needed
Enforce long randomly generated administrator passwords to raise the offline cracking cost until patching is complete

bash

# Kubernetes: disable automatic ServiceAccount token mounting for Kestra pods
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kestra
  namespace: kestra
automountServiceAccountToken: false