Il 18 novembre 2025, alle 11:20 UTC, una parte significativa dell’infrastruttura globale di Cloudflare ha improvvisamente cessato di instradare correttamente il traffico Internet, mostrando a milioni di utenti di tutto il mondo una pagina di errore HTTP che riportava un malfunzionamento interno della rete dell’azienda.

L’interruzione ha colpito una vasta gamma di servizi – dal CDN ai sistemi di autenticazione Access – generando un’ondata anomala di errori 5xx. Secondo quanto riportato da Cloudflare che lo riporta con estrema trasparenza, la causa non è stata un attacco informatico ma un errore tecnico interno, scatenato da una modifica alle autorizzazioni di un cluster database.

Cloudflare ha precisato fin da subito che nessuna attività malevola, diretta o indiretta, è stata responsabile dell’incidente. L’interruzione, come riporta il comunicato di post mortem, è stata innescata da un cambiamento a un sistema di permessi di un database ClickHouse che, per un effetto collaterale non previsto, ha generato un file di configurazione anomalo utilizzato dal sistema di Bot Management.

Tale “feature file”, contenente le caratteristiche su cui si basa il modello di machine learning anti-bot dell’azienda, ha improvvisamente raddoppiato le sue dimensioni a causa della presenza di numerose righe duplicate.

Questo file, aggiornato automaticamente ogni pochi minuti e propagato rapidamente a tutta la rete globale di Cloudflare, ha superato il limite previsto dal software del core proxy, causando un errore critico.

Il sistema che esegue l’instradamento del traffico – noto internamente come FL e nella sua nuova versione FL2 – utilizza infatti limiti rigidi per la preallocazione di memoria, con un massimo fissato a 200 feature. Il file corrotto ne conteneva più del doppio, facendo scattare un “panic” del modulo Bot Management e interrompendo l’elaborazione delle richieste.

Nei primi minuti dell’incidente, l’andamento irregolare degli errori ha portato i team di Cloudflare a sospettare inizialmente un massiccio attacco DDoS: il sistema sembrava infatti riprendersi spontaneamente per poi ricadere nel guasto, un comportamento insolito per un errore interno.

Questa fluttuazione era dovuta alla natura distribuita dei database coinvolti. Il file veniva generato ogni cinque minuti e, poiché solo alcune parti del cluster erano state aggiornate, il sistema produceva alternativamente file “buoni” e file “difettosi”, propagandoli istantaneamente a tutti i server.

Nell blog si legge :

“Ci scusiamo per l’impatto sui nostri clienti e su Internet in generale. Data l’importanza di Cloudflare nell’ecosistema Internet, qualsiasi interruzione di uno qualsiasi dei nostri sistemi è inaccettabile. Il fatto che ci sia stato un periodo di tempo in cui la nostra rete non è stata in grado di instradare il traffico è profondamente doloroso per ogni membro del nostro team. Sappiamo di avervi deluso oggi“.

Con il passare del tempo, l’intero cluster è stato aggiornato e le generazioni di file “buoni” sono cessate, stabilizzando il sistema nello stato di errore totale. A complicare ulteriormente la diagnosi è intervenuta una coincidenza inaspettata: il sito di stato di Cloudflare, ospitato esternamente e quindi indipendente dall’infrastruttura dell’azienda, è risultato irraggiungibile nello stesso momento, alimentando il timore di un attacco coordinato su più fronti.

La situazione ha iniziato a normalizzarsi alle 14:30 UTC, quando gli ingegneri hanno individuato la radice del problema e interrotto la propagazione del file corrotto. È stato quindi distribuito manualmente un file di configurazione corretto e forzato un riavvio del core proxy. La piena stabilità dell’infrastruttura è stata ripristinata alle 17:06 UTC, dopo un lavoro di recupero dei servizi che avevano accumulato code, latenze e stati incoerenti.

Diversi servizi chiave hanno subito impatti significativi: il CDN ha risposto con errori 5xx, il sistema di autenticazione Turnstile non riusciva a caricarsi, Workers KV restituiva errori elevati e l’accesso alla dashboard risultava bloccato per la maggior parte degli utenti. Anche il servizio Email Security ha visto diminuire temporaneamente la propria capacità di rilevare lo spam a causa della perdita di accesso a una fonte IP reputazionale. Il sistema di Access ha registrato un’ondata di fallimenti di autenticazione, impedendo a molti utenti di raggiungere le applicazioni protette.

