PHP2Shell: 67 indicatori, 35 esecuzioni di shell e il confine tra attacco e compromissione. L’analisi tecnica

Analisi indipendente di Cyber Threat Intelligence su PHP2Shell (CVE-2026-109618 e CVE-2026-109619), le vulnerabilità critiche del motore PHP con CVSS 9.2. Il report esamina 67 osservabili consolidati, la telemetria di honeypot, i tentativi di malware Potassium e fornisce linee guida di detection engineering per SOC e CSIRT.

Un’analisi indipendente ricostruisce l’evoluzione delle attività offensive associate a CVE-2026-109618 e CVE-2026-109619. Tra tentativi pre-disclosure, infrastrutture di exploitation, malware Potassium e prove di esecuzione remota, la differenza essenziale è tra ciò che è stato osservato e ciò che è stato dimostrato.

Di Agostino Pellegrino e Crescenzo Cuoppolo

27 ottobre 2026  ·  Cyber Threat Intelligence  ·  Vulnerability Research  ·  Detection Engineering

Un’emergenza che richiede soprattutto accuratezza

Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti di sicurezza per due vulnerabilità critiche, identificate come CVE-2026-109618 e CVE-2026-109619, collettivamente conosciute come PHP2Shell [1, 2].

Entrambe presentano un punteggio CVSS v4.0 pari a 9,2 e possono consentire, in determinate condizioni, l’esecuzione remota di codice senza autenticazione. Le vulnerabilità interessano il motore PHP, non una specifica applicazione, un plugin o un content management system.

La natura delle debolezze rende particolarmente rilevante la superficie esposta attraverso applicazioni web, piattaforme CMS, servizi legacy e prodotti che incorporano un interprete PHP.

La pubblicazione degli aggiornamenti ha coinciso con una rapida diffusione di proof of concept, scanner e tentativi di sfruttamento. Alcune attività erano state osservate persino prima della disclosure ufficiale [3].

Il problema non riguarda soltanto l’esistenza di vulnerabilità critiche o la disponibilità di strumenti per sfruttarle. La questione centrale è determinare quando un tentativo di exploitation possa essere considerato una compromissione effettiva.

È da questo interrogativo che nasce il nostro rapporto indipendente di Cyber Threat Intelligence, dedicato alla raccolta, verifica e classificazione di indicatori tecnici associati a PHP2Shell. L’analisi, aggiornata al 27 ottobre 2026, consolida 67 osservabili, distinguendo evidenze di esecuzione, attività offensive documentate e informazioni contestuali utili alle indagini.

Il risultato non è una lista di 67 sistemi compromessi, né un censimento di attacchi riusciti. È un insieme strutturato di elementi investigativi la cui interpretazione dipende dalla qualità delle evidenze disponibili.

Le vulnerabilità: corruzione della memoria e stato globale non valido

La prima vulnerabilità riguarda la gestione delle condizioni di esaurimento della memoria. PHP utilizza meccanismi di interruzione del flusso di esecuzione, tra cui longjmp(), per gestire determinati errori fatali.

Quando l’esaurimento della memoria interrompe una fase in cui alcune strutture interne non sono state completamente inizializzate, la successiva procedura di cleanup può accedere a uno stato non valido. In condizioni sfruttabili, questa situazione può condurre a corruzione della memoria ed esecuzione di codice non autorizzato [1].

CVE-2026-109619: riferimenti persistenti a memoria già liberata

La seconda vulnerabilità interessa la gestione di variabili e strutture globali che possono conservare riferimenti a memoria appartenente a richieste precedenti. Se lo stato globale non viene correttamente ripristinato, una richiesta successiva può accedere a regioni di memoria non più valide. Il problema può facilitare condizioni di accesso improprio alla memoria e, in scenari sfruttabili, esecuzione remota di codice [2].

Versioni interessate e correzioni

Le release PHP corrette pubblicate il 21 ottobre sono:

Le versioni precedenti alle rispettive release corrette risultano vulnerabili secondo gli advisory upstream. Le distribuzioni che utilizzano backport di sicurezza richiedono una verifica specifica del pacchetto installato. Per le versioni non più supportate dal progetto PHP occorre valutare gli aggiornamenti del distributore, eventuali servizi di supporto esteso oppure la migrazione.

