CVE-2026-63223: CodeIgniter4 is image/mime in upload validation bypass — unrestricted file upload leading to RCE

CodeIgniter4 versions before 4.7.4 validate file uploads with the is_image() and mime_in() rules (system/Validation/StrictRules/FileRules.php) using only the content-sniffed MIME type (finfo magic bytes). They never compare the client-supplied filename extension with the detected content type. An attacker can therefore upload a polyglot file whose first bytes are GIF89a (sniffed as image/gif) but whose body contains PHP code, named shell.php. Validation trusts the content (image ✔); the web server trusts the extension (.php → execute). This confused-deputy gap yields unrestricted file upload and remote code execution when the application saves the upload under the client filename into a web-accessible, PHP-enabled directory.

• Package/component: codeigniter4/framework — CodeIgniter\Validation\StrictRules\FileRules::is_image() and ::mime_in() (non-strict FileRules is an empty subclass, so both rule sets are affected).
• Affected versions: < 4.7.4 (reproduced on v4.7.3).
• Risk level: critical — unauthenticated remote code execution on any application that (1) validates uploads with is_image or mime_in without ext_in, (2) preserves the client filename on save, and (3) stores uploads in a web-accessible, PHP-enabled directory.

Impact Parity

• Disclosed/claimed maximum impact: code execution (unrestricted file upload → RCE).
• Reproduced impact from this run: code execution — a GIF89a+PHP polyglot uploaded as shell.php passed is_image validation on v4.7.3, was saved to public/uploads/shell.php, and an HTTP GET to /uploads/shell.php?cmd=... executed attacker-controlled commands (echo <unique marker> and id, returning uid=1000(vscode) ...) in 2/2 clean attempts.
• Parity: full.
• Not demonstrated: nothing — the claimed impact was reproduced end-to-end through the real HTTP boundary.

Root Cause

FileRules::is_image() (v4.7.3) checks uploaded[], then calls $file->getMimeType() (finfo content sniffing) and accepts the file if the detected type starts with image. mime_in() likewise compares only the sniffed type against an allow-list. Neither rule inspects $file->getClientExtension() / $file->getClientName(). Because a polyglot can simultaneously be valid GIF89a content and executable PHP source, the validator and the web server reach different conclusions about the same file:

• Fix (v4.7.4, release commit 67ead895b7491703e5e5bc17436778806192008f): adds hasInvalidImageClientExtension() to is_image() (reject non-empty client extensions that do not map to an image/* MIME type) and hasMismatchedClientExtension() to mime_in() (reject client extensions that do not match the extension guessed from the sniffed content), in system/Validation/StrictRules/FileRules.php.
• Note: the ticket names fixed commit b6e9a4fa. That hash is not present in the codeigniter4/framework distributable mirror (which receives squashed release commits from the codeigniter4/CodeIgniter4 development repo). The v4.7.4 release tag was verified to contain exactly the named fix helpers and was used as the fixed checkout; patch-anchor verification (helper absent in v4.7.3, present in v4.7.4) is enforced by the script on every run.

Reproduction Steps

1. bundle/repro/reproduction_steps.sh (self-contained; run twice consecutively, exit 0 both times).
2. The script:
   • Installs PHP CLI + extensions and Composer if absent.
   • Clones codeigniter4/framework into the prepared project cache (<project_cache_dir>/repo) or bundle/artifacts/framework as fallback.
   • Verifies the patch anchor (fix helper absent at v4.7.3 / present at the fixed ref).
   • Writes a real upload controller (app/Controllers/Upload.php) using the rule uploaded[userfile]|is_image[userfile] (no ext_in) that saves with the client filename into public/uploads/, plus a POST /upload route.
   • Builds a GIF89a+PHP polyglot (verified to sniff as image/gif) and a plain-text negative control.
   • Starts the real product server (php spark serve, PHP built-in web server bound to 127.0.0.1) and runs, for both v4.7.3 and the fixed ref:
     • Negative control: plain-text plain.php upload → rejected (rule active).
     • 2 clean vulnerable attempts: POST polyglot as shell.php, then GET /uploads/shell.php?cmd=echo <unique marker>;id.
     • 2 clean fixed attempts: same POST, then GET.
3. Expected evidence: v4.7.3 returns {"status":"saved"} and the GET response contains the unique per-attempt marker plus uid= output (and not the raw <?php source); the fixed build returns HTTP 400 {"status":"rejected"}, writes no file, and the GET returns 404.

Evidence

• Main log: bundle/logs/reproduction_steps.log.
• Per-attempt artifacts (listed in bundle/repro/runtime_manifest.json):
  • bundle/logs/repro/vuln_attempt{1,2}_upload.json → {"status":"saved","path":"uploads/shell.php"}
  • bundle/logs/repro/vuln_attempt{1,2}_shell_get.txt → e.g.

    GIF89a;
    RCE_1_1785590766_8732
    uid=1000(vscode) gid=1000(vscode) groups=1000(vscode)
    

  • bundle/logs/repro/fixed_attempt{1,2}_upload.json → {"status":"rejected","errors":{"userfile":"userfile is not a valid, uploaded image file."}} (HTTP 400), shell GET HTTP 404.
  • bundle/logs/repro/control_upload.json → plain-text upload rejected on the vulnerable build (proves is_image is enforced, not bypassed by harness misconfiguration).
  • bundle/logs/repro/service_{vuln,fixed,control}_*.log → php spark serve product server logs.
• Environment: Ubuntu 26.04, PHP 8.5.4 (cli, distro package), Composer 2.10.2, CodeIgniter v4.7.3 (ab9bf33) vulnerable vs v4.7.4 (67ead89) fixed; server = product CLI php spark serve (PHP built-in web server), which executes .php files under public/ exactly as a standard Apache/FPM deployment would for a PHP-enabled upload directory.

Recommendations / Next Steps

• Upgrade to CodeIgniter ≥ 4.7.4, which rejects uploads whose client filename extension is inconsistent with the sniffed content type.
• Defense in depth for applications regardless of framework version: always add ext_in (and max_size) to upload rules, never preserve client filenames ($file->getRandomName()), store uploads outside the webroot or behind a controller, and disable PHP execution in upload directories at the web-server layer.
• Testing: add regression tests that upload a GIF89a+PHP polyglot named shell.php and assert rejection under is_image/mime_in.

Additional Notes

• Idempotency: the script was run twice consecutively; both runs exited 0 with 2/2 vulnerable RCE attempts and 2/2 fixed rejections. It re-checkouts, re-applies the overlay, and removes public/uploads before every attempt, so it is safe to re-run.
• Edge cases/limitations: RCE requires the three deployment preconditions listed above (validation without ext_in, client filename preserved, web-accessible PHP-enabled upload dir). The proof uses php spark serve (the framework's documented development server built on PHP's web server); any deployment that executes .php under the upload directory (Apache mod_php, PHP-FPM with typical location rules) exhibits the same behavior. If uploads are stored outside the docroot or PHP is disabled there, the validation bypass still occurs (file is accepted) but code execution is not reachable — that is a deployment mitigation, not a fix.
• The named fixed commit b6e9a4fa could not be resolved in the codeigniter4/framework mirror; the v4.7.4 tag contains the exact helpers described in the advisory and was used with patch-anchor verification.