Si parla di:

Toggle

Meno di cinque minuti: è il tempo medio che serve a un attaccante non autenticato per trasformare una semplice richiesta HTTP verso un’istanza #JFrog #Artifactory esposta in un account amministratore a tutti gli effetti. È la scoperta al centro di una campagna documentata da #Wiz e ripresa da più fonti di settore, che dal 15 agosto all’8 settembre 2026 ha visto attaccanti concatenare tre vulnerabilità critiche per prendere il controllo di server di artifact management aziendali e piantarvi dentro #backdoor persistenti scritte in #Rust — capaci di sopravvivere anche dopo l’applicazione delle #patch ufficiali.

Perché Artifactory è un bersaglio di alto valoreJFrog Artifactory è uno dei repository manager più diffusi nelle pipeline CI/CD enterprise: ospita pacchetti npm, immagini Docker, artefatti Maven, moduli Python e, spesso, segreti di build e credenziali di deploy. Compromettere un’istanza Artifactory non significa solo accedere a un server: significa potenzialmente inserirsi nel punto in cui il codice sorgente diventa artefatto distribuito, con tutte le implicazioni da attacco alla supply chain software che ne conseguono — lo stesso schema concettuale sfruttato in incidenti come #SolarWinds, ma applicato al livello del repository interno anziché del prodotto finale.

Secondo le analisi diffuse da The Hacker News e BleepingComputer sulla base della ricerca Wiz, tra il 49% e il 62% delle istanze Artifactory raggiungibili da Internet risultano vulnerabili ad almeno una delle falle sfruttate in questa campagna — una superficie d’attacco enorme per un singolo prodotto, aggravata dal fatto che due delle tre vulnerabilità sono difetti logici di autenticazione, non richiedono exploit complessi o memory corruption, e sono quindi facilmente automatizzabili su larga scala.

La catena di exploit in dettaglioIl cuore tecnico dell’attacco combina tre CVE distinte:

CVE-2026-42018 — un difetto che restituisce un token JWT interno riservato all’utente anonimo a qualsiasi chiamante non autenticato, anche quando l’accesso anonimo è esplicitamente disabilitato a livello di configurazione: il primo anello della catena, che da solo non sembra critico ma apre la porta al passo successivo.

CVE-2026-42016 — una validazione insufficiente all’endpoint di creazione dei token: il sistema verifica che firma ed emittente del JWT siano validi, ma non controlla effettivamente i permessi associati, permettendo di scambiare un token a basso privilegio per uno con scope amministrativo completo.

CVE-2026-82329 — un bypass di autenticazione critico (CVSS 9.8) osservato sfruttato anche in modo indipendente dalle prime due, che da solo consente a un attaccante non autenticato di ottenere privilegi di amministratore.

Concatenando le prime due vulnerabilità, gli attaccanti ottengono in sequenza: una richiesta non autenticata verso l’endpoint dei token, la ricezione del token anonimo interno, lo scambio di quel token presso l’endpoint di creazione per uno con scope amministrativo — il tutto, secondo i dati Wiz, in una finestra media inferiore ai cinque minuti dalla prima richiesta alla creazione del nuovo account admin.

Dopo l’accesso: plugin Groovy e backdoor RustUna volta ottenuti privilegi amministrativi, il playbook osservato negli attacchi documentati segue uno schema costante e ben progettato per la persistenza. Gli attaccanti creano account amministratore aggiuntivi, spesso con nomi pensati per confondersi con account di servizio legittimi — sono stati osservati identificatori come 0xTerror, pattern svc_* e labadmin_* con suffissi casuali, oltre a nomi che imitano componenti interni come jfrog-distribution, jfrog-insight e repo-service.

Con l’accesso admin consolidato, viene installato un plugin Groovy malevolo: Artifactory supporta nativamente plugin Groovy lato server per estendere le proprie funzionalità, una feature legittima che diventa un potentissimo meccanismo di esecuzione di codice arbitrario in mano a un attaccante con privilegi sufficienti a caricarne uno personalizzato. Da lì, gli operatori distribuiscono una backdoor custom scritta in Rust con capacità di command-and-control, scaricando ulteriori payload in directory tipicamente meno monitorate come /dev/shm, /tmp e /var/tmp. In alcuni casi sono state estratte anche le chiavi di join del cluster Artifactory, che permetterebbero potenzialmente di espandere la persistenza ad altri nodi della stessa installazione distribuita.

