Due falle da 9,2 nel cuore di PHP fanno eseguire codice sul server con una sola richiesta, senza login. Gli attacchi sono già partiti e aggiornare il CMS non basta.
Sapete su quale versione di PHP gira il vostro sito? Fino a ieri era una domanda da sistemisti. Da oggi è una domanda da direzione aziendale. Il 21 ottobre il team di PHP ha pubblicato aggiornamenti d'emergenza per due vulnerabilità ribattezzate PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Le hanno trovate ricercatori di Wiz e Calif, aiutandosi con l'intelligenza artificiale. Erano lì da più di dieci anni.
Perché sono così gravi
PHP è il motore che fa girare circa sette siti su dieci: WordPress, Joomla, Drupal, PrestaShop, tanti gestionali web fatti su misura. Le due falle non stanno in un plugin o in un tema. Stanno nel motore stesso, nel modo in cui PHP gestisce la memoria tra una richiesta e l'altra. Una riguarda la memoria esaurita, che lascia dati a metà che poi vengono presi per buoni. L'altra riguarda dati di una richiesta precedente che restano in giro anche dopo essere stati cancellati. Il risultato è lo stesso: con una richiesta web costruita ad arte, chiunque può eseguire comandi sul server. Non serve un account e non serve una password. L'attacco parte prima ancora che il codice del sito venga eseguito. PHP assegna 9,2 su 10 a entrambe, watchTowr arriva a 10.
Gli attacchi ci sono già
Amazon ha registrato un tentativo di sfruttamento su uno dei suoi honeypot (server esca messi lì apposta per attirare gli attaccanti) il 17 ottobre, quattro giorni prima che le falle diventassero pubbliche. Come l'attaccante abbia avuto i dettagli in anticipo non si sa. Oggi watchTowr conferma attacchi in corso. Diverse istituzioni hanno preferito spegnere i siti in via precauzionale: tra queste il governo finlandese e l'agenzia olandese per la cybersicurezza. L'NCSC britannico è netto: se non potete aggiornare subito, mettete offline.
Cosa fare, concretamente
Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Sono colpite tutte le configurazioni che servono pagine web: PHP-FPM, mod_php su Apache, php-cgi, LiteSpeed, FrankenPHP. Chi usa versioni fuori supporto (8.1 e precedenti) ha a disposizione solo correzioni minime da compilare a mano, o i pacchetti dei distributori Linux e dei fornitori di supporto esteso. Per PHP 5 e 7 la strada vera è migrare. Aggiornare WordPress o i plugin non serve a niente: il problema è sotto. Se il sito è su hosting, va chiesto al provider che versione usa e quando aggiorna. Cloudflare ha attivato regole firewall anche sui piani gratuiti, ma secondo il team di PHP le misure tampone chiudono solo alcune strade. L'unica soluzione sicura è aggiornare.
Fonte: Il Post
La tua azienda è pronta ad affrontare una minaccia come questa?
Richiedi una valutazione gratuita →
Il 9,2 in sé non mi spaventa più di tanto: di punteggi alti ne vediamo ogni mese. Mi preoccupa dove sta il problema. Quando parlo di aggiornamenti con le aziende che seguo, quasi tutti pensano al CMS: «WordPress è aggiornato, i plugin pure». Giusto. Poi però apri il pannello dell'hosting e trovi PHP 7.4, scelto da qualcuno anni fa e mai più toccato. Il sito l'ha fatto un'agenzia che nel frattempo ha chiuso, il server lo gestisce il provider, e in azienda nessuno sa bene di chi sia la responsabilità. Non è menefreghismo. Quel livello è semplicemente invisibile finché funziona. E poi non c'è solo il sito vetrina: c'è il portale fornitori, l'intranet, il vecchio gestionale web che gira su una macchina in sala server. Il mio consiglio è di partire da lì: fare l'elenco di tutto quello che in azienda esegue PHP, non solo del sito principale.
L'exploit visto quattro giorni prima della pubblicazione dice una cosa chiara: con falle così aggiornare «appena possibile» può già voler dire essere in ritardo. Per questo nelle aziende che seguiamo, molte delle quali devono rispondere a clienti e normative come NIS2 e DORA, abbiamo messo in piedi sistemi di sicurezza che ci danno un quadro chiaro: cosa è esposto su Internet, con quale versione, cosa va patchato e con che priorità. Da lì possiamo distribuire gli aggiornamenti in modo controllato. Quando la patch non c'è ancora, oppure il sistema è troppo vecchio per riceverla subito, applichiamo una correzione mirata che chiude la strada usata dallo zero-day in attesa della soluzione definitiva. Secondo me la differenza, stamattina, l'ha fatta proprio questo: sapere in dieci minuti dove intervenire, invece di passare la giornata a scoprirlo. Se volete portare questi strumenti anche sulla vostra infrastruttura, contattatemi pure: io e il mio team siamo pronti a mettere in sicurezza i dati vostri e dei vostri clienti.