WordPress, Fortinet, AWS e OpenSSL colpiti da nuove vulnerabilità critiche

🛡️ Executive Summary

• WP2Shell combina SQL injection e confusione nel routing REST per ottenere esecuzione remota di codice su installazioni WordPress prive di autenticazione.
• CISA impone patch urgenti per due falle FortiSandbox già sfruttate, mentre AWS corregge scrittura arbitraria e disclosure nel connettore Athena.
• HollowByte sfrutta l’handshake TLS per frammentare la memoria dei server OpenSSL con richieste minime ripetute nel tempo.

Una nuova ondata di vulnerabilità critiche investe componenti centrali dell’infrastruttura digitale, dai siti basati su WordPress agli appliance di analisi malware Fortinet, passando per strumenti AWS destinati agli agenti MCP e ai database federati. Sul fronte crittografico, la falla HollowByte dimostra invece come un payload di appena 11 byte possa produrre un consumo progressivo della memoria nei server che utilizzano versioni vulnerabili di OpenSSL. Le organizzazioni devono distinguere tra problemi già sfruttati attivamente, falle capaci di produrre esecuzione remota di codice e vulnerabilità che richiedono accessi o configurazioni specifiche, assegnando priorità alle patch in base all’esposizione reale.

WP2Shell combina due falle del core WordPress per ottenere RCE

La catena denominata WP2Shell interessa direttamente il core di WordPress e non richiede l’installazione di un plugin vulnerabile. Il primo elemento è CVE-2026-60137, un’iniezione SQL nel parametro author__not_in di WP_Query. Il parametro dovrebbe ricevere un array di identificatori, ma il passaggio di una stringa appositamente costruita consente di aggirare i controlli previsti e alterare la query generata dal sistema. La seconda vulnerabilità, CVE-2026-63030, riguarda il routing delle richieste batch nella REST API: quando una sotto-richiesta genera un errore, il disallineamento tra gli array utilizzati dal dispatcher può associare una risposta o un’autorizzazione alla richiesta sbagliata. La combinazione permette di trasformare l’SQL injection iniziale in esecuzione remota di codice senza autenticazione, colpendo anche installazioni WordPress essenziali e prive di estensioni. Il rischio è particolarmente grave perché molte campagne recenti hanno già dimostrato la rapidità con cui gli attaccanti individuano siti esposti e installano webshell, redirect, loader o account amministrativi persistenti, come emerso nella campagna globale contro WordPress e Joomla con distribuzione di webshell.

Le patch WordPress devono essere applicate senza attendere il normale ciclo di manutenzione

L’iniezione SQL interessa le versioni comprese tra WordPress 6.8.0 e 6.8.5, mentre la catena completa di RCE coinvolge le release da 6.9.0 a 7.0.1. Le correzioni sono disponibili in 6.8.6, 6.9.5 e 7.0.2. L’exploit richiede che l’endpoint REST batch sia accessibile anonimamente e risulta efficace soprattutto quando il sito non utilizza una cache persistente come Redis o Memcached. Queste condizioni non devono però essere interpretate come una mitigazione sufficiente: la presenza di una cache può cambiare in seguito a interventi tecnici, mentre l’endpoint REST potrebbe essere raggiungibile attraverso configurazioni non documentate, proxy o sistemi di sicurezza che non filtrano correttamente le richieste batch. Gli amministratori devono aggiornare il core, verificare account e file modificati, controllare i log web e cercare processi PHP o richieste REST anomale. La vulnerabilità arriva dopo una lunga sequenza di attacchi contro l’ecosistema WordPress, compreso il recente WP-SHELLSTORM che ha colpito siti, componenti HTTP/3 e wallet crypto, confermando che la superficie CMS rimane uno dei bersagli più redditizi per il cybercrime automatizzato.

CISA impone una scadenza urgente per FortiSandbox

Le vulnerabilità CVE-2026-39808 e CVE-2026-25089 in Fortinet FortiSandbox sono state aggiunte al catalogo delle Known Exploited Vulnerabilities della CISA dopo la conferma dello sfruttamento attivo. FortiSandbox viene utilizzato per eseguire e analizzare file sospetti in ambienti isolati, integrare threat intelligence e fornire verdetti a firewall, endpoint e sistemi di posta. La compromissione di una piattaforma con questo ruolo può quindi offrire agli attaccanti un punto privilegiato all’interno della rete di sicurezza, con accesso a campioni, metadati, integrazioni e canali amministrativi. La CISA ha imposto alle agenzie federali statunitensi l’applicazione delle correzioni entro il 19 luglio 2026, in base alla Binding Operational Directive 26-04. Le organizzazioni private non sono obbligate formalmente a rispettare la stessa data, ma l’inserimento nel KEV costituisce una prova operativa della disponibilità di exploit e deve far salire le due falle al livello massimo di priorità. Le recenti campagne contro infrastrutture Fortinet, comprese quelle descritte nell’analisi su FortiBleed, cPanel e SimpleHelp sotto attacco attivo, mostrano come appliance e console di sicurezza vengano spesso attaccate proprio per il loro accesso esteso alle reti aziendali.

AWS HealthOmics MCP permette scrittura arbitraria fuori dalla directory prevista

