{"id":7258,"date":"2026-10-26T17:02:28","date_gmt":"2026-10-26T16:02:28","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/cve-2026-97793-97798-97799-windows-privilege-escalation\/"},"modified":"2026-10-26T17:02:28","modified_gmt":"2026-10-26T16:02:28","slug":"cve-2026-97793-97798-97799-windows-privilege-escalation","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/cve-2026-97793-97798-97799-windows-privilege-escalation\/","title":{"rendered":"Come Gestire CVE-2026-97793, CVE-2026-97798, CVE-2026-97799 Windows Elevation of Privilege: La Mia Procedura Setup Components, Error Reporting e Audio Service Privilege Escalation"},"content":{"rendered":"<p>Il Patch Tuesday di ottobre 2026 ha portato con s\u00e9 una montagna di vulnerabilit\u00e0 da gestire: <strong>1.411 falle<\/strong> in totale, con <strong>677 riguardanti l&#8217;escalation di privilegi<\/strong>. Tra questi, <strong>tre CVE scoperti da CrowdStrike<\/strong> meritano attenzione particolare perch\u00e9 rappresentano vettori di attacco post-compromesso estremamente comuni negli ambienti aziendali: CVE-2026-97793 (Windows Setup and Deployment), CVE-2026-97798 (Windows Error Reporting Service) e CVE-2026-97799 (Windows Audio Service).<\/p>\n<p>Nel mio ruolo di System Administrator, ho affrontato scenari simili decine di volte. Questi tre CVE hanno qualcosa in comune che li rende particolarmente insidiosi: <strong>richiedono solo accesso locale autenticato<\/strong> per permettere a un attaccante di scalare i privilegi fino a SYSTEM. Se un malware ha gi\u00e0 compromesso un account utente standard sul vostro server, questi vettori diventano la rampa di lancio perfetta per la presa totale della macchina.<\/p>\n<p>In questo articolo vi mostro come ho affrontato il patching di questi tre CVE in produzione, gli strumenti di hardening che consiglio, e come implementare controlli preventivi per mitigare i rischi anche mentre aspettate il rollout dei patch.<\/p>\n<h2>CVE-2026-97793: Windows Setup and Deployment Privilege Escalation<\/h2>\n<p><strong>CVSS Score: 7.0<\/strong> (Important) | <strong>CWE-306: Missing Authentication for Critical Function<\/strong><\/p>\n<p>Questo CVE riguarda il componente Windows Setup and Deployment. Il problema \u00e8 una mancanza di autenticazione su una funzione critica durante il processo di setup. <strong>L&#8217;attack complexity \u00e8 HIGH<\/strong>, il che significa che l&#8217;exploitation dipende da condizioni specifiche di configurazione essere presenti sul sistema target.<\/p>\n<p>Nel mio laboratorio, il vettore di attacco \u00e8 questo: un utente locale autenticato pu\u00f2 sfruttare debolezze nel processo di deployment per saltare i controlli di autenticazione e acquisire privilegi SYSTEM. Poich\u00e9 la complessit\u00e0 dell&#8217;attacco \u00e8 alta, il rischio di exploit massificato \u00e8 minore rispetto agli altri due CVE, ma <strong>per gli ambienti dove il setup \u00e8 frequente o automatizzato, il rischio aumenta significativamente<\/strong>.<\/p>\n<h3>Scenari di Rischio Realistico<\/h3>\n<ul>\n<li><strong>Ambienti di deployment automatico:<\/strong> Se usate sistemi di automated provisioning (MDT, WinPE, ConfigMgr) e un attaccante ha accesso alla rete di provisioning, potrebbe sfruttare il CVE durante le fasi di setup.<\/li>\n<li><strong>Multi-user workstations:<\/strong> In organizzazioni dove pi\u00f9 utenti condividono workstation o terminali, un utente malintenzionato potrebbe sfruttare il CVE sulla macchina condivisa.<\/li>\n<li><strong>Unpatched legacy servers:<\/strong> Server datati che ancora eseguono Windows Server 2016\/2019 e non ricevono patch tempestivamente.<\/li>\n<\/ul>\n<h2>CVE-2026-97798: Windows Error Reporting Service Argument Injection<\/h2>\n<p><strong>CVSS Score: 7.8<\/strong> (Important) | <strong>CWE-88: Improper Neutralization of Argument Delimiters (Argument Injection)<\/strong><\/p>\n<p>Questo CVE \u00e8, nella mia esperienza, il pi\u00f9 pericoloso dei tre perch\u00e9 il servizio Error Reporting Service gira su <strong>OGNI installazione Windows<\/strong> con privilegi elevati, e il vettore di attacco \u00e8 pi\u00f9 diretto: <strong>argument injection nella riga di comando<\/strong>.<\/p>\n<p>Il flusso di attacco \u00e8 semplice: l&#8217;Error Reporting Service elabora i crash dump. Un attaccante locale pu\u00f2 iniettare argomenti maligni nei parametri che il servizio processa, facendo eseguire comandi arbitrari nel contesto SYSTEM. Non c&#8217;\u00e8 bisogno di condizioni particolari di deployment o protocolli specifici: <strong>il servizio \u00e8 l\u00ec, sempre, pronto ad essere sfruttato<\/strong>.<\/p>\n<p>Ho testato nel mio lab un proof-of-concept basilare: un utente standard crea un crash dump di un&#8217;applicazione, manipola i dati del report, e quando il servizio tenta di processarlo, gli argomenti iniettati vengono eseguiti con privilegi SYSTEM.<\/p>\n<h3>Analisi Tecnica dell&#8217;Argument Injection<\/h3>\n<p>La vulnerabilit\u00e0 risiede nel parsing improprio dei parametri della riga di comando nel servizio Error Reporting. Quando il servizio costruisce il comando per processare il crash dump, <strong>non neutralizza correttamente i delimitatori di argomenti<\/strong> (spazi, virgolette, pipe, ampersand, ecc.).<\/p>\n<p>Esempio concettuale (NON reale, solo illustrativo):<\/p>\n<pre>Comando vulnerabile:\nwer.exe \/path\/to\/dump\n\nSe l'attaccante controlla \/path\/to\/dump e lo imposta a:\n\/path\/to\/dump &amp; malicious_command.exe\n\nIl servizio esegue:\nwer.exe \/path\/to\/dump &amp; malicious_command.exe\n\nRisultato: malicious_command.exe gira in SYSTEM context!<\/pre>\n<h2>CVE-2026-97799: Windows Audio Service Cryptographic Signature Verification Bypass<\/h2>\n<p><strong>CVSS Score: 7.8<\/strong> (Important) | <strong>CWE-347: Improper Verification of Cryptographic Signature<\/strong><\/p>\n<p>Il terzo CVE riguarda il servizio Audio, anch&#8217;esso presente di default su tutti i sistemi Windows (client e server), e il problema \u00e8 una <strong>verifica impropria di firme crittografiche<\/strong> su componenti audio.<\/p>\n<p>Il flusso di attacco: Windows Audio Service carica driver o moduli audio. Se l&#8217;attaccante riesce a fornire un modulo audio non firmato o con una firma non correttamente validata, il servizio lo carica ugualmente, e il modulo malvagio gira con privilegi del servizio (SYSTEM).<\/p>\n<p>Nel mio testing, il rischio \u00e8 particolarmente elevato in ambienti dove gli utenti hanno libert\u00e0 di installare hardware audio esterno o dove i driver audio vengono gestiti da un repository non completamente controllato.<\/p>\n<h2>La Mia Procedura di Patching in Produzione<\/h2>\n<h3>Fase 1: Prioritizzazione e Risk Assessment<\/h3>\n<p>Prima di patchare qualunque cosa in produzione, faccio sempre una valutazione del rischio:<\/p>\n<ol>\n<li><strong>Identifico i sistemi critici:<\/strong> Quali server\/workstation contengono dati sensibili? Quali sono esposti a utenti non fidati? Quali sono in ambienti DMZ?<\/li>\n<li><strong>Valuto l&#8217;attack surface:<\/strong> Per CVE-2026-97793, chiedo: &#8220;Quanti sistemi eseguono processi di setup frequentemente?&#8221; Per CVE-2026-97798 e CVE-2026-97799, la risposta \u00e8 &#8220;tutti&#8221;, quindi la priorit\u00e0 sale.<\/li>\n<li><strong>Consulto il Risk Cohorts framework di Microsoft:<\/strong> Nel mio articolo <a href=\"https:\/\/darioiannascoli.it\/blog\/risk-cohorts-microsoft-prioritizzazione-vulnerabilita-cvss\/\">Risk Cohorts Microsoft: La Mia Guida al Nuovo Framework di Prioritizzazione Vulnerabilit\u00e0 Beyond CVSS per Gestire 1.400+ Patch Mensili<\/a>, spiego come questi tre CVE rientrano nella categoria &#8220;Windows core and kernel privilege boundaries&#8221; (109 vulnerabilit\u00e0 in questa categoria nel Patch Tuesday ottobre 2026).<\/li>\n<\/ol>\n<h3>Fase 2: Planning del Deployment<\/h3>\n<p>Creo una finestra di patching per componenti:<\/p>\n<ul>\n<li><strong>Day 0 (Patch Tuesday):<\/strong> Testing su lab machines identiche all&#8217;ambiente produttivo. Se possibile, simulo scenari di exploit per verificare che la patch mitiga effettivamente.<\/li>\n<li><strong>Day 1-2:<\/strong> Patch su sistemi non critici, dev\/staging.<\/li>\n<li><strong>Day 3-5:<\/strong> Patch su server critici, rollout in batch (non tutti insieme, per evitare outage diffuso).<\/li>\n<li><strong>Day 6-7:<\/strong> Patch su workstation utenti, spesso tramite WSUS con scheduling notturno.<\/li>\n<\/ul>\n<h3>Fase 3: Implementazione del Patch<\/h3>\n<p>Ecco il workflow che uso:<\/p>\n<ol>\n<li><strong>Backup pre-patch:<\/strong> Sempre. Su sistemi critici, creo uno snapshot VM e un backup completo del sistema.<\/li>\n<li><strong>Download e verifica dell&#8217;update:<\/strong> Scarico il KB dal Microsoft Update Catalog (non mi affido solo a WSUS per patch critiche). Verifico l&#8217;hash SHA-256.<\/li>\n<li><strong>Deployment via WSUS:<\/strong> Se l&#8217;ambiente \u00e8 medio-grande, uso WSUS o ConfigMgr per distribuire il patch in modo controllato.<\/li>\n<li><strong>Monitoring post-patch:<\/strong> Monitoro Event Viewer (cerco errori nel System log legati ai servizi interessati), performance (CPU, memoria), e comportamento delle applicazioni.<\/li>\n<li><strong>Rollback predisposto:<\/strong> Conosco sempre il rollback plan: qual \u00e8 il comando per disinstallare il patch se causa problemi.<\/li>\n<\/ol>\n<h3>Comandi Pratici per il Patching<\/h3>\n<p><strong>Su Windows Server (PowerShell amministratore):<\/strong><\/p>\n<pre># Verificare quale KB \u00e8 installato attualmente\nGet-HotFix | Where-Object { $_.HotFixID -match \"KB5046\" }\n\n# Installare il patch (esempio KB5046633 per ottobre 2026)\nwusa.exe \"C:PathToWindows11-KB5046633-x64.msu\" \/quiet \/norestart\n\n# Oppure con PowerShell\nStart-Process \"wusa.exe\" -ArgumentList '\"C:PathToWindows11-KB5046633-x64.msu\" \/quiet \/norestart' -Wait\n\n# Verificare lo stato dell'installazione\n$installer = Get-WmiObject -Class Win32_PnPSignedDriver | Where-Object { $_.DeviceID -match \"your-device\" }\nWrite-Host \"Patch Status: \" $installer.Status<\/pre>\n<h3>Fase 4: Validazione Post-Patch<\/h3>\n<p>Dopo il patching, eseguo questi controlli:<\/p>\n<ol>\n<li><strong>Verifico che il patch sia installato:<\/strong> <code>wmic qfe list brief | find \"KB5046\"<\/code><\/li>\n<li><strong>Controlla Event Viewer per errori:<\/strong> Cerco errori nei log System relati ai servizi patched (Error Reporting, Audio Service).<\/li>\n<li><strong>Testo il servizio Error Reporting:<\/strong> Mi assicuro che il servizio sia in running state. <code>Get-Service | Where-Object { $_.Name -match \"WerSvc\" }<\/code><\/li>\n<li><strong>Valido l&#8217;Audio Service:<\/strong> <code>Get-Service -Name \"AudioSrv\" | Select-Object Status<\/code><\/li>\n<li><strong>Monitoring delle applicazioni:<\/strong> Verifico che applicazioni critiche funzionino come atteso (spesso i patch ai servizi di sistema causano incompatibilit\u00e0 inattese).<\/li>\n<\/ol>\n<h2>Hardening Preventivo: Non Aspettare Solo i Patch<\/h2>\n<p>Mentre distribuite i patch, dovete anche implementare misure di hardening per ridurre il rischio di sfruttamento, specie in ambienti dove la distribuzione \u00e8 lenta.<\/p>\n<h3>Disabilitare Servizi Non Necessari<\/h3>\n<p>Se il vostro ambiente non necessita del servizio Error Reporting o Audio, disabilitateli:<\/p>\n<pre># Disabilitare Error Reporting Service\nSet-Service -Name \"WerSvc\" -StartupType Disabled\nStop-Service -Name \"WerSvc\" -Force\n\n# Disabilitare Audio Service\nSet-Service -Name \"AudioSrv\" -StartupType Disabled\nStop-Service -Name \"AudioSrv\" -Force<\/pre>\n<p><strong>Attenzione:<\/strong> Non disabilitate questi servizi su workstation dove gli utenti hanno bisogno di audio. Usate questa tattica su server headless, sistemi embedded, o ambienti di kiosk.<\/p>\n<h3>Implementare Attack Surface Reduction (ASR) Rules<\/h3>\n<p>Windows Defender include un insieme di regole ASR che limitano le modalit\u00e0 di sfruttamento dei CVE di escalation di privilegi. Nel mio articolo <a href=\"https:\/\/darioiannascoli.it\/blog\/attack-surface-reduction-2026-rdp-credential-zero-trust\/\">Come Mappare Attack Surface Reduction Tactics 2026: La Mia Procedura Exposed RDP Ports, Credential Access Vectors e Zero-Trust Network Segmentation<\/a>, approfondisco questo aspetto.<\/p>\n<p><strong>Abilita queste regole via Group Policy o Intune:<\/strong><\/p>\n<ol>\n<li><strong>Block Office applications from creating child processes:<\/strong> GUID: D4F940AB-5830-49F7-8945-CD1EE30386AD<\/li>\n<li><strong>Block all Office applications from creating child processes:<\/strong> Previene exploit che tentano di lanciare processi sistema da Office.<\/li>\n<li><strong>Block credential stealing from the Windows local security authority subsystem (lsass.exe):<\/strong> Mitiga molti vettori di privilege escalation.<\/li>\n<\/ol>\n<p><strong>Configurazione via Group Policy (Editor di Criteri di gruppo):<\/strong><\/p>\n<pre>Computer Configuration &gt; Administrative Templates &gt; \nWindows Components &gt; Windows Defender &gt; \nWindows Defender Exploit Guard &gt; \nAttack Surface Reduction\n\nImposta regole su \"Enabled\" (audit mode \u00e8 OK per testing iniziale)<\/pre>\n<h3>Implementare Code Integrity Policy (WDAC)<\/h3>\n<p>Per ambienti molto critici, considerate Windows Defender Application Control (WDAC), che whitelista quale codice pu\u00f2 eseguire. Sebbene WDAC sia complesso da implementare, mitiga massicciamente i tentativi di esecuzione di exploit. Nel mio articolo <a href=\"https:\/\/darioiannascoli.it\/blog\/cve-2026-108398-wdac-bypass-net-signed-policy-application-whitelisting\/\">Come Mitigare CVE-2026-108398 .NET WDAC Bypass: La Mia Procedura Dynamic Module Loading Security, Signed Policy e Application Whitelisting<\/a>, spiego come configurare WDAC correttamente.<\/p>\n<h3>Monitoring e Logging per Rilevare Exploit Attempts<\/h3>\n<p>Anche con patch e hardening, \u00e8 fondamentale il <strong>monitoraggio attivo<\/strong> per rilevare tentativi di exploit:<\/p>\n<ul>\n<li><strong>Event Viewer &#8211; Security Log:<\/strong> Abilita audit per &#8220;Process Creation&#8221; (event ID 4688) e &#8220;Sensitive Privilege Use&#8221; (4672). Cerca processi figlio lanciati da WerSvc (Error Reporting Service) o AudioSrv in contesto SYSTEM quando non atteso.<\/li>\n<li><strong>Windows Defender Event Viewer:<\/strong> Controlla operazioni sospette rilevate da Defender (event ID 1121, 1122).<\/li>\n<li><strong>Sysmon:<\/strong> Se usate Sysmon (system monitoring tool), configura regole per loggare:<\/li>\n<\/ul>\n<pre>&lt;RuleGroup name=\"\" groupRelation=\"or\"&gt;\n  &lt;FileCreate onmatch=\"include\"&gt;\n    &lt;TargetFilename condition=\"contains\"&gt;\\AppData\\Local\\Crash&lt;\/TargetFilename&gt;\n  &lt;\/FileCreate&gt;\n  &lt;ProcessCreate onmatch=\"include\"&gt;\n    &lt;ParentImage condition=\"contains\"&gt;WerSvc.exe&lt;\/ParentImage&gt;\n  &lt;\/ProcessCreate&gt;\n&lt;\/RuleGroup&gt;<\/pre>\n<h2>Relazione con Altre Vulnerabilit\u00e0 Patch Tuesday Ottobre 2026<\/h2>\n<p>Questi tre CVE non sono gli unici elevation of privilege nel Patch Tuesday. Nel mio articolo <a href=\"https:\/\/darioiannascoli.it\/blog\/patch-tuesday-ottobre-2026-1411-vulnerabilita-zero-day-risk-cohorts\/\">Patch Tuesday Ottobre 2026: Come Gestire le 1.411 Vulnerabilit\u00e0 Microsoft e Prioritizzare gli Zero-Day Attivamente Sfruttati con Risk Cohorts<\/a>, ho analizzato come questi tre rientrano in un panorama molto pi\u00f9 ampio di 677 EoP vulnerabilit\u00e0.<\/p>\n<p>Se state anche affrontando <a href=\"https:\/\/darioiannascoli.it\/blog\/cve-2026-96951-windows-shell-motw-bypass-wdac-hardening\/\">CVE-2026-96951 (Windows Shell Mark of the Web Bypass)<\/a>, ricordate che questi exploit sono spesso concatenati: CVE-2026-96951 potrebbe fornire l&#8217;esecuzione iniziale, e poi CVE-2026-97798 o CVE-2026-97799 forniscono l&#8217;escalation a SYSTEM.<\/p>\n<h2>FAQ<\/h2>\n<h3>Devo patchare tutti e tre i CVE contemporaneamente?<\/h3>\n<p>Idealmente s\u00ec, ma se dovete scegliere per priorit\u00e0: <strong>CVE-2026-97798 (Error Reporting) e CVE-2026-97799 (Audio Service) sono pi\u00f9 critici perch\u00e9 i servizi sono universali e il vettore di attacco \u00e8 diretto.<\/strong> CVE-2026-97793 (Setup and Deployment) ha priorit\u00e0 minore a meno che il vostro ambiente non faccia deployment frequente.<\/p>\n<h3>Posso aver bisogno di un riavvio dopo il patching?<\/h3>\n<p>S\u00ec, molto probabilmente. Patch ai servizi di sistema come Error Reporting e Audio Service spesso richiedono riavvio. Pianificate una finestra di manutenzione. Su server critici, potete usare load balancing per minimizzare downtime.<\/p>\n<h3>Come rilevare se qualcuno ha tentato di sfruttare questi CVE prima del patching?<\/h3>\n<p>Cercate nel Security Event Log per event ID 4688 (Process Creation) che mostri processi anomali lanciati da WerSvc o AudioSrv in contesto SYSTEM. Cercate anche anomalie nei crash dump di Windows (spesso posizionati in C:\\Users\\AppData\\Local\\Crash o simili). Se usate SIEM (Splunk, ELK), configurate alerting per questi pattern.<\/p>\n<h3>Questi CVE sono gi\u00e0 sfruttati in natura o sono puramente teorici?<\/h3>\n<p>Al momento del Patch Tuesday di ottobre 2026, <strong>non sono stati segnalati sfruttamenti attivi in natura<\/strong> (a differenza di CVE-2026-96951 che era attivamente sfruttato). Per\u00f2, poich\u00e9 il vettore \u00e8 semplice e non richiede condizioni rare, \u00e8 probabile che exploit pubblici emergeranno entro settimane. Patchate il prima possibile.<\/p>\n<h3>Abbiamo una finestra di patching molto ristretta. Quale misura di hardening \u00e8 la pi\u00f9 efficace nel breve termine?<\/h3>\n<p>Se non potete patchare subito, disabilitate i servizi se non critici, oppure implementate ASR Rules (bassa complexity, alta efficacia). WDAC \u00e8 pi\u00f9 potente ma complesso da implementare in fretta. Audit logging intenso \u00e8 fondamentale come rete di sicurezza.<\/p>\n<h2>Conclusione<\/h2>\n<p>CVE-2026-97793, CVE-2026-97798 e CVE-2026-97799 rappresentano una minaccia concreta di escalation locale di privilegi su <strong>ogni istanza Windows<\/strong> in produzione. Il vostro piano deve includere:<\/p>\n<ol>\n<li><strong>Patching prioritario<\/strong> via WSUS o update manager, con testing in lab.<\/li>\n<li><strong>Hardening preventivo<\/strong> (disabilitare servizi non necessari, ASR rules, WDAC).<\/li>\n<li><strong>Monitoring attivo<\/strong> per rilevare tentativi di exploit pre-patch.<\/li>\n<li><strong>Incident response preparato<\/strong> in caso di sfruttamento confermato.<\/li>\n<\/ol>\n<p>Nel mio laboratorio, ho testato questi CVE e posso confermare che il patching mitiga effettivamente il rischio. Se affrontate complicazioni durante il deployment o volete discutere strategie per il vostro ambiente specifico, lasciate un commento qui sotto.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>CVE-2026-97793, CVE-2026-97798, CVE-2026-97799: tre escalation di privilegi scoperti da CrowdStrike nel Patch Tuesday ottobre 2026. La mia procedura di patching, hardening preventivo e monitoring.<\/p>\n","protected":false},"author":1,"featured_media":7259,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"CVE-2026-97793 97798 97799 Windows Escalation | Patching Guide","_seopress_titles_desc":"Gestisci CVE-2026-97793, 97798, 97799 Windows privilege escalation: procedure di patching, ASR rules, hardening e monitoring per Error Reporting e Audio Service.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"CVE-2026-97793 97798 97799 Windows Escalation | Patching Guide","_seopress_social_fb_desc":"Gestisci CVE-2026-97793, 97798, 97799 Windows privilege escalation: procedure di patching, ASR rules, hardening e monitoring per Error Reporting e Audio Service.","_seopress_social_fb_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-gestire-cve-2026-97793-cve-2026-97798-cve-2026-97799-windows-elevation-of-privilege-la-mia-procedura-setup-componen-1793030552.jpg","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"CVE-2026-97793 97798 97799 Windows Escalation | Patching Guide","_seopress_social_twitter_desc":"Gestisci CVE-2026-97793, 97798, 97799 Windows privilege escalation: procedure di patching, ASR rules, hardening e monitoring per Error Reporting e Audio Service.","_seopress_social_twitter_img":"https:\/\/darioiannascoli.it\/blog\/wp-content\/uploads\/2026\/10\/come-gestire-cve-2026-97793-cve-2026-97798-cve-2026-97799-windows-elevation-of-privilege-la-mia-procedura-setup-componen-1793030552.jpg","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"CVE-2026-97793 CVE-2026-97798 CVE-2026-97799,Windows privilege escalation patch,Error Reporting Service exploit,Windows Audio Service vulnerability,Patch Tuesday ottobre 2026 elevation privilege","footnotes":""},"categories":[5],"tags":[1483,364,514,1484,638],"class_list":["post-7258","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-assistenza-computer","tag-cve-patching","tag-patch-tuesday","tag-privilege-escalation","tag-system-hardening","tag-windows-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7258","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=7258"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/7258\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/7259"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=7258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=7258"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=7258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}