Cum generează PHP o pagină web: drumul unei cereri

Pe scurt: Când un browser solicită o pagină PHP, serverul web primește cererea și o transmite lui PHP printr-o interfață (SAPI). PHP traduce scriptul în bytecode, îl execută în Zend Engine și returnează rezultatul, de obicei HTML, serverului web. După aceea, starea cererii este curățată, pentru ca următoarea să înceapă curat.

Ce se întâmplă când cineva accesează site-ul dumneavoastră?

Pentru vizitator este un clic. Pe server se desfășoară în milisecunde mulți pași. Cine cunoaște acest proces înțelege mai bine de ce actualizările, repornirile și configurația sunt atât de importante și de ce o vulnerabilitate în PHP însuși cântărește mai greu decât una într-un plugin.

Manualul PHP menționează trei componente necesare pentru un site PHP: interpretorul PHP (ca CGI sau modul de server), un server web și un browser. Interpretorul este programul care citește și execută codul PHP. Modul în care este conectat la serverul web determină modul de operare.

Cum funcționează PHP? Șapte pași ai unei cereri

1. Cererea: Browserul trimite serverului o cerere HTTP, de exemplu GET /kontakt.php.
2. Serverul web: Apache, Nginx sau LiteSpeed primesc cererea. Fișierele statice, precum imaginile, le livrează singure. Pentru fișierele .php apelează PHP.
3. Transmiterea prin SAPI: Interfața de server (SAPI) transmite lui PHP datele cererii, precum antetele, parametrii și datele din formulare. La PHP-FPM, acest lucru se face prin protocolul FastCGI, la mod_php direct în procesul Apache. Detalii la SAPI explicat.
4. Pregătirea cererii: PHP depune datele cererii în variabile precum $_GET, $_POST, $_COOKIE și $_FILES și rezervă memorie pentru cerere.
5. Traducerea: Scriptul este descompus în elemente (tokens), din care rezultă un arbore sintactic abstract (AST) și din acesta opcodes, un fel de limbaj-mașină pentru PHP. Dacă OPcache este activ, acest pas este sărit atunci când scriptul se află deja în cache.
6. Execuția: Mașina virtuală a Zend Engine parcurge opcodes, interoghează baze de date, citește fișiere și generează ieșirea.
7. Răspunsul și curățarea: Ieșirea ajunge prin SAPI înapoi la serverul web și de acolo la browser. Apoi PHP eliberează memoria cererii și resetează starea.

AST există din PHP 7. Potrivit RFC-ului corespunzător, înainte parserul genera opcodes direct în timpul citirii; separarea în trei faze a făcut compilatorul mai ușor de întreținut.

Un exemplu: ce vede scriptul din cerere

Scriptul inofensiv de mai jos arată ce informații primește PHP din cerere și în ce mod de operare rulează:

<?php
header('Content-Type: text/plain; charset=utf-8');

echo 'Betriebsart (SAPI): ' . PHP_SAPI . "\n";
echo 'PHP-Version: ' . PHP_VERSION . "\n";
echo 'Methode: ' . ($_SERVER['REQUEST_METHOD'] ?? '-') . "\n";
echo 'Speicher in dieser Anfrage: ' . memory_get_usage() . " Bytes\n";

Pe un server cu PHP-FPM, PHP_SAPI returnează valoarea fpm-fcgi, sub Apache cu mod_php apache2handler. Păstrați asemenea fișiere de verificare în directorul public doar pentru scurt timp și niciodată permanent, deoarece informațiile despre versiune îi ajută și pe atacatori să se orienteze.

Unde intră în joc cache-ul de bytecode și JIT

Traducerea din pasul 5 consumă timp. OPcache stochează, potrivit manualului, bytecode precompilat în memoria comună și scutește astfel PHP de încărcarea și descompunerea scripturilor la fiecare cerere. Începând cu PHP 8.0, un compilator JIT poate genera suplimentar cod-mașină real din opcodes. Potrivit RFC-ului JIT, acesta este o parte aproape independentă a OPcache.

Cache-ul privește doar codul tradus. Datele fiecărei cereri, de exemplu introducerile din formulare sau valorile de sesiune, nu sunt partajate prin OPcache.

De ce PHP2Shell intervine exact în acest proces

Cele două vulnerabilități PHP2Shell nu privesc o aplicație, ci procesul însuși. La CVE-2026-109618, o stare de lipsă de memorie (out-of-memory) poate întrerupe PHP în timp ce datele cererii sunt pregătite doar parțial, deci în pasul 4. La curățarea ulterioară, datele nevalide pot fi tratate ca valide.

La CVE-2026-109619, starea internă a unei cereri poate persista după eliberarea memoriei. O cerere ulterioară în același worker o poate folosi înainte să fie resetată. Aceasta privește pasul 7, curățarea. Contextul se găsește pe pagina CVE-2026-109619 și în articolul despre ciclul de viață al cererii.

Rezultă: măsurile de protecție din codul aplicației, de exemplu pluginurile de securitate, acționează abia în pasul 6. La mod_php, potrivit echipei PHP, a fost demonstrat chiar un exploit înainte să ruleze vreun cod al aplicației. Eficientă este doar actualizarea PHP la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 și repornirea tuturor proceselor PHP, deoarece workerii de lungă durată continuă altfel să execute codul vechi.

Cum ajută PHP SOS concret?

• Procesul devine vizibil: Stabilim ce mod de operare, ce configurație și ce cache sunt de fapt active pe serverul dumneavoastră.
• Actualizare corectă: Instalăm actualizarea PHP și verificăm, pe baza orelor de pornire, că nu mai rulează niciun proces vechi.
• Securizarea straturilor: În cadrul întăririi serverului limităm dimensiunile cererilor, memoria și drepturile acolo unde acționează: înaintea codului aplicației.
• Verificarea urmelor: La serverele accesibile fără protecție căutăm semne ale unei intruziuni.

Întrebări frecvente

Surse

• Manualul PHP: introducere
• PHP RFC: Abstract Syntax Tree
• PHP RFC: JIT
• Manualul PHP: OPcache