PHP2Shell attaccato prima delle patch, GitLab corregge una RCE CVSS 10

🛡️ Executive Summary

• Amazon Threat Intelligence documenta un tentativo di sfruttamento di PHP2Shell il 17 ottobre 2026, quattro giorni prima della pubblicazione delle patch, e ulteriori attacchi nelle ore precedenti alla divulgazione ufficiale.
• GitLab corregge CVE-2026-110264, una vulnerabilità CVSS 10 nel compilatore di espressioni regolari che può consentire l’esecuzione remota di codice senza autenticazione. Sono interessate versioni distribuite a partire da GitLab 7.0.
• Le patch GitLab del 12 ottobre non correggono la nuova vulnerabilità. Gli amministratori devono aggiornare nuovamente le installazioni self-managed e verificare eventuali attività sospette.

PHP2Shell era già nel mirino degli aggressori quattro giorni prima della pubblicazione delle patch, mentre GitLab deve correggere una nuova vulnerabilità critica con punteggio CVSS 10 capace di consentire l’esecuzione remota di codice senza autenticazione. La conferma arriva da Amazon Threat Intelligence, che ha ricostruito un tentativo di sfruttamento delle vulnerabilità PHP risalente al 17 ottobre 2026, e dal nuovo bollettino di sicurezza di GitLab, che il 21 ottobre ha distribuito sette versioni correttive per la CVE-2026-110264. I due incidenti riguardano componenti differenti dell’infrastruttura digitale, ma condividono una caratteristica: la finestra temporale tra scoperta, divulgazione e disponibilità degli exploit si sta riducendo drasticamente, costringendo aziende e amministratori a rivedere i tempi delle attività di patch management.

Amazon scopre PHP2Shell il 17 ottobre, prima della divulgazione delle vulnerabilità

La nuova ricostruzione di Amazon Threat Intelligence modifica sensibilmente la cronologia degli attacchi contro CVE-2026-109618 e CVE-2026-109619, le due vulnerabilità conosciute come PHP2Shell. Il sistema MadPot, una rete di honeypot utilizzata da Amazon per intercettare attività offensive, ha registrato il 17 ottobre 2026 una richiesta riconducibile a un tentativo di sfruttamento delle falle, quattro giorni prima della pubblicazione delle correzioni. La connessione proveniva dall’indirizzo 103.216.220.92, associato a un servizio commerciale di anonimizzazione. Nel rapporto ufficiale di Amazon Threat Intelligence pubblicato il 21 ottobre, il responsabile della sicurezza integrata CJ Moses sottolinea che l’origine anonimizzata e la natura della richiesta suggeriscono un’attività ostile, senza chiarire come l’operatore sia venuto a conoscenza della vulnerabilità prima della divulgazione. Amazon documenta un tentativo di exploit, non una compromissione riuscita di un server reale, distinzione determinante per valutare le conseguenze effettive dell’incidente. La vicenda introduce un elemento nuovo rispetto alla precedente analisi sulle patch PHP2Shell e sulle due RCE critiche corrette il 21 ottobre: la data di pubblicazione dell’advisory non coincide con il primo tentativo di sfruttamento osservato. Per le organizzazioni che utilizzano PHP, eventuali verifiche forensi non dovrebbero quindi limitarsi ai log successivi al rilascio delle patch, ma comprendere almeno il periodo a partire dal 17 ottobre.

Leggi anche: PHP2Shell, due falle critiche da 9,2: aggiornamento di emergenza per PHP

Exploit PHP2Shell prima e dopo la patch: più attori e una finestra di poche ore

La telemetria Amazon documenta una seconda fase offensiva nelle prime ore del 21 ottobre, quando le vulnerabilità erano ancora soggette all’embargo sulla divulgazione tecnica. Il primo nuovo proof-of-concept viene osservato intorno alle 02:00 UTC, dodici ore prima della pubblicazione ufficiale degli aggiornamenti, seguita da ulteriori richieste fino alle 08:00 UTC. Gli attacchi utilizzavano payload differenti e infrastrutture di anonimizzazione diverse, elementi che secondo Amazon suggeriscono l’attività di più operatori indipendenti, piuttosto che una singola campagna organizzata. Dopo le 14:00 UTC, orario di pubblicazione delle patch, altri exploit sono comparsi nel giro di poche ore, raggiungendo quasi immediatamente i sensori MadPot. Amazon considera ormai PHP2Shell oggetto di sfruttamento diffuso, ma precisa che non è ancora possibile stabilire quanti tentativi siano riusciti contro infrastrutture produttive. Gli indirizzi IP associati alle attività osservate comprendono, oltre al primo identificato il 17 ottobre, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 e 95.217.98.37, tutti rilevati il 21 ottobre. Il produttore avverte però che alcuni appartengono a servizi di anonimizzazione condivisi e non devono essere trattati come indicatori esclusivi di attività criminale. La conclusione operativa è che i tradizionali intervalli di aggiornamento di sette o trenta giorni non risultano più adeguati quando una vulnerabilità critica interessa componenti esposti pubblicamente. Amazon richiama anche il contributo dell’intelligenza artificiale nell’accelerazione dell’analisi delle patch e della costruzione degli exploit, senza attribuire specificamente all’AI gli attacchi osservati contro MadPot. La dinamica conferma quanto già emerso durante lo sfruttamento della vulnerabilità PHP CVE-2024-4577 per distribuire malware, ma con tempi di reazione ulteriormente compressi.

PHP2Shell, i controlli sui server devono partire dalle richieste precedenti al 21 ottobre

Le due vulnerabilità PHP hanno ricevuto aggiornamenti correttivi nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mentre gli ambienti che utilizzano distribuzioni Linux con backport di sicurezza devono verificare la presenza delle correzioni nei pacchetti effettivamente installati. La questione più urgente riguarda gli ambienti che sono rimasti esposti durante i giorni precedenti alla pubblicazione. Amazon raccomanda di cercare richieste HTTP POST contenenti PHP_SESSION_UPLOAD_PROGRESS, eventi anomali nei log dei web server, esecuzione inattesa di processi da parte dei servizi PHP e modifiche non autorizzate ai file dell’applicazione. Il controllo deve includere eventuali installazioni nascoste nei container, versioni PHP differenti tra CLI e server web e applicazioni legacy mantenute dai fornitori. La presenza di un indirizzo IP segnalato da Amazon non dimostra automaticamente una compromissione, mentre l’assenza di errori applicativi visibili non consente di escluderla: alcune condizioni di sfruttamento possono verificarsi prima dell’esecuzione del codice del CMS e produrre tracce limitate nei normali log applicativi. Nei sistemi WordPress, Drupal, Joomla e Magento, aggiornare plugin o componenti editoriali non corregge le vulnerabilità dell’interprete. La priorità rimane quindi installare le versioni PHP corrette, riavviare i worker e verificare retroattivamente eventuali attività ostili, applicando mitigazioni WAF soltanto come protezione aggiuntiva. Il rischio per le infrastrutture aziendali richiama quello documentato nelle campagne contro WordPress e Joomla che hanno trasformato vulnerabilità applicative in accessi persistenti ai server, pur riguardando in questo caso un componente software differente.

GitLab CVE-2026-110264: un integer overflow consente RCE senza autenticazione

Il secondo fronte riguarda GitLab Community Edition ed Enterprise Edition, che il 21 ottobre 2026 hanno ricevuto un aggiornamento straordinario per correggere CVE-2026-110264, vulnerabilità valutata CVSS 3.1 10.0. Il problema risiede nel Regular Expression Compiler, componente che elabora espressioni regolari utilizzate da funzionalità della piattaforma. In determinate condizioni, una regex appositamente costruita può provocare un integer overflow e consentire l’esecuzione di codice arbitrario sul server. La vulnerabilità è sfruttabile senza autenticazione secondo il vettore CVSS ufficiale, anche se GitLab non ha pubblicato tutti i dettagli del percorso necessario a raggiungere il codice vulnerabile. Nel bollettino ufficiale GitLab Critical Patch Release del 21 ottobre vengono indicate come vulnerabili tutte le versioni a partire da GitLab 7.0, con una superficie potenzialmente molto ampia che comprende installazioni storiche e rami ancora mantenuti. Le sette versioni corrette sono 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13, con quattro backport aggiuntivi rispetto al normale ciclo delle release. La vulnerabilità è stata segnalata dal ricercatore joaxcar attraverso il programma HackerOne. Il nuovo problema è distinto dalla CVE-2026-97229, anch’essa classificata CVSS 10 e corretta il 12 ottobre, che interessava il compilatore di espressioni regolari utilizzato nelle configurazioni CI/CD. La differenza è fondamentale: chi aveva installato GitLab 19.4.2, 19.3.5 o 19.2.8 per proteggersi dalla falla precedente deve aggiornare nuovamente. Il precedente è stato approfondito nell’analisi sulla CVE-2026-97229 e sulla sicurezza delle pipeline GitLab, ma la nuova vulnerabilità amplia ulteriormente il perimetro storico interessato.