L’interruzione ha evidenziato vulnerabilità legate alla gestione distribuita della configurazione e alla dipendenza da file generati automaticamente con aggiornamenti rapidi. Cloudflare ha ammesso che una parte delle deduzioni del suo team durante i primi minuti dell’incidente si è basata su segnali fuorvianti – come il down del sito di stato – che hanno ritardato la corretta diagnosi del guasto. L’azienda ha promesso un piano di intervento strutturato per evitare che un singolo file di configurazione possa nuovamente bloccare segmenti così ampi della sua rete globale.

Cloudflare ha riconosciuto con grande trasparenza la gravità dell’incidente, sottolineando come ogni minuto di interruzione abbia un impatto significativo sull’intero ecosistema Internet, dato il ruolo centrale che la sua rete svolge.

L’azienda ha annunciato che questo primo resoconto sarà seguito da ulteriori aggiornamenti e da una revisione completa dei processi interni di generazione delle configurazioni e gestione degli errori di memoria, con l’obiettivo dichiarato di evitare che un evento simile possa ripetersi.

L'articolo Cloudflare blackout globale: si è trattato di un errore tecnico interno. Scopriamo la causa proviene da Red Hot Cyber.

A cura di Carl Windsor, Chief Information Security Officer di Fortinet

Le pratiche secure-by-design rappresentano un cambiamento fondamentale nello sviluppo software: la sicurezza non viene più considerata un’aggiunta successiva, ma è integrata fin dalle basi, nel DNA stesso del prodotto. Questa filosofia è ampiamente riconosciuta nel settore come best practice, ma non è ancora obbligatoria, né applicata in modo uniforme o pienamente compresa dai clienti. Tuttavia, adottare un approccio secure by design è sempre più cruciale, poiché le infrastrutture digitali si trovano ad fronteggiare una velocità e un volume senza precedenti di minacce sofisticate. Cybercriminali, sia inesperti che altamente qualificati, sfruttano nuove risorse – dall’acquisto di exploit kit nel dark web all’uso di strumenti automatizzati – per colpire vulnerabilità su larga scala.

Alla RSA Conference 2024, la Cybersecurity and Infrastructure Security Agency (CISA) ha presentato il proprio Secure by Design Pledge, un’iniziativa volta a innalzare il livello minimo di sicurezza informatica in tutto il settore tecnologico, integrando pratiche sicure alla base dello sviluppo dei prodotti e riducendo il rischio sistemico nell’ecosistema digitale. Fortinet è orgogliosa di essere stata tra i primi firmatari di questo impegno, e il nostro Jim Richberg ha avuto un ruolo chiave nella sua definizione.
Carl Windsor, Chief Information Security Officer di Fortinet
Sebbene Fortinet sia da tempo in prima linea nell’adozione e nella promozione delle migliori pratiche di cybersecurity, il Secure by Design Pledge rappresenta un passo avanti significativo nel definire e promuovere politiche che impongano a tutti i produttori di software standard più rigorosi. Il Pledge individua sette obiettivi principali, focalizzati sull’integrazione della sicurezza lungo l’intero ciclo di vita dello sviluppo dei prodotti, offrendo ai fornitori di software linee guida concrete per progredire verso tali traguardi.

Adozione e avanzamento dei principi Secure-by-Design in Fortinet

Fortinet adotta molti di questi principi da decenni e, in più occasioni, ha illustrato i progressi compiuti nell’implementazione e nel perfezionamento di tali standard. Di seguito una panoramica delle azioni intraprese da Fortinet per rispondere agli obiettivi del Pledge:

Obiettivo n.1: Dimostrare azioni volte ad aumentare in modo misurabile l’uso dell’autenticazione a più fattori (MFA) nei prodotti del produttore.
Risultato Fortinet: Fortinet ha abilitato l’MFA per gli account cloud dei clienti, con il 95% di questi che utilizza effettivamente questa misura di sicurezza.

Obiettivo n.2: Dimostrare progressi misurabili nella riduzione delle password predefinite nei prodotti del produttore.
Risultato Fortinet: Le password predefinite sono state eliminate nella Fortinet Secure Development Lifecycle Policy e rimosse da tutti i prodotti, imponendo agli utenti la creazione di credenziali uniche durante l’installazione.

