gcc

Barba rabbinica, tonaca e sandali: nel 2000 si autodefinì “sull’orlo dell’autismo”. Storia di Richard Stallman, l’uomo del software libero e di una rivoluzione digitale che nessuno aveva previsto. Sono diverse le figure della comunità scientifica che hanno contribuito in maniera fondamentale a traghettare la nostra civiltà dal vecchio mondo analogico all’attuale società dell’informazione (digitale). Tra queste personalità quella che occupa sicuramente un posto di rilievo nell’pantheon informatico è sicuramente Richard Stallman. Richard Stallman è un programmatore statunitense, oggi settantatreenne. Nasce e cresce a New York e ha fatto parte del celebre laboratorio di intelligenza artificiale del MIT nel Massachusetts fino al gennaio del 1984. È proprio nel perimetro di questo laboratorio che si verifica l’evento destinato a dare una svolta al corso dell’informatica. La Xerox aveva donato all’AI Lab (laboratorio di intelligenza artificiale ) del MIT una stampante laser professionale di nuova generazione ma per una strana eterogenesi dei fini questa macchina si inceppava di continuo. Stallman conosceva il problema, sapeva come risolverlo avendo negli anni precedenti risolto problemi simili su altri dispositivi di stampa ma non aveva accesso al codice perché la Xerox distribuiva solo gli eseguibili, quindi, niente reverse engineering. Una buona occasione gli si presentò quando seppe di un ricercatore che aveva lasciato la Xerox PARC per trasferirsi alla Carnegie Mellon University portando con sé il codice. Si reca quindi di persona per chiedergli del sorgente ma tutto si riduce in una breve e brutale conversazione: l’ex ricercatore aveva firmato un accordo di riservatezza con l’azienda e dunque rifiutò di concedergli il codice e qualunque altra cosa. Tempo dopo lo stesso Stallman dichiarerà: “ Era la prima volta che m’imbattevo in una clausola di non divulgazione, e mi resi immediatamente conto come questi accordi producano delle vittime. In questo caso la vittima ero io .” Stallman arrabbiato, andò via senz’aggiungere una parola. Un incontro, durato forse 30 secondi, divenne il punto di svolta della sua vita. Da quel giorno dichiarerà: ogni volta che colleghi del MIT mi offrivano lavoro in aziende che richiedevano un contratto di riservatezza, mi rifiutavo. Questo isolamento progressivo lo portò a definirsi, riprendendo Steven Levy “ l’ultimo vero hacker ”. Questo è quanto basta per convincere il giovane Stallman che il codice proprietario non deve essere l’unica strada percorribile, anzi deve esserci un’alternativa valida e condivisibile ma per questo deve costruirla da zero. Ma per capire meglio la portata di questa scelta bisogna fare un ulteriore passo indietro. Agli inizi degli anni Settanta nei Bell Labs, Ken Thompson e Dennis Ritchie stavano riscrivendo il codice di Unix donando al mondo un nuovo linguaggio di programmazione, il Linguaggio C. Questo rendeva Unix (riscritto in C) oltreché portabile su altre macchine, anche di più facile manutenzione, scelta che successivamente avrebbe permesso al progetto GNU , e più tardi a Linux, di poggiare su basi solide ma, in particolare, era la situazione accademica di quegli anni a renderlo un periodo particolare: Il clima accademico aperto, quello che Stallman vive al MIT, permetteva a ricercatori e università di scrivere e scambiarsi liberamente idee e software creato. Ma con il passare del tempo, questo clima andò via via ridimensionandosi e anche Unix avrebbe perso parte della sua apertura, diventando sempre più chiuso: codice a pagamento, licenze restrittive. Quella di Stallman fu quindi una reazione a queste increspature industriali e ad un contesto che andava cristallizzandosi verso sempre una maggiore chiusura. Così nel gennaio del 1984 anziché schierarsi dalla parte di chi si batteva per il copyright per il software come aveva fatto Bill Gates pochi anni prima scrivendo la celebre: “ Lettera aperta agli hobbisti “, Stallman si decise a compiere un gesto retrospettivamente rivoluzionario, lasciò il laboratorio del MIT per fondare un progetto nuovo, tutto suo. Nasce così il progetto GNU , dal quale nasceranno poi la Free Software Foundation e la licenza GPL . Richard Matthew Stallman Richard viene al mondo a New York nel 1953, figlio di Daniel Stallman e Alice Lippman. Il padre è un veterano della Seconda Guerra Mondiale che ha partecipato allo sbarco in Normandia: un uomo integro, ricorderà il figlio, ma anaffettivo. La madre insegna arte ed è un’attivista sindacale. Vivace e politicamente impegnata di orientamento progressista, l’esatto opposto del giovane Richard, all’epoca adolescente dalle idee conservatrici. Le loro opposte idee li porteranno spesso a quotidiani e furiosi scontri. I genitori divorzieranno nel 1958, quando Richard ha solo cinque anni. Inizia così per il futuro informatico un periodo di pendolarismo tra l’appartamento della madre a Manhattan e la casa del padre nel Queens. Anni di incomprensioni che Stallman ricorderà sempre con tristezza. Richard Matthew Stallman Un introverso enfant prodige Fin dall’infanzia si distingue per comportamenti inusuali: la madre, Alice Lippman, racconta due episodi in particolare. Da bambino, portato in spiaggia, iniziava a urlare ben prima di arrivare alla battigia, infastidito dal rumore della risacca; e piangeva ogni volta che la nonna, dai capelli rosso vivo, tentava di prenderlo in braccio, quasi infastidito dal colore stesso. Episodi che la madre, anni dopo, ricollegherà a certe caratteristiche dello spettro autistico. Sviluppa presto un proprio metodo per orientarsi nel mondo: a 7 anni memorizza le mappe della metropolitana di New York stando al finestrino del primo vagone, e lancia modellini di razzi a Riverside Drive Park annotando i risultati di ogni lancio. Fu proprio in un periodo di lutto, a dieci anni, dopo la morte dei nonni paterni, che un istruttore di un corso estivo gli procurò un manuale dell’IBM 7094: Richard iniziò a scrivere programmi su carta, senza ancora avere una macchina su cui farli girare. Comportamenti che lo stesso Stallman stigmatizzerà in un’intervista al Toronto Star del 9 ottobre 2000 (firma di Judy Steed), nella quale si autodefinì: “Sull’orlo dell’autismo” Gli studi Altro comportamento che lo contraddistingueva dai suoi coetanei a scuola era la sua avversione per i compiti scritti che per anni aveva boicottato e sistematicamente eluso. Il suo ultimo tema risaliva alla quarta elementare. Mentre frequentava la Louis D. Brandeis High School, scuola presso cui si sarebbe diplomato, Richard frequentava il Columbia Science Honors Program, un corso riservato ai migliori studenti delle medie di New York e lavorava come assistente di laboratorio alla Rockefeller University, dove il direttore rimase talmente colpito dal suo talento da telefonare alla madre anni dopo per sapere come stesse, convinto che avrebbe avuto un grande futuro in biologia. Il suo primo vero programma lo scrisse in estate all’IBM New York Scientific Center: un preprocessore per il 7094 in linguaggio PL/I, poi riscritto interamente in assembler perché troppo grande per quella macchina. Andava ancora alle medie. Mentre è ancora all’università che ha inizio la sua leggenda grazie anche alla capacità di correggere i suoi professori mentre facevano lezione, cosa che gli attirò molte antipatie, nel 1974 ad Harvard consegue la laurea in fisica. Dopo la laurea, entra a far parte del laboratorio di intelligenza artificiale del MIT (AI Lab), dove aveva già iniziato a lavorare nel 1971. In quel contesto la parola “ hacker ” non ha una valenza negativa, anzi, si riferiva a chi studiava e s’impegnava senza sosta per migliorare software e sistemi. Scrivere codice era solo un punto di partenza. La filosofia dell’AI Lab era semplice: dare e ricevere, tutto era improntato sulla condivisione e sul miglioramento del codice e chiunque poteva usarlo e migliorarlo restituendolo alla comunità scientifica con nuove aggiunte. Il laboratorio, nei suoi anni d’oro, era per Stallman qualcosa di simile a una città viva: alcune sezioni si rinnovavano continuamente, altre restavano immutate al punto che si poteva riconoscere, dalla scrittura del codice, il lavoro dei programmatori degli anni Sessanta. Poi, nei primi anni Ottanta, quella città cominciò a svuotarsi. La Symbolics, una startup nata da una costola dello stesso MIT, si portò via i migliori programmatori a uno a uno, e tutti firmarono accordi di non divulgazione con l’azienda. Stallman restò Solo. Richard Matthew Stallman Il rivoluzionario Ateo Nonostante fosse figlio di madre ebrea, si dichiarava non credente. Ma era molto provocatorio anche nel professare il suo ateismo. Leggenda vuole che girasse con una spilla su cui era scritto “Processiamo Dio”. La logica era la seguente: se una divinità così potente avesse creato il mondo senza mai correggerne i problemi, avrebbe ragionato, forse più che adorarla, sarebbe stato il caso di processarla. Questa stessa provocazione negli anni prese forma di un piccolo monologo che recita ancora oggi, impersonando l’imputato. La goccia che fa traboccare il vaso Alcuni anni dopo l’evento della stampante laser, gli hacker del MIT sotto la guida di Richard Greenblatt avevano modificato e perfezionato la Lisp Machine, un computer dell’AI Labs creato da John McCarthy negli anni Cinquanta per il linguaggio Lisp. Agli inizi degli anni 80 questo progetto si divise in due rami diversi ognuno rappresentato da una diversa azienda. La Symbolics rappresentata da Russell Noftsker, ex amministratore del laboratorio, e la Lisp Machine Inc di Greenblatt. Le due aziende si contesero il personale dell’AI Lab: alcuni furono assunti come consulenti dalla Symbolics, il resto degli esperti (hacker) andò alla Lisp Machine Inc. L’unico degli esperti che decise di rimanere all’AI Lab fu Stallman che rimase a guardia della Lisp Machine dell’AI Lab. Nel giorno del suo ventinovesimo compleanno la Symbolics ritira il suo accordo informale stipulato con il Laboratorio del MIT. L’accordo consisteva nel condividere le innovazioni e i miglioramenti del codice sviluppati dall’azienda per aggiornare il sistema operativo comune delle Lisp machine. Da quel giorno in poi se il MIT avesse voluto gli aggiornamenti avrebbe dovuto comprare macchine dalla Symbolics e interrompere ogni rapporto con la concorrenza. Stallman da hacker e genio qual’era reagì male all’ultimatum: descrisse il laboratorio come “ un paese neutrale, come il Belgio ” di fronte a un’invasione se la Germania attacca il Belgio, spiegò, il Belgio si schiera con Francia e Inghilterra. Un paragone che Stallman avrebbe ripetuto, quasi identico, anche in un’altra intervista rilasciata anni dopo al giornalista Michael Gross, segno di quanto quell’immagine gli fosse rimasta impressa. Inizio della leggenda Quel che accade dal 1982 entra a ragione nel leggendario, ogni volta che la Symbolics rilasciava una nuova funzione, un aggiornamento, Stallman lo riscriveva da zero per tenere sempre aggiornata la Lisp Machine del MIT e lo stesso laboratorio al passo coi tempi. Iniziò a sfidare, come si dice, a singolar tenzone, a colpi di tastiera e di codice i suoi migliori ex colleghi di laboratorio, passati alla concorrenza. Fu anche accusato di copiare il codice, ma per smentire le accuse smise anche di leggere il loro codice ricostruendo tutto da zero partendo solo dalla documentazione. Nonostante la tenacia e la preparazione, Stallman sapeva di non poter combattere all’infinito contro un’azienda e la maggior parte dei suoi ex colleghi, che lo ritenevano un romantico hacker anacronistico, passati tutti dal software di laboratorio al software di mercato. Si era convinto che non poteva essere più l’ultimo giapponese rimasto nella foresta a combattere a guerra finita, non aveva più senso.L’AI Lab era come una cucine di certi ristoranti storici: un po’ malandata, un po’ geniale, e impossibile da replicare altrove . Bisognava costruire qualcosa di nuovo e che nessuna azienda potesse ricomprare. GNU non è Unix Gennaio 1984. Per evitare che il MIT metta le mani sul suo codice e lo chiuda in un cassetto proprietario, Stallman taglia i ponti. Lascia l’università e lancia un’idea che ai molti suona semplicemente folle: scrivere un intero sistema operativo da zero, che sia compatibile con UNIX . Il nome scelto è tutto un programma: GNU (acronimo ricorsivo per GNU’s Not Unix ). Le regole d’ingaggio? Nessun segreto. Il codice deve rimanere aperto, studiabile e modificabile. Sempre. C’era però un ostacolo di fondo. Per far girare un sistema Unix-like serve un compilatore C, e all’epoca di roba libera non c’era neanche l’ombra. Che fare? Semplice: scriversene uno. Nasce così la Free Software Foundation (FSF) per raccogliere donazioni, e nel 1987 spunta fuori la primissima versione di GCC . Un punto di non ritorno. Era il primo compilatore C portabile e ottimizzato nato completamente libero. Insieme all’editor Emacs e alle utility di base, GCC diventa il pilastro della futura informatica. E da allora non si è mai più fermato: ha inglobato il C++, ha visto nascere un ramo sperimentale pazzesco (EGCS) che ha riscritto le regole dell’ottimizzazione, fino a supportare Fortran, Java e Ada. Oggi la chiamano GNU Compiler Collection , ed è gestita da un comitato misto di accademici e industriali. Il Kernel E il kernel? Mettiamola così: nei piani originali doveva chiamarsi Alix (il nome della ragazza di Stallman all’epoca). Poi lo sviluppatore principale, Michael Bushnell, ci mise lo zampino e optò per HURD , declassando Alix a un semplice sottosistema interno. Poco dopo la coppia scoppiò, e di Alix rimase solo un vecchio appunto nei file di progetto. Curiosità logistica: prima di Internet, come si distribuiva questa mole di codice? Via posta. Man mano che i programmi diventavano stabili, Stallman masterizzava i nastri magnetici e li spediva a casa di chi li chiedeva, dietro un piccolo rimborso spese. In pratica, aveva appena inventato la prima attività di distribuzione software della storia senza nemmeno rendersene conto. Copyleft Nel 1989 Stallman formalizza la GNU General Public License sul principio del Copyleft. Scrivendo il suo codice software come codice legale. Crea un nuovo tecnicismo giuridico fondato sul capovolgimento del funzionamento del Copyright. Il Copyleft non è usato per limitare, restringere la libertà degli utenti, anzi serve a garantirla. Chiunque sia in possesso di un software sotto licenza GPL può liberamente copiarlo, modificarlo, ridistribuirlo senza nessuna restrizione ma con un unico obbligo: qualsiasi versione derivata deve restare sotto il dominio GPL, in modo da godere delle stesse libertà delle versioni precedenti. Richard Matthew Stallman L’ambiguità Il progetto GNU nasce per promuovere la libertà e la cooperazione tra gli utenti di computer e tra i programmatori. Software libero non significa software gratuito. Con la parola Free il software va pensato come se si pensasse alla “Libertà di parola” e non a una “birra Gratis” ripete da sempre Stallman. Dunque, ci si riferisce alla libertà di chi usa quel programma. Nel manifesto del software libero (GNU), sono elencate 4 libertà Libertà 0 : Eseguire il programma per qualsiasi scopo. (Puoi usarlo come vuoi) Libertà 1 : Studiare come funziona il programma e adattarlo alle proprie necessità. (entrare nel codice e modificarlo) Libertà 2 : Ridistribuire copie per aiutare il prossimo. (Fare copie e passarle agli altri) Libertà 3 : Migliorare il programma e distribuire i miglioramenti a beneficio della comunità. (Modificare il codice e passarlo agli altri) Un software può essere distribuito gratuitamente ma non rispettare nessuna delle 4 libertà, come succede in molti casi di software proprietario distribuito senza costi. Al contrario del software libero che anche se venduto commercialmente chi lo acquista è obbligato a mantenere intatte queste 4 libertà. Sant’IGNUcius il suo Alter Ego giocoso Da anni Richard Stallman presenta conferenze dove divulga il verbo del software libero. E in particolare modo chiunque usi il termine “ open source ” al posto di “free software” viene subito richiamato all’ordine. Leggenda narra che in una conferenza, mentre veniva presentato da un docente di una famosa università statunitense come esperto di open source, Stallman balzò in piedi precisando che lui si occupava di software libero e non di altri movimenti. Ma a queste conferenze non mancano ironia e momenti iconici. A un certo punto della serata tira fuori da una busta un vecchio disco magnetico e se lo mette in testa: la luce dei riflettori lo trasforma in un’aureola perfetta. Indossa poi una tonaca nera e si presenta al pubblico come “ San IGNUcius della Chiesa di Emacs ”, alzando la mano destra in un gesto di benedizione scherzosa: “Benedico il tuo computer, figlio mio”. Lo stesso Stallman racconta sul proprio sito di aver ideato il personaggio nel 1996, come modo per “prendersi gioco di sé stesso” senza prendersi troppo sul serio. Stallman è anche conosciuto per la sua avversione alla stupidità e alle cerimonie, è risaputo che se qualcuno fa qualcosa di stupido non esita a rinfacciarglielo. San IGNUcius della Chiesa di Emacs Il trionfo silenzioso Torniamo ai primi anni Novanta. Il sistema GNU ha quasi tutti i pezzi al loro posto, ma gli manca un cuore pulsante. Il kernel HURD è in ritardo cronico. A togliere le castagne dal fuoco ci pensa, nel 1991, un giovane studente finlandese: Linus Torvalds Sforna il kernel Linux e, nel 1992, decide di pubblicarlo sotto la licenza GPL di Stallman: da lì succede l’imprevedibile. L’unione degli attrezzi di GNU con il motore di Torvalds fa nascere il sistema GNU/Linux. Quello che era partito come un mix tra idealismo radicale e l’hobby di un universitario, oggi tiene letteralmente in piedi il mondo digitale. Non ci credete? Guardatevi attorno. I 500 supercomputer più potenti della Terra usano Linux. I server di Hollywood che renderizzano gli effetti speciali? Linux. Perfino l’elicotterino Ingenuity della NASA, che ha svolazzato su Marte, ha dentro un’anima Linux. E poi, ovviamente, c’è Android. Nel 2005 Google si compra l’omonima startup, infilando di fatto un derivato di Linux nelle tasche di oltre tre miliardi di esseri umani. Ed è qui che si consuma il cortocircuito finale, la firma del vero hacker. A fronte di questo trionfo planetario del suo software, oggi Stallman si rifiuta di toccare uno smartphone. Per lui non sono altro che dispositivi di sorveglianza di massa da portare a passeggio, macchine pensate per tracciare la gente tramite software chiuso. E nel 2026? A gennaio 2026 Stallman era ad Atlanta, al Georgia Institute of Technology . Cinquanta minuti di conferenza, poi un’ora e mezza di domande. Stesso copione di sempre tranne il nemico, che stavolta ha un nome nuovo. L’intelligenza artificiale. O meglio: la “Pretend Intelligence”. Perché chiamarla “intelligente”, ragiona lui, è già cedere terreno. È comprare la réclame. È convincersi che queste macchine capiscano qualcosa mentre generano testo e basta, senza sapere cosa significa. Nel medesimo intervento ha allargato il tiro: auto connesse, backdoor nei processori, dispositivi che il produttore può spegnere da remoto con un aggiornamento. Roba che conosce bene. La logica è identica a quella della stampante Xerox: qualcuno, da qualche parte, tiene le chiavi di casa tua. Tu pensi di possedere qualcosa. Non è così. La differenza tra il 1982 e il 2026? La scala. E il fatto che adesso ci si casca in tre miliardi. Vintage C’è chi, come chi vi scrive, ricorda ancora l’odore dei laboratori informatici universitari: ventole che ronzavano a tutte le ore, e un prompt che aspettava paziente il comando gcc . Per intere generazioni di matricole, imparare il C non significava aprire un ambiente di sviluppo blasonato, ma aprire un editor spartano e invocare quel compilatore nato nel 1987 dalle mani e dalla testardaggine di Richard Stallman: il primo compilatore ANSI C ottimizzante e portabile distribuito come software libero, capace persino di ricompilare sé stesso. Il C, si diceva nei corsi, dava accesso diretto alla memoria della macchina. Un privilegio che si pagava a caro prezzo, come in uno dei tanti casi capitati al chi scrive e ai suoi colleghi di corso che, a ricevimento dal professore, si scontravano con il prodotto tra una matrice e un vettore a colpi di segmentation fault e di notti passate a inseguire un puntatore impazzito con gdb . Ma proprio in quella fragilità, in quel dover capire davvero cosa succedesse sotto il cofano, si nascondeva il fascino: GCC non nascondeva nulla, e nemmeno pretendeva di farlo. Era la prova tangibile che un’idea nata nel 1984 dal progetto GNU la libertà di usare, studiare, modificare e condividere il software potesse reggere il confronto, e spesso vincerlo, con i compilatori commerciali del tempo. Ogni errore di compilazione portava con sé quella strana familiarità con una macchina che sembrava, in fondo, condividere gli stessi principi di chi l’aveva creata. Anni dopo, Richard Stallman fu ospite d’onore in un congresso organizzato a Napoli dall’Università Federico II: un evento al quale il sottoscritto non ebbe il tempo di partecipare. Con grande, grandissimo rammarico. Fonti Sam Williams e Richard M. Stallman, Free as in Freedom 2.0: Richard Stallman and the Free Software Revolution (Free Software Foundation, 2010), distribuito sotto licenza GNU Free Documentation License. Capitolo 3: oreilly.com/openbook/freedom/ch03.html — Capitolo 7: oreilly.com/openbook/freedom/ch07.html Michael Gross, “Richard Stallman: High School Misfit, Symbol of Free Software, MacArthur-Certified Genius”: mgross.com/books/my-generation/my-generation-bonus-chapters/richard-stallman-high-school-misfit-symbol-of-free-software-macarthur-certified-genius/ Richard Stallman, “Saint IGNUcius”, pagina ufficiale dell’autore: stallman.org/saint.html — foto e video, categoria “Saint IGNUcius” su Wikimedia Commons (licenze CC-BY / CC-BY-SA): commons.wikimedia.org/wiki/Category:Saint_IGNUcius Judy Steed, Toronto Star, sezione Business, 9 ottobre 2000, p. C03 (per la citazione ‘sull’orlo dell’autismo’).” manca la precisazione concordata: “Articolo cartaceo, non disponibile in archivio digitale libero. Riferimento bibliografico verificato in: Sam Williams, Free as in Freedom, cap. 3, nota 3. Wikipedia, voce “Richard Stallman” (riferimento pubblico aggiuntivo per il dettaglio del manuale IBM 7094): en.wikipedia.org/wiki/Richard_Stallman Copertura giornalistica indipendente del discorso di Stallman al Georgia Institute of Technology, 23 gennaio 2026, tra cui Slashdot, Hardware Upgrade e Rivista AI. L'articolo RMS: l’Eretico del codice. L’uomo della rivoluzione partita da una stampante rotta proviene da Red Hot Cyber .

