php2shell/fcgi/FINDINGS.md

RCE via FastCGI + Session Upload Progress (No LFI)

Summary

When an attacker can reach PHP-FPM's FastCGI socket (TCP or unix), the session upload progress write primitive from CVE-2026-109618 / CVE-2026-109619 becomes RCE without any application-level vulnerability.

No LFI needed. No framework needed. No special PHP configuration needed. Works on default php.ini settings.

Attack chain

Worker A (held open)                Worker B (executes)
---                                 ---
FastCGI POST with                   FastCGI GET with
multipart body:                     PHP_VALUE:
  PHP_SESSION_UPLOAD_PROGRESS         auto_prepend_file=
  = <?php system(...); ?>             /tmp/sess_<SID>
                                    SCRIPT_FILENAME=
File upload content                   /var/www/html/index.php
dripped one byte at a time
  -> session file persists          PHP includes the session
  -> parser blocks for              file before index.php
    the entire drip window            -> attacker PHP runs
                                      -> RCE

Step by step

1. Open a FastCGI connection to FPM worker A. Send a POST request with Content-Type: multipart/form-data and PHPSESSID=<SID> in the HTTP_COOKIE param. The body contains:

   • A PHP_SESSION_UPLOAD_PROGRESS field with embedded PHP code
   • A file upload whose content is dripped slowly (byte by byte)

2. FPM worker A enters the multipart parser. As soon as the progress field and file header are read, session.upload_progress writes the attacker's PHP code into /tmp/sess_<SID>. The parser then blocks reading the file content from STDIN, which we control.

3. While worker A is blocked, open a second FastCGI connection to worker B. Send a GET request with:

   • SCRIPT_FILENAME = /var/www/html/index.php (any existing .php file)
   • PHP_VALUE = auto_prepend_file = /tmp/sess_<SID>

4. Worker B executes. PHP's auto_prepend_file directive causes it to include() the session file before running the main script. The session file contains the attacker's <?php ... ?> code, which executes.

5. Cleanup. The drip finishes, worker A completes normally (or times out), the session file is cleaned up. The attacker's code has already executed on worker B.

Why it works on default configuration

Setting	Default	Required
session.upload_progress.enabled	1	1
session.save_path	/tmp	Any known path
pm.max_children	5 (dynamic)	>= 2
security.limit_extensions	.php .phar	Any (not checked for auto_prepend)
session.upload_progress.cleanup	1	Does not matter (drip defeats it)

security.limit_extensions blocks execution of files without .php extension as SCRIPT_FILENAME. But auto_prepend_file loads files via include(), which ignores security.limit_extensions entirely. The session file (which has no extension) is included as PHP code regardless of limit_extensions.

When FPM is reachable

This is the main precondition. The attacker needs raw TCP or unix socket access to the FPM process. This is realistic in:

1. Docker containers. The official php:*-fpm images configure FPM to listen on TCP 0.0.0.0:9000. Any container on the same Docker network can reach it.

2. Kubernetes pods. PHP-FPM pods are typically addressed by service name. Adjacent pods, including compromised ones, can send raw FastCGI.

3. SSRF. An SSRF vulnerability in any application on the same host can reach 127.0.0.1:9000 or the unix socket. The gopher:// scheme can carry arbitrary TCP payloads including FastCGI.

4. Exposed port. Misconfigured firewalls, cloud security groups, or Docker port mappings exposing 9000 to the network.

5. Same-host access. A low-privilege shell on the same machine can often read the unix socket (permissions vary by distro).

Test results

Tested against PHP-FPM 8.3.6 with default settings:

• session.upload_progress.enabled=1 (default)
• session.save_path=/tmp (default)
• session.upload_progress.cleanup=1 (default)
• security.limit_extensions = .php .phar (default)
• pm = static, pm.max_children = 2

Results: 3/3 tests successful. Race hit on first attempt within 200ms of the drip starting. Reliable with --drip-time 5 (5 second window).

Mitigations

1. Set session.upload_progress.enabled=0 if upload progress tracking is not needed. This removes the write primitive entirely.

2. Block network access to FPM. FPM should only be reachable from the web server process. Use unix sockets with restricted file permissions, or firewall TCP port 9000.

3. Use pm.max_children=1 as a last resort. With only one worker, the racer cannot execute while the drip holds a worker. This severely impacts performance and is not practical.

4. Setting security.limit_extensions does NOT help. The inclusion happens via auto_prepend_file, which bypasses limit_extensions.

5. Setting php_admin_value[auto_prepend_file] in the FPM pool config does NOT help. Verified: with php_admin_value[auto_prepend_file] = /dev/null in the pool, a FastCGI request with PHP_VALUE: auto_prepend_file = /tmp/sess_xxx still overrides it. Raw FastCGI access bypasses the web server that would normally enforce admin values. The only effective mitigation is blocking FastCGI access.