Obiettivo n.3: Dimostrare azioni volte a ridurre in modo significativo e misurabile la presenza di una o più classi di vulnerabilità nei prodotti del produttore.
Risultato Fortinet: Fortinet ha intrapreso la rimozione delle vulnerabilità di tipo SQL injection e buffer overflow. Si tratta di un processo continuo che proseguirà nelle future versioni.

Obiettivo n.4: Dimostrare azioni intraprese dai clienti per aumentare in modo misurabile l’installazione di patch di sicurezza.
Risultato Fortinet: Fortinet ha compiuto importanti progressi in questo ambito grazie all’introduzione della funzionalità di auto-update, che ha aggiornato oltre un milione di dispositivi dalla sua implementazione, contribuendo in modo sostanziale alla sicurezza dei clienti.

Obiettivo n.5: Pubblicare una Vulnerability Disclosure Policy (VDP).
Risultato Fortinet: Fortinet è membro del Forum of Incident Response and Security Teams (FIRST), che consente ai suoi oltre 600 membri in più di 100 Paesi di condividere obiettivi, idee e informazioni relative alla gestione degli incidenti di sicurezza e allo sviluppo di programmi di risposta. Fortinet applica le conoscenze acquisite attraverso FIRST per garantire una comunicazione costante con i propri clienti. Inoltre, Fortinet pubblica la propria VDP sulla pagina dedicata al Product Security Incident Response Team (PSIRT) e tramite un file Security.txt.

Obiettivo n.6: Dimostrare trasparenza nella segnalazione delle vulnerabilità.
Risultato Fortinet: Fortinet ha implementato da tempo un programma di trasparenza radicale nella pubblicazione e comunicazione delle Common Vulnerabilities and Exposures (CVE), includendo già i campi Common Weakness Enumeration (CWE) e Common Platform Enumeration (CPE) in ogni CVE. Inoltre, Fortinet è impegnata a divulgare in modo proattivo e trasparente le vulnerabilità attraverso il suo solido programma PSIRT.

Obiettivo n.7: Dimostrare un incremento misurabile della capacità dei clienti di raccogliere evidenze di intrusioni informatiche che coinvolgono i prodotti del produttore.
Risultato Fortinet: A partire dalla versione 7.4.4 di FortiOS, sono state introdotte nuove funzionalità di controllo dell’integrità del file system per rilevare e registrare modifiche o aggiunte non autorizzate ai file. Fortinet continuerà ad aggiungere nuove funzioni con il rilascio delle versioni successive di FortiOS.

Oltre il Pledge: le iniziative aggiuntive di Fortinet

Fortinet adotta ulteriori misure che vanno oltre quanto previsto dal CISA Secure by Design Pledge, tra cui:

• Esecuzione regolare di test e audit approfonditi del codice, oltre a test di penetrazione condotti da terze parti.
• Obiettivi di performance (Management by Objectives) legati alla qualità del codice.
• Lancio di un programma pubblico di bug bounty.
• Collaborazione continua con diverse alleanze di cybersecurity, tra cui la Network Resilience Coalition, la Joint Cyber Defense Collaborative (JCDC) e la Cyber Threat Alliance (CTA), per condividere informazioni sulle minacce e sviluppare strategie volte a migliorare la resilienza cibernetica.

Guardando al futuro

Fortinet continua a lavorare su iniziative volte a incoraggiare i clienti a implementare patch e aggiornamenti, monitorando al contempo l’impatto di tali miglioramenti di sicurezza. Riconosciamo l’importanza di un’adozione su larga scala dei principi secure-by-design per costruire un ecosistema digitale più resiliente – un obiettivo che richiede un forte impegno e collaborazione tra settore pubblico e privato.

Fortinet continuerà a sostenere gli sforzi di organizzazioni come CISA e MITRE, introducendo e rispettando standard solidi che rafforzano la resilienza informatica a beneficio di tutti.

Per ulteriori informazioni dettagliate sul nostro impegno nel promuovere i principi secure-by-design, visita:

• Fortinet Reaffirms Its Commitment to Secure Product Development Processes and Responsible Vulnerability Disclosure Policies
• Proactive, Responsible Disclosure Is One Crucial Way Fortinet Strengthens Customer Security
• Fortinet’s Progress on Its Secure-by-Design Commitments
• Secure by Design: A Continued Priority in 2025 and Beyond

