Research Update Enhanced src/network-services-pentesting/pen...

src/network-services-pentesting/pentesting-web/cgi.md

@@ -165,8 +165,30 @@ curl -i -X POST \
 Notes:
 
 - The `%AD` bytes are the important part: they are the attacker-controlled "soft hyphens".
-- This was reproduced in the wild mainly against **Windows Chinese/Japanese locales**, but if you see Windows PHP-CGI exposure, just test it.
-- Patched versions start at `8.3.8`, `8.2.20`, and `8.1.29`.
+- The original issue is directly reproducible with code pages 932, 936 and 950; other Windows locales still require assessment because web-server and code-page combinations differ.<sup>[[1]](#references)</sup>
+- `8.1.29`, `8.2.20` and `8.3.8` contained the first fix, but a later parameter-injection bypass means the complete historical fix baselines are `8.1.30`, `8.2.24` and `8.3.12`. Use a currently supported, fully updated PHP branch rather than stopping at the first fixed build.<sup>[[11]](#references)</sup>
+
+### Post-fix quote-smuggling variant \(unusual Windows code pages\)
+
+A later variant targets installations whose Windows **ANSI code page \(ACP\) was manually pointed at an OEM code page**. On code page 437, for example, `%A8` can become `"`; Windows command-line parsing then removes the generated quote pair around `-s`, recreating an option even after the soft-hyphen fix. This setup requires an unusual registry modification, but it is useful when an apparently patched appliance still behaves as vulnerable.<sup>[[11]](#references)</sup>
+
+```bash
+# Source-disclosure canary for the rare quote-smuggling variant
+curl -i 'http://target/index.php?%A8-s%A8'
+```
+
+### `cgi.force_redirect` header/environment collision
+
+Older PHP-CGI also accepted either `REDIRECT_STATUS` or `HTTP_REDIRECT_STATUS` as proof that the web server invoked it through a configured redirect. Because CGI transforms an attacker-supplied `Redirect-Status` header into `HTTP_REDIRECT_STATUS`, a direct request could satisfy that check and bypass `cgi.force_redirect`. This is not RCE by itself, but configurations that also derive attacker-controlled `SCRIPT_FILENAME` values could turn direct invocation into arbitrary file inclusion. The same `8.1.30`, `8.2.24` and `8.3.12` releases fixed this collision.<sup>[[12]](#references)</sup>
+
+```bash
+# Compare the direct-call response with and without the colliding header
+curl -i 'http://target/cgi-bin/php/secretdir/script.php'
+curl -i -H 'Redirect-Status: 1' \
+  'http://target/cgi-bin/php/secretdir/script.php'
+```
+
+A change from PHP's `Security Alert!` response to normal script handling is the signal; verify the handler mapping and `SCRIPT_FILENAME` construction before claiming file inclusion.<sup>[[12]](#references)</sup>
 
 ## **Proxy / `HTTP_PROXY` \(httpoxy\)**
 
@@ -191,6 +213,8 @@ Useful notes:<sup>[[9]](#references)</sup>
 - Historically it affected CGI-style PHP, Python CGI handlers, and Go `net/http/cgi` style deployments.
 - Simply unsetting `$_SERVER['HTTP_PROXY']` in PHP may be insufficient if the code or library reads from `getenv('HTTP_PROXY')`.
 
+
+
 ## References
 
 - [1] [Orange Tsai - CVE-2024-4577: Yet Another PHP RCE, Make PHP-CGI Argument Injection Great Again!](https://blog.orange.tw/posts/2024-06-cve-2024-4577-yet-another-php-rce/)
@@ -203,5 +227,6 @@ Useful notes:<sup>[[9]](#references)</sup>
 - [8] [NVD – CVE-2014-6271](https://nvd.nist.gov/vuln/detail/CVE-2014-6271)
 - [9] [httpoxy – A CGI application vulnerability](https://httpoxy.org/)
 - [10] [Nikto documentation](https://github.com/sullo/nikto/wiki)
-
+- [11] [PHP security advisory – PHP-CGI parameter injection bypass](https://github.com/php/php-src/security/advisories/GHSA-p99j-rfp4-xqvq)
+- [12] [PHP security advisory – `cgi.force_redirect` environment-variable collision](https://github.com/php/php-src/security/advisories/GHSA-94p6-54jq-9mwp)
 {{#include ../../banners/hacktricks-training.md}}