PHP2Shell dopo una settimana: attacchi e falla kernel

Il 21 ottobre il team PHP ha rilasciato aggiornamenti d'emergenza per due falle critiche, CVE-2026-109618 e CVE-2026-109619 («PHP2Shell»). Allora la domanda era quanto velocemente applicare la patch. Una settimana dopo è cambiata: sei stato attaccato nel frattempo, e cosa può fare un attaccante una volta violato PHP?

4 giorni

attacchi segnalati prima delle patch

50.000+

richieste di attacco tracciate dalla TU Delft

600+ / 70

indirizzi IP / paesi

nuove voci CISA KEV questa settimana, 4 su software da server

Cosa è successo dal 21 ottobre

Cronologia dai primi attacchi segnalati alle scadenze CISA. Date dal catalogo CISA e dalla stampa; l'inizio il 17 ottobre deriva dai quattro giorni segnalati prima delle patch.

Gli attacchi sono iniziati prima delle patch. Secondo le segnalazioni (tra gli altri Amazon Threat Intelligence) lo sfruttamento è partito circa quattro giorni prima delle versioni corrette. I dati degli honeypot hanno poi confermato tentativi riusciti, per esempio contro Apache con mod_php su PHP 8.4.26.
La CISA lo ha confermato il 26 ottobre. Entrambe le falle PHP sono nel catalogo Known Exploited Vulnerabilities, con scadenza il 29 ottobre per le agenzie federali USA. La voce non dice quanti sistemi in produzione siano stati davvero violati.
La scala è grande. Il laboratorio di threat intelligence della TU Delft avrebbe tracciato oltre 50.000 richieste di sfruttamento da più di 600 indirizzi IP in 70 paesi. Un ricercatore ha trovato segni di sfruttamento per CVE-2026-109618 ma non per CVE-2026-109619, quindi in pratica non sono ugualmente pericolose. Correggi comunque entrambe.
I primi annunci di «violazioni riuscite» erano in parte affrettati. Attenzione ai numeri sui server compromessi: un conteggio affidabile non esiste ancora.

La novità: da PHP a root

Il 28 ottobre la CISA ha aggiunto CVE-2026-46300, una falla del kernel Linux soprannominata «Fragnesia». È un'escalation di privilegi locale nel codice ESP-in-TCP del kernel che permette a un utente senza privilegi di modificare la page cache di file che può solo leggere. Il codice exploit pubblico, secondo le segnalazioni, punta alla copia in cache di /usr/bin/su, così la prossima esecuzione del programma lancia codice dell'attaccante come root.

Secondo la voce CISA questa falla si può concatenare con le due falle PHP per installare web shell PHP ed eseguire comandi come root. Per chi gestisce server è il punto chiave: PHP2Shell da sola dà all'attaccante i diritti dell'utente del server web. Con la falla del kernel dietro, un server vulnerabile non è solo un sito modificato ma una macchina presa del tutto, con tutti gli altri siti e tutti i segreti che contiene.

La CISA non dice quanto sia diffusa la catena, e l'uso in campagne ransomware è indicato come sconosciuto. La falla del kernel è stata resa nota a maggio e riguarda i kernel compilati prima del 13 maggio 2026, quindi molti server aggiornati con regolarità hanno già la correzione. Quelli che non si riavviano mai, no.

È un caso isolato?

Nuove voci a settimana nel catalogo Known Exploited Vulnerabilities della CISA da agosto. L'ultima settimana (evidenziata) è contata fino al 29 ottobre e include le due falle PHP e quella del kernel Linux. Fonte: feed CISA KEV.

No. La CISA aggiunge in media 8 voci a settimana, tra 3 e 14 da agosto. Questa settimana è insolito che quattro su otto siano software che usi sul tuo server: PHP due volte, il kernel Linux e GitLab. Il catalogo è un buon sistema di allerta precoce, gratuito. Pubblico ogni nuova voce in una pagina a parte, con cosa controllare: vulnerabilità sfruttate attivamente.

Controllo in 15 minuti

1. PHP: quale versione gira, e in che forma? Corrette sono la 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Server web e riga di comando possono usare versioni PHP diverse.

php -v
php-fpm -v 2>/dev/null || ls /usr/sbin/php-fpm*
apachectl -M 2>/dev/null | grep -i php      # mod_php

I dettagli per Plesk, Synology, hosting condiviso e Docker sono nella guida alla patch. Se oggi non puoi aggiornare, la soluzione temporanea in php.ini riduce il rischio.

2. Kernel: la correzione è installata e attiva? Installare non basta, il nuovo kernel vale solo dopo un riavvio.

uname -r
# Debian / Ubuntu
apt list --upgradable 2>/dev/null | grep -i linux-image
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required
# RHEL / Alma / Rocky
dnf updateinfo list security | grep -i kernel
needs-restarting -r

Il bollettino di sicurezza della tua distribuzione per CVE-2026-46300 indica la versione corretta del pacchetto. Qui non riporto numeri di versione del kernel perché cambiano da distribuzione a distribuzione.

3. Non puoi ancora riavviare? Misura temporanea segnalata. Le segnalazioni consigliano di bloccare i moduli esp4, esp6 e rxrpc. Questo blocca IPsec e AFS. Verifica prima se li usi:

lsmod | grep -E 'esp4|esp6|rxrpc'
ip xfrm state | head
# solo se NON usi IPsec/AFS:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/block-esp.conf
sudo modprobe -r esp4 esp6 rxrpc

4. Cerca web shell. File PHP modificati di recente nelle cartelle web e i tipici one-liner:

find /var/www -name '*.php' -mtime -10 -ls 2>/dev/null
grep -rlE '(eval|assert|system|passthru|shell_exec)[[:space:]]*\([[:space:]]*\$_(POST|GET|REQUEST|COOKIE)' /var/www 2>/dev/null

Nel primo elenco compaiono anche gli aggiornamenti legittimi, quindi leggilo invece di contarlo soltanto. Per la falla del kernel controlla che i binari di sistema siano intatti (dpkg -V util-linux su Debian e Ubuntu, rpm -V util-linux su RHEL). L'output dovrebbe essere vuoto. Un riavvio o un aggiornamento del kernel ripulisce una page cache alterata; le segnalazioni citano anche lo svuotamento della cache (echo 3 | sudo tee /proc/sys/vm/drop_caches) dopo la mitigazione.

Se trovi qualcosa

Trattalo come una compromissione, non come un file da cancellare. Una web shell con un exploit del kernel dietro può aver significato root. Isola il server, conserva log e immagine del disco per l'analisi, ripristina da un backup pulito, cambia tutti i segreti presenti sulla macchina (password del database, chiavi API, chiavi SSH, file .env) e applica le patch prima di rimetterla in rete.

Cosa farei oggi

Aggiornare PHP ovunque, anche il PHP della riga di comando, dei cron job e dei container.
Installare l'aggiornamento del kernel e pianificare il riavvio. Una patch del kernel che aspetta «la prossima finestra di manutenzione» è una porta aperta su un server già attaccato tramite PHP.
Controllare i log fino al 17 ottobre, non solo fino al giorno della propria patch.
Limitare ciò che PHP può fare: disable_functions per exec, system, passthru, shell_exec dove l'applicazione non li usa, e pool separati per sito. Non sostituisce la patch ma rende più difficile la catena.

Fonti: Recorded Future, BleepingComputer, SOC Prime e il Known Exploited Vulnerabilities Catalog della CISA. Stato al 30 ottobre 2026; i numeri provengono dai rapporti citati e dal feed CISA e possono cambiare.