L’esposizione non è uniforme in tutte le architetture. Apache con mod_php rappresenta uno degli scenari di maggiore interesse, poiché sono stati dimostrati percorsi di sfruttamento che intervengono prima dell’esecuzione del codice applicativo. Altri modelli, tra cui PHP-FPM, PHP-CGI, FrankenPHP e LiteSpeed, richiedono una valutazione delle rispettive condizioni di sfruttabilità. La presenza di un runtime vulnerabile non dimostra che un sistema sia già stato attaccato o compromesso.

La cronologia: dalle prime attività alla prova di esecuzione

17 ottobre 2026 — Attività precedente alla divulgazione

Amazon Threat Intelligence individua attraverso la rete MadPot tentativi compatibili con PHP2Shell. L’attività precede di quattro giorni il rilascio pubblico delle correzioni. L’origine attraverso infrastrutture di anonimizzazione e la natura delle richieste indicano un’attività sospetta, senza consentire di stabilire come gli operatori avessero ottenuto le informazioni tecniche in anticipo [3].

21 ottobre 2026 — Disclosure e aggiornamenti

Il progetto PHP pubblica le release di sicurezza. Nelle ore precedenti e successive emergono strumenti di scansione, proof of concept e ulteriori tentativi osservati da fornitori di sicurezza e infrastrutture di monitoraggio [1, 2, 9].

22 ottobre 2026 — Tentativi di distribuzione malware

Sophos e Arctic Wolf descrivono attività offensive associate a payload riconducibili a Potassium, variante con caratteristiche derivate da Mirai. La presenza di payload e infrastrutture C2 non dimostra automaticamente l’installazione del malware sui sistemi bersaglio [5, 6].

24 ottobre 2026 — Evidenza di esecuzione su honeypot

Il ricercatore 0x4D31 pubblica un dataset che collega traffico HTTP, log Apache/PHP, PCAP e telemetria Tetragon. Vengono documentate 35 esecuzioni di /bin/sh su tre ambienti honeypot PHP intenzionalmente vulnerabili [4].

25 ottobre 2026 — Rettifica dell’attribuzione

Unit 42 ritira una precedente attribuzione che collegava un incidente presso un ente governativo europeo alle specifiche vulnerabilità PHP2Shell. L’incidente era osservato nel contesto di un’applicazione PHP vulnerabile, ma le evidenze non erano sufficienti per confermare che l’accesso iniziale fosse avvenuto attraverso le due CVE [11].

Anche Sophos aveva corretto il 22 ottobre una propria valutazione iniziale relativa a una compromissione presso un cliente, precisando che la telemetria disponibile documentava scansioni e tentativi falliti [5]. La solidità di un rapporto tecnico dipende anche dalla capacità di correggere le attribuzioni quando le evidenze non le sostengono.

Le 35 shell: cosa dimostrano realmente gli honeypot

Il rapporto tecnico pubblicato il 24 ottobre da 0x4D31 presenta una catena probatoria particolarmente interessante, basata su tre target PHP configurati come honeypot (T1, T2 e T3), con PHP 8.4.26, Apache mod_php e un limite di memoria PHP di 128 MiB [4].

La ricerca ha correlato 35 richieste HTTP della fase finale dell’exploit con 35 eventi di avvio di /bin/sh, generati direttamente da processi Apache. Le esecuzioni sono documentate mediante packet capture e telemetria del sistema operativo. Il dataset include eventi di creazione dei processi, relazioni padre-figlio, richieste HTTP e informazioni temporali.

In diversi casi i comandi eseguiti hanno invocato utility come id, PHP CLI e curl, producendo ulteriori elementi di conferma. Questo consente di superare la semplice osservazione di richieste anomale o di errori applicativi.

Una richiesta HTTP sospetta non prova l’esecuzione remota di codice; un errore PHP di memoria esaurita non costituisce, da solo, prova di compromissione. Nemmeno un crash del worker Apache consente automaticamente tale conclusione. La presenza di una shell avviata dal processo web, temporalmente correlata alla richiesta di exploitation, costituisce invece un’evidenza endpoint molto più forte.

