SharePoint CVE-2026-45659: patchata a maggio, sfruttata a luglio

Il 1° luglio 2026 CISA ha aggiunto CVE-2026-45659 al proprio catalogo Known Exploited Vulnerabilities, imponendo alle agenzie federali statunitensi di applicare la patch entro il 4 luglio o di mettere offline i server interessati. La vulnerabilità è una remote code execution su Microsoft SharePoint Server on-premises. Microsoft l'aveva già corretta — il 26 maggio 2026. Il problema è che quasi nessuno lo sapeva, perché la CVE, testualmente per Microsoft, è stata "inadvertitamente omessa dai Security Updates di maggio 2026". La patch è uscita. La riga che avrebbe detto a qualcuno di installarla no.

È tutta qui la storia, in una frase: una RCE critica su SharePoint è rimasta disponibile come patch per cinque settimane mentre i difensori non avevano nessuna CVE da tracciare, nessuna voce di bollettino da prioritizzare e nessun motivo, sul cruscotto di patching, per toccare quel server. Poi gli attaccanti l'hanno trovata. È la seconda estate di fila in cui SharePoint on-prem diventa il problema dell'intero settore, e il meccanismo del fallimento stavolta non è uno zero-day: è un punto cieco nel modo in cui le organizzazioni decidono cosa patchare.

Dentro CVE-2026-45659: dalla deserializzazione autenticata alla RCE

CVE-2026-45659 è un bug di deserializzazione insicura (CWE-502) con punteggio CVSS 8.8. Colpisce SharePoint Server Subscription Edition, SharePoint Server 2019 e SharePoint Enterprise Server 2016 — l'intera linea on-prem supportata. SharePoint deserializza dati controllati dall'attaccante senza validarli: un payload serializzato costruito ad arte viene ricostruito in oggetti vivi sul server e arriva all'esecuzione di codice.

Il requisito di accesso è il dettaglio che conta. Secondo l'advisory Microsoft, "qualsiasi attaccante autenticato può innescare questa vulnerabilità. Non richiede privilegi di amministratore o altri privilegi elevati." In pratica significa credenziali valide più i permessi di Site Member — il livello concesso ai normali contributor su un sito SharePoint. Non un farm admin. Non un owner. Un membro che può aggiungere contenuti.

Questo abbassa l'asticella in un modo che combacia con gli attacchi reali. Site Member è esattamente ciò che un attaccante possiede dopo una qualsiasi delle prime mosse di routine: credenziali Microsoft 365 o AD ottenute via phishing, una password sprayata contro un endpoint OWA/ADFS esposto, una sessione valida estratta da un log di infostealer. SharePoint on-prem raramente è esposto su Internet per scelta, ma è quasi sempre raggiungibile dalla rete interna — che è la rete su cui l'attaccante si trova nell'istante in cui ha un account funzionante. Una RCE da deserializzazione partendo da un contesto autenticato a basso privilegio trasforma "ho un punto d'appoggio" in "controllo il server che contiene i tuoi contratti, i file HR e i documenti legali", per riprendere l'elenco di asset usato da Robert Coles di Black Duck nello spiegare perché SharePoint vale lo sforzo.

Il rating CVSS 8.8 sottostima il valore operativo. SharePoint sta sul piano dell'identità: gira con un service account che ha portata dentro la farm, custodisce i documenti che l'attaccante vuole ed è considerato affidabile da tutto ciò che gli sta intorno. Una RCE lì è un punto di pivot, non un vicolo cieco.

La patch che nessuno poteva vedere

Il motivo per cui questa è diventata una voce KEV invece di una normale patch di maggio è un fallimento di processo, non tecnico. Microsoft ha corretto la falla negli aggiornamenti cumulativi di maggio 2026 ma ha lasciato la CVE fuori dal Security Update Guide pubblicato. Le organizzazioni che installano ogni aggiornamento cumulativo a prescindere dal contenuto erano protette in silenzio. Le organizzazioni che guidano le decisioni di patching dal bollettino — classificano il rischio delle CVE elencate, pianificano le critiche, rimandano il resto — non l'hanno mai vista. Non c'era niente da classificare.

Questo è un modello operativo comune, non negligenza. I grandi parchi SharePoint non applicano alla cieca ogni cumulativo appena esce: testano, mettono in staging, prioritizzano per severità, e la severità viene dal bollettino. Togli la CVE dal bollettino e la falla diventa invisibile proprio al processo che la maggior parte delle aziende usa per restare aggiornata. Come ha detto Ben Ronallo di Black Duck, "i bollettini di patch sono un punto di partenza, non un sostituto della verifica di ciò che è davvero in esecuzione."

Quella frase è la lezione dell'intero episodio. Uno scanner di vulnerabilità agganciato ai feed CVE non aveva nulla su cui scattare per cinque settimane. Un report di compliance che chiede "siamo patchati contro le critiche note?" rispondeva sì mentre il server era sfruttabile. L'unico segnale che avrebbe intercettato tutto questo è quello che ignora del tutto il catalogo e pone una domanda diversa: se attacco questo server come farebbe un attaccante, cade?

SharePoint on-prem, un anno dopo ToolShell

