A critical SQL injection vulnerability in Kestra, the open-source event-driven orchestration platform, allows authenticated attackers to achieve remote code execution on the underlying Docker host. Tracked as CVE-2026-34612 with a CVSS score of 9.9, the flaw affects all Kestra deployments prior to version 1.3.7 that use the default docker-compose setup with PostgreSQL.

The advisory was published on April 3, 2026. If you run Kestra in production with the default Docker Compose configuration, treat this as a drop-everything patch.

What Happened

Security researchers discovered that the GET /api/v1/main/flows/search endpoint in Kestra fails to sanitize user-supplied input before passing it to the PostgreSQL backend. An authenticated user can inject arbitrary SQL into the search query, and because the default docker-compose deployment grants the Kestra database user sufficient privileges, the injected payload can leverage PostgreSQL’s COPY ... TO PROGRAM functionality to execute arbitrary operating system commands.

The critical detail: those commands don’t run inside the Kestra container. They execute on the PostgreSQL container, which in the default docker-compose setup shares the host’s network namespace and mounts host paths. The net result is arbitrary command execution on the host.

The Attack Chain

The exploitation path is straightforward:

  1. Authentication — The attacker needs a valid session on the Kestra instance. In many deployments, Kestra’s default configuration doesn’t enforce strong authentication, and some environments expose the UI without any auth at all.

  2. SQL Injection — A crafted request to /api/v1/main/flows/search injects SQL through an unsanitized parameter.

  3. PostgreSQL COPY TO PROGRAM — The injected SQL uses COPY ... TO PROGRAM to execute an OS command within the PostgreSQL process context. This is a well-known PostgreSQL primitive that converts SQL execution into shell command execution when the database user has sufficient privileges.

  4. Host Compromise — Because the default docker-compose.yml runs PostgreSQL with elevated privileges and shared resources, command execution escapes the container boundary and lands on the host.

A one-click variant also exists: an attacker can craft a URL that, when visited by an authenticated Kestra user, silently triggers the injection via the browser session. This makes the vulnerability exploitable through social engineering even if the attacker doesn’t have direct credentials.

Who’s Affected

Kestra is widely used for data pipeline orchestration, ETL workflows, CI/CD automation, and infrastructure scheduling. It competes in the same space as Apache Airflow, Prefect, and Dagster. Organizations running Kestra versions prior to 1.3.7 with the default docker-compose PostgreSQL backend are vulnerable.

The severity is compounded by several factors:

  • Many Kestra deployments are internal tools with lax authentication requirements
  • The default docker-compose configuration ships with overprivileged database credentials
  • The COPY TO PROGRAM technique requires no special tooling — just a browser or curl
  • Host-level RCE means access to secrets, container orchestration sockets, and lateral movement opportunities

Technical Details

  • CVE: CVE-2026-34612
  • CVSS: 9.9 (Critical)
  • CWE: CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
  • Affected Versions: Kestra < 1.3.7
  • Fixed Version: Kestra 1.3.7
  • Attack Vector: Network (authenticated, but one-click via crafted URL)
  • Exploit Complexity: Low

What To Do Right Now

Patch immediately. Upgrade Kestra to version 1.3.7 or later. This is a self-hosted product, so you need to pull the new image and redeploy.

1
2
3

# If using docker-compose
docker-compose pull
docker-compose up -d

If you cannot patch immediately:

  • Restrict network access to the Kestra API. Do not expose /api/v1/ endpoints to untrusted networks.
  • Audit PostgreSQL privileges. The database user Kestra connects with should not have superuser or pg_execute_server_program privileges. Revoke COPY TO PROGRAM capability.
  • Enable authentication. If your Kestra instance runs without auth or with default credentials, fix that today.
  • Check for compromise. Review PostgreSQL logs for unusual COPY TO PROGRAM statements. Audit host-level process creation for anything spawned by the PostgreSQL process.

Broader Implications

This vulnerability highlights a persistent problem with default Docker Compose deployments: convenience configurations that ship with elevated privileges and minimal isolation. The COPY TO PROGRAM technique is not new — it has been a known PostgreSQL exploitation primitive for years. What makes CVE-2026-34612 dangerous is the combination of a trivially exploitable SQL injection with an overprivileged default deployment that turns database access into host access.

If you run any self-hosted platform with a PostgreSQL backend via Docker Compose, this is a good time to audit whether your database container runs with least privilege and whether your database user actually needs superuser capabilities. In most cases, it doesn’t.

References