CVE-2026-63220 in CodeIgniter
Summary
by MITRE • 07/31/2026
CodeIgniter is a PHP full-stack web framework. In versions prior to 4.7.4, IncomingRequest::isSecure() trusted the X-Forwarded-Proto and Front-End-Https headers from any incoming request, allowing an attacker could spoof these headers and cause the application to incorrectly treat an HTTP request as secure. This may have impacted applications that rely on isSecure(), force_https(), forceGlobalSecureRequests, or similar logic to enforce HTTPS-only access or make security-sensitive decisions. Exploitability depends on deployment configuration. Applications are most exposed if the backend is reachable directly over HTTP, or if a reverse proxy/load balancer forwards client-supplied forwarding headers without stripping or overwriting them. This issue has been fixed in version 4.7.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/31/2026
The vulnerability in CodeIgniter versions prior to 4.7.4 represents a critical security flaw in the IncomingRequest::isSecure() method that fundamentally undermines the framework's ability to accurately determine request security status. This weakness stems from the framework's trust in client-supplied HTTP headers including X-Forwarded-Proto and Front-End-Https without proper validation or sanitization, creating an attack vector where malicious actors can manipulate these headers to deceive the application into treating insecure HTTP connections as secure HTTPS ones. The vulnerability directly maps to CWE-284 Access Control Issues and specifically manifests as a lack of proper input validation for security-relevant headers that should only be trusted when originating from known, trusted proxies or load balancers rather than arbitrary client requests.
The technical implementation flaw occurs within the framework's request handling logic where it accepts and processes forwarding headers without verifying their source legitimacy or implementing proper header sanitization mechanisms. This design decision creates a path for attackers to exploit applications that depend on isSecure() method results for critical security decisions such as enforcing HTTPS-only access, redirecting users to secure endpoints, or making authorization decisions based on connection security status. When these methods incorrectly identify HTTP requests as secure, applications may bypass security checks, fail to enforce proper encryption requirements, or make incorrect access control decisions that could lead to data exposure or privilege escalation.
The operational impact of this vulnerability extends beyond simple header manipulation and can result in serious security consequences for applications that rely on the framework's security mechanisms. Applications utilizing force_https() or forceGlobalSecureRequests features become particularly vulnerable as these functions depend on accurate security status determination from isSecure(). The risk is amplified when backend servers are directly accessible over HTTP without proper reverse proxy configuration, or when load balancers forward client-supplied headers without sanitizing them first. This creates a scenario where attackers can bypass security measures that should prevent sensitive operations from occurring over unencrypted connections, potentially leading to session hijacking, data interception, or unauthorized access to protected resources.
Mitigation strategies for this vulnerability require immediate implementation of framework updates to version 4.7.4 or later where the security flaw has been addressed through proper header validation and sanitization. Organizations should also review their network infrastructure configuration to ensure that forwarding headers are properly sanitized by reverse proxies or load balancers before reaching backend applications, implementing a principle of least privilege for header handling. Security teams should conduct comprehensive audits of applications that rely on isSecure() and related methods to identify potential areas where incorrect security status determination could impact access control or encryption enforcement. Additionally, monitoring systems should be enhanced to detect unusual patterns in security-related header values that might indicate exploitation attempts, while implementing proper input validation at multiple layers of the application architecture to prevent similar vulnerabilities from emerging in custom code implementations. This vulnerability demonstrates the critical importance of validating all security-relevant inputs regardless of their source and aligns with ATT&CK technique T1071.004 Application Layer Protocol: DNS for establishing secure communication channels that should never be trusted without proper verification mechanisms.