CodeIgniter is a PHP full-stack web framework.

CVE-2026-63223 affects CodeIgniter 4 prior to version 4.7.4. The framework's is_image and mime_in upload validation rules classify a file solely by its content-derived MIME type (e.g., inspecting magic bytes). An attacker can prepend valid image magic bytes (GIF89a, PNG header, JFIF) to a PHP webshell, name it shell.php, and pass both is_image and mime_in validation. If the application then saves the file using the client-supplied filename via $file->move($path) into a web-accessible, script-enabled directory, the attacker requests /uploads/shell.php and achieves unauthenticated remote code execution. All CodeIgniter 4.x versions before 4.7.4 are affected.

The vendor assigned CVSS 9.8 CRITICAL, which models the theoretical worst case — unauthenticated, network-accessible, low-complexity. That score is defensible as a ceiling but overstates the median real-world deployment. Exploitation requires a specific compound of application-level coding patterns: the app must accept uploads, validate *only* with is_image/mime_in (no independent extension check), preserve the original client filename on disk, store into a web-accessible directory, and allow PHP execution from that directory. Each condition narrows the exploitable population. Many CodeIgniter applications already use $file->getRandomName(), store uploads outside the webroot, or gate uploads behind authentication. The vendor's 9.8 treats all of these as absent; real deployments rarely line up that perfectly.

Why this verdict

• Compound preconditions narrow the exploitable population. The chain requires four independent application-level choices to align: upload endpoint exists, no extension check, client filename preserved, PHP execution enabled in upload directory. Each condition roughly halves the eligible target set, compounding to a small fraction of CI4 deployments.
• No authentication requirement is assumed, not guaranteed. The CVSS vector sets PR:N, but many real upload endpoints sit behind login walls, session checks, or CSRF tokens. The vector overstates the unauthenticated attack surface.
• Role multiplier: CodeIgniter is a general-purpose web application framework. (a) *Low-value role:* dev/staging instances — minimal blast radius. (b) *Typical role:* line-of-business web apps — compromise yields one application's data and host-level access as www-data. (c) *High-value role:* a CI4 app serving as an internal admin panel or customer portal with access to databases holding PII/financial data. In this case the blast radius is tenant-to-host, potentially reaching database credentials and lateral movement. However, CI4 is NOT canonically a high-value-role component (it is not a DC, hypervisor, IdP, PAM, backup server, or network edge appliance). The fraction of CI4 installs in high-value roles is modest (<10%). The floor is therefore HIGH, not CRITICAL.
• Polyglot payloads are trivial to construct. GIF89a+PHP webshells are commodity knowledge. No exploit development skill is required, lowering the attacker-capability bar significantly.
• Patch is same-day. The fix (4.7.4) shipped concurrently with disclosure, giving defenders a clear remediation path and reducing the window of exposure for teams that act quickly.

Why not higher?

CRITICAL would require either active exploitation (KEV/campaign evidence), a canonical high-value-role component, or a condition-free attack path. None apply here. The vulnerability requires multiple application-coding decisions to align, and CodeIgniter is a general-purpose web framework — not an identity provider, hypervisor, or network edge device. The exploitable subset of the installed base is meaningfully smaller than the total.

Why not lower?

MEDIUM would understate the risk because when the preconditions DO align, the outcome is unauthenticated RCE — the most severe impact class. The polyglot technique is trivial, no exploit development is needed, and the pattern (upload + execute) is one of the most commonly targeted by automated scanners and botnets. A single vulnerable instance discovered by a scanner leads directly to host compromise with no further interaction.

