CVE-2026-69524 CVE-2026-69546 AD RCE: aggiornamenti e verifiche

Riepilogo: CVE-2026-69524 CVE-2026-69546 — RCE in Active Directory

CVE-2026-69524 e CVE-2026-69546 sono due vulnerabilità distinte di esecuzione remota di codice in Active Directory Domain Services (AD DS), pubblicate l’8 settembre 2026. Entrambe hanno un punteggio base CVSS 3.1 di 8.1, non richiedono privilegi né interazione dell’utente secondo i vettori CVSS e comportano una debolezza di tipo use-after-free. Microsoft afferma che il successo dello sfruttamento dipende dalla vittoria in una condizione di competizione. Questa difficoltà aggiuntiva deve orientare la pianificazione delle patch, senza escludere nessuna delle due vulnerabilità dalla coda di correzione dei controller di dominio. Si tratta di aggiornamenti di settembre esaminati a ottobre, non di nuove falle annunciate a ottobre. Il CVRF di settembre di Microsoft è la fonte dei dati sulle CVE riportati di seguito.

Per i team di difesa, le priorità immediate sono associare ogni controller di dominio al relativo aggiornamento applicabile, verificare l’installazione e il completamento del riavvio e conservare la telemetria utile. Il CVRF pubblico non fornisce una firma di evento o un indicatore di compromissione specifico delle CVE. Gli avvisi generici sulle modifiche alla directory o sullo stato dei servizi devono supportare l’indagine senza essere presentati come prova dello sfruttamento di una delle due falle.

CVE-2026-69524 e CVE-2026-69546 a confronto

I valori seguenti provengono dal CVRF di settembre recuperato il 3 ottobre 2026. Microsoft classifica entrambe le vulnerabilità come Important. Le stringhe relative allo sfruttamento sono riprodotte esattamente; le diverse valutazioni di probabilità devono rimanere distinte.

Nessuna delle due CVE era presente nel catalogo JSON Known Exploited Vulnerabilities della CISA consultato il 3 ottobre 2026; la versione recuperata del catalogo era 2026.10.02. L’assenza a quella data e i campi Exploited:No di Microsoft sono osservazioni separate. Nessuna garantisce che lo sfruttamento non possa avvenire o che tutta l’attività sia stata osservata.

Funzionamento: use-after-free e condizione di competizione

Un use-after-free si verifica quando un software accede alla memoria dopo che questa è stata liberata. Le conseguenze dipendono dall’implementazione; arresti anomali ed esecuzione non autorizzata rientrano tra le possibilità descritte nella definizione CWE-416 di MITRE. Questo spiega la classe di debolezza, senza stabilire la funzione vulnerabile o il formato preciso dei pacchetti per nessuna delle due CVE.

La FAQ di Microsoft per CVE-2026-69524 descrive un attaccante non autenticato che invia un pacchetto appositamente costruito a un servizio di rete interessato. La FAQ per CVE-2026-69546 descrive un attaccante all’interno della rete che invoca endpoint arbitrari. Entrambe le FAQ affermano che lo sfruttamento richiede di vincere una condizione di competizione. Il CVRF non identifica gli endpoint interessati, una sequenza di sfruttamento affidabile o un difetto di codice sottostante condiviso. Il raggruppamento delle vulnerabilità riflette il componente comune, la classe di debolezza e la corrispondenza degli aggiornamenti.

Perché AC:H richiede comunque un intervento

AC:H identifica un ulteriore ostacolo allo sfruttamento. Non trasforma PR:N in un requisito di autenticazione né UI:N nella necessità che qualcuno faccia clic su un collegamento. La nostra raccomandazione operativa è dare priorità ai controller di dominio interessati perché servono l’infrastruttura di identità, mantenendo le effettive valutazioni di probabilità di Microsoft. Evitate di inventare un tasso di successo, di definire queste falle propagabili tramite worm o di presumere che l’accesso alla rete implichi un’esposizione pubblica a Internet.

L’analisi di agosto delle RCE sui controller di dominio spiega perché i team inventariano i ruoli legati ai DC e ne verificano la conformità alle patch. Riguarda una pubblicazione diversa e CVE diverse; le sue descrizioni degli attacchi non devono essere trasferite a questa coppia.

Verificare l’aggiornamento corretto su ogni controller di dominio

Il CVRF di settembre associa entrambe le CVE a queste correzioni di Windows Server, inclusi i prodotti Server Core corrispondenti. La tabella registra la corrispondenza degli aggiornamenti originali, non un’istruzione a installare un pacchetto più vecchio sopra un aggiornamento cumulativo applicabile più recente.

Fate corrispondere il prodotto e la variante di installazione prima di scegliere un aggiornamento. L’inclusione in questa tabella CVRF non costituisce una dichiarazione sul diritto di un server al supporto. Per Server 2025, l’articolo di supporto KB5122871 conferma in modo indipendente la build del sistema operativo 26100.33438 e descrive i canali di installazione supportati. Consultate la documentazione della pubblicazione applicabile per i prerequisiti, i problemi noti e gli aggiornamenti successivi.

La documentazione Get-HotFix di Microsoft fornisce questo esatto comando di inventario locale:

Get-HotFix

