CVE-2012-1823

What is PHP-CGI?

PHP can be deployed in two primary modes: as an Apache module (mod_php) or as a CGI binary. In CGI mode, each HTTP request spawns a PHP process with arguments passed via the CGI interface. RFC 3875 (the CGI specification) defines that when a query string contains no = character, it should be split and passed as command-line arguments to the CGI script. PHP's command-line interpreter accepts security-sensitive flags — such as -s (output source code) and -d (set php.ini directives). This combination of RFC compliance and dangerous flag acceptance creates a critical argument injection vulnerability when PHP runs in CGI mode. PHP-CGI was commonly used with web servers like lighttpd, nginx, and in some Apache configurations.

Overview

CVE-2012-1823 is a command injection vulnerability (CWE-77) in PHP when configured as a CGI binary. A specially crafted query string — one containing no = sign — causes PHP-CGI to interpret query string tokens as command-line arguments to the PHP interpreter. This enables an unauthenticated remote attacker to pass dangerous interpreter flags via HTTP request, leading to PHP source code disclosure or full remote code execution. The vulnerability was extensively exploited in mass automated scanning campaigns within days of public disclosure.

PHP fixed this in versions 5.3.12 and 5.4.2, released May 3, 2012.

Affected Versions

Technical Details

Root cause: RFC 3875 §4.4 specifies that if the query string of a CGI request contains no = character, its +-delimited tokens should be passed as additional command-line arguments to the CGI executable. PHP-CGI complies with this RFC requirement but does not filter security-sensitive flags from the resulting argument list.

The vulnerability enables two distinct attack impacts:

Source code disclosure: Passing the -s flag via a query string causes php-cgi to output the PHP source of the target file as HTML, rather than executing it. This exposes database credentials, API keys, session secrets, and application logic embedded in PHP source files — affecting the confidentiality of all .php files served by the vulnerable installation.

Remote code execution: By passing -d flags to override php.ini directives at runtime, an attacker can enable dynamic file inclusion (via allow_url_include) and cause PHP to prepend attacker-supplied code to the target file's execution. This allows arbitrary PHP code execution without any authentication, with the privileges of the web server process.

The attack requires only a single HTTP request with a specially formatted query string — no authentication, no session, no prior knowledge of the application. Automated scanners exploited this at internet scale within hours of proof-of-concept publication.

Discovery

The vulnerability was publicly disclosed by the team at Eindbazen on May 3, 2012, alongside a proof-of-concept. The same-day public disclosure with working exploit code triggered immediate mass exploitation before the majority of hosting providers could deploy the patch.

Exploitation Context

CVE-2012-1823 was massively exploited in automated scanning campaigns within hours of disclosure. Internet-wide scanners identified PHP-CGI installations and automatically tested for the vulnerability, then installed persistent webshells for ongoing access. The ease of exploitation — a single crafted HTTP request requiring no credentials — and the prevalence of PHP-CGI in shared hosting environments made this one of the most widely exploited web vulnerabilities of 2012.

The vulnerability has seen sustained exploitation for over a decade. CISA adding it to the KEV catalog in 2022 reflects continued observed exploitation, particularly against legacy hosting environments that never migrated away from PHP-CGI to PHP-FPM or mod_php.

Remediation

1. Upgrade to PHP 5.3.12 / 5.4.2 or later — current releases are PHP 8.2 and 8.3
2. Switch from PHP-CGI to mod_php or PHP-FPM — these deployment modes are not affected by this vulnerability class
3. If PHP-CGI must be used temporarily, set cgi.force_redirect = 1 in php.ini and configure the web server to enforce the CGI redirect security mechanism
4. Add a web server rewrite rule to reject requests to PHP files with query strings containing no = sign (argument injection test pattern)
5. Scan all PHP-CGI deployments for indicators of compromise — webshells installed via this vulnerability persist in the file system even after patching
6. Audit PHP source files for hardcoded credentials that may have been exposed via source disclosure; rotate any secrets that may have been leaked