CVE-2026-63220: CodeIgniter Auth Bypass Vulnerability

CVE-2026-63220 Overview

CVE-2026-63220 affects CodeIgniter, a PHP full-stack web framework, in all versions prior to 4.7.4. The vulnerability resides in the IncomingRequest::isSecure() method, which trusted the X-Forwarded-Proto and Front-End-Https headers from any incoming request. An attacker can spoof these headers to make the application incorrectly treat an HTTP request as secure. This impacts applications that rely on isSecure(), force_https(), forceGlobalSecureRequests, or similar logic to enforce HTTPS-only access. The issue is tracked as [CWE-348: Use of Less Trusted Source] and was resolved in CodeIgniter 4.7.4.

Critical Impact
Attackers can bypass HTTPS enforcement logic and force security-sensitive decisions to treat plaintext HTTP traffic as secure, exposing cookies, credentials, and session data.

Affected Products

CodeIgniter4 versions prior to 4.7.4
Applications using IncomingRequest::isSecure() for security decisions
Deployments where reverse proxies forward client-supplied headers without stripping them

Discovery Timeline

2026-07-31 - CVE-2026-63220 published to NVD
2026-07-31 - Last updated in NVD database

Technical Details for CVE-2026-63220

Vulnerability Analysis

The vulnerability originates in CodeIgniter's HTTP request abstraction layer. The IncomingRequest::isSecure() method inspects the X-Forwarded-Proto and Front-End-Https request headers to determine whether the connection is encrypted. Before version 4.7.4, the framework accepted these headers from any client without validating the source of the request. An attacker sending an HTTP request with X-Forwarded-Proto: https caused the method to return true, effectively lying to downstream code about the transport security state.

The flaw belongs to [CWE-348: Use of Less Trusted Source]. Any application relying on the method for security enforcement inherits the trust decision. Impact includes bypass of HTTPS redirection, incorrect setting of the Secure cookie flag, and skipping of HSTS-related logic.

Root Cause

The root cause is missing validation of the request origin before honoring proxy forwarding headers. Standard practice requires accepting X-Forwarded-* headers only when the immediate upstream is a trusted proxy configured in Config\App::$proxyIPs. The pre-patch implementation omitted this check.

Attack Vector

Exploitation depends on deployment topology. An attacker can reach the application directly over HTTP or through a reverse proxy that passes through client-supplied forwarding headers. By injecting X-Forwarded-Proto: https or Front-End-Https: on, the attacker forces application logic to bypass HTTPS enforcement paths.

php

            return true;
        }

+        if (! $this->isFromTrustedProxy()) {
+            return false;
+        }
+
        if ($this->hasHeader('X-Forwarded-Proto') && $this->header('X-Forwarded-Proto')->getValue() === 'https') {
            return true;
        }
// Source: https://github.com/codeigniter4/CodeIgniter4/commit/ecbf044666bed41d23f07518096d9843fe6c08b0

The patch adds an isFromTrustedProxy() check that rejects forwarding headers unless the request originates from a proxy IP listed in Config\App::$proxyIPs.

Detection Methods for CVE-2026-63220

Indicators of Compromise

Inbound HTTP requests carrying X-Forwarded-Proto: https or Front-End-Https: on headers that did not traverse a legitimate load balancer
Application logs showing isSecure() returning true for requests received on HTTP listener ports
Anomalous session cookies issued over plaintext HTTP connections

Detection Strategies

Inspect web server access logs for X-Forwarded-Proto and Front-End-Https headers on connections that arrived directly rather than via the configured proxy
Correlate client source IP addresses against the trusted proxy list defined in Config\App::$proxyIPs to identify header injection attempts
Deploy web application firewall rules to alert on external clients supplying proxy forwarding headers

Monitoring Recommendations

Enable request header logging at the reverse proxy and compare with headers observed at the application layer
Track anomalies in HTTPS enforcement decisions by instrumenting calls to isSecure() and force_https()
Monitor for unauthenticated access to endpoints protected by forceGlobalSecureRequests

How to Mitigate CVE-2026-63220

Immediate Actions Required

Upgrade CodeIgniter4 to version 4.7.4 or later, which restricts trust of forwarding headers to proxies listed in Config\App::$proxyIPs
Configure Config\App::$proxyIPs to explicitly list the IP addresses of legitimate load balancers and reverse proxies
Ensure upstream proxies strip or overwrite client-supplied X-Forwarded-Proto and Front-End-Https headers before forwarding

Patch Information

The fix is available in GitHub Release v4.7.4. Technical details are documented in GitHub Security Advisory GHSA-7wmf-pw8j-mc78 and the remediation commit.

Workarounds

Block direct HTTP access to the backend so all traffic must traverse a trusted reverse proxy
Configure the reverse proxy to unconditionally overwrite X-Forwarded-Proto and Front-End-Https with values reflecting the actual client-side transport
Replace calls to IncomingRequest::isSecure() with server-side checks against $_SERVER['HTTPS'] or the actual listening port until patching is complete

bash

# Configuration example - app/Config/App.php
public array $proxyIPs = [
    '10.0.0.0/8'       => 'X-Forwarded-For',
    '192.168.1.10'     => 'X-Forwarded-For',
];