Il bollettino 2026-060-AWS riguarda CVE-2026-15415 nel server MCP aws-healthomics-mcp-server, vulnerabile fino alla versione 0.0.35. Un attore in grado di influenzare l’agente MCP può manipolare i percorsi utilizzati durante la gestione dei file e scrivere contenuti controllati al di fuori della directory autorizzata. Il problema combina path traversal e scrittura arbitraria, creando la possibilità di sovrascrivere configurazioni, depositare file in directory sensibili o preparare una successiva esecuzione di codice quando l’ambiente utilizza automaticamente i contenuti scritti. La gravità dipende dai privilegi del processo, dalla posizione delle directory accessibili e dal grado di autonomia concesso all’agente. AWS ha corretto il difetto nella versione 0.0.36, che deve essere considerata il livello minimo sicuro. Le implementazioni MCP devono inoltre limitare il filesystem disponibile al processo, eseguire il server con un account privo di privilegi e impedire che parametri di percorso o nomi di file vengano controllati direttamente dal modello. La falla si inserisce nel crescente problema degli agenti connessi a strumenti operativi, già evidenziato nell’approfondimento sul tool poisoning nei server MCP e sull’esfiltrazione attraverso agenti AI.

Athena per Azure Synapse può restituire dati non previsti

Il secondo advisory AWS, 2026-059-AWS, interessa il connettore federato di Amazon Athena per Azure Synapse nelle versioni da v2022.20.1 a v2026.19.1. La vulnerabilità CVE-2026-12283 consente a un utente con accesso all’account Synapse di creare una tabella con un nome appositamente costruito che, quando viene interrogata attraverso il connettore, può produrre la restituzione di dati diversi da quelli richiesti. Non si tratta quindi di un accesso completamente anonimo dall’esterno, ma di una violazione dei confini logici tra oggetti e query in un ambiente federato. In infrastrutture dove Athena interroga più sorgenti con credenziali elevate, il problema può esporre dataset non destinati all’utente che ha predisposto la tabella malevola. AWS ha risolto la falla nella versione v2026.21.1. Gli amministratori devono aggiornare il connettore, verificare i nomi delle tabelle creati da utenti con accesso a Synapse, riesaminare i log delle query e applicare privilegi distinti tra creazione degli oggetti e interrogazione dei dati federati. La vulnerabilità dimostra che la federazione tra cloud differenti estende la superficie di fiducia: un oggetto controllato in Azure può influenzare il comportamento di un connettore eseguito nell’ambiente AWS.

HollowByte frammenta la memoria con un ClientHello di 11 byte

La vulnerabilità HollowByte in OpenSSL sfrutta la fase iniziale dell’handshake TLS. Un client remoto dichiara nel record una lunghezza elevata, fino a circa 131 KB, ma invia soltanto 11 byte prima di interrompere la connessione. Le versioni vulnerabili allocano immediatamente un buffer basato sulla dimensione indicata nell’header, senza attendere che i dati arrivino realmente. Quando la sessione viene chiusa, la memoria viene liberata dal punto di vista logico, ma l’allocatore glibc può non restituirla subito al sistema operativo. Ripetendo la tecnica con dimensioni variabili, l’attaccante produce buchi nell’heap e frammentazione persistente, aumentando progressivamente il resident set del processo fino al rallentamento o all’indisponibilità del servizio. Il rapporto tra costo per l’attaccante e consumo imposto al server rende la falla adatta a campagne DoS distribuite, soprattutto contro proxy TLS, API gateway, load balancer e applicazioni che accettano un numero elevato di handshake. La correzione modifica la strategia di allocazione e fa crescere il buffer in modo incrementale, soltanto mentre i byte vengono effettivamente ricevuti.

Le versioni OpenSSL corrette vanno distribuite anche attraverso i prodotti dipendenti

HollowByte è stata corretta in OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 e 3.0.21. Aggiornare il pacchetto di sistema non garantisce però automaticamente che ogni applicazione utilizzi la libreria corretta. Appliance, container, applicazioni compilate staticamente e software che incorporano una propria copia di OpenSSL devono essere verificati singolarmente. Le organizzazioni devono identificare i servizi TLS esposti, controllare la versione realmente caricata dai processi e monitorare crescita anomala della memoria, elevato numero di connessioni incomplete e picchi di handshake interrotti. Rate limiting, limiti sulle connessioni simultanee e protezioni a monte possono ridurre l’impatto, ma non sostituiscono la patch. L’aggiornamento arriva pochi mesi dopo il rilascio di OpenSSL 4.0 con nuove funzioni di privacy e sicurezza post-quantistica, ricordando che anche una libreria crittografica matura può contenere difetti legati non agli algoritmi, ma alla gestione della memoria e del protocollo.

Le priorità operative partono da exploit attivi e servizi esposti

Le due vulnerabilità FortiSandbox devono ricevere la precedenza assoluta perché risultano già sfruttate in ambienti reali. Subito dopo vengono WP2Shell sui siti WordPress raggiungibili da Internet e HollowByte sui servizi TLS esposti ad alto volume. Le falle AWS richiedono invece una valutazione più contestuale: il rischio cresce quando gli agenti MCP possono controllare parametri operativi, quando i processi dispongono di privilegi ampi o quando utenti non pienamente fidati possono creare oggetti in Azure Synapse. Una risposta efficace deve combinare aggiornamento, revisione dei log, ricerca di indicatori di compromissione, rotazione delle credenziali eventualmente esposte e segmentazione dei sistemi. Le vulnerabilità mostrano quattro percorsi differenti verso il danno: concatenazione di bug applicativi, compromissione di un dispositivo di sicurezza, abuso dei confini di fiducia tra agenti e cloud, ed esaurimento delle risorse attraverso un difetto di allocazione. Trattarle come semplici numeri CVE rischia di nascondere proprio le differenze che devono guidare il patch management.