CVE-2012-1823 is a PHP-CGI query string parameter vulnerability in PHP PHP. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 March 2022, which means attackers have used it in real attacks. sapi/cgi/cgi_main.c in PHP, when configured as a CGI script, does not properly handle query strings, which allows remote attackers to execute arbitrary code.
What this vulnerability means in practice
PHP-CGI query string parameter flaws matter because CGI mode can turn an HTTP request into code execution when the runtime mishandles how query strings are parsed. For a web application, that moves the issue from a simple input-handling bug to a direct server compromise path.
The danger is not limited to one application layer. If PHP is exposed through CGI and an attacker can influence request parameters, the vulnerability can become a remote execution primitive that bypasses normal application logic and reaches the underlying host.
Why exposed PHP-CGI deployments are high risk
CGI places special weight on request parsing, because the web server hands parameters to the runtime in a format that must be interpreted safely and consistently. When that boundary is weak, malformed query strings can alter execution behaviour rather than just application output.
That is why this class of issue is especially serious in internet-facing PHP stacks: a single reachable endpoint may be enough to convert a routine web request into arbitrary code execution. For authoritative record details, readers should consult the CVE Program and the NIST National Vulnerability Database.
How organisations assess exposure and limit blast radius
The first question is whether PHP is actually running in CGI mode anywhere in the estate, especially on public web servers, legacy virtual hosts, shared hosting environments, or appliances that bundle older PHP configurations. Asset inventory and configuration review matter because the vulnerable condition depends on deployment style, not just version naming alone.
Organisations also need to check internet exposure and vendor guidance together, since an exposed service may be reachable before patching can be scheduled. When remediation is delayed, compensating controls such as restricting external access, removing unnecessary CGI exposure, and placing stronger request filtering in front of the service can reduce immediate risk.
This is a classic case for disciplined vulnerability management, and the practical workflow is easier to sustain when it is tied to scope, prioritisation, exceptions, and verification rather than ad hoc patching. The Vulnerability Management Guide is a useful companion for that lifecycle view.
Detection, remediation, and compromise review
Once a vulnerable PHP-CGI deployment has been identified, remediation should be treated as a compromise-priority item when the system is reachable from untrusted networks. If exploitation is suspected, review web logs, process execution traces, and filesystem changes for signs that the request path was used to execute code or stage follow-on activity.
Post-patch review matters because fixing the flaw does not prove the host was clean before the patch. If attackers gained code execution, they may have planted web shells, modified application files, or used the server to access adjacent systems, so recovery should include integrity checks and a search for persistence.
For defenders mapping detection and response patterns, MITRE D3FEND Guide is helpful for thinking about artifact inspection, process analysis, and credential-hardening countermeasures after exploitation.
Risk and Threat Considerations
This vulnerability is dangerous because it can collapse the boundary between a web request and code execution. If an attacker can reach a PHP-CGI endpoint that mishandles query strings, the result may be full compromise of the web process and whatever data, sessions, or downstream services that process can access.
Failure mechanism: The CGI runtime misinterprets attacker-controlled query string content, so the request is processed as executable input instead of inert parameters.
Impact: Remote code execution can lead to defacement, data theft, credential capture, lateral movement, or the use of the server as a foothold for further intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE requires ongoing identification and remediation of exposed vulnerable assets. |
| Recommendation — Prioritise, patch, and verify exposed PHP-CGI assets under continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | The issue is found and tracked through vulnerability discovery and exposure review. |
| SI-2 — Flaw Remediation | A known exploited code-execution flaw requires timely remediation and validation. | |
| Recommendation — Scan for exposed PHP-CGI deployments and track remediation until verification is complete. Remediate the PHP-CGI flaw promptly and confirm the fix with post-change validation. | ||
| OWASP ASVS | V13 — Configuration | The vulnerability depends on unsafe PHP CGI configuration and request handling. |
| Recommendation — Eliminate unsafe CGI configurations and verify deployment settings before exposure. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Remote attackers exploit a public web application path to gain execution on the host. |
| Recommendation — Hunt for public-facing exploitation attempts and correlate them with web-server execution traces. | ||
Practitioner Guidance
Why practitioners should care: This term is not just a historical CVE label, it is a deployment-risk signal. If PHP-CGI is present anywhere in the estate, it deserves explicit inventory, exposure review, and incident-history checking because internet exposure can turn a legacy configuration into an active attack surface.
Practitioner takeaway: Treat this as both a remediation item and a compromise-assessment trigger, especially on externally reachable systems that still rely on CGI execution.
Related resources from NHI Mgmt Group
- CVE-2024-4577 (PHP-CGI OS Command Injection)
- How should security teams prioritize patching when an internet-facing PHP server still relies on CGI mode?
- What are the signs that PHP-CGI exploitation is already underway on a server?
- What breaks when hostname allowlists rely on naive string matching in PHP applications?