CVE-2026-45659 arriva quasi esattamente un anno dopo la campagna ToolShell del luglio 2025, e l'accostamento è istruttivo. ToolShell concatenava CVE-2025-53770 — una RCE da deserializzazione non autenticata con CVSS 9.8 — a un bypass di autenticazione per colpire SharePoint senza alcuna credenziale. Secondo il threat brief di Palo Alto Unit 42, lo sfruttamento è iniziato intorno al 7 luglio 2025, prima della patch, e ha compromesso oltre 85 server in 29 organizzazioni già nella prima ondata. Imperva ha registrato più di 60.000 tentativi di attacco in un solo giorno. Tre gruppi legati alla Cina — Linen Typhoon, Violet Typhoon e Storm-2603 — sono stati collegati alla campagna, e la guida di Microsoft stessa ha dovuto avvisare i clienti che la sola patch non bastava, perché gli attaccanti avevano rubato le ASP.NET machine key e potevano falsificare accessi anche dopo l'aggiornamento.

	ToolShell (CVE-2025-53770)	CVE-2026-45659
Divulgazione	Luglio 2025 (zero-day)	Maggio 2026 (patch silenziosa)
Autenticazione	Nessuna (unauth)	Site Member (autenticato)
CVSS	9.8	8.8
Causa radice	Deserializzazione + auth bypass	Deserializzazione (CWE-502)
Modo del fallimento per i difensori	Più veloce della patch	Patch esistente ma invisibile
Rischio post-patch	Machine key rubate	Assunto identico — ruotare le chiavi

Le due falle sono diverse nel meccanismo ma identiche in ciò che dicono sulla superficie d'attacco. SharePoint on-prem è una piattaforma ricca di deserializzazione, adiacente all'identità e difficile da dismettere, che attira attenzione statuale e criminale ogni singola volta che emerge una classe di bug. Il caso 2026 è forse peggiore per i difensori proprio perché appare più silenzioso: nessun titolo drammatico su uno zero-day, nessun picco di telemetria a 60.000 tentativi al giorno, solo una falla rimasta patchata-ma-non-tracciata finché lo sfruttamento non ha costretto la mano a CISA. The Register ha notato che la valutazione pubblica di sfruttabilità di Microsoft è rimasta "Less Likely" fino a quando CISA non ha confermato il contrario.

"Siamo completamente patchati sulle critiche di maggio — ho girato il report lunedì." "Quale report?" "Lo scanner. Tira giù il feed CVE, incrocia con le nostre build, segnala tutto ciò che è in KEV. Siamo puliti." "CVE-2026-45659 non era in nessun bollettino fino a questa settimana. A maggio non era nel tuo feed. Su cosa doveva fare match lo scanner?"

Quello scambio è il divario tra conforme e non sfruttabile. Non sono la stessa proprietà, e questa CVE ne è la prova.

Remediation

Un runbook completo per CVE-2026-45659. Da eseguire in ordine.

1. Sono interessato?

Controlla la build version della farm. Dalla SharePoint Management Shell su un qualsiasi server della farm:

(Get-SPFarm).BuildVersion

Confronta con le build corrette qui sotto. Qualsiasi build inferiore a quella corretta per la tua edizione è vulnerabile:

• SharePoint Server Subscription Edition — corretta in 16.0.19725.20280
• SharePoint Server 2019 — corretta in 16.0.10417.20128
• SharePoint Enterprise Server 2016 — corretta in 16.0.5552.1002

Se l'ultimo aggiornamento cumulativo è precedente al rilascio di maggio 2026 (grosso modo, server non patchati dopo il 21 maggio 2026), consideralo vulnerabile fino a prova contraria. Non affidarti al "a maggio non avevamo CVE critiche aperte": la CVE era esclusa da quel bollettino.

2. Patch — versioni corrette esatte

Installa l'aggiornamento cumulativo di maggio 2026 (o successivo) per la tua edizione fino a raggiungere la build corretta sopra. Secondo Microsoft, i sistemi che hanno già installato gli update di maggio 2026 non richiedono ulteriori azioni: il fix è in quel pacchetto anche se la CVE non era elencata. Conferma la build risultante con (Get-SPFarm).BuildVersion dopo il completamento di PSConfig. L'advisory MSRC è la fonte autorevole per i pacchetti KB per edizione.

3. Non puoi patchare stanotte? Controlli compensativi

• Taglia la raggiungibilità pre-autenticazione. Poiché lo sfruttamento richiede un Site Member autenticato, restringi chi può raggiungere i web front-end SharePoint: limita a VPN/ZTNA, imponi MFA su ogni account che può accedere a un sito SharePoint e rimuovi le concessioni Site Member stagnanti.
• Attiva AMSI in Full Mode per SharePoint (supportato su SE, 2019 e 2016 con aggiornamenti recenti). L'integrazione AMSI è la singola mitigazione più efficace che Microsoft abbia rilasciato per la classe di deserializzazione SharePoint: ispeziona il corpo della richiesta prima che il payload venga deserializzato.
• Poni la farm dietro una regola WAF che ispezioni i body POST verso gli endpoint /_layouts/ e /_vti_bin/ alla ricerca di payload .NET serializzati (anomalie __VIEWSTATE, marker di gadget TypeConfuseDelegate/ObjectDataProvider).

