In breve: quando un browser richiede una pagina PHP, il server web accetta la richiesta e la passa a PHP tramite un'interfaccia (SAPI). PHP traduce lo script in bytecode, lo esegue nella Zend Engine e restituisce il risultato, di solito HTML, al server web. Poi lo stato della richiesta viene ripulito, in modo che la successiva parta pulita.
Che cosa accade quando qualcuno apre il Suo sito web?
Per i visitatori è un clic. Sul server in pochi millisecondi si svolgono molti passaggi. Chi conosce questo flusso capisce meglio perché aggiornamenti, riavvii e configurazione siano così importanti e perché una vulnerabilità in PHP stesso pesi più di una vulnerabilità in un plugin.
Il manuale PHP indica tre componenti necessari per un sito PHP: l'interprete PHP (come CGI o modulo del server), un server web e un browser. L'interprete è il programma che legge ed esegue il codice PHP. Il modo in cui è collegato al server web determina la modalità di esecuzione.
Come funziona PHP? Sette passaggi di una richiesta
- Richiesta: il browser invia al server una richiesta HTTP, ad esempio
GET /kontakt.php. - Server web: Apache, Nginx o LiteSpeed accettano la richiesta. I file statici come le immagini li consegnano da soli. Per i file
.phpchiamano PHP. - Passaggio tramite la SAPI: l'interfaccia del server (SAPI) passa a PHP i dati della richiesta come intestazioni, parametri e dati dei moduli. Con PHP-FPM ciò avviene tramite il protocollo FastCGI, con mod_php direttamente nel processo Apache. Dettagli in SAPI spiegata.
- Preparare la richiesta: PHP deposita i dati della richiesta in variabili come
$_GET,$_POST,$_COOKIEe$_FILESe riserva memoria per la richiesta. - Tradurre: lo script viene scomposto in elementi (token), da cui nasce un albero sintattico astratto (AST) e da questo gli opcode, una specie di linguaggio macchina per PHP. Se OPcache è attivo, questo passaggio viene saltato quando lo script è già nella cache.
- Eseguire: la macchina virtuale della Zend Engine elabora gli opcode, interroga i database, legge i file e genera l'output.
- Risposta e pulizia: l'output torna al server web tramite la SAPI e da lì al browser. Poi PHP libera la memoria della richiesta e ripristina lo stato.
L'AST esiste dalla versione PHP 7. Secondo la relativa RFC, in precedenza il parser generava gli opcode direttamente durante la lettura; la suddivisione in tre fasi ha reso il compilatore più semplice da mantenere.
Un esempio: che cosa vede lo script della richiesta
Il seguente script innocuo mostra quali informazioni PHP riceve dalla richiesta e in quale modalità gira:
<?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";
Su un server con PHP-FPM PHP_SAPI restituisce il valore fpm-fcgi, con Apache e mod_php apache2handler. Salvi questi file di verifica solo per poco tempo e mai in modo permanente nella directory pubblica, perché le indicazioni di versione aiutano anche gli aggressori a orientarsi.
Dove entrano in gioco la cache di bytecode e il JIT
La traduzione del passaggio 5 richiede tempo. Secondo il manuale, OPcache memorizza nella memoria condivisa bytecode già compilato e risparmia così a PHP di caricare e scomporre gli script a ogni richiesta. Da PHP 8.0 un compilatore JIT può inoltre generare dagli opcode vero codice macchina. Secondo la RFC sul JIT è una componente quasi autonoma di OPcache.
| Fase | Risultato | Viene messo in cache? |
|---|---|---|
| Lexing | flusso di token | no |
| Parsing | albero sintattico astratto (AST) | no |
| Compilazione | opcode (op array per file e funzione) | sì, in OPcache |
| JIT (opzionale) | codice macchina | sì, nella memoria di OPcache |
| Esecuzione | output della pagina | no |
La cache riguarda solo il codice tradotto. I dati della singola richiesta, ad esempio gli input dei moduli o i valori di sessione, non vengono condivisi tramite OPcache.
Perché PHP2Shell colpisce proprio in questo flusso
Le due vulnerabilità di PHP2Shell non riguardano un'applicazione, ma il flusso stesso. Con CVE-2026-109618 una condizione di memoria esaurita (out-of-memory) può interrompere PHP mentre i dati della richiesta sono preparati solo in parte, cioè al passaggio 4. Nella successiva pulizia dati non validi possono poi essere trattati come validi.
Con CVE-2026-109619 lo stato interno di una richiesta può rimanere dopo la liberazione della memoria. Una richiesta successiva nello stesso worker può usarlo prima che venga ripristinato. Ciò riguarda il passaggio 7, la pulizia. Approfondimenti sono nella pagina CVE-2026-109619 e nell'articolo sul ciclo di vita della richiesta.
Ne consegue che le misure di protezione nel codice dell'applicazione, ad esempio i plugin di sicurezza, intervengono solo al passaggio 6. Con mod_php, secondo il team PHP, è stato mostrato un exploit perfino prima che giri qualsiasi codice dell'applicazione. È efficace solo l'aggiornamento di PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 insieme al riavvio di tutti i processi PHP, perché altrimenti i worker di lunga durata continuano a eseguire il vecchio codice.
Come aiuta concretamente PHP SOS?
- Rendere visibile il flusso: accertiamo quali modalità di esecuzione, configurazione e cache sono effettivamente attive sul Suo server.
- Aggiornare correttamente: installiamo l'aggiornamento di PHP e verifichiamo dagli orari di avvio che non giri più alcun vecchio processo.
- Proteggere i livelli: nell'ambito dell'hardening del server limitiamo dimensioni delle richieste, memoria e permessi dove sono efficaci: prima del codice dell'applicazione.
- Cercare tracce: sui server raggiungibili senza protezione cerchiamo segni di un'intrusione.
Domande frequenti
Il codice PHP viene tradotto di nuovo a ogni richiesta?
Senza cache sì: PHP scompone lo script, costruisce un albero sintattico e ne ricava gli opcode. Con OPcache attivo gli opcode restano nella memoria condivisa e vengono riutilizzati finché il file non cambia.
Che cosa resta in memoria dopo una richiesta?
In linea di principio lo stato di una richiesta viene ripulito alla fine, in modo che la richiesta successiva parta pulita. Hanno vita lunga solo elementi come OPcache o le connessioni persistenti. È proprio in questa pulizia che interviene CVE-2026-109619.
Perché PHP va riavviato dopo un aggiornamento?
Con PHP-FPM e mod_php i processi girano in modo continuativo e hanno già caricato il vecchio codice del programma. I nuovi file sul disco non cambiano nulla. Solo un riavvio carica il codice corretto.
Un server web senza PHP è più sicuro?
Ha meno superficie di attacco, perché nessuna logica di programma reagisce alle richieste. Per contenuti puramente statici è un'opzione reale. Per shop, moduli e login serve però un linguaggio lato server, e allora conta la sua manutenzione.