La scelta di Rust per la backdoor non è casuale: binari compilati staticamente, assenza di dipendenze runtime come una VM o un interprete, e una superficie di rilevamento comportamentale ancora poco coperta dalle firme EDR tradizionali rispetto a impianti scritti in C/C++ o script. È una tendenza che si osserva sempre più spesso in malware post-exploitation di livello medio-alto nel 2026.

Perché la sola patch potrebbe non bastareIl dettaglio più critico per chi gestisce infrastrutture Artifactory è che applicare la patch chiude la vulnerabilità di accesso iniziale, ma non rimuove automaticamente ciò che è stato piantato durante i 24 giorni di campagna osservata. Gli account amministratore creati dagli attaccanti, i plugin Groovy malevoli e la backdoor Rust restano attivi sul sistema finché non vengono identificati e rimossi manualmente — un pattern da manuale “patch ma non remedia” che ha già causato incidenti di re-compromissione in altre campagne di sfruttamento di vulnerabilità di gestione repository negli ultimi anni.

Raccomandazioni per i difensoriAggiornare immediatamente Artifactory a una delle versioni corrette: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20 (o successive nella rispettiva linea).

Non fermarsi alla patch: effettuare un audit completo degli account amministratore esistenti, con particolare attenzione a nomi anomali o pattern tipo svc_, labadmin_ o identificatori che imitano componenti di sistema.

Revisionare l’elenco dei plugin Groovy installati e rimuovere quelli non riconducibili a un cambio di configurazione tracciato e approvato.

Cercare processi o binari sospetti in /dev/shm, /tmp e /var/tmp, ed effettuare scansione EDR mirata per binari Rust non firmati con comportamento di rete C2.

Ruotare le chiavi di join del cluster e le credenziali associate se l’istanza è risultata esposta durante la finestra 15 agosto – 8 settembre 2026.

Restringere l’esposizione diretta a Internet delle console di amministrazione Artifactory, ponendole dietro VPN o zero-trust proxy, indipendentemente dallo stato delle patch.

Il caso Artifactory è l’ennesima conferma che gli strumenti di infrastruttura per lo sviluppo software — repository manager, registry di pacchetti, sistemi CI/CD — sono ormai bersagli di prima scelta esattamente quanto i perimetri di rete tradizionali, perché offrono un accesso privilegiato e trasversale a tutto ciò che un’organizzazione costruisce e distribuisce. Trattarli come infrastruttura critica, con lo stesso rigore di patching, segmentazione e monitoraggio riservato ai sistemi di produzione, non è più opzionale.

Indicatori di compromissione e riferimenti tecniciProdotto: JFrog Artifactory
Periodo campagna osservata: 15 agosto - 8 settembre 2026 (24 giorni)
Scopritore: Wiz (ricerca cloud security)

CVE sfruttate:

• CVE-2026-42018: JWT anonimo interno restituito a chiamante non autenticato
  anche con accesso anonimo disabilitato
• CVE-2026-42016: validazione insufficiente dei permessi in fase di
  creazione token, consente escalation a scope amministrativo
• CVE-2026-82329 (CVSS 9.8): bypass di autenticazione che concede privilegi
  admin a un attaccante non autenticato, sfruttata anche stand-alone

Tempo medio exploit-to-admin: < 5 minuti

Versioni corrette: 7.111.21+ / 7.117.28+ / 7.125.20+ / 7.133.29+ /
7.146.38+ / 7.161.20+

Account amministratore sospetti osservati:
0xTerror
svc_[stringa_casuale]
labadmin_[stringa_casuale]
jfrog-distribution
jfrog-insight
repo-service

Post-exploitation:

• Plugin Groovy malevoli per RCE persistente
• Backdoor custom in Rust con funzionalità C2
• Payload droppati in /dev/shm, /tmp, /var/tmp
• Estrazione chiavi di join del cluster

Superficie stimata: 49-62% delle istanze Artifactory esposte su Internet
vulnerabili ad almeno una delle CVE sopra elencate

The LG TV network scanning story breaking today includes UDP 9999 Kasa discovery broadcasts every 25 seconds. That's the exact port I documented in CVE-2026-13230 as returning unauthenticated precise GPS coordinates from Kasa cameras with no authentication. Any LG TV + unpatched Kasa camera on the same network = GPS harvesting every 25 seconds. @briankrebs@infosec.exchange Advisory: https://github.com/BadChemical/IoT-Vulnerability-Research-Public/blob/main/TP-Link_Kasa_EC71/Kasa_EC71.md

#Iot #CVE #TPlink #LG #infosec

