Introduction
A SQL injection flaw in Kestra's flow search API escalates directly to remote code execution on the host operating system, earning a CVSS score of 9.9. For any organization running Kestra's default docker compose deployment, an authenticated user clicking a single crafted link is all it takes for an attacker to gain OS level command execution on the database host.
Kestra is an open source, event driven orchestration platform designed to automate scheduled and event driven workflows across data, AI, and infrastructure domains. The platform has seen rapid enterprise adoption, executing over 2 billion workflows in 2025 and reporting a 25x increase in enterprise revenue over 18 months. Backed by $36M in total funding, Kestra occupies a growing niche in the workflow orchestration space, making its security posture relevant to a broad set of organizations.
Technical Information
Root Cause
CVE-2026-34612 is classified under CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). The vulnerability exists in the GET /api/v1/main/flows/search endpoint. User supplied input to this endpoint is incorporated into a SQL query without adequate sanitization or parameterization, allowing an attacker to inject arbitrary SQL statements.
The PostgreSQL Escalation Path
What makes this vulnerability particularly severe is the execution mechanism. Rather than being limited to data extraction or manipulation, the injected SQL payload leverages PostgreSQL's COPY ... TO PROGRAM ... functionality. This is a well known PostgreSQL feature that allows the database to pipe query output to an operating system command. In a legitimate context, this is used for tasks like exporting data to external tools. In an exploitation context, it provides a direct bridge from SQL injection to arbitrary OS command execution on the host where PostgreSQL is running.
Because the default docker compose deployment is explicitly noted as vulnerable, organizations that followed the standard setup documentation are exposed without any additional misconfiguration required.
Attack Flow
Based on the available advisory details, the exploitation sequence proceeds as follows:
-
Authentication: The attacker must first obtain valid credentials for the Kestra platform. This could be through credential theft, brute force, or by leveraging a legitimate but low privilege account.
-
Payload Delivery: The attacker crafts a malicious URL targeting the
GET /api/v1/main/flows/searchendpoint. The URL contains SQL injection payloads embedded in one or more query parameters used by the search functionality. -
Trigger: The crafted link is visited by an authenticated user. This could be the attacker themselves if they have credentials, or a legitimate user tricked via phishing or social engineering into clicking the link.
-
SQL Injection: The Kestra backend processes the request and passes the unsanitized input into a SQL query executed against the PostgreSQL database.
-
OS Command Execution: The injected SQL uses
COPY ... TO PROGRAM ...to instruct PostgreSQL to execute an arbitrary operating system command on the host. At this point, the attacker has achieved remote code execution with the privileges of the PostgreSQL process.
The commit message associated with the fix references "SQL injection vulnerabilities in label search," which provides additional context about where in the search functionality the injection point exists.
Impact
The blast radius of this vulnerability is significant. Successful exploitation grants the attacker the ability to run arbitrary commands on the host system. From there, standard post exploitation activities become possible: establishing persistence, lateral movement within the network, data exfiltration, or deploying additional payloads. The fact that this targets an orchestration platform, which by design has connectivity to numerous downstream systems and services, amplifies the potential impact considerably.
Affected Systems and Versions
The vulnerability affects Kestra deployments with the following characteristics:
- Versions: All versions prior to 1.3.7
- Deployment configuration: Default docker compose deployments are explicitly confirmed as vulnerable
- Database backend: PostgreSQL (required for the
COPY ... TO PROGRAM ...escalation path) - Fixed version: 1.3.7
Organizations should verify both their Kestra version and their deployment method. The fix is available in version 1.3.7.
Vendor Security History
A review of Kestra's GitHub security advisories reveals a pattern of input validation issues, particularly concentrated in early 2026:
| Advisory | Vulnerability Type | Severity | Date |
|---|---|---|---|
| GHSA-365w-2m69-mp9x | Remote Code Execution via SQL Injection | Critical | March 30, 2026 |
| GHSA-v2mc-8q95-g7hp | Stored Cross Site Scripting via Flow YAML Fields | High | March 23, 2026 |
| GHSA-r36c-83hm-pc8j | Stored Cross Site Scripting in Markdown File Preview | High | March 3, 2026 |
| GHSA-qpj4-4r6r-wvf4 | Stored XSS in Kestra below 0.22 | Moderate | July 7, 2025 |
Three advisories in a single month, all related to insufficient input handling, suggest a systemic gap in input validation practices across the codebase. Organizations using Kestra should factor this track record into their risk assessments and maintain an aggressive patching cadence for this platform.
