Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti di sicurezza per due vulnerabilità critiche. Le falle CVE-2026-109618 e CVE-2026-109619 sono discusse sotto il nome «PHP2Shell». Errori nella gestione della memoria possono, in determinate condizioni, consentire ad aggressori di eseguire da remoto e senza previa autenticazione codice proprio su un server interessato. È coinvolto l’ambiente di esecuzione che esegue le applicazioni PHP sul server.[1][2]
PHP costituisce la base tecnica di numerosi siti web e applicazioni, tra cui WordPress, Drupal e Joomla. Possono quindi essere interessati anche negozi online, portali clienti e applicazioni aziendali sviluppate su misura. I ricercatori hanno inoltre dimostrato la possibilità di leggere la memoria dei processi, che può contenere ad esempio password o chiavi tecniche d’accesso. Le conseguenze effettive di un attacco dipendono in particolare dalla configurazione, dalle autorizzazioni e dalle connessioni con altri sistemi. A seconda dell’utilizzo, possono verificarsi interruzioni dell’attività, divulgazioni di segreti commerciali o manipolazioni dei processi aziendali. Oltre ai costi di ripristino, possono derivarne perdite di fatturato e pretese dei clienti.[2]
Occorre verificare in particolare l’installazione PHP sulla quale è eseguito il sistema di gestione dei contenuti. Il progetto PHP considera a rischio tutte le installazioni che elaborano richieste web e valuta il rischio particolarmente elevato per Apache con mod_php. Le correzioni di sicurezza sono disponibili dal 21 ottobre nelle versioni PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Nei pacchetti di un distributore Linux o di un fornitore con supporto a lungo termine, la correzione potrebbe essere stata riportata in un ramo di versioni precedente. È determinante lo stato delle correzioni comprovato del pacchetto effettivamente in uso.[1]
Il primo compito consiste nell’individuare le proprie dipendenze. Il servizio informatico e i fornitori incaricati dovrebbero censire tutti i sistemi PHP e trattare prioritariamente le applicazioni accessibili pubblicamente. Le direzioni aziendali dovrebbero farsi confermare per iscritto i sistemi interessati, le misure di protezione previste e il momento in cui l’aggiornamento diventa effettivo. In presenza di ostacoli tecnici, una limitazione o disattivazione temporanea del servizio interessato va ponderata rispetto alle conseguenze di un attacco.[3]
Le misure transitorie descritte dal team PHP riducono singole modalità di attacco. La rimozione completa delle vulnerabilità pubblicate richiede l’aggiornamento di sicurezza. Parallelamente va verificato se vi siano già indizi di compromissione. Un aggiornamento chiude la falla nota; l’indagine sugli accessi già avvenuti e sulle possibili backdoor rimane un compito distinto. In caso di sospetto, specialisti dovrebbero preservare i registri rilevanti e valutare quali credenziali d’accesso rinnovare e quali sistemi ripristinare.[1][3]
Dal punto di vista della protezione dei dati, la responsabilità inizia già prima che si verifichi un danno. L’art. 8 LPD impone ai titolari del trattamento e ai responsabili del trattamento misure tecniche e organizzative che garantiscano una sicurezza dei dati adeguata al rischio. Ne deriva un obbligo continuativo di verifica e intervento nella gestione delle vulnerabilità divenute note. Sul piano giuridico, la combinazione tra accessibilità pubblica, elevato potenziale di danno e disponibilità di correzioni di sicurezza depone a favore di una priorità molto elevata. Il termine adeguato dipende dal pericolo concreto e dalle misure di protezione attuabili.[4][5]
In una società anonima, tali rischi riguardano anche gli obblighi del consiglio d’amministrazione ai sensi degli artt. 716a e 717 CO. Esso deve assicurare un’organizzazione e una vigilanza adeguate. La rimozione operativa delle vulnerabilità compete agli specialisti responsabili; a livello direttivo occorrono competenze chiare, risorse sufficienti e una rendicontazione affidabile. La responsabilità personale ai sensi dell’art. 754 CO presuppone una violazione colpevole degli obblighi, un danno e il necessario nesso causale. Sono determinanti le informazioni disponibili all’epoca e le misure richieste dalle circostanze concrete.[6]
Anche in caso di hosting esternalizzato, l’impresa rimane responsabile del proprio trattamento dei dati. Secondo l’art. 9 cpv. 2 LPD, deve in particolare accertarsi che il responsabile del trattamento sia in grado di garantire la sicurezza dei dati. Nella pratica, ciò comprende lo stato delle correzioni, il momento dell’attuazione e la ripartizione dei compiti tra fornitore di hosting, agenzia web e impresa. I contratti dovrebbero inoltre stabilire la rapidità con cui devono essere trattate le vulnerabilità critiche, chi comunica gli incidenti di sicurezza e quale assistenza è dovuta per gli accertamenti.[7]
La violazione di obblighi concordati di manutenzione, sicurezza o informazione può dar luogo a pretese di risarcimento ai sensi dell’art. 97 CO. Sono determinanti le prestazioni dovute, il danno e il nesso causale; in questa responsabilità contrattuale la colpa è in linea di principio presunta. Vanno inoltre considerate le specifiche disposizioni contrattuali e i limiti legali alle restrizioni della responsabilità.[6]
Per gli obblighi di notifica occorre distinguere tra vulnerabilità e violazione della sicurezza dei dati. L’accertamento di una versione PHP vulnerabile richiede innanzitutto verifiche e misure di protezione. Ai fini dell’art. 24 LPD è determinante una violazione della sicurezza dei dati ai sensi dell’art. 5 lett. h LPD. Vi rientrano ad esempio l’accessibilità di dati personali a persone non autorizzate, la loro modifica illecita o la loro perdita. La sola accessibilità non autorizzata può già essere rilevante. L’esame giuridico comprende quindi più della prova di un’effettiva sottrazione di dati.[4]
Se una simile violazione comporta verosimilmente un rischio elevato per la personalità o i diritti fondamentali delle persone interessate, il titolare del trattamento deve informare l’IFPDT il più rapidamente possibile. Sono centrali le possibili conseguenze per le persone coinvolte, ad esempio a causa di dati sanitari divulgati o di credenziali d’accesso utilizzabili abusivamente. Secondo la guida dell’IFPDT, quando è riconoscibile un rischio verosimilmente elevato, la notifica deve avvenire tempestivamente, mentre proseguono gli accertamenti più lunghi. Le informazioni mancanti possono essere fornite successivamente. Nella valutazione del rischio vanno escluse le misure correttive soltanto pianificate.[8]
Il responsabile del trattamento deve notificare al titolare ogni violazione della sicurezza dei dati il più rapidamente possibile, indipendentemente dalla classificazione come rischio elevato. Ai sensi dell’art. 24 cpv. 4 LPD, le persone interessate devono essere informate quando la loro protezione lo richiede o l’IFPDT lo esige. Ciò può verificarsi, ad esempio, se devono cambiare le proprie credenziali d’accesso. Questo obbligo d’informazione va valutato autonomamente. Le imprese dovrebbero pertanto esaminare separatamente la notifica all’autorità e la comunicazione con clienti, collaboratori o pazienti.[8]
Possono aggiungersi ulteriori obblighi di notifica. Dal 1° aprile 2025, i gestori di infrastrutture critiche soggetti alla legge sulla sicurezza delle informazioni devono notificare determinati ciberattacchi all’Ufficio federale della cibersicurezza (UFCS) entro 24 ore dalla loro scoperta. Sono rilevanti, tra gli altri, gli attacchi che compromettono la funzionalità, provocano una fuga di informazioni o una manipolazione oppure sono connessi a un’estorsione. L’assoggettamento di un’impresa dipende dal campo d’applicazione legale e dalle eccezioni.[9]
Per gli istituti sottoposti alla vigilanza della FINMA si applicano inoltre i requisiti di vigilanza. In caso di ciberattacco che raggiunge la soglia di rilevanza, la FINMA si attende in linea di principio una prima notifica entro 24 ore dalla scoperta e una notifica completa entro 72 ore. I termini sono calcolati di regola nei giorni lavorativi bancari ufficiali; gli attacchi gravi devono essere notificati entro 24 ore anche al di fuori di tali giorni. Per le funzioni esternalizzate, già la scoperta da parte del fornitore terzo può avviare il decorso dei termini. Le banche devono quindi prestare particolare attenzione a definire canali contrattuali di notifica che consentano di ricevere tempestivamente le informazioni necessarie.[10]
Le imprese con legami con il mercato dell’UE dovrebbero inoltre verificare l’applicabilità del RGPD. Nella misura in cui si applica, l’art. 33 prevede una notifica senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui si viene a conoscenza della violazione dei dati personali. La soglia di notifica è inferiore a quella della LPD svizzera e comprende in linea di principio già un rischio prevedibile per i diritti e le libertà. Per beneficiare di un’esenzione, deve essere improbabile che la violazione comporti un rischio di questo tipo. Destinatari, soglie e termini vanno pertanto valutati separatamente per ciascun regime.[11]
Infine, le violazioni intenzionali dei requisiti minimi di sicurezza dei dati stabiliti dal Consiglio federale possono essere punite, a querela di parte, con una multa fino a CHF 250’000 ai sensi dell’art. 61 lett. c LPD. Le disposizioni penali si rivolgono principalmente alle persone fisiche. Una simile sanzione presuppone che siano realizzati gli elementi della specifica fattispecie penale. Un incidente di sicurezza o un aggiornamento tardivo, da soli, non permettono quindi ancora un giudizio attendibile sulla punibilità. La responsabilità civile va esaminata separatamente e può essere rilevante anche in caso di negligenza.[4][12]
Per la direzione aziendale è ora consigliabile un breve rapporto sulla situazione, fondato su elementi verificabili. Dovrebbe indicare quali applicazioni sono interessate, quali correzioni sono state effettivamente installate, quali tracce di attacco vengono esaminate e chi decide sugli obblighi di notifica. Se un servizio rimane temporaneamente vulnerabile, la decisione deve includere i motivi, le misure di protezione supplementari e un termine vincolante per la risoluzione. Questa documentazione crea la base per ridurre in modo mirato i rischi tecnici e rendere comprensibile la procedura seguita a clienti, controparti contrattuali e autorità di vigilanza.