OrcaCyber Research - PHP2Shell: Hoe een mislukt verzoek uitmondde in remote code execution

De proof of concept in dit onderzoek is gemaakt met OrcaCyber Zero en OrcaCyber Ultra-modellen. De onderzoeksbundel documenteert analyse op bronniveau, een gecontroleerde reproductie met een aangepaste publieke exploit, een artefact voor geheugenopenbaarmaking, procescrashes en bewijs van commando-uitvoering. De aangeleverde bestanden registreren niet zelfstandig welke stappen door elk model zijn uitgevoerd; de modeltoewijzing wordt door het onderzoeksteam verstrekt.

Een fatale out-of-memory-situatie moet een verzoek veilig beëindigen. Hier kon daardoor PHP worden onderbroken terwijl de native state slechts gedeeltelijk was geïnitialiseerd, waardoor referenties achterbleven die in het volgende verzoek voortbestonden. Het resultaat was een schending van de geheugenlevensduur tussen verzoeken, met gevolgen variërend van openbaarmaking tot uitvoering van code op afstand in de geteste omgeving.

Belangrijkste bewijs in één oogopslag

• Doel — PHP 8.4.26, Apache/mod_php, één worker, geïsoleerd Docker-lab.

• Crashlogboeken — Eén SIGABRT en drie SIGSEGV-workerafsluitingen in het aangeleverde fragment.

• HTTP-respons — 819.200 bytes in de URL-gedecodeerde PHPSESSID-waarde.

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

• Regressie — Het rapport beschrijft vier mislukte pogingen op gepatchte PHP 8.4.27; ruwe runs zijn niet meegeleverd.

Bron: geüploade REPORT.md, crash_evidence.log, leak_attempt.resp en rce_proof_8426.txt. De hieronder beschreven bewijsstukken reproduceren die artefacten als gezette bewijspanelen; het zijn geen foto's of native terminalscreenshots.

1. De kwetsbaarheid: eigenaarschapfout op de verzoekgrens

De twee gerelateerde problemen betreffen onderbroken initialisatie van aanvragen en verouderde runtime-globale pointers. In de relevante PHP-architectuur kunnen multipart/form-data-afhandeling en callbacks voor uploadvoortgang van sessies worden uitgevoerd vóór normale gebruikersapplicatiecode. Een uitzonderlijke overgang in de controlestroom, waaronder code>zend_bailout()/code>, kan verwachte opschoning overslaan en ervoor zorgen dat de status naar geheugen blijft wijzen dat later wordt vrijgegeven of hergebruikt.

Beveiligingsinvariant: een worker-globale referentie die aan request B wordt blootgesteld, mag nooit verwijzen naar geheugen waarvan het eigenaarschap en de levensduur met request A zijn beëindigd. De gemelde fout schendt die invariant.

Het gedemonstreerde endpoint was een minimale PHP-pagina die eenvoudigweg OK retourneerde; het exploitverhaal was niet afhankelijk van SQL-injectie op applicatieniveau, bestandsinclusie of deserialisatie-endpoints.

2. Technische volgorde

• A1 — onderbreking. Afhandeling van multipart en uploadvoortgang veroorzaakt OOM tijdens opschonen, waardoor verouderde sessiestatus achterblijft.

• B1 — lek. Een daaropvolgende aanvraag zorgt ervoor dat de serialisatie van de sessiecookie voorbij een geldige sessie-ID leest.

• Adresherstel. Gelekte pointerwaarden worden gebruikt om de relevante bibliotheek- en heapindeling in die build af te leiden.

• A2/B2 — corruptie. Een verdere sequentie van twee verzoeken vormt verouderde gegevens die bij het afsluiten worden gebruikt en leidt deze om.

• Resultaat. De aangepaste publieke exploit meldt commando-uitvoering als www-data.

Bewijsstukken: wat de aangeleverde bestanden daadwerkelijk laten zien

Bijlage A — beëindiging van een worker uit het Apache-log

• code> [core:notice] [pid 1:tid 1] AH00051: kindproces met pid 54 beëindigd door signaal Abort (6), mogelijk coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: kindproces pid 55 beëindigingssignaal Segmentation fault (11), mogelijke coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: kindproces pid 58 beëindigd door signaal Segmentation fault (11), mogelijk coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: kindproces pid 61 beëindigd met signaal Segmentation fault (11), mogelijk coredump in /etc/apache2/code>

Gezet uittreksel uit crash_evidence.log (23 oktober 2026). Meerdere worker-exits wijzen op een geheugenveiligheidsfout; crashes alleen bewijzen geen RCE.

Bijlage B — HTTP-respons met een afwijkend sessiecookie

• code>HTTP/1.1 200 OK/code>, waarbij binaire gegevens zijn weggelaten.

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

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

• code>Set-Cookie: PHPSESSID=[weggelaten binaire gegevens]/code>

• Gecodeerde cookielengte: 2.330.754 bytes.

• URL-gedecodeerde waarde: 819.200 bytes.

Meting rechtstreeks berekend op basis van leak_attempt.resp. De binaire waarde is opzettelijk weggelaten om te voorkomen dat eventuele gelekte procesinhoud wordt gereproduceerd.

Bijlage C — bewijs van uitvoering

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

Exacte inhoud van rce_proof_8426.txt, zoals aangeleverd. Dit ondersteunt de gerapporteerde uitvoeringsuitkomst, maar is geen volledig transcript van commando's of sessies.

Bijlage D — correctie van de sessie-levenscyclus