L'articolo Il Pledge ‘Secure by Design’ di CISA: un anno di progresso nella sicurezza informatica proviene da Red Hot Cyber.

A gastroscopy is a procedure that, in simple terms, involves sticking a long, flexible tube down a patient’s throat to inspect the oesophagus and adjacent structures with a camera fitted to the tip. However, modern technology has developed an alternative, in the form of a camera fitted inside a pill. [Aaron Christophel] recently came across one of these devices, and decided to investigate its functionality.

[Aaron’s] first video involves a simple teardown of the camera. The small plastic pill is a marvel of miniaturization. Through the hemispherical transparent lens, we can see a tiny camera and LEDs to provide light in the depths of the human body. Slicing the camera open reveals the hardware inside, however, like the miniature battery, the microcontroller, and the radio hardware that transmits signals outside the body. Unsurprisingly, it’s difficult to get into, since it’s heavily sealed to ensure the human body doesn’t accidentally digest the electronics inside.

Unwilling to stop there, [Aaron] pushed onward—with his second video focusing on reverse engineering. With a little glitching, he was able to dump the firmware from the TI CC1310 microcontroller. From there, he was able to get to the point where he could pull a shaky video feed transmitted from the camera itself. Artists are already making music videos on Ring doorbells; perhaps this is just the the next step.

Smart pills were once the realm of science fiction, but they’re an increasingly common tool in modern medicine. Video after the break.

youtube.com/embed/pf_eOLRd6B4?…

youtube.com/embed/qEIW5gOLzIs?…

hackaday.com/2025/11/18/hackin…

Questo è il quinto di una serie di articoli dedicati all’analisi della violenza di genere nel contesto digitale, in coincidenza con la Giornata Internazionale per l’Eliminazione della Violenza contro le Donne del 25 novembre . Il focus qui è sulla Misoginia 2.0 e l’impatto dell’odio di genere online sul dibattito democratico.

Il panorama digitale, essenziale per la libertà di espressione, è tristemente divenuto l’ecosistema predominante per la proliferazione dei discorsi d’odio. Tra le manifestazioni più virulente si annovera l’odio misogino online o Online Sexist Hate Speech, un fenomeno che colpisce in modo mirato le donne, in particolare quelle in ruoli di visibilità pubblica, minacciando non solo la loro dignità ma anche l’integrità del dibattito democratico. La rete, infatti, garantisce l’anonimato e una diffusione trans-giurisdizionale che complica notevolmente ogni azione repressiva.

Il silenziamento democratico

La violenza di genere veicolata online non è un fenomeno marginale; i dati evidenziano una prevalenza allarmante tra le giovani donne. L’effetto più insidioso di questa violenza sistematica è il cosiddetto chilling effect, o dinamica di silenziamento.

Donne e persone non conformi al genere sono quotidianamente esposte a minacce online, spesso estreme, che culminano nell’autocensura e nell’esclusione digitale. Per paura dell’abuso, le vittime si trovano nell’impossibilità di partecipare pienamente ed esprimersi online, venendo di fatto estromesse dal dibattito pubblico e dalla vita politica.

L’odio misogino online cessa così di essere un mero attacco alla reputazione individuale e si configura come un attacco diretto ai principi fondamentali di libertà di manifestazione del pensiero (Art. 21 Cost.) e di parità democratica (Art. 3 Cost.). Se metà della popolazione è strutturalmente impedita dal partecipare al principale spazio di dibattito, l’integrità democratica ne è minata.

Il contesto europeo e la lacuna nell’ordinamento giuridico nazionale

Negli ultimi tempi si registra un aumento di discorsi, anche veicolati attraverso la rete, motivati in qualche modo dall’odio, dal disprezzo nei confronti dell’altro, verso il debole, verso il diverso.

Tuttavia, in questo contesto generale, l’odio di genere, e in particolare la misoginia digitale, emerge con una specifica virulenza, amplificando l’esclusione delle donne dal dibattito pubblico e rendendo la loro discriminazione un caso emblematico della necessità di adeguamento normativo.

Tale fenomeno, comunemente indicato con l’espressione hatespeech, pur non essendo specifico di internet, esprime il massimo della lesività proprio attraverso lo strumento telematico e ciò per una serie di ragioni.