Una catena di due CVE trasforma SharePoint in un bersaglio non autenticatoAd agosto 2026 Rapid7 e VulnCheck hanno pubblicato, in tempi ravvicinati, l’#analisi tecnica di una catena di exploit che colpisce Microsoft #SharePoint Server on-premises con impatto massimo: esecuzione di codice remoto senza alcuna autenticazione. La catena combina due vulnerabilità distinte, #CVE-2026-55040 (bypass di autenticazione JWT, CVSS 9.1) e CVE-2026-63520 (istanziazione insicura di tipi .NET nel motore Business Data Connectivity), e secondo Shadowserver oltre 8.700 server SharePoint risultano ancora esposti direttamente su #Internet. Per chi gestisce infrastrutture SharePoint on-prem non si tratta di un bollettino da archiviare: è una delle catene di attacco più pericolose viste sulla piattaforma dai tempi di ToolShell.

CVE-2026-55040: quando il token JWT non prova più nullaIl primo anello della catena riguarda la pipeline di validazione dei token JWT usati internamente da SharePoint per l’autenticazione tra servizi. A causa di controlli insufficienti su questi token, un attaccante che conosca in anticipo l’identità di un utente target (tramite il suo SID di Active Directory o il suo UPN, entrambi spesso enumerabili o prevedibili in ambienti aziendali) può forgiare un token valido e impersonarlo senza fornire alcuna credenziale. Il risultato è un bypass completo dell’autenticazione: l’attaccante #entra nel sistema con l’identità di un utente legittimo, potenzialmente un amministratore.

Da sola, questa vulnerabilità (classificata CWE-1390, “Weak Authentication”) sarebbe già critica. Ma è il punto di ingresso che rende possibile il secondo, ben più devastante, stadio della catena.

CVE-2026-63520: RCE tramite Business Data ConnectivityIl secondo CVE affligge il sottosistema Business Data Connectivity (BDC) di SharePoint, che permette di collegare fonti dati esterne tramite modelli descritti in file XML con estensione .bdcm. La causa radice è un’istanziazione di tipi .NET non sufficientemente validata nella classe DbTypeReflector: il metodo ResolveDotNetType() chiama direttamente Type.GetType() su un valore TypeName controllato dall’attaccante, senza un controllo efficace. Il filtro di sicurezza esistente si limitava a bloccare nomi di tipo corti, ma nomi di tipo superiori ai 15 caratteri bypassavano il controllo, aprendo la porta a qualunque tipo .NET disponibile nella Global Assembly Cache (GAC).

In pratica, un attaccante autenticato (o, dopo il bypass JWT, di fatto chiunque) può caricare un file BDCM appositamente costruito che definisce un LobSystem, un’Entity e un MethodInstance di tipo Finder. Quando SharePoint valuta una External List collegata a quel modello, il Finder viene eseguito automaticamente. I ricercatori hanno dimostrato più catene di gadget funzionanti, tra cui una basata su System.Windows.Data.ObjectDataProvider combinato con System.Diagnostics.Process per l’esecuzione diretta di comandi, e una variante che sfrutta System.Web.UI.LosFormatter.Deserialize() con un gadget TypeConfuseDelegate codificato in Base64 per innescare la deserializzazione insicura. Un semplice payload di prova può lanciare calc.exe sul server con i privilegi dell’account di servizio di SharePoint; in produzione, lo stesso meccanismo consente l’esecuzione di codice arbitrario, inclusi payload di post-exploitation completi.

La catena completa: da zero credenziali a RCEConcatenando le due vulnerabilità, un attaccante che conosce solo lo UPN o il SID di un account SharePoint può:

Forgiare un token JWT valido sfruttando CVE-2026-55040, ottenendo un contesto di autenticazione senza credenziali reali;

Usare quel contesto per caricare un modello BDC malevolo e sfruttare CVE-2026-63520;

Ottenere esecuzione di codice remoto con i privilegi dell’account applicativo di SharePoint, tipicamente con accesso ampio al farm e, a cascata, ad Active Directory.

È esattamente questo l’aspetto che ha spinto VulnCheck a pubblicare i dettagli tecnici in anticipo rispetto all’embargo standard di 30 giorni: un PoC pubblico era già in circolazione e la finestra di rischio per i server non patchati si stava riducendo rapidamente. Bleeping Computer e SecurityAffairs hanno successivamente confermato tentativi di sfruttamento attivo in the wild, mentre la società di threat intelligence Defused ha osservato attività di ricognizione sistematica contro honeypot SharePoint esposti.