Questi eventi riguardano sistemi honeypot deliberatamente vulnerabili, non ambienti produttivi di organizzazioni terze. I due indirizzi IP individuano due gruppi di traffico, non necessariamente due attori indipendenti. La somiglianza dei payload non basta ad attribuire un controllo comune.

Il materiale è coerente con una catena di sfruttamento associata a CVE-2026-109618. Non permette, da solo, di dimostrare lo sfruttamento di un percorso indipendente e specifico di CVE-2026-109619.

La sequenza tecnica osservata

• A1 — Memory pressure. Una richiesta HTTP multipart provoca una condizione di esaurimento della memoria nel processo PHP.
• B1 — Memory disclosure. Una seconda richiesta produce una risposta contenente dati anomali nel valore di sessione, utilizzabili per inferire informazioni sulla memoria del processo.
• A2 — Ulteriore memory pressure. Una successiva richiesta prepara lo stato necessario allo sfruttamento.
• B2 — Execution stage. Una richiesta finale, adattata alle informazioni raccolte, conduce all’avvio di una shell nei casi documentati.

In alcune sequenze il worker Apache termina successivamente per segmentation fault. La combinazione tra disclosure della memoria e successivo adattamento del payload è significativa perché dimostra la possibilità di superare, in quelle specifiche condizioni sperimentali, ostacoli introdotti dalla randomizzazione dello spazio di indirizzamento. Le condizioni operative del test non autorizzano a generalizzare la stessa probabilità di successo a tutte le installazioni PHP [4].

Potassium: il malware collegato ai tentativi

Parallelamente alla diffusione degli exploit, diversi ricercatori hanno osservato attività orientate alla distribuzione di malware. Un caso riguarda Potassium, famiglia con caratteristiche riconducibili all’ecosistema Mirai [5, 6].

I campioni analizzati presentano funzionalità di downloader, comunicazione con infrastrutture remote e capacità di condurre attacchi di interruzione del servizio. Tra gli indirizzi associati all’infrastruttura figurano 134.199.154.64 e 117.55.202.115. Ulteriori indicatori comprendono domini di staging e URL destinati al recupero di payload.

L’interesse investigativo riguarda la possibile concatenazione tra accesso iniziale, esecuzione di codice, download di un componente secondario e successiva attività malevola. Nel caso documentato da Sophos, tuttavia, l’analisi successiva ha stabilito che il tentativo non aveva prodotto l’installazione del malware sul sistema cliente [5].

Gli hash pubblicati identificano campioni analizzati, non file necessariamente trovati su vittime compromesse. La disponibilità di un malware e l’osservazione di un tentativo di consegna non dimostrano il completamento della catena d’infezione.

La nostra analisi CTI: 67 osservabili e tre livelli probatori

Il consolidamento ha prodotto un dataset di 67 indicatori e artefatti tecnici, selezionati e contestualizzati attraverso fonti pubbliche. La classificazione non è costruita esclusivamente sulla reputazione dell’indirizzo, sull’origine dell’infrastruttura o sulla pericolosità presunta del contenuto: il criterio è la relazione documentabile tra l’osservabile e uno specifico evento.

Livello A: evidenza diretta nell’ambiente osservato

Comprende indirizzi sorgente associati alle 35 shell, un endpoint di callback, un boundary HTTP ricorrente e 16 digest dei corpi multipart della fase di esecuzione. Non rappresenta 20 compromissioni indipendenti. La classificazione descrive il collegamento dell’elemento a episodi di RCE documentati sui target di ricerca.

Livello B: attività offensiva e infrastruttura

Raccoglie IP di scansione, tentativi di exploitation, server associati a payload, domini e hash dei campioni Potassium. La presenza di questi indicatori in una rete richiede approfondimento, ma non certifica il successo dell’attacco.

Livello C: contesto investigativo

Include User-Agent, boundary multipart, marker di validazione, strumenti ospitati su server esposti e digest appartenenti a fasi preliminari dell’exploit. Sono elementi utili per riconoscere pattern di attività o collegare eventi, ma alcuni sono aspecifici e producono falsi positivi se interpretati isolatamente.