In primo luogo perché attraverso la rete posso raggiungere chiunque dovunque si trovi, quindi un bacino di utenza illimitato. In secondo luogo perché il messaggio può travalicare i confini nazionali, rendendo necessaria, per la punibilità dell’autore, una cooperazione internazionale non sempre agevole o possibile. A ciò si aggiunga, soprattutto, che anche se rimosso, un dato messaggio d’odio può riapparire nel tempo in un’altra parte della rete, rendendosi praticamente “eterno”.

Da un punto di vista giuridico si tende ad evidenziare come l’hatespeech si caratterizzi da un lato per la volontà del soggetto agente di discriminare taluno o un gruppo per la sua razza, religione, orientamento sessuale o altro; dall’altro per la reale capacità del messaggio di determinare tale discriminazione e magari il concretizzarsi di azioni violente che da tale messaggio traggono linfa. È appena il caso di sottolineare come anche i messaggi d’odio veicolati in rete finiscono per avere effetti, talvolta gravissimi, nel reale. Pensiamo, ad esempio, alle persone che sono state spinte a tentare il suicidio a seguito di vere e proprie campagne di odio.

Su come considerare l’hatespeech, orientamenti diversi si registrano negli Stati Uniti ed in Europa. Se, infatti, nel primo ci si rifà al Primo Emendamento e quindi in sostanza si cerca di evitare qualunque restrizione alla manifestazione del pensiero, a livello europeo si predilige l’impostazione per cui la libera manifestazione del pensiero non può essere illimitata, per cui si parla di responsabilità di parola.

Per quanto riguarda l’hatespeech telematico importanti indicazioni provengono dal Protocollo addizionale alla Convenzione di Budapest sulla criminalità informatica, relativo all’incriminazione di atti di natura razzista e xenofobica commessi a mezzo di sistemi informatici, che obbliga gli Stati aderenti ad adottare sanzioni penali per punire la diffusione di materiale razzista e xenofobo attraverso i sistemi informatici.

Di estremo interesse è anche il Digital Service Act, che si propone esplicitamente di garantire un ambiente on line sicuro, responsabilizzando il più possibile i provider e le piattaforme digitali che veicolano contenuti e, quindi, anche quelli che esprimono odio e discriminazione.

In Italia, se da un lato l’art. 21 della Costituzione fissa come principio fondamentale quello della libera manifestazione del pensiero, dall’altro la stessa trova dei limiti nel buon costume, nella riservatezza e onorabilità delle persone, nel segreto di Stato, nel segreto giudiziario e, infine, nell’apologia di reato.

Ciò posto, e considerata la copertura costituzionale non illimitata alla libertà di parola, l’espressioni di odio che tendono ad una discriminazione assumono rilevanza giuridica in virtù di quanto statuito dalla legge n.205/1993 (c.d. legge Mancino), che punisce oggi, attraverso l’Art. 604-bis c.p., l’istigazione alla discriminazione e alla violenza per motivi razziali, etnici o religiosi, escludendo, tuttavia, esplicitamente le discriminazioni basate sul genere.

In vero, da tempo si discute in merito a una possibile estensione della norma ai reati basati sulla discriminazione in base all’orientamento sessuale e all’identità di genere, ma allo stato non si è pervenuti a un allargamento delle ipotesi previste, né tanto meno all’introduzione di una legge specifica da più parti auspicata, lasciando così l’odio misogino online senza un’adeguata e specifica cornice sanzionatoria.

L’obbligo di adeguamento europeo

Il quadro italiano è destinato a mutare radicalmente con l’adozione della Direttiva (UE) 2024/1385, che stabilisce norme minime per la lotta alla violenza contro le donne e alla violenza domestica.

L’Articolo 8 della Direttiva impone un obbligo di risultato stringente. Gli Stati membri devono punire esplicitamente l’istigazione alla violenza o all’odio nei confronti di un gruppo di persone definito con riferimento al genere, se tale istigazione è diffusa tramite tecnologie dell’informazione e della comunicazione (TIC).

Il confronto diretto tra l’Art. 8 UE e l’Art. 604-bis c.p. rivela il gap normativo che non è più sostenibile. L’inclusione del genere nel 604-bis c.p. non è più una facoltà oggetto di dibattito politico, ma un imperativo legale di origine sovranazionale. La riforma che ne deriverà deve consentire al sistema legale di punire l’odio misogino per la sua intrinseca capacità di minare l’uguaglianza, al di là del danno specifico causato alla singola vittima.