Versioni affette e patch disponibiliMicrosoft ha rilasciato aggiornamenti dedicati per tutte le edizioni supportate on-premises:

SharePoint Server Subscription Edition: KB5002882, build 16.0.19725.20434

SharePoint Server 2019: KB5002883, build 16.0.10417.20175

SharePoint Enterprise Server 2016: KB5002891, build 16.0.5561.1001

SharePoint Online (Microsoft 365) non è interessato: il rischio riguarda esclusivamente le installazioni on-premises. Se gestite un farm SharePoint self-hosted, la priorità è applicare queste patch ora, non nella prossima finestra di manutenzione pianificata.

Cosa fare subito, in praticaOltre al patching, che resta la contromisura primaria e non negoziabile, alcune azioni concrete per ridurre l’esposizione e rilevare eventuali compromissioni:

Inventariare i server esposti: verificate quali istanze SharePoint sono raggiungibili direttamente da Internet e valutate se sia davvero necessario, oppure se possano essere posizionate dietro un reverse proxy con autenticazione aggiuntiva o una VPN.

Controllare la build corrente: dalla Central Administration o via PowerShell (Get-SPFarm | Select BuildVersion) verificate che i server siano allineati alle build patchate elencate sopra.

Monitorare i log IIS e ULS per pattern di autenticazione anomali (token JWT sospetti, accessi con identità che normalmente non generano traffico da quell’origine) e per upload o modifiche di modelli BDC non pianificati.

Verificare le configurazioni Business Connectivity Services: se il farm non usa BDC/BCS in modo attivo, valutate se disabilitare il servizio riduce la superficie d’attacco senza impatti operativi.

Applicare il principio del minimo privilegio agli account di servizio di SharePoint, così da limitare il “raggio d’azione” di un’eventuale esecuzione di codice riuscita.

La combinazione di autenticazione bypassabile e deserializzazione insicura è un pattern che SharePoint ha già visto in passato (basti pensare a ToolShell nel 2025), e che continua a ripresentarsi perché il BDC/BCS resta un componente ricco di superficie d’attacco poco monitorato rispetto ad altre parti della piattaforma. Vale la pena, in generale, trattare ogni funzionalità di connettività dati esterna come un potenziale vettore di deserializzazione e sottoporla a hardening a prescindere dal CVE del momento.

Fonte originale: Petri IT Knowledgebase – SharePoint Exploit Code Puts Thousands of Internet-Facing Servers At Risk. Analisi tecnica aggiuntiva: Rapid7 su CVE-2026-55040, Rapid7 su CVE-2026-63520 e VulnCheck.

Due vulnerabilità critiche, due superfici di attacco diverseIl 25 agosto 2026 il team di Next.js ha rilasciato un aggiornamento di sicurezza fuori dal normale ciclo di rilascio, anticipando la pubblicazione dopo aver identificato una seconda vulnerabilità critica in una dipendenza upstream mentre stava già preparando la #patch per la prima. Il risultato sono due falle di Remote Code Execution non autenticata con severità critica, entrambe corrette nelle versioni 15.5.24 (Maintenance LTS) e 16.3.3 (Active LTS). Per chi gestisce applicazioni Next.js in produzione, specialmente self-hosted, questo è un aggiornamento da applicare senza rimandare.

CVE-1: RCE tramite l’Image Optimization API su file AVIFLa prima vulnerabilità (GHSA-2xp9-vwfh-vxw4, CVSS stimato 9.5) risiede in libheif, la libreria usata da sharp per la decodifica delle immagini AVIF, a sua volta impiegata dall’Image Optimization API integrata in Next.js. La falla upstream (GHSA-g89c-p67h-r497) è un heap buffer overflow nel codice di scaling delle immagini: un file AVIF costruito ad arte, con riferimenti annidati di tipo identity-derivation e auxiliary item, induce il decoder a costruire un’immagine con una profondità di bit del canale Alpha incoerente rispetto al buffer allocato. Lo scaler alloca #spazio per dati a 8 bit ma vi scrive valori a 16 bit, scrivendo circa 16.384 byte oltre il limite dell’allocazione: la combinazione classica che apre la strada all’esecuzione di codice arbitrario.

L’aspetto più critico è la superficie di attacco: qualunque endpoint Next.js che passi un’immagine controllata dall’utente attraverso l’Image Optimization API (upload di avatar, contenuti caricati da terzi, immagini remote proxate) è potenzialmente sfruttabile senza autenticazione. Le versioni patchate risolvono il problema nell’immediato disabilitando l’ottimizzazione AVIF finché la fix upstream in libheif non sarà completamente propagata nella supply chain.