La confidenza elevata attribuita alla pubblicazione di un osservabile indica che la fonte ne documenta l’esistenza; non significa che qualsiasi corrispondenza rappresenti un incidente.

Dall’indicatore alla detection: il ruolo del SOC

Una delle principali criticità operative è la tendenza a trasformare automaticamente gli indicatori CTI in regole di blocco. Un IP associato a una scansione può appartenere a un’infrastruttura condivisa, a un provider di hosting o a una rete di anonimizzazione. Una corrispondenza su un User-Agent può rappresentare una scansione autorizzata oppure una stringa imitabile. Un digest di payload HTTP può identificare una richiesta già osservata senza dimostrare che il comando associato sia stato eseguito.

Il rapporto propone un approccio di detection engineering basato sulla correlazione tra rete, applicazione ed endpoint.

Hunting sui log PHP

Tra i segnali tecnici figura la combinazione tra errore fatale PHP, esaurimento della memoria e stringa Unknown on line 0. Un esempio preliminare KQL per Elastic Security, da adattare ai dataset disponibili, è:

message: “PHP Fatal error” and

message: “Allowed memory size” and

message: “Unknown on line 0”

Elastic ha pubblicato una regola denominata Potential PHP2Shell Exploitation Attempt, orientata al riconoscimento del caratteristico errore OOM. La regola identifica possibili tentativi, non costituisce una prova autonoma di esecuzione remota [10].

Hunting comportamentale su Linux

La telemetria di processo può rilevare l’avvio di shell, interpreti o utility di rete da parte dei processi web. Esempio EQL:

process where host.os.type == “linux” and

  event.type == “start” and

  process.parent.name : (“apache2″,”httpd”,”php-fpm*”,

    “php”,”php-cgi”,”nginx”,”lsphp*”) and

  process.name : (“sh”,”bash”,”dash”,”curl”,”wget”,

    “python*”,”perl”,”nc”,”socat”)

La logica ricerca comportamenti compatibili con attività post-exploitation e non è limitata a PHP2Shell.

Hunting comportamentale su Windows

Su Windows l’attenzione deve concentrarsi sulle relazioni tra i processi web e gli interpreti di comando o le utility utilizzabili per attività successive all’accesso iniziale. Esempio EQL:

process where host.os.type == “windows” and

  event.type == “start” and

  process.parent.name : (“w3wp.exe”,”php.exe”,

    “php-cgi.exe”,”httpd.exe”,”nginx.exe”) and

  process.name : (“cmd.exe”,”powershell.exe”,”pwsh.exe”,

    “certutil.exe”,”bitsadmin.exe”,”curl.exe”,”mshta.exe”)

Entrambe le ricerche richiedono copertura EDR, normalizzazione ECS e validazione sui comportamenti legittimi dell’organizzazione.

Il valore della correlazione

Una sequenza investigativa di particolare interesse comprende:

• Richiesta HTTP multipart sospetta.
• Errore di memoria PHP durante l’inizializzazione della richiesta.
• Eventuale disclosure di dati di sessione o crash del worker.
• Creazione inattesa di una shell da parte del processo web.
• Esecuzione di comandi di ricognizione o utility di rete.
• Connessioni outbound e modifiche del filesystem.

Maggiore è il numero di evidenze indipendenti temporalmente coerenti, più solida diventa la valutazione. Gli access log standard non contengono necessariamente gli header completi o i corpi multipart necessari a identificare i fingerprint descritti. Occorre verificare quali informazioni siano realmente disponibili tramite WAF, CDN, reverse proxy, log applicativi e sensori di rete.

Il runbook proposto per SOC e CSIRT