La strategia integrata contro la misoginia

La gestione del fenomeno è complessa, sia per il confine mobile tra diffamazione individuale e odio collettivo, sia per le sfide procedurali.

Le indagini sui discorsi d’odio in rete presentano notevoli difficoltà. La natura dinamica e volatile della comunicazione online ostacola l’acquisizione forense dei dati, che possono essere rimossi velocemente dall’autore o dalle piattaforme. Il reperimento e la conservazione delle prove necessitano del ricorso a competenze specialistiche in digital forensics.

La Polizia Postale, in collaborazione con l’OSCAD (Osservatorio per la Sicurezza Contro gli Atti Discriminatori), svolge un lavoro cruciale, ma i dati aggregati, che nel 2023 hanno visto 2.712 casi trattati per discriminazione e odio, nascondono una sottostima sistemica (underreporting). Le vittime non denunciano per timore di ritorsioni o sfiducia nel sistema.

Per rafforzare la tutela e affrontare la Misoginia 2.0 occorre, a mio avviso, agire su più fronti.

• Innanzitutto, investire nella formazione specialistica per le Forze dell’Ordine e le Autorità Giudiziarie sul riconoscimento del chilling effect come danno concreto e sulle tecniche avanzate di digital forensics.
• Inoltre, bisogna rafforzare il monitoraggio e l’applicazione sanzionatoria nei confronti degli operatori digitali che non adempiono agli obblighi di moderazione e rimozione di contenuti illegali, in linea con il Digital Services Act e la Direttiva UE.
• Infine,vi è necessità di implementare misure di protezione, assistenza specialistica e valutazione individuale delle esigenze di sicurezza per aumentare la fiducia delle vittime ed incentivare le segnalazioni.

La Misoginia 2.0 esige di essere equiparata all’odio razziale, non per similitudine, ma per l’identico potenziale lesivo della parità democratica. Il sistema giudiziario non può più permettersi l’alibi di una tutela frammentata, che subordina la libertà di espressione delle donne alla mera lesione dell’onore individuale.

L'articolo Misoginia 2.0: l’istigazione all’odio che zittisce le donne proviene da Red Hot Cyber.

Google ha rilasciato nuovi aggiornamenti per il suo browser Chrome nel mezzo di una nuova ondata di attacchi in cui gli aggressori sfruttano una falla nel motore V8. L’azienda ha riconosciuto che una delle vulnerabilità scoperte è già utilizzata in incidenti reali, quindi le patch sono state rilasciate immediatamente.

Il problema principale era il CVE-2025-13223, con severity di 8,8. Si tratta di un bug che può portare alla corruzione della memoria. In uno scenario di successo, un aggressore remoto potrebbe eseguire codice arbitrario tramite una pagina HTML appositamente creata.

Il problema è stato segnalato da Clement Lessin del team Threat Analysis Group, che ha identificato il problema il 12 novembre. L’azienda non ha rivelato chi potrebbe essere stato preso di mira dagli attacchi né la loro portata, ma conferma che esiste già uno strumento antimalware funzionante.

Questo bug è diventato la terza anomalia attiva di questa classe nella V8 di quest’anno, unendosi a CVE-2025-6554 e CVE-2025-10585 . È stato risolto anche un problema simile nel motore, CVE-2025-13224. È stato scoperto dall’agent di intelligenza artificiale interno di Google, Big Sleep .

Entrambi i bug hanno ricevuto lo stesso livello di gravità a causa del rischio di esecuzione di azioni arbitrarie nel sistema.

L’azienda ricorda che, inclusa la versione di novembre, il numero di vulnerabilità zero-day risolte in Chrome dall’inizio dell’anno ha raggiunto quota sette. L’elenco include CVE-2025-2783 , CVE-2025-4664 , CVE-2025-5419 , CVE-2025-6554 , CVE-2025-6558 e CVE-2025-10585 .

Per ridurre i rischi, consigliamo di installare le versioni più recenti di Chrome: 142.0.7444.175 o .176 per Windows, 142.0.7444.176 per macOS e 142.0.7444.175 per Linux.

È possibile verificare la presenza di aggiornamenti andando su Aiuto > Informazioni su Google Chrome e riavviando il browser. Anche gli utenti di Edge, Brave, Opera e Vivaldi dovrebbero attendere il rilascio degli aggiornamenti corrispondenti nelle loro build.

L'articolo Google Chrome, un altro bug critico risolto. Basta una pagina HTML contraffatta per sfruttarlo proviene da Red Hot Cyber.

There’s been a bit of a virtualization revolution going on for the last decade or so, where tools like Docker and LXC have made it possible to quickly deploy server applications without worrying much about dependency issues. Of course as these tools got adopted we needed more tools to scale them easily. Enter Kubernetes, a container orchestration platform that normally herds fleets of microservices in sprawling cloud architectures, but it turns out it’s perfectly happy running on a tiny computer stuffed in a cat carrier.

This was a build for the recent Kubecon in Atlanta, and the project’s creator [Justin] wanted it to have an AI angle to it since the core compute in the backpack is an NVIDIA DGX Spark. When someone scans the QR code, the backpack takes a picture and then runs it through a two-node cluster on the Spark running a local AI model that stylizes the picture and sends it back to the user. Only the AI workload runs on the Spark; [Justin] also is using a LattePanda to handle most of everything else rather than host everything on the Spark.

To get power for the mobile cluster [Justin] is using a small power bank, and with that it gets around three hours of use before it needs to be recharged. Originally it was planned to work on the WiFi at the conference as well but this was unreliable and he switched to using a USB tether to his phone. It was a big hit with the conference goers though, with people using it around every ten minutes while he had it on his back. Of course you don’t need a fancy NVIDIA product to run a portable kubernetes cluster. You can always use a few old phones to run one as well.

youtube.com/embed/XudewmfourQ?…

hackaday.com/2025/11/18/kubern…

18 novembre 2025 – Dopo ore di malfunzionamenti diffusi, l’incidente che ha colpito la rete globale di Cloudflare sembra finalmente vicino alla risoluzione. L’azienda ha comunicato di aver implementato una correzione e di essere ora nella fase di monitoraggio attivo, dopo una giornata caratterizzata da disservizi, errori intermittenti e problemi sui servizi applicativi e di sicurezza.

L’incidente, iniziato alle 11:48 UTC, ha coinvolto varie componenti dell’infrastruttura Cloudflare, generando rallentamenti, timeout e blocchi a livello globale, con impatti anche su CDN, API, autenticazione e dashboard di gestione.

Di seguito la ricostruzione completa della giornata.

Timeline dell’incidente Cloudflare

11:48 UTC – Inizio dell’incidente
Cloudflare segnala un degrado interno del servizio. Diversi servizi risultano instabili a livello globale e viene avviata l’analisi del problema.

12:03 UTC – Indagine in corso
Cloudflare conferma che alcuni servizi continuano a essere colpiti da errori intermittenti.

12:21 UTC – Prime evidenze di ripristino parziale
Cloudflare osserva miglioramenti, ma i clienti sperimentano ancora errori più elevati del normale.

12:37 UTC – Indagine ancora attiva
Persistono anomalie diffuse sulla rete.

12:53 UTC – Indagine ancora in corso
I tecnici continuano a lavorare senza individuare ancora una soluzione definitiva.

13:04 UTC – Disattivato temporaneamente l’accesso WARP a Londra
Durante i tentativi di mitigazione, Cloudflare disattiva WARP nella region di Londra. Gli utenti locali non riescono a connettersi tramite il servizio.

13:09 UTC – Problema identificato
Cloudflare comunica di aver individuato la causa dell’incidente e di aver iniziato a implementare una soluzione.

13:13 UTC – Ripristino parziale di Access e WARP
Cloudflare ripristina Access e WARP, riportando i livelli di errore alla normalità.
WARP Londra torna operativo. Si continua a lavorare sui restanti servizi applicativi.

13:35 UTC – Problemi ancora presenti
I servizi applicativi non sono ancora stati ripristinati completamente.

13:58 UTC – Lavori in corso
Continuano gli interventi per riportare online i servizi rimanenti.

14:22 UTC – Ripristino dashboard
La dashboard Cloudflare torna operativa, anche se i servizi applicativi mostrano ancora instabilità.

14:34 UTC – Continuano i lavori di ripristino
Il team tecnico prosegue con le attività necessarie a ripristinare tutti i servizi.