CVE-2026-75604: RCE su server Windows con Pages Router + App RouterLa seconda falla (CVE-2026-75604 / GHSA-p293-qw3h-jr36, CVSS stimato 9.0) è più circoscritta ma non meno seria per chi ospita Next.js su #Windows. Colpisce le applicazioni che utilizzano contemporaneamente Pages Router e App Router senza avere Cache Components attivo, quando il server gira su un filesystem Windows: in questo scenario è possibile innescare un path traversal che porta a RCE non autenticata sfruttando le differenze di gestione dei percorsi tra i due router in ambiente Windows.

#Linux e macOS non sono affetti da questa specifica vulnerabilità, il che la rende particolarmente rilevante per ambienti enterprise .NET/Windows Server che ospitano frontend Next.js accanto a backend .NET, uno scenario comune in molte aziende italiane con infrastruttura ibrida. Il team Next.js è stato esplicito: non esiste una mitigazione applicativa nota per le applicazioni Windows-hosted affette; l’unica strada è l’aggiornamento.

Versioni interessatePath traversal su Windows (#CVE-2026-75604): Next.js 13.4–15.5.23 e 16.0–16.3.2

RCE via AVIF: Next.js 10.0.0–15.5.23 e tutte le versioni 16.x fino alla 16.3.2

libheif: tutte le versioni fino alla 1.23.1 inclusa

Come verificare l’esposizione e aggiornareIl primo passo è capire quale router state utilizzando e se l’Image Optimization API è esposta a input non fidati. Un controllo rapido nella codebase:

Versione installata di Next.js

npm ls next

Cercate se esistono sia pages/ che app/ nello stesso progetto

find . -maxdepth 2 -type d ( -name "pages" -o -name "app" ) -not -path "/node_modules/"

Verificate se il Cache Components flag è attivo in next.config

grep -R "cacheComponents" next.config.*Se il progetto usa entrambi i router senza Cache Components e il server è ospitato su Windows (IIS con iisnode, Windows Server con PM2, #container Windows), l’aggiornamento non è opzionale. Per aggiornare:

npm install next@15.5.24 # ramo 15.5 (Maintenance LTS)
npm install next@16.3.3 # ramo 16.3 (Active LTS)

con pnpm

pnpm add next@15.5.24
pnpm add next@16.3.3

con yarn

yarn add next@15.5.24
yarn add next@16.3.3Dopo l’aggiornamento, ricordate di rigenerare il lockfile e di verificare in CI che la build non introduca regressioni, in particolare se il progetto fa uso intensivo di next/image con sorgenti AVIF: l’ottimizzazione per quel formato resterà disabilitata finché non arriverà una fix upstream in libheif, quindi può essere necessario prevedere temporaneamente un fallback a JPEG/WebP per le immagini caricate dagli utenti.

Perché conviene reagire subito, anche se si usa VercelLe applicazioni ospitate su Vercel sono protette automaticamente lato piattaforma, ma questo non copre chi fa self-hosting su VM, container Docker, Kubernetes, Azure App Service, IIS o qualunque altro ambiente gestito direttamente. Per i team DevOps italiani che gestiscono deployment Next.js su infrastruttura on-premise o su Windows Server per motivi di compliance o integrazione con sistemi legacy .NET, il rischio è concreto: si tratta di RCE non autenticata, quindi sfruttabile da un attaccante remoto senza credenziali, con impatto potenzialmente totale sul server applicativo.

Alcune azioni consigliate oltre al semplice upgrade:

Inventariate tutte le applicazioni Next.js in produzione, incluse quelle gestite da team diversi, e verificate la versione installata con npm ls next o controllando il package-lock.json.

Se non potete aggiornare immediatamente, valutate di disabilitare temporaneamente l’Image Optimization API per sorgenti non fidate, o di filtrare a livello di reverse proxy/WAF le richieste verso l’endpoint /_next/image.

Per gli ambienti Windows, se non è possibile aggiornare a breve, considerate la migrazione temporanea del workload su un host Linux/macOS finché la patch non è applicata, dato che non esiste mitigazione nota per Windows.

Automatizzate il monitoraggio delle security advisory di Next.js e delle sue dipendenze critiche (in particolare sharp e le librerie di decodifica immagini) tramite Dependabot, Renovate o strumenti equivalenti, per ridurre il tempo di reazione a futuri annunci simili.

ConclusioneQuesto doppio rilascio di sicurezza è un promemoria utile su due fronti. Il primo è tecnico: le pipeline di elaborazione immagini, spesso trattate come funzionalità “di contorno”, restano una delle superfici di attacco più insidiose nelle applicazioni web moderne, perché processano input binario complesso proveniente direttamente dagli utenti. Il secondo è organizzativo: la disponibilità di RCE non autenticate senza mitigazione nota per specifiche piattaforme (in questo caso Windows) impone di conoscere esattamente dove e come sono ospitate le proprie applicazioni Next.js, non solo quale versione del framework stanno eseguendo. Chi gestisce ambienti misti Windows/.NET con frontend Next.js dovrebbe trattare questo aggiornamento come priorità operativa immediata.

Fonte: Next.js – August 2026 Security Release e The Hacker News – Next.js Patches Critical AVIF and Windows Flaws Enabling Unauthenticated RCE

Quando una vulnerabilità critica in un prodotto enterprise passa dalla ricerca accademica allo sfruttamento attivo nel giro di poche settimane, il tempo a disposizione dei team IT per applicare la patch si riduce drasticamente. È esattamente quello che sta succedendo con CVE-2026-55040, un bypass di autenticazione in Microsoft SharePoint Server che, dopo la pubblicazione di un proof-of-concept dettagliato, è ora oggetto di tentativi di exploitation attiva da IP distribuiti in più paesi. Per chi gestisce ambienti SharePoint on-premises, capire il meccanismo dell’attacco è il primo passo per dare priorità corretta alla remediation.

Cos’è CVE-2026-55040La vulnerabilità, con punteggio CVSS 3.1 pari a 9.1 (critico) e classificata come CWE-1390 (Weak Authentication), risiede nella pipeline di validazione dei token JWT usata da SharePoint per l’autenticazione server-to-server (S2S). Il risultato pratico è che un attaccante non autenticato, conoscendo l’identificativo di un utente (il SID di Active Directory o lo UPN), può forgiare un token che SharePoint accetta come legittimo — arrivando fino all’impersonificazione di un account amministrativo.

Sono colpite tre versioni principali del prodotto:

SharePoint Server Subscription Edition (build 16.0.19725.20434 e precedenti)

SharePoint Server 2019 (build 16.0.10417.20175 e precedenti)

SharePoint Enterprise Server 2016 (build 16.0.5561.1001 e precedenti)

Come funziona il bypassL’analisi tecnica pubblicata da Rapid7 Labs descrive una catena di quattro debolezze concatenate nel processo di verifica dei token Bearer S2S, che nel loro insieme permettono di costruire un token accettato senza una firma crittografica valida: un header che dichiara un algoritmo di firma “none”, l’uso del certificato STS di SharePoint stesso come chiave di firma anziché come verificatore, un certificato non correttamente validato contro TrustedSecurityTokenServices, e — punto più critico — la firma del token che di fatto non viene mai verificata end-to-end.

In pratica, un attaccante che conosce (o enumera) l’identificativo di un utente può costruire un token che SharePoint tratta come proveniente da un servizio fidato, ottenendo l’accesso alle API e alle risorse del sito con i privilegi di quell’utente — amministratore incluso, se il SID target è quello giusto.

Perché è particolarmente pericolosaTre fattori la rendono un rischio prioritario rispetto alla media delle CVE mensili:

Nessuna autenticazione richiesta: l’attaccante non ha bisogno di credenziali valide, solo della conoscenza (o della capacità di enumerare) l’identificativo dell’utente target.

PoC pubblico e riproducibile: la disponibilità di un exploit funzionante abbassa drasticamente la barriera tecnica per chi vuole sfruttarla, come dimostra l’aumento dei tentativi osservati nei giorni successivi alla pubblicazione.

Superficie di attacco diretta: qualsiasi istanza SharePoint on-premises esposta a Internet, anche solo per l’accesso remoto di dipendenti o partner, è un bersaglio potenziale.

Cosa mostra la telemetria degli attacchiSecondo i dati di tracking condivisi dalla community di threat intelligence (KEVIntel), i primi tentativi di sfruttamento risalgono al 19 luglio 2026, con una intensificazione marcata nei giorni successivi alla pubblicazione del PoC — otto tentativi registrati solo tra il 12 e il 13 agosto, provenienti da otto indirizzi IP distinti localizzati tra Hong Kong, Giappone, Paesi Bassi, Taiwan e Stati Uniti. Un pattern tipico delle campagne opportunistiche che seguono la pubblicazione di un exploit pubblico: scansioni automatizzate su larga scala alla ricerca di istanze non ancora aggiornate.

Patch e mitigazioniMicrosoft ha già rilasciato gli aggiornamenti correttivi; il primo passo per qualsiasi team che gestisce SharePoint on-premises è verificare di aver applicato i seguenti KB in base alla versione in uso:

SharePoint Server Subscription Edition → KB5002882
SharePoint Server 2019 → KB5002883
SharePoint Enterprise Server 2016 → KB5002891Oltre all’applicazione della patch, che resta la mitigazione principale, vale la pena eseguire una checklist di hardening più ampia:

Verificare la build corrente tramite l’interfaccia di amministrazione centrale o PowerShell (Get-SPFarm | Select BuildVersion), confrontandola con le versioni corrette rilasciate da Microsoft.

Analizzare i log IIS e ULS alla ricerca di pattern di richieste anomale verso gli endpoint di autenticazione S2S, in particolare token Bearer con struttura o claim inusuali.

Ridurre l’esposizione diretta a Internet dei server SharePoint on-premises dove non strettamente necessario, preferendo l’accesso tramite VPN o reverse proxy con autenticazione aggiuntiva.

Segmentare la rete in modo che un’eventuale compromissione del front-end SharePoint non dia accesso diretto ad altri sistemi interni.

Rivedere gli account con privilegi elevati su SharePoint, applicando il principio del privilegio minimo e monitorando le attività degli account amministrativi per individuare comportamenti anomali successivi alla finestra di esposizione.

ConclusioneCVE-2026-55040 è un promemoria diretto di quanto velocemente un bypass di autenticazione ben documentato possa trasformarsi in sfruttamento attivo su scala. Per chi amministra ambienti SharePoint on-premises, la priorità immediata è verificare lo stato delle patch KB5002882/KB5002883/KB5002891 e, in assenza di conferma dell’aggiornamento, trattare l’istanza come potenzialmente compromessa fino a prova contraria — controllando log di autenticazione e attività degli account amministrativi nella finestra temporale in cui la vulnerabilità è rimasta senza patch.

Fonti: Petri IT Knowledgebase, Rapid7 Labs, The Hacker News

Una race condition nascosta nel cuore del sandboxing di SnapIl 21 luglio 2026 il Threat Research Unit di Qualys ha reso pubblica CVE-2026-8933, una vulnerabilità di local privilege escalation (LPE) che colpisce snap-confine, il componente che costruisce l’ambiente sandbox per le applicazioni Snap su Ubuntu. Il difetto, classificato come “High” severity, permette a un utente locale non privilegiato di ottenere accesso root completo sulle installazioni di default di Ubuntu Desktop 24.04, 25.10 e 26.04.

La cosa interessante, dal punto di vista di chi amministra sistemi Linux, non è tanto la gravità in sé (le LPE locali sono un classico), quanto come ci si è arrivati: una modifica pensata per aumentare la sicurezza ha introdotto, per effetto collaterale, una finestra di race condition sfruttabile.

Perché snap-confine è cambiatosnap-confine è il binario che Canonical usa per costruire l’ambiente isolato in cui gira ogni applicazione Snap: monta i namespace, applica i profili AppArmor/seccomp e prepara le directory temporanee di lavoro. Storicamente era un binario set-uid-root: partiva già con i privilegi di root e li abbandonava progressivamente.

Per ridurre la superficie d’attacco, Canonical ha migrato snap-confine a un modello basato su set-capabilities: il processo ora gira con l’UID effettivo dell’utente chiamante, ma mantiene comunque delle capability quasi-root (tra cui CAP_SYS_ADMIN e simili) necessarie per completare il setup del sandbox. È un cambiamento in linea con il principio del least privilege, ma ha spostato il problema: durante l’inizializzazione, le directory temporanee sotto /tmp vengono create con proprietario l’utente non privilegiato, e solo in un secondo momento la ownership passa a root. In quella finestra, per quanto stretta, l’attaccante ha ancora pieno controllo sui file.

La catena di exploitIl team Qualys ha ricostruito un attacco che combina due race condition concorrenti:

Bypass del mount namespace via FUSE: l’attaccante monta un filesystem FUSE sopra la directory temporanea di scratch appena creata, prima che snap-confine applichi l’isolamento tramite mount namespace. In questo modo la directory resta accessibile anche dall’esterno del sandbox.

Symlink race su fchown(): l’attaccante sostituisce un file atteso con un symlink verso un target arbitrario. Quando snap-confine tenta di creare un file nel sandbox, la open() segue il symlink e scrive sul target reale. Una seconda race condition permette poi di allargare i permessi a 0666 prima che venga invocata fchown() per trasferire la ownership a root.

Escalation via udev: per aggirare la confinazione AppArmor, l’exploit punta al percorso /run/udev/, che consente accesso in lettura/scrittura. Depositando un file .rules malevolo in /run/udev/rules.d/ e innescando un ciclo di mount/unmount FUSE, l’attaccante costringe il demone systemd-udevd a eseguire comandi arbitrari come root.

Il risultato finale: da semplice accesso locale non privilegiato a controllo completo del sistema, senza bisogno di interazione da parte di altri utenti.

Versioni coinvolte e patch disponibiliSono interessate le release che spediscono di default la variante set-capabilities di snap-confine:

Ubuntu Desktop 26.04

Ubuntu Desktop 25.10

Ubuntu Desktop 24.04 (con pacchetti snapd aggiornati)

Canonical ha rilasciato pacchetti snapd corretti, tra cui 2.76+ubuntu26.04.3 per Ubuntu 26.04, 2.76+ubuntu24.04.1 per Ubuntu 24.04 e 2.76+ubuntu22.04.1 per Ubuntu 22.04. La disclosure è stata coordinata con l’Ubuntu Security Team.

Come verificare se un sistema è vulnerabilePer controllare la versione di snapd installata:

snap version
apt-cache policy snapdSe la versione del pacchetto snapd è precedente a quelle corrette indicate sopra, il sistema va aggiornato immediatamente:

sudo apt update
sudo apt install --only-upgrade snapd
snap versionPer un controllo su larga scala, chi usa strumenti di vulnerability management (Qualys CSAM o equivalenti) può cercare asset con sistema operativo Ubuntu e pacchetto snapd installato, incrociando poi la versione con quella patchata.

Mitigazioni in attesa della patchSe non è possibile applicare l’aggiornamento immediatamente, alcune contromisure temporanee riducono l’esposizione:

Limitare l’accesso a shell locale ai soli utenti fidati, specialmente su workstation condivise o ambienti multi-utente (lab, terminal server, VDI).

Monitorare la creazione di regole udev non autorizzate sotto /run/udev/rules.d/, ad esempio con auditd:

auditctl -w /run/udev/rules.d/ -p wa -k udev_rules_watch

Disabilitare il montaggio FUSE per utenti non privilegiati dove non strettamente necessario, tramite policy su /etc/fuse.conf o restrizioni AppArmor aggiuntive.

Nessuna di queste misure sostituisce la patch ufficiale: sono palliativi utili solo per il tempo strettamente necessario a pianificare l’aggiornamento.

ConclusioneCVE-2026-8933 è un promemoria utile per chi progetta meccanismi di sandboxing e privilege dropping: il passaggio da set-uid a set-capabilities è, sulla carta, una scelta più sicura, ma introduce una superficie temporale (la finestra tra creazione del file e trasferimento della ownership) che va gestita con la stessa attenzione riservata alle race condition classiche nei binari set-uid. Per chi amministra flotte Ubuntu Desktop, la priorità pratica resta semplice: verificare le versioni di snapd installate, applicare la patch e, nel frattempo, restringere l’accesso shell locale dove possibile.

Fonte: Qualys Threat Research Unit – CVE-2026-8933: Local Privilege Escalation in Set-Capabilities snap-confine

Nessun login richiestoIl 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.

Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.

Le due CVE, in breveLe vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:

CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.

CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.

La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.

Perché la object cache fa la differenzaIl dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.

La risposta di WordPressTrattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:

7.0.2 — release principale, corregge entrambe le vulnerabilità

6.9.5 — backport, corregge entrambe le vulnerabilità

6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)

7.1 Beta 2 — corregge entrambe

Le versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:

Da riga di comando, con WP-CLI

wp core version

Oppure dalla dashboard: Bacheca → AggiornamentiIl ruolo del WAF: difesa in profondità, non sostituto della patchCloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:

RegolaCVEAzione predefinitaWordPress – SQL InjectionCVE-2026-60137BlockWordPress – Remote Code ExecutionCVE-2026-63030BlockLa prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.

Checklist operativaPer chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:

Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).

Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato:
wp core update --version=7.0.2
wp core update-db

Se dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.

Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta: