Per alcuni gestori la scelta è stata sospendere i servizi prima di rischiare. Nelle cronache del 22 ottobre, PHP2Shell è già un problema di continuità operativa: siti pubblici e piattaforme temporaneamente irraggiungibili mentre vengono affrontate due vulnerabilità critiche di PHP.

La notizia riguarda anche chi ha un e-commerce, un portale clienti o un gestionale. La domanda da fare al proprio responsabile IT è immediata: «Usiamo PHP? È stato corretto? Possiamo verificare che cosa è accaduto prima?».

Siti offline per precauzione: che cosa riportano le notizie di oggi

Reuters, nell’articolo disponibile su Euronext il 22 ottobre, riferisce di siti europei messi offline il giorno precedente. Il Ministero dell’Interno francese ha posto i propri siti in manutenzione preventiva; in Finlandia il fornitore pubblico Valtori ha comunicato la sospensione precauzionale di servizi di rete. Anche l’agenzia nazionale di cybersecurity olandese ha disattivato il proprio sito per precauzione.

RSI riporta inoltre che l’Amministrazione cantonale ticinese ha disattivato temporaneamente alcuni servizi online. Sono misure precauzionali: un sito offline non dimostra che sia stato violato. Mostrano però che anche la gestione prudente di una vulnerabilità può interrompere servizi utili a cittadini e aziende.

Le due testate riferiscono che strumenti di intelligenza artificiale hanno contribuito alla scoperta delle falle. Il problema resta nel software PHP; per chi gestisce un’azienda, la priorità è capire quali servizi lo utilizzano e se siano stati aggiornati.

PHP: il problema può essere sotto il sito

PHP è il software che, sul server, esegue il codice di molti siti e applicazioni: da WordPress agli e-commerce, fino ai portali sviluppati su misura. È uno dei componenti che permettono al servizio di funzionare, anche se chi lo utilizza normalmente non lo vede.

Le due vulnerabilità riguardano la gestione della memoria. In parole semplici, richieste costruite apposta possono mandare in errore PHP e, in determinate condizioni, permettere a un estraneo di eseguire comandi sul server. Le conseguenze possono comprendere interruzioni, esposizione di informazioni o compromissione del sistema.

Il PHP Security Team segnala un rischio particolarmente elevato per Apache con mod_php, una modalità di esecuzione di PHP: il percorso dimostrato può essere attivato prima che venga eseguito il codice dell’applicazione. Anche altre configurazioni, come PHP-FPM, richiedono attenzione. L’effettiva possibilità di sfruttamento va valutata nell’ambiente interessato.

La conseguenza pratica è semplice: aggiornare WordPress, un tema o un plugin non corregge il software PHP del server. Deve intervenire chi amministra quel componente, internamente oppure presso il provider di hosting.

Quattro giorni prima dell’annuncio c’erano già tentativi

Secondo Amazon Threat Intelligence, il primo tentativo osservato risale al 17 ottobre 2026. È stato rilevato attraverso MadPot, la rete di sistemi-esca con cui Amazon studia le attività malevole su Internet.

Il 21 ottobre, prima della divulgazione pubblica, Amazon ha osservato altri tentativi. Anche Cloudflare ha confermato traffico di attacco verso i propri clienti, con variazioni delle richieste per cercare di aggirare le protezioni.

Queste osservazioni non dimostrano che ogni tentativo sia riuscito. Amazon precisa che il successo dei primi tentativi su sistemi reali resta incerto. Dimostrano però quanto possa essere breve, o persino assente, il tempo tra la notizia e l’attività degli attaccanti.

La patch chiude la falla. L’indagine guarda anche indietro

Il 21 ottobre il PHP Security Team ha rilasciato le versioni correttive: 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Per i rami non più supportati dal progetto bisogna verificare subito le correzioni dei rispettivi fornitori oppure aggiornare a una versione supportata.

Un filtro per il traffico web può ridurre alcuni percorsi di attacco, ma non sostituisce l’aggiornamento. Gli sviluppatori PHP indicano che non esistono mitigazioni complete alternative alla correzione.

C’è poi una distinzione decisiva. Immaginiamo un server compromesso il 19 ottobre e aggiornato il 22: correggere la vulnerabilità non elimina automaticamente eventuali accessi, file o modifiche lasciati prima. Chiudere una porta difettosa non ci dice se qualcuno l’abbia già attraversata.

Per questo Amazon raccomanda di analizzare le attività almeno dal 17 ottobre: richieste web sospette, programmi avviati in modo inatteso e modifiche anomale ai file. Servono dati disponibili e leggibili; l’assenza di un allarme, da sola, non dimostra che tutto sia andato bene.

Che cosa verificare subito in azienda

  • Quali sistemi usano PHP? Includi siti, portali, applicazioni interne, container e servizi gestiti da fornitori. Chiedi la versione effettivamente in esecuzione e le correzioni applicate dal fornitore: alcune distribuzioni correggono il difetto mantenendo il numero di versione originale.
  • Chi applica le correzioni? Dai priorità ai servizi esposti su Internet e chiedi al provider conferma dell’aggiornamento, con la versione installata e le correzioni applicate dal fornitore.
  • Quali eventi abbiamo conservato? Verifica con chi gestisce la sicurezza se esistono dati utili dal 17 ottobre e se sono presenti segnali da approfondire.
  • Chi prende in carico un sospetto? Definisci il riferimento tecnico e le responsabilità per approfondimento, eventuale contenimento e ripristino.

Per una PMI questo significa poter ottenere risposte concrete da chi gestisce i sistemi, senza dover ricostruire contatti e responsabilità nel pieno dell’urgenza.

È qui che un presidio come ARGUS acquista valore

Quando arriva una notizia come questa, partire da eventi già raccolti e da un monitoraggio operativo aiuta a orientare le verifiche. È il valore di ARGUS — Managed Security Operations Center by Redaxer: un presidio gestito che raccoglie e analizza i segnali di sicurezza dei sistemi collegati e invia notifiche operative sugli eventi rilevanti.

Un esempio: una richiesta insolita al sito, seguita dall’avvio di un programma inatteso e dalla modifica di un file, può meritare un approfondimento. Avere visibilità su quei passaggi aiuta a dare contesto al sospetto e a indirizzare il lavoro tecnico.

Non possiamo affermare che ARGUS avrebbe certamente riconosciuto PHP2Shell prima della divulgazione. Il vantaggio concreto è affrontare l’emergenza con un presidio già attivo e informazioni disponibili, secondo i sistemi monitorati, le sorgenti integrate e i dati conservati.

Nei piani che li includono, la ricerca delle minacce e gli strumenti per organizzare cronologie ed evidenze permettono di approfondire gli eventi; il contenimento dipende dal piano e dalle configurazioni concordate. La correzione di PHP resta in capo a chi gestisce il server.

Per un’azienda senza un SOC interno, ARGUS porta un presidio continuativo su cui costruire questa capacità. Quando la prossima vulnerabilità arriva senza preavviso, avere già occhi aperti sull’infrastruttura può rendere più tempestive e informate le decisioni.

Fonti e riferimenti