#sharepoint

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.

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