L’emergenza PHP2Shell ha riportato al centro dell’attenzione degli investitori le aziende che offrono strumenti di sicurezza informatica: mentre siti e servizi cercavano di ridurre i rischi o installare le correzioni, il firewall per applicazioni web di Cloudflare era direttamente pertinente alla risposta. Nelle contrattazioni intraday il titolo Cloudflare è salito di oltre il 6%, mentre hanno guadagnato anche altre società del comparto sicurezza e software. Ma le falle PHP non spiegano da sole tutti i rialzi: le cronache di mercato hanno citato anche lo spostamento di capitali dai semiconduttori al software e notizie separate sulla collaborazione tra Nvidia e CrowdStrike per la sicurezza dell’IA.
19
20
22
17
Perché sono saliti i titoli
La divulgazione delle vulnerabilità e le chiusure precauzionali di alcuni siti hanno riportato l’attenzione sulla spesa per la sicurezza digitale. TradingKey ha collegato l’allarme ai rialzi di diverse società software, tra cui Datadog, Okta e Zscaler. Un altro resoconto pomeridiano indicava Cloudflare in rialzo di circa il 7% e Palo Alto Networks del 4%. Sono rilevazioni intraday, non rendimenti di chiusura verificati, e non dimostrano che l’incidente PHP abbia determinato da solo l’andamento di ciascun titolo.
19
20
Cloudflare aveva un legame diretto con l’emergenza: la società ha descritto l’attivazione di protezioni nel proprio firewall per applicazioni web, o WAF, contro le falle. I suoi servizi erano quindi rilevanti per le organizzazioni che cercavano di limitare l’esposizione mentre preparavano l’aggiornamento del software. Una regola WAF va considerata una misura temporanea di mitigazione, non un sostituto della correzione di PHP.
15
11
Sul mercato agivano anche altri catalizzatori. Un resoconto ha descritto uno spostamento dagli investimenti nei semiconduttori verso i titoli software, sullo sfondo dei dubbi sulla sostenibilità della spesa per le infrastrutture di IA e dei costi di finanziamento. Un’altra notizia ha collegato il rialzo di CrowdStrike all’ampliamento della collaborazione con Nvidia sulla sicurezza dell’intelligenza artificiale; nello stesso resoconto salivano anche Datadog e Okta. Questi elementi aiutano a spiegare perché il movimento della giornata fosse più ampio della sola vicenda PHP.
22
17
Che cosa comportavano le falle PHP
Le due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, sono state chiamate collettivamente PHP2Shell. Secondo le notizie disponibili, entrambe avevano un punteggio di gravità di 9,2 sulla scala CVSS v4.0 e potevano consentire l’esecuzione di codice da remoto senza autenticazione: in altre parole, un aggressore avrebbe potuto eseguire codice su un server vulnerabile senza prima effettuare l’accesso.
14
15
Cloudflare ha indicato che il problema riguardava i server web che utilizzavano PHP 5.4 o versioni successive. Le correzioni d’emergenza per i rami supportati erano PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12.
15
8
Gli sviluppatori di PHP hanno segnalato le falle martedì 20 ottobre; le correzioni sono diventate disponibili il giorno seguente. Un resoconto ha indicato che l’aggiornamento correttivo era stato confermato intorno alle 13:45 GMT del 21 ottobre.
13
9
Perché alcuni siti sono andati offline
In Europa, siti di enti pubblici, ospedali e università sono stati messi offline in via precauzionale mentre gli amministratori lavoravano per affrontare le vulnerabilità. Una sospensione temporanea, da sola, non dimostra che il sito sia stato attaccato con successo.
3
L’avviso di Wikimedia ha elencato in particolare Cloud VPS e Toolforge tra i servizi disattivati durante la manutenzione precauzionale. Questo non significa che tutti i servizi di Wikipedia fossero indisponibili.
7
La preoccupazione rifletteva anche l’ampia diffusione di PHP: secondo una stima riportata, il linguaggio è utilizzato da circa il 70% dei siti web. La cifra descrive la diffusione della tecnologia, non il numero di siti effettivamente vulnerabili o compromessi.
8
Cosa dovrebbero fare i gestori dei siti
Cloudflare ha dichiarato di osservare l’emergere di attacchi, mentre alcune autorità nazionali hanno riferito di non aver rilevato attività di sfruttamento. Le due indicazioni non sono necessariamente in contraddizione: copertura e periodi di osservazione possono essere diversi. E non rilevare attacchi non equivale a dimostrare che un sistema vulnerabile sia al sicuro.
1
3
Per chi gestisce un piccolo sito su hosting condiviso, la verifica essenziale è chiedere al provider se la versione di PHP del server sia stata aggiornata a una release corretta o protetta con una correzione retroportata dal fornitore. Aggiornare il sistema di gestione dei contenuti non significa necessariamente aggiornare anche la versione di PHP su cui gira. Il WAF può offrire una protezione temporanea: conviene chiedere al provider che cosa è stato corretto e quando.
11
14