Microsoft Entra ID is removing an extra MFA hurdle for Windows Hello and macOS PSSO users Microsoft is changing how Entra ID handles MFA for people who sign in with Windows Hello for Business (WHfB) or macOS Platform Single Sign-On (PSSO). The rollout reaches worldwide and GCC tenants starting early October 2026, with completion expected by late November. Microsoft says the change “helps organizations expand the use of phishing-resistant authentication methods” and cuts reliance on weaker ones, according to an update tracked as MC1450134 in the Microsoft 365 Message Center Archive. Both methods can already satisfy MFA requirements during primary sign-in. Users can still be asked to register and use another authentication method when they encounter certain step-up MFA prompts, Authentication Strength policies, or sign-in frequency checks. Once the rollout lands, WHfB and macOS PSSO will satisfy these MFA requirements without registering an additional passkey. Users who rely on WHfB or macOS PSSO as their only registered MFA method will also be considered MFA-capable. Entra ID will stop prompting password users to register another MFA method when WHfB or macOS PSSO is already registered as their MFA credential. There is one issue worth flagging. WHfB and macOS PSSO credentials are bound to a device, which means users may be unable to complete an MFA challenge from another device where the credential is unavailable. Microsoft recommends that users register a portable MFA method for these situations, such as a synced passkey or a passkey stored in Microsoft Authenticator. No configuration changes are required for the rollout, which is good news for admins. Organizations should still review onboarding and MFA registration processes, as well as Authentication Strength policies, before deployment.