I parametri documentati -Id e -ComputerName possono essere applicati alla corrispondenza di Server 2025 come segue. DC01 è un nome di esempio; usate il nome effettivo del controller. Questi comandi sono esempi basati sulla documentazione, non risultati ottenuti da un ambiente cliente.

Get-HotFix -Id KB5122871 -ComputerName DC01

Conservate le prove di installazione restituite insieme alla versione esatta del sistema operativo, alla build in esecuzione e allo stato del riavvio forniti dagli strumenti di gestione. Get-HotFix usa la classe Win32_QuickFixEngineering, la cui copertura degli aggiornamenti è limitata. Una voce mancante richiede un’indagine; da sola non dimostra una vulnerabilità, in particolare quando un aggiornamento successivo sostituisce la KB originale. Confermate l’applicabilità e la sostituzione prima di chiudere il registro.

Rilevamento: raccogliere il contesto, poi indagare

Separate l’esposizione dovuta a patch mancanti dal sospetto di compromissione. La prima richiede un inventario affidabile degli aggiornamenti. Il secondo richiede attività correlate e un’indagine. Nessun ID evento seguente identifica in modo univoco lo sfruttamento di CVE-2026-69524 o CVE-2026-69546.

Microsoft documenta la registrazione diagnostica AD DS, inclusa la raccolta predefinita di eventi critici e di errore. Aumentate il dettaglio diagnostico solo per un’indagine circoscritta e ripristinate poi l’impostazione normale; un maggiore dettaglio può influire sulle prestazioni. Inoltrate centralmente i registri Security e Directory Service e controllate lo stato dell’acquisizione prima di fare affidamento sulla loro assenza.

I riferimenti primari degli eventi sono 5136: oggetto della directory modificato e 1102: registro di audit cancellato. Per 5136, conservate SubjectUserName, ObjectDN, AttributeLDAPDisplayName, AttributeValue, OperationType e OpCorrelationID. Una modifica produce generalmente eventi separati di eliminazione e aggiunta del valore; correlateli usando OpCorrelationID e il contesto dell’oggetto e dell’attributo per confrontare i valori vecchi e nuovi. La guida al monitoraggio AD spiega perché criteri di audit, raccolta, corrispondenza dei campi e correlazione devono funzionare insieme prima che i rilevamenti basati sugli eventi forniscano una copertura utile.

Per il triage locale, questo esempio adatta la sintassi Get-WinEvent e il filtro tramite tabella hash di Microsoft. Eseguitelo sul controller con i diritti appropriati di lettura dei registri:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=5136,1102} -MaxEvents 100
Get-WinEvent -LogName 'Directory Service' -MaxEvents 100

Il limite circoscrive i record visualizzati; non è una soglia di allarme né una cronologia completa dell’incidente. Esaminate l’intervallo di tempo pertinente nel SIEM, correlate le modifiche inattese con la telemetria dell’host e della rete ed escludete la manutenzione documentata. Una query senza risultati non può certificare che un DC sia aggiornato o non compromesso.

Correzione: applicare le patch, riavviare e conservare le prove

1. Creare un registro degli aggiornamenti per ogni controller. Includete il prodotto Windows Server esatto, la variante di installazione, la KB applicabile o l’aggiornamento che la sostituisce, il responsabile e le prove di completamento. Risolvete esplicitamente i casi di sistemi irraggiungibili o che non comunicano il proprio stato.
2. Distribuire l’aggiornamento applicabile supportato. Entrambe le CVE richiedono un’azione del cliente. Usate il canale di aggiornamento approvato e le indicazioni della pubblicazione sui prerequisiti e sui problemi noti. Per Server 2025, l’articolo di supporto raccomanda l’ultimo aggiornamento Windows applicabile e registra la successiva risoluzione di un problema RDS che interessava la pubblicazione di settembre.
3. Completare il riavvio richiesto e convalidare lo stato dei servizi. Entrambe le voci CVRF indicano che gli aggiornamenti Server elencati richiedono un riavvio. Confermate autenticazione e replica tramite i normali controlli operativi e confrontate i nuovi errori del servizio directory con la situazione di riferimento precedente alla manutenzione.
4. Ricontrollare le prove di installazione. Usate il comando di inventario documentato e i registri di gestione, confermate la build in esecuzione e la sostituzione degli aggiornamenti e conservate il risultato per ogni controller. Un pacchetto distribuito con un riavvio ancora in sospeso non costituisce un registro di modifica completato.
5. Indagare separatamente sui sospetti credibili di compromissione. Conservate i registri raccolti centralmente e le prove degli host, coordinate il contenimento con il team di risposta agli incidenti di identità e valutate le modifiche non autorizzate alla directory. La sola installazione della correzione non annulla le modifiche che un attaccante potrebbe aver già effettuato.

Come EtcSec rileva questo problema

Usate i risultati degli audit di configurazione EtcSec insieme a registri indipendenti di conformità alle patch e all’indagine SIEM. Questa analisi non convalida un controllo EtcSec per nessuna delle due CVE, per il relativo aggiornamento installato o per il loro sfruttamento. Un risultato di configurazione da solo non può stabilire se un controller abbia ricevuto l’aggiornamento AD DS di settembre applicabile.