• 1. Identificazione dell’esposizione. Inventariare runtime PHP, versioni, configurazioni web server, prodotti embedded e backport. Dare priorità agli asset Internet-facing.
• 2. Preservazione delle evidenze. Per eventi sospetti conservare log HTTP, PHP error, EDR, eventi processo, connessioni rete, file ed eventuali evidenze volatili.
• 3. Correlazione temporale. Ricostruire richieste, risposte, PID dei worker e processi figli. Verificare il client IP reale attraverso i proxy attendibili.
• 4. Classificazione dell’evento. Separare scansione, tentativo, possibile memory disclosure, RCE verificata e successivo impatto.
• 5. Remediation. Installare le versioni corrette o gli aggiornamenti con backport verificato. Impiegare WAF come controllo aggiuntivo, non sostitutivo delle patch.
• 6. Revalidazione. Verificare aggiornamenti, copertura dei sensori ed eseguire retro-hunt a partire almeno dal 17 ottobre 2026.

Gli indicatori A meritano hunting prioritario, senza escalation automatica in assenza di riscontri locali. Gli osservabili B richiedono enrichment e correlazione, con blocchi selettivi previa valutazione del rischio. Gli elementi C costituiscono soprattutto supporto investigativo e per le ricerche retrospettive.

Le infrastrutture complesse e il problema del patching

La diffusione di PHP in applicazioni web, piattaforme legacy e prodotti embedded rende la gestione di PHP2Shell un problema trasversale. Non è sufficiente interrogare la versione del linguaggio installata sui server più visibili. Occorre considerare componenti applicative non censite, istanze secondarie, ambienti di test raggiungibili dall’esterno, dipendenze di terze parti e runtime distribuiti insieme ad altri prodotti.

In ambienti complessi, tra cui organizzazioni pubbliche e infrastrutture con numerosi fornitori, il problema principale può essere la conoscenza incompleta della superficie applicativa. Il rischio è aggravato dalla differenza tra disponibilità della patch e applicazione effettiva.

Le evidenze precedenti al 21 ottobre mostrano anche che la finestra investigativa non deve iniziare necessariamente dalla disclosure ufficiale: occorre includere eventi antecedenti quando esistono indicatori attendibili di tentativi osservati durante il periodo di embargo.

Conclusioni: la CTI deve produrre evidenza, non soltanto allarmi

PHP2Shell rappresenta un caso significativo non soltanto per la gravità delle vulnerabilità, ma per la rapidità con cui la comunità ha prodotto osservazioni, strumenti e valutazioni differenti.

I tentativi offensivi sono documentati anche prima della divulgazione. Esistono infrastrutture e campioni malware collegati alle attività osservate. La ricerca su honeypot ha dimostrato esecuzioni remote di codice in specifiche condizioni sperimentali. Non è invece corretto trasformare queste evidenze in una dichiarazione generalizzata di compromissioni produttive attribuite alle due vulnerabilità.

Le rettifiche dei ricercatori devono essere incorporate nelle analisi successive, evitando che informazioni superate continuino a circolare come fatti accertati. Il nostro dossier CTI nasce da questa impostazione: ogni osservabile deve essere accompagnato da contesto, provenienza e livello probatorio.

Per un SOC, un CSIRT o un team di Incident Response, il valore dell’intelligence non coincide con il numero di IOC raccolti. Coincide con la capacità di utilizzarli per formulare ipotesi verificabili, individuare anomalie significative e ricostruire, quando possibile, una catena di evidenza. È questa la differenza tra identificare un tentativo di attacco e dimostrare una compromissione.

Appendice tecnica — Dataset CTI PHP2Shell

Snapshot del 27 ottobre 2026. Gli indicatori sono destinati ad attività di hunting, enrichment e correlazione; non rappresentano una blocklist da distribuire indiscriminatamente. Le classificazioni A/B/C si riferiscono agli eventi documentati, non a proprietà permanenti dell’indicatore.

A. Indirizzi IPv4

B. Domini, URL ed endpoint

Non visitare o eseguire gli URL da dispositivi di lavoro. Infrastrutture e indirizzi potrebbero essere stati modificati o riassegnati dopo il periodo osservato.

C. Hash malware Potassium

SHA-256 · Campione 1

0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486

MD5 · Stesso campione

b61a098fc62a2c2696e196dca78da71a

SHA-1 · Stesso campione

c472dab4ff7c16782a8037f988d4daa6d4bdb343

SHA-256 · Campione 2

e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3

I primi tre hash si riferiscono allo stesso campione. Gli hash di file sono indicatori di malware analizzato, non prova di installazione su un host produttivo. Tutti sono di livello B.

D. Fingerprint HTTP e indicatori contestuali

Il boundary CCCCCCCCCC è presente nel traffico che ha prodotto RCE sugli honeypot, ma è generico e, isolatamente, comporta alto rischio di falsi positivi. Header, marker e valori multipart possono non essere acquisiti dai normali access log.

E. Digest SHA-256 dei corpi HTTP multipart

I 19 SHA-256 che seguono riguardano corpi HTTP multipart decodificati e NON file malware. Il confronto richiede PCAP o telemetria WAF/reverse proxy con body completo e normalizzazione coerente con quella del rapporto originale [4].

Tre digest preliminari — livello C

A1 · Memory pressure

8e8fc166e6b326d20bb7611d8ef3cee3bd5da46447985312c1492ab0a44d1eb6

B1 · Memory disclosure

b6c547e0e9a2bb26607df1521de96f4d5c9adf4621c28b7ab491587b21ae40f2

A2 · Memory pressure

7af66c8f35c5fa6b47a539da6dca361d19543d9f62d61e4af891c2802bd5e236

Sedici digest della fase B2 — livello A

01   e538361aa02f01bb9e00f53d2107eb1369f778203033e08506496a767c0e4abc

02   aab24fa5ec0df76f731c1ea4bac9fd36aa350eef9a42c33315e485178e1e5892

03   b8a67dc5173272afd95cd603b2bd7b49bb6e0900af53237096b8caf9fd48ca97

04   567659d699213c360e4598c257c40260cf0d7b1377e4a25851ca3f59a427899c

05   a744539cce8295ac07ca70fd5eab9601ef79fb62f142749373d855033fb101e0

06   675647c9919681e3f6a58c54be30a22942b523e036ee53f0e4fdccf22a506408

07   d2d86024e947cbdcecb725e3dae4930579b28f23bff80eedaad6b3f11544bcff

08   dcb4e2b4f6879827222d0bb5efa14dc838357251880302401bc8702bb3085370

09   b8e69e39c49c986a6edae77f08b11be1ab1675d4fda6c05dcf0628149eefbd06

10   c1263f68fcb9565dc3b162481574ed6f64ad11436e654751a9da4644352bbcee

11   c61540651b07f744fa9d43ff326daa7a81c51f90ffdd05b28d1b552ade5320a4

12   c1fc4df4a886aff090471f27a40c29358444b3668257e1b2074577477ba2e36c

13   ff73391d30efd875a28c65178a59cacf6b933f911ae51654b2ffb4d4d3fe850a

14   23b0d9cb7dce28dbeb9749d2664eacd64474f7a4fab3c152747603c33214e58a

15   77afd5bf9c28069616b514a2955dbf52dc62e3b5c5c04c1e86c7a3c3fc5a5156

16   e5a9ca54352814eaefc2051013aa424d4e6fd780a2c0d1085fdd35eac392e5c4

Una corrispondenza su questi digest non certifica da sola l’esito RCE. Non convertirli in hash IOC file-based per EDR.

F. Indicatori esclusi dal consolidamento

Sono stati esclusi dieci elementi o categorie di elementi non sufficientemente specifici, non verificati indipendentemente oppure oggetto di rettifica. Tra questi figurano boundary sperimentali, indirizzi probabilmente riconducibili a scanner di ricerca, fingerprint confondibili con la distinta vulnerabilità WordPress WP2Shell e indicatori dell’incidente europeo per cui Unit 42 ha ritirato l’attribuzione.

L’esclusione è parte integrante del metodo analitico: la presenza di un valore in una regola sperimentale o in una directory non basta a qualificarlo come IOC accertato.

Bibliografia e fonti tecniche

Riferimenti tecnici pubblici richiamati nell’articolo. Data di consultazione del dossier: 27 ottobre 2026. I collegamenti sono cliccabili; le date delle singole pubblicazioni sono riportate quando note.

[1] PHP Development Team. (2026, 21 ottobre). RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). GitHub Security Advisory. https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

[2] PHP Development Team. (2026, 21 ottobre). RCE via stale global state (GHSA-6wmf-4rv5-p3rp). GitHub Security Advisory. https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

