--- title: "php2shell: le due vulnerabilità critiche di PHP e cosa fare sul tuo piano hosting" description: "Il 21 ottobre PHP ha corretto due falle critiche, CVE-2026-109618 e CVE-2026-109619. Ti spieghiamo in parole semplici cosa sono, quali versioni sono colpite e cosa puoi fare sul tuo piano hosting." canonical_url: "https://spaziorc.com/blog/php2shell-vulnerabilita-php" --- > Index of every page on this site: [llms.txt](https://spaziorc.com/llms.txt) Il 21 ottobre 2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che in rete hanno preso il nome di "php2shell". Chi le sfrutta può far eseguire comandi al server senza conoscere nessuna password. Ti spieghiamo cosa sono, quanto sono gravi e cosa puoi fare sul tuo piano hosting. Le informazioni sono aggiornate al 21 ottobre alle 20:52, ora italiana. L'unica protezione completa è aggiornare PHP a una versione corretta e riavviare i processi che lo eseguono. Nessuna impostazione chiude del tutto il problema, come scrive il [comunicato ufficiale su php.net](https://www.php.net/archive/2026.php#2026-10-21-5). ## Cosa sono le due vulnerabilità Il nome "php2shell" non è ufficiale: il progetto PHP usa solo i codici CVE, come ricorda il [blog di AlmaLinux](https://almalinux.org/blog/2026-10-21-php2shell-cve-2026-109618-cve-2026-109619/). La prima, [CVE-2026-109618](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), riguarda la memoria. Ogni richiesta PHP ha un limite di memoria. Con un modulo o un upload costruito apposta, un attaccante può farla esaurire (in gergo si parla di OOM, out of memory). In quel momento PHP interrompe la richiesta in modo brusco e lascia alcuni dati a metà. La pulizia finale li tratta come validi e la memoria si corrompe. La seconda, [CVE-2026-109619](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), nasce dal fatto che un processo PHP serve molte richieste una dopo l'altra. Se una richiesta si interrompe per un errore grave, alcune informazioni restano attive anche se la memoria che le conteneva è già stata liberata. La richiesta successiva le riusa. È quello che si chiama use-after-free: PHP usa un pezzo di memoria che aveva già restituito. In entrambi i casi l'attaccante può eseguire codice sul server da remoto, senza autenticarsi, con i permessi dell'utente che esegue PHP. Le falle sono state segnalate l'11 agosto da Calif e da OpenAI, in modo indipendente. Wiz e OpenAI hanno poi trovato altri modi per sfruttarle, come racconta la [PHP Foundation](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/). Secondo [Fastly](https://www.fastly.com/blog/fastlys-proactive-protection-critical-php-rce-cve-2026-109618), il percorso di attacco più vecchio dimostrato esiste dal 2012. Il rischio più alto riguarda Apache con PHP caricato come modulo (mod_php): lì l'attacco funziona prima ancora che parta il codice del sito. Con PHP-FPM e LiteSpeed è più difficile e spesso dipende da come è scritta l'applicazione, ma non è escluso. ## Quali versioni sono colpite Sono colpite tutte le versioni precedenti a 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Queste quattro sono le versioni corrette, insieme alla 8.6.0 RC4, ancora in prova. Al momento in cui scriviamo, su [php.net](https://www.php.net/) non c'è nessuna 8.5.13 o 8.4.28. PHP 8.1 e le versioni più vecchie non ricevono più aggiornamenti dal progetto PHP. Vista la gravità, il team di sicurezza ha pubblicato correzioni minime per 7.4, 8.0 e 8.1, ma solo come codice sorgente. Tocca a chi prepara i pacchetti integrarle. [cPanel ha già pubblicato](https://support.cpanel.net/hc/en-us/articles/44397389677335-Critical-PHP-Security-Release-CVE-2026-109618-and-CVE-2026-109619) i pacchetti EasyApache corretti (ea-php), dalla 7.4 alla 8.5. Per le versioni PHP di CloudLinux, quelle che scegli da "Seleziona versione PHP", la situazione è diversa. CloudLinux ha annunciato correzioni per tutte le versioni dalla 5.2 alla 8.5. Sulla sua [pagina di stato](https://cloudlinux.statuspage.io/incidents/zl0vt1yq3dj5) risultano già disponibili la 7.4 e la 8.0 per diversi sistemi, e la 8.1 solo per Alpine Linux. Le versioni 8.2, 8.3, 8.4 e 8.5 corrette non risultano ancora pubblicate. ## Quanto sono gravi Per il progetto PHP entrambe valgono 9.2 su 10 nella scala CVSS 4.0, cioè "critica". La PHP Foundation lo aveva anticipato [su X](https://x.com/ThePHPF/status/2112633155631108544) la sera prima. Red Hat le valuta 8.1 su 10 con la scala CVSS 3.1 e le classifica "Important", un gradino sotto ([scheda Red Hat](https://access.redhat.com/security/cve/cve-2026-109618)). Il punteggio 10.0 circolato prima dell'annuncio ufficiale era sbagliato, come ha chiarito la PHP Foundation. In Italia il CSIRT dell'Agenzia per la Cybersicurezza Nazionale ha pubblicato un [avviso](https://www.acn.gov.it/portale/w/php-sanate-vulnerabilita-critiche), rilanciato anche [su X](https://x.com/csirt_it/status/2112937462624313518), che invita ad aggiornare e a controllare eventuali compromissioni. ## Ci sono già attacchi? Le fonti non dicono tutte la stessa cosa. [watchTowr](https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/) vede tentativi di attacco su entrambe le falle, ma finora nessuno risulta andato a segno. Fastly parla di attacchi visti già prima dell'annuncio. Il CTO di Cloudflare ha scritto [su X](https://x.com/dok2001/status/2112811965735202970) di aver visto i primi attacchi la mattina del 21 ottobre. La [CISA](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching), l'agenzia statunitense per la sicurezza informatica, chiede di aggiornare subito. Allo stesso tempo scrive di non aver osservato sfruttamenti al momento della pubblicazione, e le due CVE non sono nel suo catalogo delle vulnerabilità sfruttate. Al momento in cui scriviamo non risultano compromissioni confermate. Circolano anche programmi dimostrativi pubblici, non verificati, e alcuni potrebbero contenere malware. Non scaricarli e non provarli sul tuo sito. ## Cosa non è ancora chiaro Su X si parla di una patch 8.5.12 "incompleta". Tutto parte dalla segnalazione di un crash, ma chi l'ha rilanciata ha precisato che un crash da solo non prova un attacco riuscito. Per ora non è dimostrato e il team PHP non ha fatto dichiarazioni. C'è poi un problema separato, che non è una falla di sicurezza dimostrata. Nelle versioni 8.4.27 e 8.5.12, i siti che usano SimpleXML possono andare in crash con l'errore "zend_mm_heap corrupted" ([issue #24488](https://github.com/php/php-src/issues/24488)). La correzione è in lavorazione. Se vedi questo errore dopo un aggiornamento, è probabile che si tratti di questo e non di un attacco. Infine Fastly e altri ricercatori si aspettano varianti dello stesso problema. È probabile che servano altri aggiornamenti di PHP. ## Cosa puoi fare sul tuo piano hosting ### Scegli una versione PHP supportata Sui nostri piani hosting scegli la versione PHP da cPanel, nella sezione "Seleziona versione PHP" di CloudLinux. Trovi le versioni dalla 7.4 alla 8.4. Se il tuo sito usa ancora 7.4, 8.0 o 8.1, passa alla 8.2 o a una versione più recente appena puoi: sono le versioni ancora seguite dal progetto PHP. La CISA arriva a consigliare di mettere offline i sistemi esposti con PHP 8.1 o precedente che non si possono aggiornare. Prima del cambio controlla che tema e plugin siano compatibili con la nuova versione. Dopo il cambio apri le pagine principali del sito e prova i moduli di contatto. Se qualcosa non funziona, scrivici prima di tornare a una versione vecchia. ### Controlla la tua versione di php La versione impostata in cPanel e quella che il sito usa davvero non sempre coincidono. Per saperlo con certezza, crea nella cartella del sito un file chiamato per esempio `info.php`, scrivi dentro ` Le misure temporanee suggerite da PHP, come disattivare il session upload progress, non bastano. Secondo l'analisi di [Datadog Security Labs](https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/) l'attacco funziona anche così, e l'unica difesa vera è la versione PHP corretta. ### Tieni d'occhio i segnali di allarme Nei file e nei log del sito, questi sono i segnali da non ignorare: - file PHP che non hai caricato tu, oppure file modificati senza motivo; - operazioni pianificate (cron job) o account che non riconosci; - nel log degli errori, messaggi "Allowed memory size ... exhausted" con l'indicazione "Unknown on line 0", cioè PHP che finisce la memoria prima di eseguire qualsiasi pagina. Se trovi qualcosa, non cancellare nulla e scrivici: i log servono a capire cosa è successo. Tieni presente che un log pulito non garantisce che il sito sia al sicuro. Datadog ha riprodotto le due falle e ha visto che l'attacco può riuscire senza far andare in crash PHP, quindi senza lasciare errori evidenti nei log. ### Aggiorna WordPress, temi e plugin Tieni aggiornati WordPress, il tema e i plugin, e togli quelli che non usi. Questo non chiude le due falle, che sono dentro PHP, ma riduce gli altri modi in cui un sito può essere attaccato. ## Se hai dubbi Se non sai quale versione PHP usa il tuo sito, o temi che il cambio di versione rompa qualcosa, scrivici. Indicaci il dominio e la versione che vedi in cPanel, così possiamo risponderti più in fretta. ## Sitemap See the full [sitemap](https://spaziorc.com/sitemap.md) for all pages.