Il 21 ottobre 2026 il team di sicurezza di PHP ha pubblicato aggiornamenti d’emergenza per due vulnerabilità critiche, ribattezzate PHP2Shell, che permettono di eseguire codice sul server senza alcuna autenticazione. Per chi gestisce un accesso remoto sicuro aziendale (il gestionale aperto agli agenti, l’intranet raggiungibile da casa, il pannello usato dal fornitore) la notizia pone una domanda scomoda: quante delle tue applicazioni web rispondono oggi a chiunque su Internet?
In questo articolo vediamo cosa è successo, perché le vulnerabilità che colpiscono prima del login cambiano il modo di ragionare sull’accesso remoto, e le sette mosse concrete per non ritrovarti la prossima volta con un server esposto e una patch ancora da installare.
Indice dei contenuti
- Cos’è PHP2Shell e chi è a rischio
- Perché il login non basta: le vulnerabilità pre-autenticazione
- Il vero problema è l’esposizione
- VPN o accesso senza VPN?
- Accesso remoto sicuro aziendale in 5 mosse
- Cosa fa (e cosa non fa) un cancello di accesso
- Domande frequenti
Cos’è PHP2Shell e chi è a rischio
PHP2Shell è il nome informale dato a due vulnerabilità del linguaggio PHP, tracciate come CVE-2026-109618 e CVE-2026-109619. Entrambe hanno ricevuto un punteggio di gravità CVSS v4.0 di 9,2 su 10 e sono state analizzate dai ricercatori di watchTowr. Il 20 ottobre il PHP Security Team aveva annunciato un rilascio straordinario per il giorno successivo, anticipando i tempi dopo che alcune informazioni sulle falle erano trapelate prima della data concordata.
Il meccanismo, semplificando: quando una richiesta viene interrotta (per esempio per mancanza di memoria), PHP lascia in memoria dati non validi e poi li riutilizza. Un attaccante può sfruttare questo comportamento per far eseguire al server il proprio codice, con i privilegi del processo web. Una delle catene d’attacco confermate passa da session.upload_progress, la funzione che tiene traccia dell’avanzamento dei caricamenti di file ed è attiva di serie.
Sono a rischio tutte le installazioni non aggiornate che elaborano richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il caso peggiore è mod_php, per cui i ricercatori hanno dimostrato un attacco che parte prima ancora che il codice dell’applicazione venga eseguito. Secondo Kaspersky, i primi tentativi di sfruttamento sono stati osservati già prima della pubblicazione delle patch.
Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami 8.1 e precedenti non ci sono correzioni ufficiali: per 7.4, 8.0 e 8.1 gli sviluppatori hanno pubblicato correzioni minime da compilare a mano, mentre segnalazioni non ancora confermate indicano che il problema risalirebbe fino a PHP 5.4. Tutti i dettagli sono nell’archivio degli annunci di php.net.
Il perimetro è enorme: PHP è alla base di WordPress, Drupal, Joomla, di molti e-commerce e piattaforme di formazione, e soprattutto di tantissimi gestionali e portali scritti su misura negli ultimi vent’anni.
Perché il login non basta: le vulnerabilità pre-autenticazione
Quando si parla di accesso remoto sicuro aziendale, il primo istinto è rafforzare la porta d’ingresso: password robuste, verifica in due passaggi, blocco dopo troppi tentativi. Sono tutte misure giuste. Ma vivono dentro l’applicazione, e un difetto come PHP2Shell colpisce l’interprete che esegue l’applicazione, a monte di qualsiasi schermata di login.
È come montare una serratura blindata su una porta incastrata in un muro di cartongesso: la serratura non viene forzata, viene semplicemente ignorata. In gergo si parla di vulnerabilità pre-autenticazione (in inglese pre-auth): basta poter inviare una richiesta al server, senza conoscere alcuna credenziale.
PHP2Shell non è un caso isolato. A settembre 2026 la CISA statunitense ha inserito nel proprio catalogo delle vulnerabilità sfruttate attivamente (il catalogo KEV) una falla di Adobe Commerce e Magento, CVE-2026-75650, usata per installare web shell e backdoor sui negozi online. Solo nel secondo trimestre del 2026 sono entrate nel catalogo 75 nuove vulnerabilità, circa la metà classificate come critiche. Molte riguardano proprio interfacce web esposte: pannelli di amministrazione, console di gestione, portali di autenticazione.
Se un’applicazione web risponde a tutta Internet, la sua sicurezza dipende da quanto in fretta riesci ad aggiornarla. Se risponde solo a chi hai autorizzato, hai guadagnato tempo.
Il vero problema è l’esposizione, non solo la patch
Tra la scoperta di una vulnerabilità e l’installazione della correzione c’è sempre una finestra di esposizione. Con PHP2Shell quella finestra si è ridotta quasi a zero: le informazioni sono circolate prima delle patch, e gli scanner automatici che passano al setaccio Internet giorno e notte non aspettano che tu abbia letto il bollettino.
Il punto debole tipico delle PMI non è il sito vetrina, che di solito sta presso un hosting che aggiorna PHP per conto del cliente. È il resto:
- il gestionale in PHP su un server in sede, pubblicato con una regola sul router «solo per qualche settimana»;
- l’intranet o il portale documentale aperto per lo smart working;
- il pannello di amministrazione del CMS, del centralino o del software di monitoraggio;
- l’ambiente di prova di un progetto, mai spento dopo la consegna.
Sono applicazioni con un pubblico preciso e limitato: dieci dipendenti, tre agenti, un consulente. Eppure, dal punto di vista della rete, sono visibili a qualunque indirizzo del pianeta. Spesso girano su versioni di PHP vecchie, proprio perché «funzionano e nessuno le tocca»: è il classico debito tecnico delle PMI, che in giorni come questi presenta il conto.
Un accesso remoto sicuro aziendale, quindi, non si misura solo dalla robustezza del login, ma da chi riesce ad arrivare fino al server. Meno sono, meno conta la velocità con cui esce la prossima PHP2Shell.
VPN o accesso senza VPN?
La risposta classica a «come tolgo il gestionale da Internet» è la VPN. Funziona, ma porta con sé tre costi che chi la gestisce conosce bene: un client da installare e aggiornare su ogni PC e telefono, utenti esterni che non vogliono (o non possono) installarlo, e un accesso che apre tutta la rete quando servirebbe una sola applicazione.
C’è poi un aspetto che PHP2Shell rende evidente: anche il concentratore VPN è un servizio esposto su Internet, con un suo portale web di accesso. Non a caso i portali di autenticazione di firewall e VPN compaiono con regolarità nel catalogo KEV: nel secondo trimestre del 2026, per esempio, è stata inserita CVE-2026-0300, che consentiva l’esecuzione di codice tramite il portale di autenticazione di PAN-OS.
L’alternativa è l’accesso senza VPN basato su un cancello davanti alla singola applicazione: chi deve entrare dimostra chi è dal browser, e solo allora la richiesta raggiunge il server. Abbiamo messo a confronto in dettaglio VPN, ZTNA, reverse proxy fatti in casa e gateway in cloud nell’articolo MFA su applicazioni legacy: 5 soluzioni concrete; qui ci concentriamo su cosa fare adesso.
Accesso remoto sicuro aziendale in 5 mosse
1. Fai l’inventario di ciò che risponde su Internet
Non fidarti della memoria: verifica dall’esterno quali indirizzi e domini dell’azienda rispondono, su quali porte, con quale applicazione dietro. Vecchi sottodomini, porte alternative aperte per il manutentore, ambienti di test: sono quasi sempre lì che si nascondono le versioni di PHP dimenticate.
2. Separa ciò che deve essere pubblico da ciò che non deve esserlo
Per ogni voce dell’inventario fatti una domanda sola: chi deve poterla raggiungere? Il sito istituzionale e il negozio online devono essere aperti a tutti, e per loro l’unica vera difesa contro una falla come PHP2Shell è l’aggiornamento tempestivo. Il gestionale, l’intranet, i pannelli e gli ambienti di prova hanno invece un elenco di persone ben definito: non c’è alcun motivo perché rispondano a chiunque. È su questa seconda lista che si gioca l’accesso remoto sicuro aziendale.
3. Metti l’identità prima della pagina, senza VPN
Per le applicazioni della seconda lista, il controllo va spostato davanti al server. È quello che fa Gate443, il cancello di accesso sviluppato da MiriuM: si mette tra Internet e l’applicazione e, prima ancora che la pagina si apra, verifica chi sta bussando e da dove arriva.
- L’utente apre l’indirizzo del servizio e scrive la propria email.
- Riceve un codice di sei cifre, valido 5 minuti e solo nella pagina e sulla connessione da cui l’ha chiesto. Nell’email non c’è nessun link da cliccare.
- Solo dopo, la richiesta arriva all’applicazione, che l’utente usa come sempre, login compreso.
Chi non è nell’elenco degli utenti abilitati non vede nemmeno la pagina di login, e le sue richieste non raggiungono il PHP del tuo server. Per ogni utente puoi anche indicare le reti da cui è consentito entrare (la sede, la casa di chi lavora da remoto): il codice dice chi sta entrando, l’indirizzo dice da dove. Gli utenti non installano nulla: bastano browser e casella email, da PC, tablet o telefono.
Rispetto a una vulnerabilità pre-autenticazione, la differenza è netta: invece di chiunque su Internet, al server arrivano soltanto le persone che hai abilitato, una per una, con un registro di chi è entrato e quando.
4. Blinda l’origine e verifica che non si possa aggirare
Questo è il passaggio che rende la protezione reale, e spetta a te. Se il server dell’applicazione continua a rispondere a chiunque, chi conosce il suo indirizzo può saltare il cancello e andare dritto al PHP vulnerabile. Il server deve quindi accettare connessioni solo da Gate443. Le strade possibili:
- Elenco degli indirizzi consentiti sul firewall o sul web server, con tutti gli IP di Gate443 indicati nella guida del pannello (sono più di uno, perché esiste un indirizzo di riserva).
- Un nome di dominio stabile fornito da Gate443, che punta sempre agli indirizzi giusti: se cambiano, il firewall non va riconfigurato.
- Un segreto condiviso: Gate443 aggiunge alle richieste un’intestazione nota solo a te e a Gate443, e l’applicazione rifiuta quelle che non la hanno.
- Un collegamento privato, con VPN tra i server o linea dedicata.
Il filtro sul firewall è il più sicuro, perché una richiesta rifiutata non arriva nemmeno al web server, e quindi nemmeno a PHP.
5. Tieni traccia e preparati alla prossima
Ci sarà un’altra PHP2Shell, in PHP o altrove. Prepara oggi quello che ti servirà quel giorno:
- un registro degli accessi che dica chi è entrato, quando, da dove e su quale servizio, esportabile per un audit o un’indagine;
- una procedura di revoca: chi lascia l’azienda o termina un incarico va disattivato in un passaggio solo, su tutti i servizi;
- un calendario degli aggiornamenti con un responsabile per ogni server, compresi quelli dati in gestione a terzi;
- se sviluppi e vendi software, una procedura per gestire le vulnerabilità sfruttate attivamente: dall’11 settembre 2026 il Cyber Resilience Act prevede già l’obbligo di segnalarle.
Cosa fa (e cosa non fa) un “cancello” di accesso contro PHP2Shell
Un accesso remoto sicuro aziendale si costruisce a strati, e nessuno strato fa tutto da solo. Ecco, scenario per scenario, dove Gate443 aiuta e dove no.
| Scenario | Gate443 aiuta? | Perché |
|---|---|---|
| Gestionale o intranet in PHP dietro Gate443, con origine blindata | Sì | Le richieste di chi non è abilitato si fermano al cancello e non arrivano al server: l’esposizione passa da «tutta Internet» a un elenco di persone note. |
| Pagine pubbliche di un sito WordPress o di un e-commerce | In parte | Le pagine pubbliche devono arrivare a PHP, quindi serve la patch. Gate443 può chiudere wp-login.php, wp-admin e xmlrpc.php e fermare chi fa troppe richieste in poco tempo. |
| Origine non blindata | No | Chi conosce l’indirizzo diretto del server aggira il cancello. |
| Utente abilitato con casella email compromessa | Solo in parte | Può superare il cancello, ma l’accesso resta registrato e puoi limitarlo alle reti consentite. |
| Server non aggiornato | Non sostituisce la patch | Riduce chi può arrivare al server e ti fa guadagnare tempo, ma l’aggiornamento resta necessario. |
In sintesi: Gate443 è un livello in più, non sostituisce il login dell’applicazione né l’aggiornamento del software. Quello che cambia è chi può arrivare a bussare. Se gestisci siti WordPress, trovi i dettagli sulla protezione dell’area di amministrazione nella pagina dedicata a Gate443 per WordPress.
Domande frequenti sull’accesso remoto sicuro aziendale
Come si imposta un accesso remoto sicuro aziendale senza VPN?
Si mette un livello di accesso davanti a ogni applicazione web da raggiungere da fuori, si abilitano per nome gli utenti che possono entrare e si configura il server perché accetti traffico solo dal “cancello”. Così un accesso remoto sicuro aziendale non richiede client da installare: l’utente apre il browser, si identifica con email e codice e arriva all’applicazione.
Se aggiorno PHP sono al sicuro?
Da queste due vulnerabilità sì, a patto di riavviare i processi e di verificare che il server non sia già stato compromesso prima dell’aggiornamento. Ma la prossima falla pre-autenticazione troverà di nuovo esposte tutte le applicazioni che rispondono a chiunque: per questo conviene ridurre chi può raggiungerle.
Un firewall applicativo (WAF) blocca PHP2Shell?
Non va dato per scontato. Un WAF filtra le richieste in base a regole, e un attacco nuovo può non corrispondere a nessuna regola esistente. Per le applicazioni interne la protezione più solida è un’altra: le richieste di chi non ha dimostrato la propria identità non devono proprio arrivare al server.
Che differenza c’è tra VPN e accesso senza VPN?
La VPN collega il dispositivo dell’utente all’intera rete aziendale e richiede un client su ogni dispositivo. L’accesso senza VPN di Gate443 sta davanti alla singola applicazione web: l’utente si identifica dal browser con email e codice, ed entra solo in quell’applicazione. Le due soluzioni possono anche convivere.
Chiudi il cancello prima della prossima vulnerabilità
PHP2Shell ha ricordato una cosa semplice: un’applicazione che nessuno può raggiungere è un’applicazione che nessuno può attaccare da fuori. Aggiorna PHP oggi, e da domani fai in modo che gestionali, intranet e pannelli rispondano solo a chi deve entrare.
Con Gate443 imposti un accesso remoto sicuro aziendale in pochi minuti: niente VPN, niente app da installare, sul tuo dominio e con il tuo marchio, con sviluppo e datacenter in Italia.
