Una catena di due CVE trasforma SharePoint in un bersaglio non autenticato

Ad 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ù nulla

Il 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 Connectivity

Il 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 RCE

Concatenando le due vulnerabilità, un attaccante che conosce solo lo UPN o il SID di un account SharePoint può:

1. Forgiare un token JWT valido sfruttando CVE-2026-55040, ottenendo un contesto di autenticazione senza credenziali reali;
2. Usare quel contesto per caricare un modello BDC malevolo e sfruttare CVE-2026-63520;
3. 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 disponibili

Microsoft 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 pratica

Oltre 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.