1. Store uploads outside the web root or on object storage — Move upload targets to a non-web-accessible path (e.g., /var/lib/app/uploads/) or use S3/GCS with signed URLs. This completely breaks step 5 of the attack chain. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity.
2. Randomize filenames on save — Replace $file->move($path) with $file->move($path, $file->getRandomName()) or use $file->store(). This strips the .php extension and prevents direct execution even if stored in the webroot. A code-level change deployable in a hotfix.
3. Disable script execution in upload directories — Add php_flag engine off in .htaccess (Apache) or a location block returning 403 for .php in nginx upload paths. This is a server-config change that requires no application code modification.
4. Add explicit extension validation — Append ext_in[field,jpg,png,gif,webp] to your validation rules alongside is_image/mime_in. On 4.7.4+ this checks the client filename extension. On older versions, combine with a manual check: pathinfo($file->getClientName(), PATHINFO_EXTENSION).
5. Deploy WAF rules blocking PHP in upload payloads — Configure ModSecurity, Cloudflare WAF, or AWS WAF to inspect multipart upload bodies for PHP opening tags (<?php, <?=, <? ). This catches naive polyglots but can be bypassed with encoding.

Run this script on each CodeIgniter 4 application host as a user with read access to the Composer lock file. Invoke with: bash check_cve_2026_63223.sh /var/www/myapp where the argument is the application root directory. No elevated privileges required.

#!/usr/bin/env bash
# check_cve_2026_63223.sh — Detect CVE-2026-63223 in CodeIgniter 4
# Usage: bash check_cve_2026_63223.sh /path/to/ci4/app
set -euo pipefail

APP_ROOT="${1:-}"
if [ -z "$APP_ROOT" ]; then
  echo "Usage: $0 /path/to/ci4/app"
  exit 3
fi

LOCK_FILE="$APP_ROOT/composer.lock"
if [ ! -f "$LOCK_FILE" ]; then
  echo "UNKNOWN — composer.lock not found at $LOCK_FILE"
  exit 2
fi

# Extract codeigniter4/framework version from composer.lock
CI_VERSION=$(python3 -c "
import json, sys
with open('$LOCK_FILE') as f:
    data = json.load(f)
for pkg in data.get('packages', []) + data.get('packages-dev', []):
    if pkg['name'] == 'codeigniter4/framework':
        print(pkg['version'].lstrip('v'))
        sys.exit(0)
print('NOT_FOUND')
" 2>/dev/null || echo 'PARSE_ERROR')

if [ "$CI_VERSION" = "NOT_FOUND" ]; then
  echo "UNKNOWN — codeigniter4/framework not found in composer.lock"
  exit 2
fi

if [ "$CI_VERSION" = "PARSE_ERROR" ]; then
  echo "UNKNOWN — failed to parse composer.lock (python3 required)"
  exit 2
fi

echo "Detected codeigniter4/framework version: $CI_VERSION"

# Compare version — vulnerable if < 4.7.4
REQUIRED="4.7.4"
if python3 -c "
from packaging.version import Version
import sys
try:
    if Version('$CI_VERSION') < Version('$REQUIRED'):
        sys.exit(0)  # vulnerable
    else:
        sys.exit(1)  # patched
except Exception:
    # Fallback: simple string split comparison
    v = list(map(int, '$CI_VERSION'.split('.')[:3]))
    r = list(map(int, '$REQUIRED'.split('.')[:3]))
    sys.exit(0 if v < r else 1)
" 2>/dev/null; then
  echo "VULNERABLE — codeigniter4/framework $CI_VERSION is below $REQUIRED (CVE-2026-63223)"
  exit 1
else
  echo "PATCHED — codeigniter4/framework $CI_VERSION >= $REQUIRED"
  exit 0
fi

Sources

1. GHSA-mmj4-63m4-r6h5 — CodeIgniter4 Security Advisory
2. CodeIgniter4 Security Advisories
3. CVE-2026-48062 — ext_in Bypass (GitLab Advisory)
4. GitHub Issue #3184 — is_image validation vulnerability
5. CodeIgniter Market Share — Enlyft
6. CWE-434: Unrestricted Upload of File with Dangerous Type
7. CodeIgniter4 on CVE Details