Gateway Check Point violati tramite PHP2Shell: il produttore conferma attacchi, una backdoor e un wiper

Monitoraggio cyber di Top-Secured: analisi indipendente basata sulle fonti citate più in basso. Top-Secured non è affiliato alle aziende menzionate e non le chiederà mai le sue credenziali bancarie né le sue password.

Check Point riferisce che alcuni attaccanti hanno sfruttato le falle PHP2Shell del portale Mobile Access su gateway non aggiornati e poi una seconda falla per diventare root. Su alcuni bersagli hanno installato una backdoor e sono passati a host VMware ESXi per distruggere file.

Cosa è successo

Il 12 novembre 2026 Check Point Research ha pubblicato l’analisi di attacchi contro i firewall dello stesso produttore. Gli attaccanti hanno usato PHP2Shell (CVE-2026-109618 e CVE-2026-109619), due falle di PHP valutate 9,2 su 10 da Check Point e trattate per i suoi gateway in un bollettino pubblicato per la prima volta il 21 ottobre. L’attività è iniziata circa una settimana dopo la disponibilità della correzione, quindi sono stati colpiti solo gateway non aggiornati. Una prima ondata, il 30 ottobre, ha preso di mira organizzazioni israeliane, con distruzioni presso alcune; una seconda, il 2 novembre, ha colpito organizzazioni di vari paesi e settori, senza distruzioni osservate. Check Point non indica il numero di vittime; il suo bollettino sulla seconda falla parla di sfruttamento attivo presso un paio di decine di clienti.

Come sono entrati gli attaccanti

Il punto di ingresso era il portale Mobile Access esposto su Internet. Una volta dentro, gli attaccanti hanno usato la CVE-2026-123039, una falla locale del servizio DynamicCLI, per ottenere i privilegi di root. Hanno depositato webshell nei modelli del portale, una backdoor che sopravvive ai riavvii, una libreria che fa da proxy di rete e uno scanner. Da alcuni gateway si sono collegati via SSH a host VMware ESXi e vi hanno eseguito un wiper per Linux. Check Point rileva punti in comune con strumenti associati a un gruppo legato alla Cina, ma dice di non poter stabilire con certezza la vera natura dell’operazione.

Cosa fare subito

  1. Aggiornate: Jumbo Hotfix Accumulator Take 14 o successivo su R82.20, Take 52 su R82.10, Take 132 su R82, Take 174 su R81.20, oppure l’hotfix autonomo della sk1000302 (serve un riavvio). Spark: R82.00.11 build 998002843 o R81.10.17 build 996005005 e successive. Verificate il Take installato con cpinfo -y all.
  2. Su R81.10 e versioni precedenti (fuori supporto) pianificate un aggiornamento: per la CVE-2026-123039 non è prevista alcuna correzione.
  3. Se non potete aggiornare subito, applicate la mitigazione manuale della sk1000302 e fermate dynamic_server come indicato nella sk1000362.
  4. Cercate tracce di compromissione, anche dopo l’aggiornamento: /tmp/CPconfigdaemon, /lib/libcpfwcommon.so, file zz*.tpl nei modelli del portale, un servizio in ascolto sulla porta TCP 11072 (netstat -tlnp) e gli indirizzi IP pubblicati da Check Point.
  5. Se trovate qualcosa, reinstallate il gateway, rinnovate segreti e certificati VPN e controllate gli host ESXi che può raggiungere.

Il nostro parere

Anche un firewall è un server, e i suoi portali web usano le stesse librerie di qualsiasi sito. Una settimana tra correzione e attacco è ormai la norma: gli apparati perimetrali meritano gli stessi tempi di aggiornamento del server web più esposto, e il loro accesso di amministrazione agli hypervisor va interrotto.

Fonti

Come scegliamo, verifichiamo e scriviamo le nostre analisi →

Il vostro server è esposto? Fate un test gratuito — solo informazioni pubbliche, senza intrusione:

Verificare un server Verificare un sito

Temi che i tuoi server siano esposti? Il nostro team verifica, aggiorna e monitora infrastrutture Linux e cloud 24/7.

Parla con un esperto I nostri servizi di gestione server →