CodeIgniter is a PHP full-stack web framework.

CVE-2026-63222 is a path traversal flaw in CodeIgniter 4 prior to version 4.7.4. When application code calls UploadedFile::move() without supplying a second argument (the target filename), the framework defaults to using the raw, unsanitized client-provided filename. An attacker can inject path traversal sequences like ../../public/shell.php into the filename field of a multipart upload, writing arbitrary content outside the intended upload directory. Because this is PHP, landing a .php file in a web-accessible path typically means immediate remote code execution.

The vendor's HIGH / 7.5 score is defensible at the framework level — unauthenticated, network-reachable, low complexity. However, it overstates real-world exposure because exploitation requires the application developer to have used the one-argument form of move(). Applications that explicitly pass a server-generated filename as the second argument are not affected. The CVSS vector also scores only Integrity impact (C:N/I:H/A:N), ignoring the practical RCE chain that follows arbitrary file write in PHP environments — so it simultaneously underrates the blast radius of a successful exploit while overrating the breadth of affected deployments.

Why this verdict

• Unauthenticated remote vector with low complexity — the CVSS base metrics (AV:N/AC:L/PR:N/UI:N) are accurate at the framework level; the vulnerable move() call does not validate filenames at all.
• Application-pattern prerequisite narrows exposure — only apps calling move($dir) without the second argument are affected. Developers who generate server-side filenames (a common best practice) are immune. This meaningfully reduces the reachable population below what a 7.5 implies.
• PHP file write = practical RCE — the vendor's Integrity-only scoring (C:N/A:N) understates the real blast radius. In PHP environments, arbitrary file write to a web-accessible path is functionally equivalent to full server compromise. This prevents a deeper downgrade.
• Role multiplier: CodeIgniter is a general-purpose PHP web framework, not a canonically high-value infrastructure component. Typical deployments are line-of-business web applications. The blast radius of a successful exploit is per-application/per-host, not fleet-scale or identity-scale. A compromised CI4 app does not directly yield domain admin, hypervisor access, or supply-chain pivot. This role profile does not trigger the HIGH/CRITICAL floor rule.

Why not higher?

The vulnerability cannot be upgraded to CRITICAL because it requires a specific application code pattern — not all CodeIgniter 4 installations are vulnerable by default. CodeIgniter is not a canonically high-value-role component (it's not an IdP, hypervisor, domain controller, or security agent), so the blast radius is limited to the individual application host. There is no evidence of active exploitation or public PoC weaponization as of disclosure day.

Why not lower?

Despite the code-pattern prerequisite, the vulnerability cannot be reduced to MEDIUM because when the pattern IS present, the attack is unauthenticated, remotely exploitable, requires no user interaction, and results in arbitrary file write that chains trivially to RCE in PHP. The traversal payload is dead simple to construct — no specialized tooling or deep target knowledge required. The absence of exploitation evidence reflects only that the CVE is hours old.

1. Audit application code for one-argument move() calls — Search your codebase for ->move( calls that pass only a directory argument without a filename. If found, add an explicit server-generated filename as the second argument immediately. This eliminates the vulnerability regardless of framework version. Do this within the noisgate mitigation SLA of 30 days for HIGH.
2. Upgrade to CodeIgniter 4.7.4 — Run composer update codeigniter4/framework to pull the patched version. The fix sanitizes the default filename when no second argument is provided. Target completion within the noisgate remediation SLA of 180 days, but prefer sooner given the trivial exploit path.
3. Disable PHP execution in upload directories — Configure your web server (Apache .htaccess with php_flag engine off, or nginx location block with deny all for .php) to prevent execution of any PHP files in upload directories. This breaks the RCE chain even if the file write succeeds.
4. Deploy WAF rule to strip path traversal from upload filenames — Add a WAF rule (ModSecurity, Cloudflare, AWS WAF) that blocks or sanitizes multipart upload requests where the filename field in Content-Disposition contains ../ or ..\ sequences. This provides defense-in-depth at the network edge.
5. Enable file integrity monitoring on webroot — Configure FIM (Wazuh, OSSEC, Tripwire) to alert on new .php files appearing in web-accessible directories. This won't prevent the write but ensures rapid detection of successful exploitation.

Run this on each target host where a CodeIgniter 4 application is deployed. Requires read access to the Composer lock file in the project root. Example: bash check_cve_2026_63222.sh /var/www/myapp

#!/usr/bin/env bash
# check_cve_2026_63222.sh — Check for CVE-2026-63222 (CodeIgniter UploadedFile path traversal)
# Usage: bash check_cve_2026_63222.sh /path/to/codeigniter4/project
# Requires: read access to composer.lock; jq installed
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-}"

if [ -z "$PROJECT_DIR" ]; then
  echo "Usage: $0 /path/to/codeigniter4/project"
  exit 2
fi

LOCKFILE="$PROJECT_DIR/composer.lock"

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

if ! command -v jq &>/dev/null; then
  echo "UNKNOWN — jq is required but not installed"
  exit 2
fi

# Extract codeigniter4/framework version from composer.lock
CI_VERSION=$(jq -r '.packages[] | select(.name == "codeigniter4/framework") | .version' "$LOCKFILE" 2>/dev/null | sed 's/^v//')

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

echo "Detected codeigniter4/framework version: $CI_VERSION"

# Compare versions: vulnerable if < 4.7.4
# Use sort -V for version comparison
MIN_SAFE="4.7.4"
OLDEST=$(printf '%s\n%s' "$CI_VERSION" "$MIN_SAFE" | sort -V | head -n1)

if [ "$CI_VERSION" = "$MIN_SAFE" ] || [ "$OLDEST" = "$MIN_SAFE" ]; then
  echo "PATCHED — version $CI_VERSION >= $MIN_SAFE"
  exit 0
else
  echo "VULNERABLE — version $CI_VERSION < $MIN_SAFE (CVE-2026-63222)"
  # Bonus: check for vulnerable code pattern
  echo ""
  echo "Checking for potentially vulnerable move() calls (one-argument pattern):"
  grep -rn '->move(' "$PROJECT_DIR/app" --include='*.php' 2>/dev/null | grep -v ',\s*' || echo "  No one-argument move() calls found in app/ (may still exist in other dirs)"
  exit 1
fi

Sources

1. CodeIgniter 4.7.4 Changelog
2. GHSA-c9w5-rwh3-7pm9 — UploadedFile::move() Path Traversal
3. CodeIgniter Uploaded Files Documentation
4. CodeIgniter4 GitHub CHANGELOG
5. BuiltWith — CodeIgniter Usage Statistics
6. Enlyft — CodeIgniter Market Share
7. FIRST EPSS Model