CVE-2026-55040: bypass di autenticazione in SharePoint sotto attacco attivo, ecco come proteggersi
Quando una vulnerabilità critica in un prodotto enterprise passa dalla ricerca accademica allo sfruttamento at
Altro...
Quando una vulnerabilità critica in un prodotto enterprise passa dalla ricerca accademica allo sfruttamento at
Altro...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.