GitLab corregge altre undici falle: LDAP, OAuth e credenziali esposte

Il rilascio GitLab non si limita alla RCE principale, ma comprende dodici correzioni di sicurezza complessive, tra cui due vulnerabilità di gravità elevata. La CVE-2026-15723, valutata CVSS 8,2, riguarda l’integrazione OmniAuth SAML e LDAP: quando entrambe le funzionalità di collegamento automatico delle identità sono abilitate, un utente già autenticato può, in determinate condizioni, assumere il controllo di un account LDAP esistente senza alcuna interazione del titolare. La CVE-2026-112212, con punteggio 7,5, permette invece di manipolare documenti di discovery OAuth/OIDC conservati in cache condivise, potenzialmente reindirizzando alcuni flussi di autenticazione verso server controllati dall’attaccante. Altri problemi riguardano accessi impropri a informazioni di progetti privati attraverso GraphQL e API, credenziali interne presenti nelle intestazioni delle risposte HTTP e controlli incompleti sulle policy di approvazione delle merge request. La gravità della nuova RCE è amplificata dalla posizione di GitLab nella catena di sviluppo del software, perché una compromissione del server potrebbe esporre repository, pipeline CI/CD, credenziali di distribuzione e configurazioni utilizzate per raggiungere servizi cloud e ambienti produttivi. Un punto centrale è che le vulnerabilità non interessano esclusivamente le installazioni Enterprise: la CVE-2026-110264 coinvolge sia CE sia EE, mentre alcune delle correzioni aggiuntive riguardano specifiche funzionalità Enterprise. Il quadro conferma l’importanza del controllo delle identità e delle credenziali già evidenziata nelle precedenti vulnerabilità GitLab che avevano consentito l’esposizione di informazioni sensibili e l’ingresso nel catalogo KEV della CISA.

Continua con:

GitLab CVSS 10, attacchi su Artifactory, PaperCut e Cisco FMC

GitLab e AWS, l’AI diventa un control plane: RCE e credenziali a rischio

PHP2Shell già attaccato, GitLab ancora senza exploit confermati: cosa aggiornare subito

La differenza più importante tra le due vicende riguarda le evidenze di sfruttamento attivo. Nel caso PHP2Shell, Amazon ha documentato tentativi prima della divulgazione e successivamente una diffusione più ampia degli exploit, pur senza confermare il numero di compromissioni riuscite. Per GitLab CVE-2026-110264, invece, il produttore non ha comunicato prove pubbliche di sfruttamento riuscito nel mondo reale. Ha tuttavia distribuito due regole di rilevamento, denominate “Onigmo native worker crash” e “Org mode render error burst”, che aiutano gli amministratori delle installazioni self-managed a individuare eventi anomali nei log. Le regole sono strumenti investigativi e non costituiscono, da sole, la conferma di una campagna di attacco in corso. GitLab.com utilizza già la versione corretta, mentre i clienti GitLab Dedicated che eseguono le build interne indicate dall’advisory non devono intervenire. Le aziende che gestiscono direttamente i propri server devono invece procedere immediatamente all’aggiornamento, verificare l’integrità dei repository e controllare le credenziali CI/CD qualora emergano indicatori concreti di compromissione. Sul versante PHP, le verifiche devono comprendere almeno le attività registrate dal 17 ottobre, senza limitarsi all’analisi degli eventi successivi alla pubblicazione degli advisory. I due casi dimostrano che la sicurezza del software non può dipendere esclusivamente dalla disponibilità di una patch: occorre sapere quando gli attaccanti hanno iniziato a operare, quanto tempo serve per distribuire le correzioni e quali sistemi possono essere stati esposti prima dell’intervento.