• 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>* hercodeert de sessie tijdens het opstarten van het verzoek, vóór RINIT, wanneer er geen gebruiker is/code>

• code>/* Wordt uitgevoerd vóór RINIT: er mag geen gebruikerscode worden aangeroepen, zie php_session_unserialize_init() *//code>

• code>/* Dit wordt uitgevoerd vóór RINIT, dus we moeten deze vroeg opschonen *//code>

• code>php_rinit_session_globals();/code>

Geselecteerde source-diffregels uit session.c.diff. Deze wijziging reset de sessie-globale toestand expliciet eerder dan bij een gewone RINIT.

3. Waarom het bewijs ertoe doet

De geheugenopenbaarmaking vormt de brug tussen een procescrash en een exploitketen. Een sessiewaarde met een abnormale grootte en ingebedde binaire gegevens stemt overeen met een runtime die ongeldig geheugen als een Zend-string interpreteert. Het onderzoeksrapport beschrijft verder het extraheren van code- en heapadressen uit het gelekte venster. Het bewijsmateriaalpakket bevat de ruwe respons, maar geen zelfstandig script dat elk teruggevonden adres aantoont.

Het RCE-artefact toont de beveiligingscontext van www-data. Het bewijst geen roottoegang, compromittering van een productieomgeving of volledige overdraagbaarheid naar willekeurige PHP-implementaties. De laboratoriumconfiguratie met één worker is belangrijk omdat de volgorde van verzoeken en worker-affiniteit het mechanisme beïnvloeden.

4. Een oplossing voor de onderliggende levenscyclus, niet alleen het symptoom

De meegeleverde source diff voor PHP-patchcommit 01a40e89fbfc ("Avoid state corruption via bailout") toont vroege initialisatie van sessieglobalen, wijzigingen in de OOM-afhandeling van de allocator en bredere reset-/opschoningslogica. Deze wijzigingen zijn bedoeld om te voorkomen dat native state na een onderbroken verzoek in een ongeldige toestand blijft bestaan. Alleen het cookie-encoderingstraject repareren zou op zichzelf deze garantie voor geheugeneigendom niet herstellen.

Het onderzoeksrapport stelt dat pogingen tegen PHP 8.4.27 in vier proeven niet de afwijkende cookie, crash of RCE-bewijs opleverden. De daadwerkelijke transcripten van de gepatchte versie zitten niet in deze bundel, dus die vergelijking wordt gerapporteerd als een observatie van de onderzoeker in plaats van als een onafhankelijk inspecteerbaar bewijsstuk.

5. Defensieve acties

• Onmiddellijk. Werk de getroffen ondersteunde PHP-versielijn bij naar de release met de beveiligingsfix en gebruik adviezen van de leverancier om de exacte pakketstatus te bevestigen.

• Beperking van de blootstelling. Overweeg om multipart-invoer te beperken en code>session.upload_progress/code> uit te schakelen als deze niet wordt gebruikt; deze vervangen de patch niet.

• Detectie. Controleer crashes tijdens de initialisatie van aanvragen, onverwachte 500's en te grote code>Set-Cookie/code>-responsheaders.

• Borging. Test opnieuw met worker pools die representatief zijn voor productie en valideer dat oude sessiestatus niet kan blijven voortbestaan tussen verzoeken.

6. OrcaCyber onderzoeksmethodologie

De waardevolle onderzoeksopdracht is niet alleen het signaleren van individuele onveilige bewerkingen; het is het traceren van een volledige schending van een invariant over requestparsing, allocatorgedrag, persistente native globals, serialisatie en shutdown. OrcaCyber Zero en OrcaCyber Ultra werden gebruikt om de PoC in dit onderzoek te maken, zoals toegeschreven door het onderzoeksteam. De openbare artifactset ondersteunt de technische reproductie, maar biedt geen uitvoeringstraces per model en bewijst niet dat kwetsbaarheden autonoom zijn ontdekt.

Bewijsladder: hypothese in de broncode → bereikbare trigger → runtime-fout → informatielekkage → uitvoeringsbewijs → regressie van de opgeloste versie. Deze volgorde schept meer vertrouwen dan een kwetsbaarheidsbeschrijving of een resultaat dat enkel een crash aantoont. Ze moedigt ook aan om onzekerheid duidelijk te melden wanneer bronbestanden of ruwe uitvoeringslogs ontbreken.

7. Reikwijdte en beperkingen

Deze publicatie beschrijft een geautoriseerd geïsoleerd Docker-lab. De exploit is gebaseerd op eerder gepubliceerd PHP2Shell-onderzoek, met lokale aanpassing gedocumenteerd in het meegeleverde rapport. De bundel bevat scripts, diffs, responsbytes, logboeken en bewijsuitvoer, maar laat de volledige upstream exploit-checkout, native screenshots en volledige ruwe patch-regressietranscripten weg. Er wordt niet geclaimd dat een echt slachtoffer of een echte klant is gecompromitteerd.

Bronnen en artefacten

Primair: aangeleverd 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-broncodewijzigingen). Publieke context: PHP-beveiligingsadviezen GHSA-w8hw-w9fx-j79w en GHSA-6wmf-4rv5-p3rp; aankondigingen van PHP-beveiligingsreleases. Publieke toeschrijving van de exploit: 9bie/php2shell-bypass-aslr-exp. Onderzoeksrepository: orcacyber-php2shell-research.

Conclusie: één verzoek mislukte; een pointer bleef bestaan; het volgende verzoek vertrouwde erop. Het moeilijke aan het begrijpen van deze kwetsbaarheid is die verbinding vaststellen met waarneembaar bewijs.