4. Caccia alla compromissione

Una RCE da deserializzazione su SharePoint ha una forma post-sfruttamento costante. Mappa la caccia su MITRE ATT&CK:

• T1190 (Exploit Public-Facing Application) → T1059.001 (PowerShell) / T1059.003 (cmd): cerca w3wp.exe (il worker IIS di SharePoint) che genera cmd.exe, powershell.exe o csc.exe. Un processo worker di SharePoint che avvia una shell non è quasi mai legittimo.
• T1505.003 (Web Shell): cerca file .aspx nuovi o modificati sotto C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ e i percorsi _app_bin/wpresources della farm. ToolShell rilasciava lì un ruba-chiavi in stile spinstall; tratta come IOC qualsiasi .aspx inatteso in queste directory.
• T1552 (Unsecured Credentials): la lezione di ToolShell — gli attaccanti esfiltrano le ValidationKey/DecryptionKey ASP.NET (machineKey) da web.config, poi falsificano payload __VIEWSTATE firmati che superano la validazione dopo la patch. Analizza i log ULS e IIS per POST __VIEWSTATE anomali e per connessioni in uscita dal service account SharePoint.
• T1136 (Create Account): verifica nuovi farm admin, nuovi site collection admin e account AD inattesi creati intorno alla finestra di sfruttamento.

5. Bonifica e verifica

• Rimuovi eventuali web shell trovate; non limitarti a cancellare il file — identifica la richiesta di accesso iniziale nei log IIS e ricostruisci l'intera sessione.
• Ruota le ASP.NET machine key su tutta la farm (Set-SPMachineKey / rotazione delle chiavi a livello di farm seguita da PSConfig), poi esegui un IIS reset. Non è opzionale: se le chiavi sono state rubate, la patch non sfratta l'attaccante. È stato il passaggio più trascurato nell'ondata del 2025.
• Ruota il service account della farm SharePoint e ogni credenziale raggiungibile da quell'account.
• Riesegui il controllo della build version per confermare la build corretta, poi riesegui le query di caccia per confermare che gli indicatori post-sfruttamento siano puliti dopo la patch, non prima.

Dove la validazione continua avrebbe intercettato tutto

Tutto quanto sopra presuppone che tu sappia che il server era sfruttabile. Il fallimento in CVE-2026-45659 è che la maggior parte delle organizzazioni non lo sapeva, perché tutta la loro postura di rilevamento per "sono vulnerabile?" sta a valle di un catalogo CVE che, per cinque settimane, era sbagliato. Uno scanner che incrocia le build con CISA KEV vale solo quanto il feed — e qui il feed era vuoto finché lo sfruttamento non era già iniziato.

La domanda che sopravvive a una voce di bollettino mancante non è "questa CVE è nella mia lista?" ma "se lancio l'attacco, il server cade?". È esattamente ciò a cui il motore di generative pentest di Zero Hunt è progettato per rispondere. Il suo sciame di 10 agenti AI — Recon, Exploit, Web, Credential, Post-Exploit, Pivot e gli altri, coordinati da un AI Controller — valida un bersaglio tentando la catena, non consultando un catalogo. Per una falla corretta in silenzio, senza voce su ExploitDB e senza PoC pubblico, quella distinzione è tutto: gli agenti Exploit e Web scrivono una probe di deserializzazione per-bersaglio con un LLM locale contro l'ambiente che hanno davanti, quindi non c'è dipendenza da una firma che ancora non esiste. Ogni skill candidata viene backtestata nell'AI Gym contro corpora come Vulhub e NYU CTF Bench prima ancora di toccare una farm di produzione, e ogni finding è firmato ECDSA con chain-of-custody, così "abbiamo validato SharePoint il 3 luglio" è un record verificabile, non un'affermazione.

Poiché le campagne sono change-triggered e schedulate, una farm SharePoint viene ritestata quando cambia e a cadenza fissa: gli agenti Credential e Post-Exploit in modalità assumed-breach percorrono il cammino da Site Member a RCE esattamente come farebbe un intruso reale con un account phishato, e fanno emergere l'esposizione a prescindere dal fatto che un bollettino l'abbia mai nominata. E quando un attaccante passa davvero, l'AI Traffic Analysis on-appliance di Zero Hunt — un modello deep-learning con quattro teste di inferenza a 2.7+ Gbit/s su GPU locale, senza cloud — sorveglia il filo per la firma post-sfruttamento: un host SharePoint che storicamente serviva solo contenuti e che d'improvviso genera beacon in uscita o mette in staging un burst di esfiltrazione. Patchata-a-maggio-sfruttata-a-luglio è esattamente la finestra in cui vedere l'attività mentre accade batte il leggerla nel digest SIEM del mattino dopo.

Non puoi rimediare a ciò che il tuo catalogo non ha mai elencato. Puoi validare ciò che è davvero in esecuzione. Parlaci se questo divario è uno di quelli che porti su una farm SharePoint on-prem in questo momento.