Proof of Concept Background: Cos’è libblkid? libblkid è la libreria di probing per partizioni e filesystem al cuore dello stack storage di Linux. È il componente che risponde alla domanda “cosa c’è su questo block device?” — e viene invocata ovunque: inserimento USB → udev → udisks2 → libblkid → “ha una partizione ext4” ↓ automount / mkfs / fsck Ogni volta che Linux processa un nuovo disco — dall’inserimento di una chiavetta USB all’analisi di un’immagine disco di una VM — libblkid legge le tabelle delle partizioni e registra ciò che trova. La vulnerabilità risiede nel parser degli Extended Boot Record (EBR), utilizzato per gli schemi di partizione MBR con più di 4 partizioni. Il Codice Vulnerabile libblkid/src/partitions/dos.c, funzione parse_dos_extended(). Questa funzione viene chiamata per ogni partizione estesa in un layout MBR, percorrendo la catena di EBR che descrivono le partizioni logiche (partizioni 5+). static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, uint32_t ex_start, uint32_t ex_size, uint32_t cur_start, uint32_t cur_size){ /* ... */ for (p = p0, i = 0; i = 2) { /* (3) guard SOLO per i≥2 */ if (start + size > cur_size) continue; if (abs_start ex_start + ex_size) continue; } if (blkid_partlist_get_partition_by_start(ls, abs_start)) continue; par = blkid_partlist_add_partition(ls, tab, abs_start, size); /* SINK */ Tre osservazioni dalla lettura del codice: 1: dos_partition_get_start(p) legge un valore little-endian a 32 bit direttamente dal buffer del disco — completamente controllato dall’attaccante. 2: abs_start = cur_start + start è un’addizione uint32_t non verificata. In C, l’aritmetica su interi senza segno è modulo 2³², quindi se la somma supera 0xFFFFFFFF si azzera silenziosamente — nessuna eccezione, nessun warning, nessun UB. 3: Il blocco if (i >= 2) contiene i bounds check che avrebbero intercettato questo problema — ma si applicano solo alla terza e quarta entry dell’EBR. Le prime due entry (la partizione dati e il puntatore al prossimo EBR) vengono elaborate senza alcun controllo. La Matematica Impostando cur_start = 2 (il settore EBR, un valore legittimo comune) e artefando la prima entry dell’EBR con lba_start = 0xFFFFFFFE: abs_start = (uint32_t)(cur_start + start) = (uint32_t)(2 + 0xFFFFFFFE) = (uint32_t)(0x100000000) ← supera il range uint32 = 0x00000000 ← wrap al settore 0 dell'MBR Il valore 0x00000000 viene passato a blkid_partlist_add_partition() come inizio della partizione. libblkid ora ritiene che esista una partizione da 128 KB che inizia al primo settore del disco — l’MBR. Costruzione dell’Immagine Artefatta L’immagine disco artefatta è un file da 4 KB. L’MBR all’offset 0 contiene una entry di partizione estesa standard che punta al settore 2. L’EBR al settore 2 contiene una entry di partizione con lba_start = 0xFFFFFFFE e lba_size = 0x100. import struct, sysdef write_le32(val): return struct.pack(' UINT32_MAX - cur_start) { DBG(LOWPROBE, ul_debug("#%d: EBR start overflow -- ignore", i + 1)); continue;} Il maintainer upstream Karel Zak ha accettato la segnalazione ma ha implementato un fix significativamente più robusto che affronta la causa radice in modo più completo. La sua analisi ha correttamente identificato che il problema non era soltanto l’overflow aritmetico, ma l’assenza totale di una validazione corretta dei bounds per le entry EBR — il codice era debole nel non garantire che i dati EBR rimanessero all’interno dell’area della partizione estesa master. Il fix upstream (firmato da Karel Zak, Reported-by: Michele Piccinni) affronta tre problemi distinti: Fix 1 — Aritmetica a 64 bit elimina il wraparound alla radice Invece di un guard preventivo, l’addizione viene promossa a uint64_t, rendendo fisicamente impossibile l’overflow: uint64_t ex_end = (uint64_t) ex_start + ex_size; /* nuovo: boundary area */...uint64_t abs = (uint64_t) cur_start + start; /* nuovo: addizione 64-bit */abs_start = (uint32_t) abs; /* cast sicuro dopo validazione */(uint64_t)(2 + 0xFFFFFFFE) = 0x100000000 — nessun wraparound. Il valore viene poi validato prima di essere troncato di nuovo a uint32_t. Fix 2 — Bounds check unificato per TUTTE le entry EBR Il codice originale applicava i bounds check solo per gli indici di loop i >= 2. Le entry i=0 e i=1 venivano elaborate senza alcuna validazione. Il fix applica un unico bounds check a tutte e quattro le entry in modo uniforme: /* la partizione dati deve essere all'interno dell'area estesa — per TUTTI i */if (abs ex_end) { DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside " "extended -- ignore", i + 1)); continue;} Questa è la soluzione architetturalmente corretta: qualsiasi partizione dati EBR, per definizione, deve risiedere all’interno dei confini della partizione estesa master. La precedente distinzione i >= 2 era logicamente ingiustificata. Fix 3 — Validazione della chain EBR Il fix rafforza anche l’attraversamento della chain EBR (il processamento del puntatore al prossimo EBR), impedendo link all’indietro e navigazione fuori dai limiti: uint64_t next = (uint64_t) ex_start + start;if (next + size > ex_end) { DBG(LOWPROBE, ul_debug("EBR link outside extended area -- leave")); goto leave;}if (next ex_end) {+ DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside "+ "extended -- ignore", i + 1));+ continue;+ }+ abs_start = (uint32_t) abs;+ if (i >= 2) { if (start + size > cur_size) continue;- if (abs_start ex_start + ex_size)- continue; }@@ -142,8 +150,22 @@ static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, if (i == 4) goto leave;- cur_start = ex_start + start;- cur_size = size;+ {+ uint64_t next = (uint64_t) ex_start + start;++ if (next + size > ex_end) {+ DBG(LOWPROBE, ul_debug("EBR link outside "+ "extended area -- leave"));+ goto leave;+ }+ if (next = 2 esiste come ulteriore sanity check per i casi anomali; non era mai stato pensato come confine di sicurezza per le prime due entry. Una Vulnerabilità Presente da 17 Anni Uno degli aspetti più significativi di questo finding è la sua longevità. Il file dos.c che contiene parse_dos_extended() reca nel copyright header: Copyright (C) 2009 Karel Zak Il codice vulnerabile — l’addizione uint32_t senza overflow guard alla riga 96 — è presente sin dalla prima scrittura del file nel 2009, quando Karel Zak estese libblkid per supportare il probing delle tabelle delle partizioni in util-linux-ng 2.17. La vulnerabilità è sopravvissuta intatta per 17 anni attraverso decine di release, centinaia di commit e un’intera generazione di aggiornamenti di distribuzione. Nel 2016, CVE-2016-5011 aveva già portato attenzione proprio su parse_dos_extended(), identificando un bug di loop infinito nella stessa funzione. Quel fix ha aggiunto un check per i duplicati (riga 112), ma non ha toccato il codice di addizione aritmetica a riga 96. Due bug distinti, stessa funzione, a 7 anni di distanza. Perché è sopravvissuta così a lungo? La risposta è nella natura stessa del bug: l’overflow uint32_t è comportamento definito in C (standard ISO/IEC 9899:2018 §6.2.5). Non è undefined behaviour, non è un errore di compilazione, non è un warning con -Wall o -fanalyzer. Il codice è sintatticamente corretto, semanticamente sbagliato. Solo un checker taint-aware come Coverity o Clang alpha.security.taint — strumenti non tipicamente integrati nelle CI pipeline dei progetti open source — riesce a tracciare il percorso da un byte letto dal disco fino al suo utilizzo come indice critico senza sanitizzazione. Questa combinazione, vecchio codice, bug definito ma semanticamente errato, assenza di strumenti taint-aware nella CI, è esattamente il profilo delle vulnerabilità che rimangono nascoste per decenni in componenti critici di infrastruttura.

Spotless compliance evidence can still hide a broken control In this interview with Help Net Security, Marc Rubbinaccio, Head of Cybersecurity and Compliance at Secureframe, explains where security teams go wrong when preparing for CMMC and FedRAMP 20x. The conversation covers how organizations check the 110 requirements but miss the 320 assessment objectives beneath them, why spotless SOC 2 evidence can hide a broken control, and how continuous monitoring is changing compliance work. It also includes advice for junior practitioners on AI and practical moves a mid-market defense supplier can use to get ready for a CMMC Level 2 assessment on a tight budget. Walk me through the last time you watched a security team try to map an existing control set onto a CMMC or FedRAMP 20x requirement and realized the mapping was a fiction. What did the room look like, and what did you change after that? CMMC is based on NIST 800 171r2 which not only has 110 requirements but within those high level requirements are 320 assessment objectives. This is where I have seen organizations assume preparedness through the 110 requirements, without understanding how deep the assessment objectives go. When organizations are comparing current control sets and other frameworks to NIST 800 171, I have noticed that organizations assume intent of the high level requirement when in reality it’s important to map controls to the underlying assessment objectives themselves. AC.L2-3.1.1 says limit system access, but the objectives underneath ask whether authorized users are identified, whether processes acting on behalf of users are identified, whether devices are identified, etc. Teams will check the top-level box and miss three of the four objectives. FedRAMP 20x KSIs are not like your typical controls in standard information security frameworks, it is focused on outcome and objective instead of specific implementation. This means a FedRAMP KSI could map across multiple internal controls a company has implemented. Pick one client engagement where the compliance evidence looked spotless on paper but the underlying control was broken. How was it discovered, and who caught it first, the auditor, the red team, or an incident? The pattern I see most often is during SOC 2 Type 2 audits, and it can show up in access reviews. The policy could be written with the proper processes and procedures, quarterly reviews, manager attestation, evidence retained. The Secureframe platform is then wired to send reviewers reminders, and the reminders get acknowledged. What auditors find during sampling is that the same approver has been clicking ‘approved’ across multiple cycles without actually opening the user list. The policy says reviews happened. The platform says reviews happened. The control, meaningful human judgment about access, is broken. It’s almost always the auditor who catches it, not the customer, and usually when asking about the review itself or catching a mistake in the evidence. FedRAMP 20x is leaning hard into continuous monitoring and machine-readable artifacts. What does your team do on a Tuesday morning that a FedRAMP 20x environment makes obsolete, and what new muscle have you had to build? The Tuesday morning task that FedRAMP 20x makes obsolete is the manual evidence gathering routine. For years compliance teams would start the week by emailing infrastructure administrators for current server inventories, requesting user access lists from each application owner, and dropping the results into spreadsheets to review. I’ve been moving customers away from this since 2020 through automated tests and integrations, and FedRAMP 20x now formalizes that expectation. Inventory pulls, user access reviews, configuration checks, and control evidence are produced continuously by the platform rather than pulled together by administrators prior to audit. The biggest change is in how validations are designed. Traditional control testing asks whether a setting is enabled, true or false. FedRAMP 20x KSIs are outcome focused, which means it is not enough to show that encryption at rest is turned on or that MFA is configured. The validation needs to demonstrate that the outcome is actually occurring on a continuous basis, including how often the control fires, what happens when it fails, and how the evidence is presented in a machine readable format that agencies can consume directly. Building that capability requires our team to think less like auditors confirming a checkbox and more about how each KSI can be measured continuously, mapped clearly to underlying controls, and surfaced in a way that supports the persistent validation model FedRAMP is moving toward. What is the worst piece of advice junior practitioners are getting right now from LinkedIn thought leaders about AI in security operations, and what do you tell them instead when they show up at your door? The worst advice circulating on LinkedIn right now is that AI is going to handle the fundamentals of cybersecurity, instead of learning the fundamentals of security and compliance work, learn how to use AI. Usually posts are stating how AI can write policies, write reports, map controls to frameworks, but the importance of reviewing and having the expertise is extremely understated. The AI can be often wrong, and how can you determine when it is right or wrong without the underlying experience. AI in security operations sits in the middle of the two extremes you see online. AI is not taking every job and it is not useless. It is genuinely advancing capabilities on both the defender and attacker sides, vulnerability detection and exploit generation included, but it is also expensive to run and generates a significant volume of false positives that still require human judgment to sift through. To get real value from AI in a security or compliance context you need enough domain expertise to know when the model is wrong, which means the fundamentals matter more now, not less. What I tell junior practitioners who ask is to invest first in learning the frameworks, the control objectives, and how organizations need to meet these controls in the real work, and to treat AI as something that accelerates that work rather than replaces the need to understand it. The people who will be valuable in this field over time are the ones who can look at an AI generated finding, an AI drafted policy, or an AI suggested control mapping and tell you confidently whether it is right, partially right, or wrong. For a mid-market defense supplier staring down a CMMC Level 2 assessment in the next nine months with a small team and a tight budget, what are the two or three moves you have seen work that are not in any of the official guidance documents? The most important thing is not to wait. CMMC is complex from readiness through assessment, and starting early is what gives you the runway to scope your environment properly and bring in the expertise you need to hit your target certification timeline. The first step is understanding exactly where your sensitive data and CUI live. Once you know where CUI is stored, processed, transmitted, and ingested, you can make deliberate decisions about where to limit it. The key to a manageable CMMC effort is scoping in as little as possible. A small environment, or an enclave dedicated to CUI and in-scope assets, will save you significant pain during both readiness and audit compared to trying to bring an entire corporate environment into scope. The second step is configuration. Working with a provider that knows CMMC well is critical because choosing an enclave platform like GCC High or Google Workspace will not automatically get you CMMC compliant. Those platforms give you the foundation, but the systems inside them still need to be configured against the 110 requirements and the 320 underlying assessment objectives. Organizations that assume the platform does the work for them are the ones that struggle most during assessment. The third step is choosing the right assessor. Having early conversations with C3PAOs in the industry about your environment, your scope, and your timeline will help you identify which assessors are most experienced with services and architectures similar to yours. An assessor who has worked with environments like yours will move faster and ask sharper questions than one who has not, and that difference shows up directly in how smoothly the assessment runs. Download: Simplify security management with CIS SecureSuite Platform

Rilevate vulnerabilità in prodotti GIGABYTE Alert AL02/260402/CSIRT-ITA Sintesi Rilevate due vulnerabilità con gravità “alta” nel prodotto GIGABYTE Control Center (GCC) e in una sua componente interna, la Performance Library, sfruttabile tramite il servizio EasyTune Engine. Tali vulnerabilità, qualora sfruttate, potrebbero permettere a un utente malintenzionato di scrivere file arbitrari sul filesystem, elevare i propri privilegi ed eseguire codice arbitrario sui sistemi interessati. Tipologia Arbitrary File Write Privilege Escalation Arbitrary Code Execution Prodotti e/o versioni affette GIGABYTE Control Center (GCC), versione 25.07.21.01 e precedenti EasyTune Engine, versioni precedenti alla 25.12.31.01 Azioni di mitigazione In linea con le dichiarazioni del vendor, si raccomanda di aggiornare i prodotti vulnerabili seguendo le indicazioni dei bollettini di sicurezza riportati nella sezione Riferimenti.

The GIGABYTE Control Center is vulnerable to an arbitrary file-write flaw that could allow a remote, unauthenticated attacker to access files on vulnerable hosts. The hardware maker says that successful exploitation could potentially lead to code execution on the underlying system, privilege escalation, and a denial-of-service condition. The GIGABYTE Control Center (GCC), which comes pre-installed on all the company’s laptops and motherboards, is GIGABYTE’s all-in-one Windows utility that lets users manage and configure their hardware. It supports hardware monitoring, fan control, performance tuning, RGB lighting control, driver and firmware updates, and device management. A feature in the Control Center is “pairing,” which allows the tool to communicate with other devices or services over the network. Systems with the 'pairing' option enabled on Control Center versions 25.07.21.01 and earlier are exposed to attacks. “When the pairing feature is enabled, unauthenticated remote attackers can write arbitrary files to any location on the underlying operating system, leading to arbitrary code execution or privilege escalation,” warned Taiwan’s CERT. The issue, tracked as CVE-2026-4415, was discovered by security researcher David Sprüngli. Based on the CVSS v4.0 scoring system, the issue has a critical severity rating (9.2 out of 10). Users are recommended to upgrade to the latest version of Control Center, currently 25.12.10.01, which includes fixes for download path management, message processing, and command encryption to effectively mitigate the vulnerability. “Customers are strongly advised to upgrade to the latest GCC version immediately,” the vendor warns in the security bulletin. It is recommended that users of GIGABYTE products download the latest GCC version from the vendor’s official software portal to minimize the risk of receiving trojanized installers. BleepingComputer has contacted both GIGABYTE to learn more about CVE-2026-4415, but we did not receive a response by publishing time. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Secureframe automates CMMC compliance with secure infrastructure and AI SSPs Secureframe has launched Secureframe Defense, an end-to-end solution for CMMC certification. It provides secure infrastructure deployment, AI-generated System Security Plans (SSPs), policies, and comprehensive monitoring that Defense Industrial Base (DIB) organizations need to achieve and maintain certification faster, without unnecessary cost or complexity. With CMMC enforcement underway, readiness across the DIB remains critically low. The Department of Defense (DoD) estimates nearly 80,000 organizations will ultimately require CMMC Level 2 certification, yet fewer than 800 organizations—less than 1%—have achieved certification as of January 2026. Research indicates that most DIB organizations spend over a year and $100K–$300K or more preparing for CMMC Level 2 certification by a Certified Third-Party Assessment Organization (C3PAO). Meanwhile, 47% of contractors have already received flow-down requests from prime contractors requiring proof of certification, making readiness urgent for subcontractors at every tier. “Secureframe Defense reflects everything we learned going through our own CMMC Level 2 assessment and the feedback we received from our partner C3PAOs about the real problems organizations face,” said Shrav Mehta, CEO of Secureframe. “Our AI-powered platform can take organizations with zero infrastructure to assessment-ready in less than 8 weeks.” From zero to CMMC ready with Secureframe Secureframe Defense guides organizations through three critical stages: Stage 1: Deploy secure CUI environments in minutes Traditional enclave deployments typically take 8–10 weeks and require significant resources from internal IT teams or consultants. With Secureframe, teams can stand up a CMMC-compliant enclave in under 30 minutes. The Secureframe platform automatically configures Google Workspace or Microsoft GCC High with all required CMMC controls, including access control, logging and monitoring, and security event notifications, to isolate CUI. Organizations can then auto-provision secure Azure virtual desktops for CUI access in minutes, or use a FedRAMP Moderate authorized, pre-configured device management solution to enforce CMMC baselines across their fleet of laptops and workstations. Stage 2: Document and manage your cybersecurity program Turn the CMMC requirements into an AI-guided implementation workflow with Defense Navigator. After configuring your scope, integrations, and enclave, Secureframe’s AI engine generates SSPs and policies tailored to your exact environment. Built-in modules cover risk assessments, vendor reviews, policy assignments, and security awareness training, with continuous monitoring to flag controls the moment they fall out of compliance. Stage 3: Get and stay CMMC certified Secureframe’s Audit Module packages documentation and evidence artifacts automatically for efficient C3PAO review, reducing manual evidence collection and long assessment timelines. Organizations also gain access to the Secureframe network of vetted CMMC Registered Practitioners who can provide additional guidance and a network of vetted C3PAO partners experienced with the platform to complete your assessment. Months saved, hundreds of hours recovered Secureframe Defense reduces overall certification timelines from 12-18 months down to 4-8 weeks, cutting readiness time significantly compared to manual processes or point solutions. Manufacturing Consulting Company, a defense contractor supporting U.S. Air Force programs, significantly reduced the operational complexity of documenting and monitoring compliance with Secureframe and passed their CMMC Level 2 assessment months before the Phase 1 deadline. “Using Secureframe to get NIST 800-171 and CMMC compliant saved us at least 500 hours,” said David Hoenisch, Lead Cybersecurity Engineer at Manufacturing Consulting Company. “Having a tool that can come alongside and augment your personnel force is a huge blessing. It was a weight off our shoulders.” “Everyone in the defense tech space has to be compliant, but many are relying on manual processes. It’s the peace of mind that Secureframe provides, the continuous monitoring, the fact that we have a system as opposed to a person trying to manage and ensure all of this – that’s the value add for us,” said Stephanie Castro, Director of Operations, Adyton.

Microsoft is rolling out passkey support for Microsoft Entra on Windows devices, adding phishing-resistant passwordless authentication via Windows Hello. The feature is opt-in and will enter public preview from mid-March through late April 2026 for worldwide tenants. Government cloud environments (GCC, GCC High, and DoD) follow with mid-April through mid-May rollout windows. Notably, this also extends passwordless sign-in to unmanaged Windows devices, a gap that previously left personal and shared devices relying on password-based authentication. "We're introducing Microsoft Entra passkeys on Windows to enable phishing-resistant sign-in to Entra-protected resources. This update allows users to create device‑bound passkeys stored in the Windows Hello container and authenticate using Windows Hello methods (face, fingerprint, or PIN)," Microsoft explains on the Microsoft 365 message center. "It also expands passwordless authentication to Windows devices that aren't Entra‑joined or registered, helping organizations strengthen security and reduce reliance on passwords." The generated passkeys are cryptographically bound to the device and never transmitted over the network, so threat actors can't steal them in phishing or malware attacks to circumvent multi-factor authentication. Microsoft added that each Entra account will register its own passkey per device, and multiple accounts can coexist on a single machine. However, passkeys are device‑bound and cannot be synced across devices, so each Entra account will require separate registration. To enroll in the public preview, IT administrators must enable the Passkeys (FIDO2) authentication method in Entra's Authentication Methods policies, create a passkey profile with the required Windows Hello AAGUIDs, and assign it to the appropriate groups. "Windows Hello for Business remains recommended for managed, Entra‑joined or registered devices; passkeys supplement unmanaged device scenarios and do not support device sign‑in," Microsoft noted. "Users can’t register a passkey on Windows if a Windows Hello for Business credential already exists for the same account and container. This block may not apply once the user exceeds 50 total credentials across passkeys (FIDO2), Windows Hello for Business, and Mac Platform Credentials." Microsoft announced in May 2025 that all new Microsoft accounts will be "passwordless by default" to secure them against phishing, brute-force, and credential-stuffing attacks. One year earlier, it rolled out support for passkey authentication for personal Microsoft accounts, after adding a built-in passkey manager for Windows Hello with the Windows 11 22H2 feature update. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Microsoft says Teams will soon automatically tag third-party bots in lobbies, allowing organizers to control whether they can join meetings. As detailed in a new Microsoft 365 roadmap entry, the feature is currently in development and scheduled to roll out in May 2026. When it reaches general availability, it will be available across Windows, macOS, Android, and iOS platforms for worldwide standard multi-tenant and GCC cloud environments. After the rollout, external third-party bots attempting to join a Teams meeting will be distinctly labeled in the lobby rather than blending in with human participants. Organizers will then have to explicitly allow the bot to join the meeting, ensuring it cannot be accidentally accepted alongside a group of human attendees. "During Teams meetings, if there is an external 3P bot trying to join the meeting, organizers will be able to see a clear representation of the bots while they wait in the lobby. Organizers will be required to explicitly and separately admit these bots into the meeting, if really required," Microsoft said. "This approach will ensure that no one inadvertently accepts the external bots into the meeting ensuring that the organizers have full control over the presence of these bots." The change ensures that malicious apps controlled by threat actors or third-party bots (used for note-taking, transcription, or other automated tasks) cannot join Teams meetings without attendees realizing that a non-human participant has been added. In January, Microsoft announced that Teams will get a call reporting feature by mid-March, allowing users to flag suspicious or unwanted calls as potential scams or phishing attempts. Teams has also added new fraud-protection features for calls, warning users about external callers impersonating trusted organizations in social-engineering attacks. Starting in December, admins can block external Teams users via the Defender portal to thwart cybercrime gangs(including ransomware groups) that attempt to abuse the video conferencing and collaboration platform in social engineering attacks targeting victims' employees. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

OpenWrt 25.12.0 ships with new package manager, built-in upgrade tool, support for 2200+ devices OpenWrt 25.12.0 is now available for download. The release incorporates over 4,700 commits since branching from OpenWrt 24.10. Package manager changes One of the most significant structural changes in 25.12.0 is the replacement of the opkg package manager with apk, the Alpine Package Keeper. The OpenWrt fork of opkg is no longer maintained, and the project moved to apk as an actively maintained alternative. The command-line interface for apk differs from opkg, and the project has published an opkg-to-apk cheatsheet for users managing existing systems. Most package names remain the same, with only a small number changing. Attended sysupgrade now installed by default The attended sysupgrade (ASU) application is now included in default LuCI installations. On devices with larger flash storage, the owut command-line upgrade tool is also included by default. ASU enables users to upgrade firmware while retaining installed packages and configuration. It does this by submitting the list of installed packages to a build server, which assembles a custom firmware image with those packages baked into the SquashFS filesystem. This stores packages more compactly than the overlay filesystem method. Three clients are available for running ASU: the web-based Firmware Selector, the LuCI Attended Sysupgrade interface, and owut for command-line use. Shell history stored in RAM Shell command history is now preserved across sessions using a RAM-backed filesystem. Prior to this change, history was lost between logins. The default configuration avoids writing history to flash storage, which reduces write cycles on devices with limited flash endurance. Users who want persistent history storage can change the behavior by editing /etc/profile.d/busybox-history-file.sh. Wi-Fi management scripts rewritten in ucode The Wi-Fi scripts have been rewritten in ucode, continuing a broader effort to replace shell scripts in OpenWrt’s management layer. The project uses ucode for system scripts because it runs faster and has fewer error-prone behaviors than shell scripts, and it integrates directly with the ubus messaging system and UCI configuration interface. Device and hardware support OpenWrt 25.12.0 supports over 2,200 devices in total, adding support for over 180 devices that were not supported in 24.10. New hardware targets include: The siflower target for Siflower SF21A6826 and SF21H8898 SoCs The sunxi/arm926ejs subtarget for Allwinner F1C100 and F1C200s SoCs The microchipsw/lan969x target for Microchip LAN969x switches Extended support in the realtek target, covering 10G Ethernet switch SoCs Extended support in the qualcommax target for ipq50xx and ipq60xx SoCs Core component versions The 25.12.0 release ships with Linux kernel 6.12.71 across all targets. The toolchain includes gcc 14.3.0, binutils 2.44, musl libc 1.2.5, and glibc 2.41. Key package versions include dnsmasq 2.91, dropbear 2025.89, busybox 1.37.0, and a hostapd master snapshot from August 2025. The cfg80211/mac80211 wireless stack is drawn from kernel 6.18.7. Known issues Two Wi-Fi interoperability problems are documented at release. Pixel 10 phones have difficulty connecting to WPA3-protected Wi-Fi 6 access points. Separately, enabling 802.11r Fast Transition causes connectivity problems with some Wi-Fi clients when WPA3 is in use. Both issues are tracked in the project’s GitHub issue tracker. Users of Zyxel EX5601-T0 devices need to verify WAN interface configuration, as the port was renamed from eth1 to wan. End-of-life timeline for 24.10 With the 25.12.0 stable release, the 24.10 series enters a six-month wind-down period. Security updates for OpenWrt 24.10 will end in September 2026. Direct sysupgrade from 23.05 to 25.12.0 is not officially supported.

Iran will “absolutely” respond to the US and Israeli air strikes with cyber-attacks against a wide range of targets in the Middle East and beyond, Google’s chief of cyber threat intelligence has warned. John Hultquist, chief analyst of Google Threat Intelligence Group (GTIG), made the comments at an event hosted by the Royal United Services Institute (RUSI) defense think tank in London. The discussion was intended to focus on the threat of Russian cyber sabotage in Europe, but sudden escalation of the conflict in the Middle East saw much of the conversation focus around Iran and Iranian cyber capabilities. Iran has long been classed as capable nation-state actor in cyberspace with a history of numerous cyber espionage and other malicious hacking campaigns against the West. Since the conflict started, Iran has retaliated with missile strikes against several of its neighbors – including Gulf Cooperation Council (GCC) members Qatar, Bahrain, Jordan, the United Arab Emirates (UAE) and Kuwait – all of which are home to US military bases. Hultquist believes that these countries will inevitably find themselves being targeted by “aggressive” cyber-attacks by Iran. “You’re not going to see some secret weapon; it won’t be very different from what we’ve seen going on for the last few years. What changes is the targeting,” he explained. “Previously, we were talking about the targeting of a small state with an incredibly mature security capability [Israel]. Now we’re talking about a host of other targets, who may not have the same maturity. What that means is that we’re going to be forced to secure a very different attack surface globally.” Hacktivist and Ransomware as a Front for Hostile State-Backed Cyber Action Speaking to Infosecurity, Hultquist explained that there have long been blurred lines between the Iranian state and Iranian cybercriminal and hacktivist groups. “They’re really good at playing in this foggy space,” he said. Hackers associated with the Iranian government have previously been accused of secretly working with ransomware groups to facilitate campaigns against organizations in the US. Hultquist also expects Iran to continue to deploy these arms-length operations in offensive cyber campaigns against their perceived enemies, some of which might not have as robust cyber defenses as Israel or the US. “I’m absolutely expecting attacks by hacktivist fronts that aren’t truly hacktivist fronts, that are just fronts for the Iranian Revolutionary Guard Corps (IRGC). And I’m expecting ransomware incidents that aren’t really ransomware incidents,” he said. “I’m expecting them in the US, GCC and anyone else who’s drawn Iran’s ire right now. Suddenly, they have a massive attack surface they can choose from, so they’re going to carry out those attacks,” Hultquist added. Following the escalation of the conflict in Iran and the surrounding region, The National Cyber Security Centre (NCSC) has urged organizations to take action to review their cybersecurity posture – especially if they have operations in the Middle East. “There is almost certainly a heightened risk of indirect cyber threat for those organisations and entities who have a presence, or supply chains, in the Middle East,” the alert by the agency warned.

Protectt.ai enhances AppProtectt with advanced RASP and AI-driven mobile threat protection Protectt.ai has launched the latest version of AppProtectt, its mobile application security solution featuring advanced Runtime Application Self-Protection (RASP) and AI-led behavioral monitoring. Protectt.ai works with leading banking, financial services, insurance, and digital-first enterprises to secure high-risk mobile applications against fraud, tampering, and emerging cyber threats. The latest release introduces enhanced runtime protection capabilities and intelligent, policy-driven controls designed to help organizations across the Middle East deliver secure, compliant, and resilient mobile app experiences. As mobile applications underpin digital banking, payments, insurance, and citizen services across the GCC, AppProtectt enables enterprises to strengthen trust, ensure regulatory alignment, and maintain application integrity across diverse device and network environments. “As mobile apps become the primary interface between enterprises and customers, security must evolve beyond static controls. The latest version of AppProtectt combines behavioral intelligence, adaptive runtime protection, and deep visibility to help organizations across the Middle East stay ahead of modern cyber threats while meeting stringent compliance and trust requirements,” said Manish Mimani, CEO, Protectt.ai. “The enhanced capabilities align with our objective of addressing evolving threats and enabling enterprises in the GCC to meet regulatory mandates for secure Mobile app usage. This next generation version is a strong testament to Protectt.ai’s commitment to safeguarding financial transactions and protecting customer data in the region,” Pushkar Singh, Country Head Middle East & Africa (MEA) region at Protectt.ai, added. Built for mobile-first enterprises, AppProtectt delivers multi-layered runtime protection that enables secure app operation across varied devices, networks, and user behaviors without compromising performance or user experience. Key enhancements include device integrity protection, behavioral monitoring, strengthened network and application-level safeguards, and dynamic policy-driven controls for both Android and iOS. These capabilities help enterprises detect anomalous behavior, prevent misuse, and enforce contextual security policies without requiring code changes. With growing focus on application-level security and data protection across the GCC, including expectations from local regulators, AppProtectt supports organizations through low-code integration, AI-driven fraud detection, comprehensive RASP capabilities, and compliance alignment, creating a resilient, self-defending mobile application environment.

Concentric AI releases Private Scan Manager for AWS GovCloud (US) Concentric AI announced further expansion of the Private Scan Manager functionality in its Semantic Intelligence AI and data security governance platform to include AWS GovCloud (US). Government agencies, contractors, partners, and other organizations—including those that use Microsoft 365 Government Community Cloud (GCC) High—which handle sensitive data and Controlled Unclassified Information (CUI) subject to stringent compliance requirements can now deploy Semantic Intelligence within their own isolated regions. This news follows two 2025 announcements by Concentric AI, which announced support for content scanning and categorization in both the Microsoft Azure and AWS private cloud environments. This functionality enables organizations that are required to process their data on premises to meet compliance standards while also benefiting from the advanced capabilities of Concentric AI’s AI and data security governance solution. AWS GovCloud (US) is a specialized cloud environment that meets federal security requirements by providing security beyond what is offered with standard commercial clouds. This includes personnel controls (US citizens only); physically and logically isolated private US sovereign regions; and compliance with standards such as FedRAMP, International Traffic in Arms Regulations (ITAR), and U.S. Department of Defense (DoD) Cloud Computing Security Requirements Guide (CC SRG) Impact Levels 2, 4, and 5 for unclassified data. Concentric AI’s Private Scan Manager for AWS GovCloud enables US government agencies, public sector entities, and contractors with highly regulated data that cannot leave their on-premises environments to leverage a leading AI and data security governance solution while ensuring compliance with elevated federal requirements. “With this support for private scanning within AWS GovCloud, organizations in the public sector can leverage our platform’s robust discovery, categorization, remediation, and GenAI data security capabilities to manage and secure their high-value, mission- and business-critical assets while ensuring data sovereignty,” said Dhruv Jhain, VP of Products at Concentric AI. “All data remains within the customer’s isolated cloud environment, which is operated by US citizens on US soil.” Semantic Intelligence redefines what’s possible in data security governance by serving as a single end-to-end platform to protect enterprise data wherever it lives and however it travels. This includes data at rest across cloud and on-premises environments; data in motion being emailed, uploaded to file sharing applications, and posted on social media; and across all the GenAI applications users interact with today. Instead of relying on rigid rules, keywords, or data samples, Semantic Intelligence uses its patented AI to understand the context behind both structured and unstructured data. This enables it to identify not only PII, PCI, and PHI with exceptional accuracy, but also sensitive information such as intellectual property and critical business documents that others may overlook. The result is stronger, more accurate classifications and access policies within the platform and across a customer’s security stack. Its category-aware DLP protects sensitive data from being leaked through email and GenAI applications while continuous risk monitoring and remediation ensure that excessive permissions; risky sharing; data that’s unclassified, misclassified, or in the wrong location; and anomalous behavior in relation to data are handled automatically. Concentric AI’s new Private Scan Manager for AWS GovCloud (US) is available now in the Semantic Intelligence platform.

Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione. Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica. C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale. Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/

Microsoft announced that the transcription, dictation, and read aloud features will stop working in older versions of Office 365 applications in late January 2026. Read aloud lets users hear documents and emails read back, transcription converts speech into text in real-time, and the dictation feature allows for voice-to-text input across Office applications. The company advised customers to update their Microsoft 365 Office apps to a version higher than 16.0.18827.20202 (released in early July) by the end of January 2026 to maintain access to these accessibility and productivity features. This deadline provides most organizations with approximately one year to plan and implement the necessary software updates across their environments. However, Redmond added that government cloud customers using GCC, GCC High, and DoD environments have two more months, until March 2026, to update their software. "To ensure continued high-quality performance of the Read Aloud, Transcription, and Dictation features in Microsoft 365 Office apps, we're upgrading the backend service that powers these capabilities," the company said in a Friday message center message. "As a result, these features will no longer function on Office clients running versions earlier than 16.0.18827.20202 after January 2026." The change stems from Microsoft's decision to upgrade the backend service that powers these voice-enabled capabilities. Users running Office clients with version numbers below the specified threshold will lose access to the features after the deadline. The company stated that Office clients running versions higher than 16.0.18827.20202 will not be affected by the infrastructure upgrade and will experience no changes to their current functionality. In May, Redmond also announced plans to end support for Office apps on Windows 10 later this year and that it will continue providing security updates for three more years, until 2028. One month earlier, in April, Microsoft reminded customers that Office 2016 and Office 2019 will reach the end of extended support two months from now, on October 14, 2025. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

A newly discovered Linux malware, which has evaded detection for over a year, allows attackers to gain persistent SSH access and bypass authentication on compromised systems. Nextron Systems security researchers, who identified the malware and dubbed it "Plague," describe it as a malicious Pluggable Authentication Module (PAM) that uses layered obfuscation techniques and environment tampering to avoid detection by traditional security tools. This malware features anti-debugging capabilities to thwart analysis and reverse engineering attempts, string obfuscation to make detection more difficult, hardcoded passwords for covert access, as well as the ability to hide session artifacts that would normally reveal the attacker's activity on infected devices. Once loaded, it will also scrub the runtime environment of any traces of malicious activity by unsetting SSH-related environment variables and redirecting command history to /dev/null to prevent logging, eliminating audit trails and login metadata, and erasing the attacker's digital footprint from system history logs and interactive sessions. "Plague integrates deeply into the authentication stack, survives system updates, and leaves almost no forensic traces. Combined with layered obfuscation and environment tampering, this makes it exceptionally hard to detect using traditional tools," threat researcher Pierre-Henri Pezier said. "The malware actively sanitizes the runtime environment to eliminate evidence of an SSH session. Environment variables such as SSH_CONNECTION and SSH_CLIENT are unset using unsetenv, while HISTFILE is redirected to /dev/null to prevent shell command logging." While analyzing the malware, the researchers also discovered compilation artifacts indicating active development over an extended period, with samples compiled using various GCC versions across different Linux distributions. Additionally, although multiple variants of the backdoor have been uploaded to VirusTotal over the past year, none of the antivirus engines have flagged them as malicious, suggesting that the creators of the malware have been operating undetected. "The Plague backdoor represents a sophisticated and evolving threat to Linux infrastructure, exploiting core authentication mechanisms to maintain stealth and persistence," Pezier added. "Its use of advanced obfuscation, static credentials, and environment tampering makes it particularly difficult to detect using conventional methods." In May, Nextron Systems discovered another malware exploiting the flexibility of the PAM (Pluggable Authentication Modules) Linux authentication infrastructure, which enables its creators to steal credentials, bypass authentication, and gain stealthy persistence on compromised devices. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report