14:42 UTC – Cloudflare: “Incidente risolto, monitoraggio in corso”
Cloudflare annuncia di aver implementato una correzione definitiva. Tutti i servizi dovrebbero tornare progressivamente alla normalità, ma rimane attivo il monitoraggio post-incident.

Impatti dell’incidente

L’incidente ha avuto un impatto rilevante su scala globale. Molti siti web serviti da Cloudflare (tra cui redhotcyber.com) hanno mostrato rallentamenti, pagine non raggiungibili, errori 502, 522 e 526, oltre a problemi di caching e routing.

I servizi di sicurezza e autenticazione, come Cloudflare Access e WARP, sono stati fortemente colpiti nella prima fase. In alcune regioni gli utenti non hanno potuto autenticarsi o accedere alle risorse protette.

Anche Downdetector ha mostrato malfunzionamenti, rendendo difficile monitorare l’ampiezza dell’incidente e contribuendo alla percezione di un blackout molto esteso.

L’infrastruttura globale Cloudflare ha registrato rallentamenti e instabilità, con ripercussioni a catena su servizi non direttamente ospitati sulla piattaforma.

Che cos’è Cloudflare WARP

Cloudflare WARP è un servizio sviluppato da Cloudflare con l’obiettivo di migliorare la sicurezza e le prestazioni della connessione Internet degli utenti. A differenza delle VPN tradizionali, che puntano principalmente a fornire anonimato instradando tutto il traffico attraverso server remoti, WARP è progettato per rendere la navigazione più veloce, stabile e protetta, senza appesantire la connessione.

Come funziona

WARP utilizza il protocollo WireGuard, noto per essere leggero, rapido e altamente sicuro. Il traffico viene instradato attraverso la rete globale di Cloudflare, che funge da “strato protettivo” tra l’utente e il web. Questo permette di:

• criptare le connessioni su reti non sicure (come Wi-Fi pubblici),
• ridurre la latenza grazie alla rete globale Cloudflare,
• filtrare automaticamente traffico malevolo o sospetto,
• proteggere da intercettazioni e attacchi man-in-the-middle.

Non mira all’anonimato totale come una VPN classica, ma si concentra su sicurezza e stabilità della connessione.

La differenza tra WARP e WARP+

Cloudflare offre due versioni del servizio:

• WARP: gratuito, utilizza la rete standard Cloudflare.
• WARP+: a pagamento, instrada parte del traffico tramite la tecnologia Argo Smart Routing, che sceglie dinamicamente il percorso più veloce tra i server Cloudflare, migliorando ulteriormente la velocità.

Situazione attuale

Secondo l’ultimo aggiornamento, la correzione è stata applicata con successo e i servizi stanno tornando alla normalità. Cloudflare è ora nella fase di monitoraggio attivo e nelle prossime ore potrebbero verificarsi residui di instabilità durante l’assestamento della rete

L'articolo Cloudflare va giù nel magnifico Cloud! incidente globale in fase di risoluzione proviene da Red Hot Cyber.

“Build a better mousetrap and the world will beat a path to your door,” so goes the saying, but VHS beat Betamax and the world hasn’t been the same since. In any case, you might not get rich building a better mousetrap, but you can certainly create something more humane than the ol’ spring’n’snap, as [nightcustard] demonstrates.

The concept is the same as many humane mousetraps on the market. The mouse is lured into a confined cavity with the use of bait, and once inside, a door closes to keep the mouse inside without injuring it. [nightcustard] achieved this by building a plastic enclosure with plenty of air holes, which is fitted with a spring-loaded door. When a mouse walks through an infra-red break beam sensor, a Raspberry Pi Pico W triggers a solenoid which releases the door, trapping the mouse inside. This design was chosen over a passive mechanical solution, because [nightcustard] noted that mice in the attic were avoiding other humane traps with obvious mechanical trigger mechanisms.

As a bonus, the wireless connectivity of the Pi Pico W allows the trap to send a notification via email when it has fired. Thus, you can wake up in the morning and check your emails to see if you need to go and release a poor beleaguered mouse back into the wild. This is critical, as otherwise, if you forget to check your humane trap… it stops being humane pretty quickly.

If you’re looking for more inspiration to tackle your mouse problems, we can help. We’ve featured other traps of this type before, too. Meanwhile, if you’ve got your own friendly homebrew solutions to pesky pest problems, don’t hesitate to hit up the tipsline.

hackaday.com/2025/11/18/humane…