[3] Amazon Threat Intelligence. (2026, 21 ottobre). Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog. https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

[4] 0x4D31. (2026, 24 ottobre). PHP2Shell exploitation observed: Packet-to-process RCE evidence. GitHub. https://github.com/0x4D31/honeypot-data/blob/main/reports/php2shell/2026-10-24-confirmed-rce.md

[5] Sophos. (2026, ottobre). Proof-of-concept exploit released for PHP vulnerabilities (CVE-2026-109618, CVE-2026-109619). https://www.sophos.com/en-us/blog/proof-of-concept-exploit-released-for-php-vulnerabilities-109618-109619

[6] Arctic Wolf Labs. (2026, 22 ottobre). PHP2Shell: Critical PHP vulnerabilities enable unauthenticated remote code execution. https://arcticwolf.com/resources/blog/php2shell-critical-php-vulnerabilities-enable-unauthenticated-remote-code-execution/

[7] SOCRadar Threat Intelligence Unit. (2026, ottobre). PHP2Shell exploit tooling found on exposed attacker server. https://socradar.io/blog/php2shell-exploit-tooling-attacker-server/

[8] Hunt.io. (2026, 22 ottobre). Hunting leaked PHP2Shell RCE across open directories. https://hunt.io/blog/php2shell-CVE-2026-109618-109619-open-directories

[9] Fastly. (2026, ottobre). PHP2Shell: Finding the needles in a 250,000 request haystack. https://www.fastly.com/blog/how-fastly-detected-and-built-a-coordinated-response-to-php2shell

[10] Elastic. (2026). Potential PHP2Shell exploitation attempt. Elastic Security. https://www.elastic.co/guide/en/security/8.19/prebuilt-rule-8-19-36-potential-php2shell-exploitation-attempt.html

[11] Palo Alto Networks, Unit 42. (2026, aggiornamento 25 ottobre). Threat brief: Critical vulnerabilities in PHP—CVE-2026-109618, CVE-2026-109619. https://unit42.paloaltonetworks.com/CVE-2026-109618-CVE-2026-109619/

[12] Amazon Web Services. (2026, 21 ottobre). Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities. AWS Security Blog. https://aws.amazon.com/blogs/security/using-aws-waf-to-apply-mitigations-for-php2shell-rce-vulnerabilities-CVE-2026-109618-and-CVE-2026-109619/

[13] PHP Development Team. (2026). PHP release archive. https://www.php.net/archive/2026.php

[14] CISA. (2026). Experimental SIGMA rule for PHP2Shell. GitHub. https://github.com/cisagov/SIGMA_Rules/blob/develop/CISA_SIGMA_261429_CVE_2026_109618-109619_PHP2Shell_TLP_CLEAR.yaml

Nota metodologica

Il presente articolo è una sintesi analitica indipendente basata su correlazione e classificazione di evidenze tecniche pubbliche. Non rappresenta un advisory ufficiale, non implica accesso diretto ai sistemi delle organizzazioni citate e non certifica compromissioni produttive in assenza di evidenze specifiche. Gli osservabili devono essere interpretati nel contesto temporale e tecnologico delle rispettive fonti. Il rapporto CTI originario e il dataset strutturato rimangono le fonti canoniche delle classificazioni.

Autori: Agostino Pellegrino e Crescenzo Cuoppolo. Rapporto di riferimento: PHP2Shell — Dalla telemetria alla prova. IOC, catena di evidenza e detection engineering. Edizione indipendente del 27 ottobre 2026.

Agostino Pellegrino

E’ un libero professionista, insegnante e perito di informatica Forense, Cyber Security ed Ethical Hacking e Network Management. Ha collaborato con importanti istituti di formazione a livello internazionale e ha esercitato teaching e tutorship in tecniche avanzate di Offensive Security per la NATO ottenendo importanti riconoscimenti dal Governo degli Stati Uniti. Il suo motto è “Studio. Sempre”.

Aree di competenza: Cybersecurity architecture, Threat intelligence, Digital forensics, Offensive security, Incident response & SOAR, Malware analysis, Compliance & frameworks