Recherche OrcaCyber - PHP2Shell : comment une requête échouée a mené à une exécution de code à distance

The proof of concept in this investigation was created with OrcaCyber Zero and OrcaCyber Ultra models. The research bundle documents source-level analysis, a controlled reproduction using an adapted public exploit, a memory-disclosure artifact, process crashes, and command-execution evidence. The supplied files do not independently record which steps were performed by each model; the model attribution is provided by the research team.

A fatal out-of-memory condition should terminate a request safely. Here, it could interrupt PHP while native state was only partially initialized, leaving references that persisted into the next request. The result was a cross-request memory-lifetime violation with consequences ranging from disclosure to remote code execution in the tested environment.

Key evidence at a glance

• Target — PHP 8.4.26, Apache/mod_php, single worker, isolated Docker lab.

• Crash logs — One SIGABRT and three SIGSEGV worker exits in the supplied excerpt.

• HTTP response — 819,200 bytes in the URL-decoded PHPSESSID value.

• Execution proof — code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>.

• Regression — The report describes four unsuccessful attempts on patched PHP 8.4.27; raw runs are not bundled.

Source: uploaded REPORT.md, crash_evidence.log, leak_attempt.resp, and rce_proof_8426.txt. Exhibits described below reproduce those artifacts as typeset evidence panels; they are not photographs or native terminal screenshots.

1. The vulnerability: request-boundary ownership failure

The two related issues concern interrupted request initialization and stale runtime-global pointers. In the relevant PHP architecture, multipart/form-data handling and session upload-progress callbacks can run before normal user application code. An exceptional control-flow transition, including code>zend_bailout()/code>, can skip expected cleanup and leave state pointing at memory that later gets released or reused.

Security invariant: a worker-global reference exposed to request B must never reference memory whose ownership and lifetime ended with request A. The reported failure violates that invariant.

The demonstrated endpoint was a minimal PHP page that simply returned OK; the exploit narrative did not depend on application-level SQL injection, file inclusion, or deserialization endpoints.

2. Technical sequence

• A1 — interruption. Multipart and upload-progress handling triggers OOM during cleanup, leaving stale session state.

• B1 — leak. A subsequent request causes session-cookie serialization to read beyond a valid session ID.

• Address recovery. Leaked pointer values are used to infer relevant library and heap layout in that build.

• A2/B2 — corruption. A further two-request sequence shapes and redirects stale data used at shutdown.

• Outcome. The adapted public exploit reports command execution as www-data.

Evidence exhibits: what the supplied files actually show

Exhibit A — worker termination from Apache log

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 54 exit signal Abort (6), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 55 exit signal Segmentation fault (11), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 58 exit signal Segmentation fault (11), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 61 exit signal Segmentation fault (11), possible coredump in /etc/apache2/code>

Typeset excerpt from crash_evidence.log (October 23, 2026). Multiple worker exits support a memory-safety failure; crashes alone do not establish RCE.

Exhibit B — HTTP response with anomalous session cookie

• code>HTTP/1.1 200 OK/code>, with binary data omitted.

• code>Server: Apache/2.4.69 (Debian)/code>

• code>X-Powered-By: PHP/8.4.26/code>

• code>Set-Cookie: PHPSESSID=[omitted binary data]/code>

• Encoded cookie length: 2,330,754 bytes.

• URL-decoded value: 819,200 bytes.

Measurement computed directly from leak_attempt.resp. The binary value is intentionally omitted to avoid reproducing any leaked process contents.

Exhibit C — execution proof

code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>

Exact contents of rce_proof_8426.txt, as supplied. It supports the reported execution outcome but is not a full command/session transcript.

Exhibit D — session lifecycle fix

• code>static inline void php_rinit_session_globals(void)/code>

• code>@@ -121,6 +120,7 @@ static inline void php_rinit_session_globals(void)/code>

• code>* re-encodes the session during request startup, before RINIT, when no user/code>

• code>/* Runs before RINIT: no user code may be invoked, see php_session_unserialize_init() *//code>

• code>/* This runs before RINIT, so we need to clear these early *//code>

• code>php_rinit_session_globals();/code>

Selected source-diff lines from session.c.diff. This change explicitly resets session-global state earlier than ordinary RINIT.

3. Why the evidence matters

The memory disclosure provides the bridge between a process crash and an exploit chain. An abnormally sized session value with embedded binary data is consistent with the runtime interpreting invalid memory as a Zend string. The research report further describes extracting code and heap addresses from the leaked window. The evidence bundle contains the raw response but not a standalone script proving every recovered address.

The RCE artifact shows the www-data security context. It does not establish root access, compromise of a production environment, or complete portability to arbitrary PHP deployments. The single-worker laboratory configuration is important because request sequencing and worker affinity affect the mechanism.

4. A fix to the underlying lifecycle, not just the symptom

The supplied source diff for PHP patch commit 01a40e89fbfc ("Avoid state corruption via bailout") shows early session-global initialization, changes to allocator OOM handling, and broader reset/cleanup logic. These changes aim to prevent native state from surviving an interrupted request in an invalid state. Fixing only the cookie encoding path would not, by itself, restore this memory-ownership guarantee.

The research report states that attempts against PHP 8.4.27 did not produce the abnormal cookie, crash, or RCE proof in four trials. The actual patched-version transcripts are not in this bundle, so that comparison is reported as a researcher observation rather than an independently inspectable exhibit.

5. Defensive actions

• Immediate. Upgrade the affected supported PHP line to its security-fixed release and use vendor advisories to confirm exact package status.

• Exposure reduction. Consider restricting multipart inputs and disabling code>session.upload_progress/code> if unused; these do not replace the patch.

• Detection. Review crashes during request initialization, unexpected 500s, and oversized code>Set-Cookie/code> response headers.

• Assurance. Retest with production-representative worker pools and validate that old session state cannot persist across requests.

6. OrcaCyber research methodology

The valuable research task is not only spotting individual unsafe operations; it is tracing a full invariant violation across request parsing, allocator behavior, persistent native globals, serialization, and shutdown. OrcaCyber Zero and OrcaCyber Ultra were used to create the PoC in this investigation, as attributed by the research team. The public artifact set supports the technical reproduction, but does not provide model-by-model execution traces or prove autonomous vulnerability discovery.

Evidence ladder: source hypothesis → reachable trigger → runtime failure → information disclosure → execution proof → fixed-version regression. This sequence creates stronger confidence than a vulnerability description or crash-only result. It also encourages clearly reporting uncertainty when source files or raw execution logs are absent.

7. Scope and limitations

This publication describes an authorized isolated Docker lab. The exploit is based on previously published PHP2Shell research, with local adaptation documented in the supplied report. The bundle includes scripts, diffs, response bytes, logs, and proof output, but omits the full upstream exploit checkout, native screenshots, and complete raw patch-regression transcripts. No real-world victim or customer compromise is claimed.

Sources and artifacts

Primary: supplied php2shell-report-bundle.tar.gz (REPORT.md; report-CVE-2026-109618.md; report-CVE-2026-109619.md; crash_evidence.log; leak_attempt.resp; rce_proof_8426.txt; PHP source diffs). Public context: PHP security advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp; PHP security release announcements. Public exploit attribution: 9bie/php2shell-bypass-aslr-exp. Research repository: orcacyber-php2shell-research.

Takeaway: one request failed; a pointer survived; the next request trusted it. The hard part of understanding this vulnerability is establishing that connection with observable evidence.