I probe PHP2Shell superano quota 74.000 senza alcuna violazione confermata
Gli attacchi PHP2Shell hanno generato più di 74.000 tentativi di exploit o ricognizione, secondo Wordfence, sebbene l’azienda non abbia confermato che alcun sito web sia stato compromesso attraverso le due vulnerabilità PHP sottostanti. Il progetto PHP ha pubblicato aggiornamenti di emergenza il 21 ottobre 2026 per le vulnerabilità critiche CVE-2026-109618 e CVE-2026-109619. Wordfence basa la propria valutazione sulla telemetria proveniente da oltre 5.000.000 di siti WordPress protetti e afferma che sta ampliando il monitoraggio. La correzione richiesta consiste nell’installare PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure un pacchetto del fornitore esplicitamente confermato come contenente entrambe le correzioni. Gli amministratori devono quindi riavviare ogni PHP worker, ossia un processo che gestisce le richieste al sito web. L’aggiornamento di WordPress non aggiorna il software PHP separato che opera dietro di esso.
Un vasto cluster di attacchi ha inviato richieste multipart/form-data, un formato web che suddivide un caricamento in più sezioni denominate. Le richieste includevano un identificatore di sessione, la funzionalità PHP_SESSION_UPLOAD_PROGRESS e campi ripetuti denominati da t[0] fino almeno a t[136]. Nel pubblicare il proprio esempio, Wordfence ha omesso 134 di questi campi. I dati ripetuti sembravano progettati per esercitare pressione sulla memoria e influenzare il modo in cui PHP allocava la richiesta. Le stringhe incorporate includevano il marcatore di esecuzione dei comandi P2S_OK, il nome della funzione system e comandi destinati a mostrare i dettagli del server e a leggere i primi 200 byte di .env, ../.env, ../../.env e wp-config.php. Questi file possono contenere environment variables, ossia valori di configurazione forniti a un’applicazione, oltre a credenziali del database e altri dati segreti. La richiesta dimostra un intento, ma da sola non può provare che la memoria sia stata danneggiata o che un comando sia stato eseguito correttamente.
Wordfence ha inoltre esaminato 10.000 eventi raccolti dal 20 al 22 ottobre. Il campione è stato selezionato deliberatamente in base alle richieste che menzionavano PHP_SESSION_UPLOAD_PROGRESS, quindi non è rappresentativo di tutto il traffico web malevolo. Conteneva 3.752 apparenti tentativi PHP2Shell di memory pressure o state corruption finalizzati all’esecuzione di comandi e al furto di configurazioni. Altri 1.139 utilizzavano Laravel serialized-object gadget chains, sequenze che tentano di sfruttare impropriamente classi già installate in un’applicazione per eseguire un comando shell. Ulteriori 2.534 tentavano di usare oggetti serializzati associati a Monolog, Symfony, Guzzle, WordPress, ThinkPHP e altre classi. Queste categorie descrivono le caratteristiche dei payload e possono sovrapporsi.
Lo stesso campione comprendeva 512 tentativi NxSP di session-file poisoning. Questi tentano di inserire contenuto malevolo in un file temporaneo di sessione e di combinarlo con una local-file-inclusion flaw separata, ossia una debolezza che consente a un’applicazione di caricare un file locale che non dovrebbe esporre. Trenta richieste contenevano canary di caricamento PHP out-of-band, test che attendono una callback Internet separata per mostrare se un altro metodo di caricamento o esecuzione ha funzionato. Wordfence avverte che il traffico NxSP e quello dei canary utilizzano la stessa area multipart o upload-progress, ma dipendono da vulnerabilità separate o dal comportamento dell’applicazione. Non devono quindi essere considerati uno sfruttamento confermato di una delle due nuove CVE. Il dataset contiene richieste anziché risposte o prove dirette provenienti dai server presi di mira, quindi ogni conteggio misura i tentativi, non le intrusioni riuscite.
Nei payload osservati, gli attaccanti hanno cercato di confermare l’esecuzione mediante P2S_OK, NxSP seguito da cifre e SHL_OK. Comandi come id, uname -a e hostname avrebbero permesso di profilare un server. Altre azioni miravano a sottrarre dati segreti da environment variables, .env e wp-config.php, cercavano nelle directory più comuni dei sistemi di gestione dei contenuti e tentavano di creare file di comando persistenti denominati wp2s.php nelle posizioni scrivibili destinate a caricamenti, plugin o temi. Alcune richieste tentavano di scaricare ed eseguire un altro payload mediante curl, wget e un interprete shell. Altre utilizzavano hostname univoci nei domini oast.pro, oast.fun e oast.online per un out-of-band callback, ossia una connessione dal server preso di mira a un servizio esterno. Ulteriori indicatori utili alla difesa includono ADV618BOUNDARY, ----P2SB, php2shell.php, axiom_*.php e i nomi delle classi Illuminate\Broadcasting\PendingBroadcast, Monolog\Handler\BufferHandler e Requests_Utility_FilteredIterator.
I 20 indirizzi sorgente più attivi erano 87.121.84.174 con 8.525 tentativi bloccati, 181.215.186.252 con 7.856, 185.196.220.132 con 7.146, 185.161.210.29 con 5.796, 152.233.51.69 con 5.317, 45.134.225.16 con 3.623, 107.189.14.87 con 2.365, 193.47.62.24 con 2.263, 2409:40d2:204e:4be:2a1f:f9c9:a055:e00b con 1.953 e 103.147.220.17 con 1.860. Gli indirizzi rimanenti erano 143.246.223.124 con 1.791, 52.74.54.75 con 1.260, 65.49.200.56 con 836, 193.142.147.111 con 775, 85.137.56.188 con 672, 85.137.53.26 con 664, 167.254.242.130 con 648, 217.112.152.168 con 619, 203.78.119.133 con 616 e 140.245.32.169 con 616.
L’efficacia dello sfruttamento resta legata alla configurazione di PHP, alla Server Application Programming Interface (SAPI) che collega PHP al web server, alle estensioni installate, alle classi dell’applicazione disponibili e allo stato corrente di un PHP worker. In precedenza, Wordfence aveva ottenuto code execution durante i test di CVE-2026-109619 in un laboratorio Apache appositamente configurato che utilizzava PHP 8.5.11. Lo stesso proof of concept causava invece il crash di una build PHP 8.5.11 normalmente ottimizzata, mentre PHP 8.5.12 rimaneva stabile. Per CVE-2026-109618, i suoi test hanno riprodotto comportamenti diversi tra le versioni vulnerabili e quelle corrette, ma non hanno ottenuto autonomamente code execution. Il traffico di produzione appena analizzato non modifica questi risultati di laboratorio né dimostra la riuscita di un exploit nel mondo reale.
Per confermare una compromissione sarebbero necessarie prove ricavate da risposte, file, processi, PHP worker arrestati in modo anomalo, richieste Domain Name System o connessioni web in uscita sul server preso di mira. Wordfence sottolinea che l’assenza di tale conferma nella propria telemetria non rende sicuro un sistema privo di patch, perché errori e callback possono verificarsi al di fuori di WordPress e dei suoi log. I gestori di siti che sospettano una compromissione devono conservare le prove pertinenti; Wordfence ha inoltre invitato a inviare campioni all’indirizzo samples@wordfence.com. I clienti Wordfence Care e Wordfence Response possono contattare il suo team di incident response e l’azienda dichiara che Response è disponibile 24 ore su 24, 7 giorni su 7, 365 giorni all’anno, con un tempo di risposta di un’ora. Per i proprietari di siti che stanno valutando il ruolo del livello di hosting nella propria protezione, AEU Hosting offre hosting WordPress gestito e protetto end-to-end. Indipendentemente dalla soluzione di hosting, l’attività immediata consiste nel verificare il servizio PHP dietro ogni sito web, installare una versione contenente entrambe le correzioni e riavviare i relativi PHP worker.