# PHP2Shell: due falle critiche in PHP, una richiesta HTTP e il server è tuo. Come aggiornare > CVE-2026-109618 e CVE-2026-109619, ribattezzate PHP2Shell: due vulnerabilità nel motore di PHP permettono l'esecuzione di codice da remoto senza autenticazione, già sfruttate in rete. Cosa sono, chi è esposto e come si risolve davvero: aggiornare l'interprete, non il CMS. - URL: https://mautoblog.com/posts/php2shell-vulnerabilita-critiche-php-rce-aggiornare-2026/ - Lingua: it - Pubblicato: 2026-10-22 - Autore: Matteo - Categorie: Sicurezza e Privacy, Sviluppo Software - Tags: PHP, Cybersecurity, DevOps, Docker - Traduzione (en): https://mautoblog.com/en/posts/php2shell-critical-php-vulnerabilities-rce-update-2026/ --- C'è un tipo di notizia di sicurezza che fa paura più delle altre: quella in cui il problema non sta nel tuo codice, né in un plugin scaricato da chissà dove, ma nel **linguaggio stesso**. È il caso di questa settimana. Il 21 ottobre il PHP Security Team ha rilasciato correzioni per due vulnerabilità critiche nel motore di PHP, la **CVE-2026-109618** e la **CVE-2026-109619**, ribattezzate collettivamente **PHP2Shell**. Il [CERT-AGID](https://cert-agid.gov.it/news/due-vulnerabilita-critiche-in-php-consentono-lesecuzione-di-codice-da-remoto-rilasciati-aggiornamenti-di-sicurezza/) e il [CERT-EU](https://cert.europa.eu/publications/security-advisories/2026-018/) hanno subito diramato i loro avvisi. Punteggio CVSS v4.0: **9.2** per entrambe. Tradotto: una richiesta HTTP costruita ad arte, nessuna autenticazione, e in certe configurazioni l'attaccante esegue codice sul server **prima ancora che parta la tua applicazione**. ## Cosa si è rotto (spiegato senza puntatori) Tutte e due le falle nascono da errori di gestione della memoria all'interno dell'interprete. - **CVE-2026-109618, la memoria che finisce a metà.** Se PHP esaurisce la memoria mentre sta preparando una richiesta, alcune strutture interne restano inizializzate a metà. Il codice di pulizia che parte subito dopo le tratta come se fossero valide. E da lì si arriva a scrivere dove non si dovrebbe. - **CVE-2026-109619, lo stato che sopravvive.** Una richiesta lascia dietro di sé uno stato globale che punta a memoria già liberata (un classico *use-after-free*). La richiesta successiva servita dallo **stesso worker** ci inciampa sopra. Oltre all'esecuzione di codice, PHP conferma anche la possibile lettura di memoria. È come un cameriere che sparecchia un tavolo mentre i clienti stanno ancora ordinando, e poi porta il conto sbagliato al tavolo dopo. ## Chi rischia di più Sono coinvolti praticamente tutti i modi di far girare PHP: **PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed**. Secondo il team di PHP però il rischio è massimo con **Apache mod_php**, dove una singola richiesta non autenticata può far partire l'exploit prima di qualsiasi codice applicativo. Con PHP-FPM lo sfruttamento è possibile solo in condizioni specifiche. Secondo [Tenable](https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote), il primo percorso di codice vulnerabile risale addirittura a **PHP 5.4**. Le stime sugli host esposti e potenzialmente vulnerabili superano il milione. E i ricercatori di Calif dichiarano di aver confermato l'esecuzione di codice pre-autenticazione contro versioni specifiche di **WordPress, Drupal, Joomla e Magento**. In Italia il CERT-AGID segnala in particolare il tema Drupal `italia/design-comuni-drupal-theme` fino alla versione 1.8.1 (basato su Drupal 9): tradotto, una bella fetta dei siti dei Comuni. ## Non è un allarme teorico La timeline è di quelle che non lasciano molto spazio all'ottimismo: - **17 ottobre**: Amazon Threat Intelligence vede un tentativo di sfruttamento contro i suoi honeypot, **quattro giorni prima** della divulgazione pubblica. - **20 ottobre**: i dettagli trapelano prima della data prevista. - **21 ottobre**: escono le patch. Lo stesso giorno watchTowr, Cloudflare e Amazon osservano attacchi in rete, con payload e infrastrutture che fanno pensare a più gruppi diversi. Circolano anche PoC pubblici, non tutti verificati. Ma quando gli attacchi partono prima delle patch, il dibattito "è sfruttabile davvero?" diventa accademico. ## La soluzione: aggiornare l'interprete (non il CMS) Questo è il punto che tutti gli avvisi ripetono e che vale la pena scrivere in grassetto: **aggiornare WordPress, Drupal o i plugin non serve a niente**. Il bug è in PHP. Bisogna aggiornare PHP. ### 1. Le versioni corrette | Ramo | Versione con la correzione | |---|---| | PHP 8.5 | 8.5.12 | | PHP 8.4 | 8.4.27 | | PHP 8.3 | 8.3.36 | | PHP 8.2 | 8.2.35 | | PHP 7.4, 8.0, 8.1 | nessun rilascio ufficiale: backport minimi del PHP Security Team o pacchetti della tua distribuzione | | PHP 7.3 e precedenti | nessuna correzione: è ora di migrare | Se usi i pacchetti di una distribuzione (Debian, Ubuntu, RHEL), il numero di versione può restare "vecchio" perché la correzione arriva come backport: controlla gli avvisi di sicurezza del distributore, non il numero. ### 2. Capire come gira PHP sul tuo server ```bash # PHP caricato come modulo di Apache? (il caso peggiore) apachectl -M 2>/dev/null | grep -i php # PHP-FPM attivo? ps -eo pid,ppid,args | grep '[p]hp-fpm' # Versione della CLI (attenzione: può essere diversa da quella del web server) php -v ``` La versione che conta è quella usata dal **web server**, non dal terminale. Il modo più sicuro per verificarla è una pagina temporanea con `