CVE-2026-63220: Trust of Untrusted Reverse Proxy Headers in CodeIgniter4

CodeIgniter4 is a full-stack PHP framework used for developing web applications. To handle incoming network requests, CodeIgniter4 relies on the IncomingRequest class, which exposes the isSecure() method to determine if a connection is encrypted via HTTPS. This determination is a critical step for application security controls, such as enforcing SSL, setting secure cookies, and initiating forced secure redirects.

In versions prior to v4.7.4, the implementation of isSecure() evaluated client-supplied forwarding headers, such as X-Forwarded-Proto and Front-End-Https, without verifying the origin of the network request. In normal multi-tier infrastructures, reverse proxies terminate TLS and add these headers to downstream requests. However, when CodeIgniter4 accepts these headers blindly from any client, the boundary of trust is broken.

This flaw allows remote, unauthenticated attackers to manipulate the application's perceived network protocol. By appending specific HTTP headers to a plaintext request, an attacker can bypass secure transport validations and force the application to treat the connection as secure. This can lead to downstream exposure of sensitive session identifiers and configuration bypasses.

The root cause of CVE-2026-63220 resides in the logical sequence of the IncomingRequest::isSecure() helper method. The framework evaluates the presence of X-Forwarded-Proto and Front-End-Https headers immediately after checking standard local server environment variables. Because this evaluation is unconditional, the application assumes that any request carrying these headers was validated by an upstream proxy.

In a standard secure deployment, a reverse proxy sits between the public internet and the application server. The proxy is responsible for stripping incoming client-side forwarding headers and replacing them with verified values. However, if the application is directly exposed to the internet or the upstream proxy does not clean incoming headers, the application processes attacker-controlled headers as authentic.

This behavior matches the classification of CWE-348 (Use of Less Trusted Source). By prioritizing incoming header metadata over the physical and network origin of the request, CodeIgniter4 relies on unverified, less-trusted input for making critical security decisions. The framework lacks a validation layer to ensure the request peer address (REMOTE_ADDR) matches a predefined list of trusted proxies before interpreting forwarding headers.

Reviewing the vulnerable code path in IncomingRequest.php shows how the application evaluated the headers unconditionally:

public function isSecure(): bool
{
    if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') {
        return true;
    }
 
    if ($this->hasHeader('X-Forwarded-Proto') && $this->header('X-Forwarded-Proto')->getValue() === 'https') {
        return true;
    }
 
    if ($this->hasHeader('Front-End-Https') && $this->header('Front-End-Https')->getValue() === 'on') {
        return true;
    }
 
    return false;
}

The patched version introduces an immediate origin check via isFromTrustedProxy() before evaluating these headers. The updated isSecure() method in IncomingRequest.php is structured as follows:

public function isSecure(): bool
{
    if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] === 'on') {
        return true;
    }
 
    if (! $this->isFromTrustedProxy()) {
        return false;
    }
 
    if ($this->hasHeader('X-Forwarded-Proto') && $this->header('X-Forwarded-Proto')->getValue() === 'https') {
        return true;
    }
    // ...
}

The helper method isFromTrustedProxy() retrieves the registered proxy IP array from the application configuration. It then verifies the value of $_SERVER['REMOTE_ADDR'] against this whitelist. If the client IP address is not registered as a trusted proxy, the function returns false, preventing the application from interpreting any client-supplied protocol headers.

Furthermore, the patch implements a robust, binary-based IP comparison routine using inet_pton() inside checkIPAgainstProxy(). This update replaces the legacy, custom string-manipulation routine which was fragile and prone to parsing errors. The use of PHP's native network utilities ensures consistent validation across dual-stack IPv4 and IPv6 network environments.

An attacker can exploit this flaw by targeting web servers that are directly exposed to the internet or deployed behind misconfigured reverse proxies. The prerequisite is that the target server must accept HTTP traffic on port 80 and the application must use isSecure() or helper functions like force_https() to enforce security logic.

To simulate or verify the vulnerability, an attacker constructs an unencrypted HTTP request targeting a sensitive application endpoint. Using standard command-line tools, the attacker appends the X-Forwarded-Proto header with a value of https:

curl -H "X-Forwarded-Proto: https" http://example-target.com/login

Upon receiving this request, the vulnerable application server evaluates the isSecure() check. Because the header is present and equals https, the framework bypasses any forced redirect logic that would normally upgrade the client's connection to HTTPS. The login page loads over plain, unencrypted HTTP, allowing the user to transmit sensitive login credentials over a plaintext channel, exposing them to network-level sniffing attacks.

This flow chart illustrates how the vulnerability is exploited to bypass HTTPS redirection logic. The attacker maintains a plaintext connection while the application acts as if TLS is active.

The impact of CVE-2026-63220 is classified as Medium, with a CVSS v3.1 base score of 4.8. This rating reflects the dependency of the vulnerability on specific deployment patterns, such as direct exposure to the public internet or lack of proxy-side header sanitization. Although it does not directly enable remote code execution, it degrades transport layer protections and access controls.

A primary risk involves the exposure of sensitive session identifiers. Web browsers append the Secure attribute to session cookies to prevent them from being transmitted over unencrypted HTTP. However, if the application believes the connection is secure, it may output sensitive data or reflect active session state in a context where the transport layer is actually plaintext, leading to information disclosure.

Additionally, this issue can result in redirect loops or routing errors. If an upstream proxy actively enforces HTTPS redirects, but the backend is misconfigured or cannot properly validate the proxy, it may continuously issue redundant redirects or allow unauthenticated requests to bypass network boundary checks. This weakens defense-in-depth postures across the application infrastructure.

The primary remediation for this vulnerability is to upgrade CodeIgniter4 to version v4.7.4 or later. This version enforces origin validation on all requests containing protocol forwarding headers, preventing clients from spoofing their protocol status directly to the application.

In addition to upgrading the framework, developers must properly configure the $proxyIPs setting in the app/Config/App.php configuration file. If the application runs behind a reverse proxy, load balancer, or CDN, all associated upstream IP addresses or subnets must be declared. If the application is directly exposed to the internet, this configuration must remain completely empty to disable header forwarding interpretation:

public array $proxyIPs = [
    '192.168.1.100' => 'X-Forwarded-For',
    '10.0.0.0/24'   => 'X-Forwarded-For'
];

For dual-stack network configurations, ensure that both IPv4 and their corresponding IPv6-mapped IPv4 addresses (such as ::ffff:192.168.1.100) are registered. If these are omitted, the strict address check will fail to identify the proxy, falling back to a secure-by-default posture that rejects the proxy forwarding headers.

At the infrastructure layer, reverse proxies and web application firewalls (WAFs) must be configured to sanitize incoming headers. Administrators must configure edge servers to strip or overwrite any client-supplied X-Forwarded-Proto, X-Forwarded-For, or Front-End-Https headers before forwarding the request to the backend. This prevents spoofed headers from reaching the application tier entirely.