--- title: 'PHP2Shell: RCE critico in tutto PHP | DevSense' description: 'Anatomia di PHP2Shell — CVE-2026-109618 e CVE-2026-109619, un RCE non autenticato nel cuore di PHP: come sono fatte le vulnerabilità, perché fanno paura, chi si è precipitato a correre ai ripari e come proteggere il tuo server. Senza exploit funzionante, a scopo didattico.' faq: - { question: "Cos'è PHP2Shell e quali versioni di PHP sono coinvolte?", answer: "PHP2Shell è il nome collettivo di due vulnerabilità del cuore di PHP, CVE-2026-109618 e CVE-2026-109619, divulgate il 21 ottobre 2026. Insieme consentono l'esecuzione di codice da remoto senza autenticazione attraverso il normale parsing di una richiesta HTTP. Sono coinvolti praticamente tutti i rami dell'ultimo decennio; le correzioni sono arrivate con PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mentre per 8.1/8.0/7.4 PHP ha rilasciato backport minimi." } - { question: "L'attaccante ha bisogno di autenticazione o di un plugin vulnerabile?", answer: "No. È proprio qui il punto: la falla è nel cuore stesso di PHP, sul percorso di parsing della richiesta in arrivo, che viene eseguito ancora prima del codice dell'applicazione. Non servono né login, né una CMS specifica, né un plugin vulnerabile — basta che il server accetti richieste HTTP e faccia girare PHP. Ecco perché i ricercatori parlano del «70% del web»: è la quota di siti basati su PHP, non il numero di server davvero violati." } - { question: 'La vulnerabilità viene sfruttata in attacchi reali?', answer: 'Al momento della stesura (terzo giorno dalla divulgazione) non ci sono violazioni pubblicamente confermate proprio tramite PHP2Shell, ma Cloudflare e altri osservano già scansioni e tentativi di sfruttamento, per di più con mutazione del payload per aggirare i filtri. Con un RCE non autenticato fino a CVSS 9.2, la finestra tra «nessuno ha fatto in tempo ad aggiornare» e «sono arrivati gli attacchi di massa» si misura in giorni.' } - { question: 'Cosa fare subito se aggiornare immediatamente non è possibile?', answer: "L'aggiornamento di PHP è l'unica soluzione completa. Finché non è distribuito: attiva un WAF (Cloudflare, Fastly, Akamai, Imperva e i provider cloud hanno già rilasciato protezioni di default), limita la dimensione del corpo della richiesta sul reverse proxy, disabilita session.upload_progress.enabled e, su PHP 8.5, fatal_error_backtraces, e tieni d'occhio nei log gli errori di memoria esaurita con «Unknown on line 0» e i crash dei worker. Riduce il rischio, ma non chiude la falla." } published: '2026-10-23' --- # PHP2Shell: RCE critico in tutto PHP — cos'è successo e come difendersi Esiste un tipo speciale di vulnerabilità: quelle che vivono non nel plugin di qualcuno, né in una riga storta di una singola applicazione, ma nelle fondamenta stesse su cui poggia tutto il resto. PHP2Shell è esattamente così. Non è una falla in WordPress, non è lo scivolone di un singolo sviluppatore e non è un `eval()` dimenticato. È una crepa nel muro portante: in quel codice del cuore di PHP che analizza la richiesta in arrivo ancora prima che venga eseguita la prima riga della tua applicazione. Il 21 ottobre 2026 PHP ha pubblicato release d'emergenza e divulgato due vulnerabilità — **CVE-2026-109618** e **CVE-2026-109619** — che insieme regalano ciò di più temibile che quasi esista nel web: **l'esecuzione di codice da remoto senza autenticazione**. Senza login. Senza plugin vulnerabile. Senza un solo clic della vittima. Questo articolo è stato scritto nel terzo giorno dalla divulgazione, quando la patch esiste già ma metà di internet non ha ancora aggiornato — ed è proprio per questo scritto senza una sola riga di exploit funzionante. Analizzeremo cosa si è rotto e perché è così pericoloso, ma non consegneremo un'arma in mano a nessuno. L'obiettivo è che tu capisca il nemico e chiuda la porta, non che qualcuno assembli un attacco a partire dal nostro testo. **Materiali correlati:** [Attacchi web e come prevenirli](web-attacks-and-prevention) · [Integrazioni resilienti](resilient-external-integrations) · [Osservabilità e monitoraggio](observability-monitoring-laravel) · [Zero-downtime deployment](zero-downtime-deployment-laravel) ## Indice * [In breve: cosa sapere in trenta secondi](#tldr) * [Perché una vulnerabilità nel cuore è un'altra scala di grandezza](#why-core) * [Timeline: come l'IA ha trovato la falla in tutto PHP](#timeline) * [Due porte: cosa si nasconde dietro i due CVE](#two-doors) * [Quanto è grave il danno](#impact) * [Lo sguardo dell'attaccante: modello delle minacce senza istruzioni](#attacker) * [Chi si è già precipitato a correre ai ripari](#responders) * [Ci sono già vittime](#victims) * [Come difendersi: passo per passo](#defense) * [Come vedere l'attacco nei tuoi log](#detection) * [PHP è vivo — e questa ne è la prova](#php-alive) * [Checklist](#checklist) * [Quiz di autoverifica](#self-test-quiz) --- ## In breve: cosa sapere in trenta secondi * **Cosa:** due vulnerabilità del cuore di PHP sotto il nome comune di PHP2Shell — CVE-2026-109618 e CVE-2026-109619. * **Cosa comporta:** esecuzione di codice da remoto senza autenticazione (RCE), gravità fino a **CVSS 9.2**. * **Chi colpisce:** praticamente tutti i rami di PHP dell'ultimo decennio, indipendentemente da CMS e framework. * **Dove è corretta:** PHP **8.5.12, 8.4.27, 8.3.36, 8.2.35**; per 8.1/8.0/7.4 — backport minimi dal team di PHP. * **Cosa fare:** aggiornare PHP e riavviare PHP-FPM e i worker delle code. Subito. Il resto sono solo puntelli temporanei. Se stai leggendo questo dalla produzione, su una versione non patchata — chiudi l'articolo, aggiorna, torna. Sul serio. --- ## Perché una vulnerabilità nel cuore è un'altra scala di grandezza La maggior parte delle vulnerabilità web assomiglia a una finestra lasciata aperta in un singolo appartamento: un bug in un plugin, una SQL injection in un controller scritto a mano, un controllo dei permessi dimenticato. Sistemi l'appartamento e la finestra è chiusa. PHP2Shell, invece, è un difetto di fabbrica nella serratura montata su una porta su due del pianeta. PHP elabora la richiesta in arrivo a strati. Prima c'è il cuore: legge le intestazioni, analizza il corpo della richiesta, riempie i superglobali `$_POST`, `$_FILES`, `$_COOKIE`. E solo dopo il controllo arriva al tuo codice — al router di Laravel, al cuore di WordPress, alla prima riga che hai scritto tu. PHP2Shell vive **sul primo strato**. Il percorso vulnerabile viene eseguito per tutti e sempre, semplicemente perché il server ha accettato una richiesta. Da qui la famosa formula dei ricercatori sul «70% di internet». È importante capire cosa significa: PHP serve circa il 70% di tutti i siti del mondo, e la superficie d'attacco teorica sono tutti loro. Questo **non** significa che il 70% dei siti sia già stato violato o che ciascuno di essi sia garantito di cadere in una sola richiesta. Significa che il tetto di questa vulnerabilità ha le dimensioni del web. --- ## Timeline: come l'IA ha trovato la falla in tutto PHP Questa storia ha un dettaglio per cui finirà sui libri di testo — e non è la vulnerabilità in sé. È stata trovata non con un classico audit manuale, ma grazie al tandem uomo-IA. I ricercatori di Wiz hanno condotto la caccia con l'aiuto di modelli moderni e, a loro stesse parole, il modello ha dato un «contributo inestimabile» non solo all'individuazione, ma anche alla trasformazione delle scoperte in exploit funzionanti contro diversi bersagli — «in poche ore». Viviamo in un mondo in cui il fuzzing del cuore di PHP è condotto non solo da un umano con un debugger, ma anche da un'IA, e entrambi i lati della barricata lo hanno già capito. Cronologia del 2026 (secondo i dati di Wiz): | Data | Evento | |------|---------| | 19 agosto | Trovata la prima delle vulnerabilità | | 20 agosto | Confermato un RCE non autenticato contro Drupal | | 21 agosto | Confermato un RCE non autenticato contro WordPress | | 24 agosto | Segnalato al team di sicurezza di PHP | | 21 settembre | PHP conferma il problema e avvia una correzione coordinata | | 21 ottobre | Rilasciate le patch e avvenuta la divulgazione pubblica | Quasi due mesi — tra la segnalazione silenziosa al team di PHP e la divulgazione pubblica. Ed è proprio questo il processo corretto, «da adulti»: prima si ripara, poi si racconta. L'articolo che stai leggendo è apparso due giorni dopo l'ultima riga di questa tabella. --- ## Due porte: cosa si nasconde dietro i due CVE Sotto il nome PHP2Shell si nascondono due difetti distinti — due porte che danno sulla stessa stanza. Ricercatori e vendor diversi descrivono i bug alla base con lievi divergenze nei dettagli, e dietro ogni CVE si cela più una classe di problemi che una singola riga. Rimaniamo di proposito al livello della meccanica — «cosa esattamente si è rotto» — senza scendere alla ricetta per arrivare alla shell. ### CVE-2026-109618 — gestione dei dati in arrivo della richiesta La prima porta si apre nella fase in cui PHP analizza il corpo di una richiesta POST e la gestione degli upload. Il problema sta nel modo in cui viene trattata la memoria lungo questo percorso: con una certa forma dei dati in ingresso, il cuore accede a memoria che ha già liberato, oppure sbaglia la contabilità quando la alloca. Dove dovrebbe esserci un ordinato «alloca — usa — libera», si apre una finestra in cui lo stato della memoria smette di corrispondere a ciò che il codice si aspetta. E una gestione della memoria compromessa in codice nativo è un classico trampolino: da lì parte la strada sia verso la fuga di frammenti della memoria del processo (e quindi verso l'aggiramento di difese come l'ASLR), sia verso il controllo dell'esecuzione. Dettaglio chiave: questo percorso non richiede né autenticazione, né una configurazione particolare dell'applicazione. Basta che PHP analizzi automaticamente il corpo della richiesta — e lo fa sempre. ### CVE-2026-109619 — stato residuo tra una richiesta e l'altra La seconda porta è più sottile e, in un certo senso, più elegante. PHP-FPM è un processo a vita lunga: lo stesso worker serve richiesta dopo richiesta, senza ricaricare il framework (perché questo è insieme veloce e pericoloso l'abbiamo analizzato nell'articolo sulle [code in produzione](laravel-queues-production#memory)). Se dopo l'elaborazione di una richiesta nel worker rimane uno stato «spazzatura» — per esempio dal meccanismo di tracciamento dell'avanzamento degli upload (`session.upload_progress`) o dalla costruzione delle tracce degli errori fatali — allora la richiesta successiva può inciampare in questi dati andati a male. Una richiesta prepara la trappola, la seconda ci casca dentro. L'insidia sta nel fatto che parte di questi meccanismi funziona anche se l'applicazione non li ha mai invocati esplicitamente. `session.upload_progress` è attivo di default e scatta senza un solo `session_start()` nel tuo codice. > [!NOTE] > Tieni a mente due impostazioni della seconda porta — `session.upload_progress.enabled` e (su PHP 8.5) `fatal_error_backtraces`. Più sotto, nella sezione sulla difesa, sono proprio queste che andremo a coprire, se aggiornare in questo momento non è possibile. --- ## Quanto è grave il danno L'RCE è il vertice della catena alimentare delle vulnerabilità. Non «dati trafugati», non «pagina alterata», ma **codice altrui che gira sul tuo server con i privilegi del tuo processo web**. Cosa significa in pratica: * **Controllo totale sull'applicazione.** L'attaccante legge e modifica qualunque cosa nel codice e nei file accessibili a `www-data`. * **Accesso ai segreti.** Il `.env` con la password del database, le chiavi dei sistemi di pagamento, i token delle API, l'`APP_KEY` — tutto ciò che il processo può leggere, lo legge anche l'attaccante. * **Il database per intero.** Non tramite un'injection ingegnosa, ma direttamente — con le stesse credenziali dell'applicazione. * **Movimento laterale.** Il server diventa una testa di ponte: da qui si scansiona la rete interna, si attaccano i servizi vicini, ci si radica tramite una web shell. * **Silenzio.** Uno sfruttamento riuscito può restituire un normale HTTP 200 e non far cadere il worker. Da fuori: niente. Dentro: lo sconosciuto è già in casa. Per un sito come DevSense, dove non ci sono pagamenti né dati personali degli utenti oltre il minimo, il danno diretto è minore che per un e-commerce o una banca. Ma «minore» non vuol dire «nullo»: anche il nostro server è accesso al database, alle chiavi della posta, all'infrastruttura di deploy e un'ottima testa di ponte per attacchi ad altri. Per questo [abbiamo aggiornato PHP](../tools/dockerfile-php-best-practices) lo stesso giorno. --- ## Lo sguardo dell'attaccante: modello delle minacce senza istruzioni Guardare la vulnerabilità con gli occhi dell'attaccante è utile — così si capisce meglio dove piazzare le difese. Ma «lo sguardo dell'attaccante» qui significa **modello delle minacce ed economia dell'attacco**, non una ricetta passo per passo. La ricetta non la daremo per principio: ha due giorni, colpisce un RCE non autenticato, e metà dei server non è ancora al sicuro. Cosa muove l'attaccante in una situazione del genere: * **La quantità conta più della precisione.** Quando è vulnerabile «tutto il web», nessuno sceglie la vittima di mira. Parte una scansione a tappeto: si prova con tutti indiscriminatamente, ci si radica su chi ha ceduto. Il tuo sito finisce sotto attacco non perché sei interessante, ma perché esisti e rispondi alle richieste. * **La corsa con la patch.** Il valore dell'exploit è massimo nei primi giorni, finché le masse non hanno aggiornato. Da qui l'impennata di attività subito dopo la divulgazione — già osservabile. * **Aggiramento dei filtri.** Appena i vendor di WAF hanno rilasciato le regole, gli attaccanti hanno iniziato a mutare il payload per non caderci dentro. Lo ha già rilevato Cloudflare. Conclusione per te: il WAF è tempo guadagnato, non una vittoria. Vince solo la patch. * **L'automazione è anche dalla loro parte.** Se l'IA ha aiutato a trovare e a sviluppare la vulnerabilità in poche ore dal lato dei ricercatori, allora anche dal lato degli aggressori il ciclo «dal CVE allo scanner di massa» è diventato più breve che mai. Il senso pratico di questa ottica è uno solo: non contare sul fatto che «il mio piccolo sito non interessa a nessuno». Nel mondo degli attacchi a tappeto, i siti che non servono non esistono. --- ## Chi si è già precipitato a correre ai ripari La buona notizia: l'industria ha reagito a PHP2Shell come un organismo coeso, e questa è forse la migliore illustrazione del fatto che l'ecosistema PHP è vivo e in salute. La divulgazione è stata coordinata — all'ora X la protezione era già in piedi. * **Cloudflare** ha rilasciato le regole WAF **circa 9 ore prima della divulgazione pubblica** e ha attivato la protezione di default il 21 ottobre alle 3:02 UTC — su tutti i piani, compreso quello gratuito, senza alcun intervento del cliente. Secondo i loro dati, vedono già traffico d'attacco e le sue mutazioni. * **Fastly, Akamai, Imperva** — hanno rilasciato proprie regole difensive per i clienti che non possono aggiornare all'istante. * **AWS, Google Cloud, Microsoft, Vercel** — hanno pubblicato guide di risposta e protezioni a livello delle proprie piattaforme. * **Automattic** (l'azienda dietro WordPress.com) e altri attori dell'ecosistema — nell'elenco di chi ha aiutato con la risposta coordinata. Un discorso a parte merita lo stesso team di sicurezza di PHP: due mesi di lavoro silenzioso, il rilascio sincrono delle patch su tutti i rami supportati e persino backport per i rami il cui supporto ufficiale è già finito (7.4, 8.0, 8.1). Per un progetto che da anni viene seppellito nei commenti, è una reazione esemplare. --- ## Ci sono già vittime Qui è importante essere onesti e non moltiplicare il panico. **Nel terzo giorno dalla divulgazione non ci sono violazioni pubblicamente confermate proprio tramite PHP2Shell.** Nessuna grande organizzazione è stata finora indicata come vittima. Ma alcune cose sono note con certezza: * Gli exploit funzionanti esistono — sono stati dimostrati dai ricercatori contro immagini aggiornate di WordPress, Drupal e Joomla. È una dimostrazione della superficie, non la radice del problema: la questione non sta in queste CMS, ma in PHP sotto di esse. * Scansioni e tentativi di sfruttamento sono già in corso — lo dicono sia Cloudflare, che osserva traffico d'attacco, sia i bollettini di settore, che registrano la «comparsa di tentativi di sfruttamento». * L'assenza di vittime pubbliche al terzo giorno non è «l'abbiamo scampata», ma «è ancora presto». Tra la scansione di massa e i primi report pubblici sulle violazioni di solito passano settimane. La finestra in cui bisogna fare in tempo ad aggiornare è aperta proprio adesso. In parole semplici: il silenzio sul tabellone non è il cessato allarme, è un vantaggio. Sfruttalo. --- ## Come difendersi: passo per passo ### 1. Aggiorna PHP — è l'unica vera soluzione Tutto il resto qui sotto sono puntelli che comprano tempo. La falla la chiude solo la patch. ```bash # Debian/Ubuntu, repository di Ondřej Surý (come il nostro) sudo apt-get update sudo apt-get install --only-upgrade -y \ $(dpkg-query -W -f='${db:Status-Abbrev} ${Package}\n' 'php8.5*' | awk '$1 == "ii" {print $2}') # Riavviare tutto ciò che tiene il vecchio binario in memoria sudo systemctl restart php8.5-fpm sudo supervisorctl restart all # anche i worker delle code sono PHP ``` Versioni di destinazione: **8.5.12 / 8.4.27 / 8.3.36 / 8.2.35** o più recenti. Verifica sia la CLI sia FPM: ```bash php -v | head -1 /usr/sbin/php-fpm8.5 -v | head -1 ``` > [!WARNING] > Il riavvio di PHP-FPM è obbligatorio. Il processo a vita lunga tiene in memoria il vecchio binario vulnerabile anche dopo `apt upgrade`, finché non viene riavviato. Lo stesso vale per i worker delle code sotto Supervisor o Horizon — non vedono il nuovo PHP fino al riavvio. Nel dettaglio su aggiornamento e ricostruzione delle immagini — nella nostra analisi dell'[immagine di produzione per PHP](../tools/dockerfile-php-best-practices). ### 2. Alza un WAF Se sei dietro Cloudflare — la protezione è già attiva di default, verifica solo che le regole siano in modalità di blocco. Fastly, Akamai, Imperva e i provider cloud hanno rilasciato qualcosa di analogo. Ricorda la mutazione del payload: il WAF è una misura temporanea. ### 3. Limita il corpo della richiesta al confine Sul reverse proxy (nginx, bilanciatore) taglia i corpi di richiesta anomalmente grandi prima che arrivino a PHP. Non cura, ma abbatte una parte consistente dei tentativi automatici. ### 4. Copri la seconda porta con le impostazioni Se la patch non è ancora stata distribuita — disabilita i meccanismi attraverso cui opera CVE-2026-109619. DevSense non li usa, e questo non incide sul funzionamento del sito: ```ini ; /etc/php/8.5/fpm/conf.d/99-hardening.ini session.upload_progress.enabled = 0 fatal_error_backtraces = 0 ; solo PHP 8.5 expose_php = Off ``` ```bash sudo systemctl restart php8.5-fpm ``` Questo riduce l'esposizione, ma **non sostituisce l'aggiornamento**. --- ## Come vedere l'attacco nei tuoi log Una difesa senza osservabilità è cieca. Ecco gli indicatori onesti su cui vale la pena tenere gli occhi (nessuno di essi da solo prova una violazione — conta la correlazione): * **Nei log di PHP-FPM:** `Allowed memory size ... exhausted` in combinazione con `Unknown on line 0`. La stringa `on line 0` significa che il crash è avvenuto nella fase di inizializzazione della richiesta, ancora prima del codice dell'applicazione — ed è proprio lì che vive la prima porta. * **Crash dei worker:** segfault (`SIGSEGV`, `exited on signal 11`) nei log di PHP-FPM o di Apache, soprattutto in serie. * **Richieste anomale:** POST con nomi di campo insolitamente lunghi (dell'ordine dei megabyte), dati binari e byte nulli nei valori dei campi. * **Cookie `PHPSESSID` insolitamente grandi** — uno dei segnali indicati dagli stessi ricercatori. * **Processi orfani lanciati dall'utente web:** una shell avviata da `www-data` non è più un indizio, ma quasi una condanna: ```bash ps -eo user,pid,ppid,cmd | awk '$1=="www-data"' | grep -vE "php-fpm|nginx" sudo grep -h "Unknown on line 0" /var/log/php8.5-fpm.log* 2>/dev/null | tail ``` Come integrare questi segnali in un monitoraggio e in alert permanenti — nell'articolo sull'[osservabilità](observability-monitoring-laravel). --- ## PHP è vivo — e questa ne è la prova PHP viene seppellito con invidiabile regolarità. «Linguaggio morto», «legacy», «sono tutti passati a Node e Go» — questo necrologio lo scrivono ogni anno. PHP2Shell, per quanto paradossale, è un argomento in direzione esattamente opposta. In primo luogo, una vulnerabilità di questa portata è possibile solo in una tecnologia su cui poggia davvero una parte enorme del web. I linguaggi morti non finiscono nei titoli di CISA e non costringono Cloudflare a rilasciare una protezione nove ore prima della divulgazione. In una falla grande come il 70% di internet ci cade dentro solo ciò che quell'internet sostiene. In secondo luogo — ed è l'essenziale — guarda alla reazione. Il team di sicurezza di PHP ha condotto una correzione coordinata esemplare, ha rilasciato le patch su tutti i rami in modo sincrono e ha persino portato le fix nei rami senza supporto ufficiale. L'intera industria — da Automattic ad AWS — ha lavorato come un unico organismo. Non è così che si comporta un progetto morente, ma un ecosistema maturo, vivo, con processi da adulti. PHP 8.5 con i property hook, la visibilità asimmetrica, le proprietà tipizzate e l'operatore pipe è un linguaggio moderno, non un pezzo da museo. Ciò che è vivo ha un sistema immunitario, e nell'ottobre 2026 ha reagito in fretta e in modo coeso. Più vivo di tutti i vivi — anche perché sa rimarginare in fretta ferite come queste. --- ## Checklist 1. PHP aggiornato a 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 o più recente — sia la CLI sia PHP-FPM. 2. PHP-FPM riavviato; worker delle code (Supervisor/Horizon) riavviati. 3. Verificato che il processo FPM non tenga il vecchio binario (`/proc//exe` senza l'etichetta `(deleted)`). 4. WAF attivo e in modalità di blocco; ricorda la temporaneità di questa misura. 5. Al confine è limitata la dimensione del corpo della richiesta. 6. Se la patch non è distribuita — disabilitati `session.upload_progress.enabled` e `fatal_error_backtraces`. 7. Log controllati per `Unknown on line 0`, segfault e shell lanciate da `www-data`. 8. Immagini dei container ricostruite e ri-deployate, se PHP viene installato da un'immagine. --- ## Conclusione PHP2Shell è uno di quei rari casi in cui una vulnerabilità è interessante non solo per ciò che rompe, ma anche per ciò che mostra. Rompe le fondamenta: un RCE non autenticato nel cuore su cui poggia gran parte del web. E mostra — che l'ecosistema attorno a quel cuore è vivo, rapido e coeso. La patch è uscita, i grandi attori hanno fatto scudo a chi non ha fatto in tempo, e da te si richiede un'azione sola e semplice: aggiornare e riavviare. Fallo prima che finisca il vantaggio. --- ## Quiz di autoverifica ### Domanda 1: Perché PHP2Shell è più pericolosa di una tipica vulnerabilità in un plugin di una CMS? - A) Perché è più difficile da individuare con gli scanner. - B) Perché è nel cuore di PHP, sul percorso di parsing della richiesta, e scatta prima del codice dell'applicazione — senza autenticazione e indipendentemente da CMS o framework. - C) Perché riguarda solo le versioni obsolete di PHP.
Mostra la risposta **Risposta: B** Il difetto vive sul primo strato di elaborazione della richiesta, comune a tutte le applicazioni PHP. Non servono né login, né una CMS specifica, né un plugin vulnerabile — basta che il server accetti richieste ed esegua PHP.
### Domanda 2: Perché dopo `apt upgrade` è obbligatorio riavviare PHP-FPM e i worker delle code? - A) Altrimenti i file di configurazione non si aggiornano. - B) Perché i processi a vita lunga tengono in memoria il vecchio binario vulnerabile di PHP, finché non vengono riavviati. - C) Per svuotare l'OPcache dalle pagine statiche.
Mostra la risposta **Risposta: B** PHP-FPM e i worker delle code sono processi a vita lunga. Continuano a eseguire il vecchio binario caricato in memoria anche dopo l'aggiornamento del pacchetto, finché non vengono riavviati. Lo si può verificare dal collegamento simbolico `/proc//exe`.
### Domanda 3: Perché il WAF è tempo guadagnato e non una soluzione completa? - A) Il WAF rallenta il sito e lo si deve disattivare. - B) Perché gli attaccanti mutano il payload per aggirare le regole — la falla la chiude solo l'aggiornamento di PHP. - C) Perché il WAF protegge solo dagli attacchi autenticati.
Mostra la risposta **Risposta: B** Le regole del WAF filtrano le forme note di attacco, ma gli aggressori stanno già mutando il payload per non caderci dentro (lo ha rilevato Cloudflare). Il WAF riduce il rischio e compra tempo per l'aggiornamento, ma l'unica soluzione completa è la patch.