Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Four Malicious npm Packages Steal SSH Keys, Cloud Credentials, and Crypto Wallets in Coordinated Supply Chain Attack
#CyberSecurity
securebulletin.com/four-malici…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Hackers Actively Exploiting Critical NGINX RCE Vulnerability in the Wild
#CyberSecurity
securebulletin.com/hackers-act…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

CISA Warns of Actively Exploited Microsoft Exchange Server XSS Flaw — Patch by May 29
#CyberSecurity
securebulletin.com/cisa-warns-…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Windows ‘MiniPlasma’ Zero-Day Grants SYSTEM Privileges on Fully Patched Systems — Public PoC Released
#CyberSecurity
securebulletin.com/windows-min…
Cybersecurity & cyberwarfare ha ricondiviso questo.

Dopo i recenti attacchi informatici, la Polonia ha intimato ai funzionari pubblici di non utilizzare più #Signal per le comunicazioni sensibili

Sarebbe pronta un'alternativa sviluppata dallo Stato. La decisione fa seguito a ripetuti attacchi informatici contro gli account Signal di politici, militari e dipendenti pubblici. Le autorità ritengono che le campagne siano collegate a gruppi APT (Advanced Persistent Threat) sostenuti dalla Russia.

securityaffairs.com/192381/int…

@informatica

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Poland shifts away from #Signal following cyberattacks on officials’ accounts
securityaffairs.com/192381/int…
#securityaffairs #hacking
Cybersecurity & cyberwarfare ha ricondiviso questo.

Massive MENA #cybercrime #Operation #Ramz disrupts infrastructure and arrests 201 suspects
securityaffairs.com/192357/unc…
#securityaffairs #hacking #malware

“L’AI rende il cybercrime accessibile anche ai principianti”. Allarme dell’Interpol


@Informatica (Italy e non Italy)
Gli strumenti dell’AI stanno rendendo più facile e veloce la vita ai cybercriminali, ha detto il responsabile del cybercrime dell’Interpol al sito specializzato Politico.eu. In un’intervista rilasciata venerdì scorso, Neal Jetton, direttore del

Cybersecurity & cyberwarfare ha ricondiviso questo.

Shai-Hulud worm copycats emerge after source code leak
securityaffairs.com/192366/mal…
#securityaffairs #hacking #malware
Cybersecurity & cyberwarfare ha ricondiviso questo.

📺 Between Two Nerds: Russia's hacker university

risky.biz/video/between-two-ne…

reshared this

DK 10x31 - Scricchiolii


The media in this post is not displayed to visitors. To view it, please log in.

Quando qualcosa crolla, prima scricchiola.


dk.dataknightmare.eu/dk10x31-s…


DK10x31 - Scricchiolii


Ascolta l'episodio su Spreaker.com

Quando qualcosa crolla, prima scricchiola.

Da qualche giorno, ci sono delle coincidenze che mi danno da pensare. E pensare è un'attività perfino sovversiva in questi tempi in cui tutti gli incentivi premiano soltanto le nostre reazioni istintive.

Fatemi mettere assieme un po' di pezzi e vediamo se anche voi cominciate a vedere quello che vedo io.

La prima cosa, ovviamente, è che le assicurazioni stanno come un sol uomo smettendo di stipulare polizze per danni causati dall'intelligenza artificiale.

Questa è gente che ai soldi sta attenta, e il fatto che non vogliano pagare certe cose ha una spiegazione molto semplice: il rischio di dover pagare è troppo alto.

Abbiamo un primo segnale: dopo quattro anni di propaganda incessante, quelli che dovrebbero aiutare a contenere i rischi, vedono rischi troppo grandi. Interessante, andiamo avanti.

Seconda cosa: i grandi istituti bancari stanno reincartando i rischi dei prestiti ai mega datacenter in strumenti finanziari per il mercato al consumo che si chiamano… Obbligazioni di debito collateralizzato.

Se non vi dice niente, stiamo parlando dei CDO di cui abbiamo visto i risultati nel crack del 2008. In quel caso le obbligazioni rivendevano il rischio di mutui subprime, in questo caso rivendono il rischio di prestiti ai costruttori di megadatacenter. Il rischio essendo, ovviamente, che mutui e prestiti non vengano ripagati.

Nel 2008, il crac fu dovuto al fatto che la stragrande maggioranza dei CDO era relativo a mutui che erano stati concessi a chiunque e al suo cane, gente che non avrebbe mai ripagato il prestito. Oggi, invece, i CDO sono relativi ai prestiti rilasciati a serissimi imprenditori dell'Intelligenza Artificiale per la costruzione di datacenter di dimensioni comparabili alle visioni mistiche che Sam Altman illustra ai propri investitori: mostri da 160Km^2, praticamente un quadrato di dodici kilometri e mezzo di lato, praticamente l'intera città di Milano, dalla Bicocca a San Donato e dal Parco delle Cave a Lambrate.

C'è solo il piccolo problema che non c'è l'elettricità per farli funzionare, e infatti uno dei pochi datacenter veramente costruiti, quello di Musk in Minnesota, funziona con una cinquantina di turbine a gas perché la fornitura locale di elettricità non è nemmeno lontanamente sufficiente.

A parole, c'è una corsa all'oro nella costruzione di datacenter, perché i signorotti dell'Intelligenza Artificiale parlano a destra e a manca di fantastiliardi di investimenti (ovviamente di soldi altrui), che verranno ripagati non appena l'Intelligenza Artificiale, tra due o tre anni, funzionerà come ci promettono ogni semestre da cinque anni.

Nei fatti, la maggioranza dei datacenter ha a malapena iniziato i lavori, e come ci racconta Ed Zitron, i soldi per completarli e soprattutto per farli rendere non esistono.


Altra notiziola: il carrozzone dell'Intelligenza Artificiale sta facendo di tutto per agganciarsi alle commesse statali, in primis quelle della difesa.

Anthropic ha fatto carte false per entrare al Pentagono, usando poi l'aggressione israelo-statunitense all'Iran come momento promozionale. Ve li ricordate i titoli, "Anthropic aiuta il Pentagono a pianificare 1000 missioni nelle prime 24 ore", incluso il bombardamento di una scuola media che però curiosamente nessuno ha voluto attribuirsi.

Naturalmente, due mesi e mezzo dopo, l'esercito più potente del mondo, assistito dall'Intelligenza Artificiale, non sa come tirarsi fuori dall'ennesima sconfitta; lo stretto di Hormuz, che prima dell'attacco era libero, paga pedaggio all'Iran, e tre portaerei della marina statunitense, quelli di Top Gun, stanno con i loro gruppi di battaglia il più possibile fuori vista per evitare di perdere una portaerei contro due poveracci su un motoscafo imbottito di tritolo.

openAI, dall'alto dei suoi risultati, è invece riuscita ad assicurarsi l'analisi dei dati di decenni di test nucleari, una cosa per la quale un rappresentante di openAI si è dovuto presentare ammanettato a una valigetta per installare chatGPT sui blindatissimi supercomputer del centro di ricerche di Los Alamos.

In quale modo un modello linguistico, che deve essere istruito separatamente su quante erre ci siano in "raspberry", possa servire nell'analisi di dati, è al di là della mia comprensione, ma evidentemente anche a Los Alamos credono alla magia.


Contemporaneamente, a seguito delle richieste di nessuno, continua la corsa dei produttori a mettere la cosiddetta Intelligenza Artificiale dentro qualsiasi cosa, Google annuncia un Googlebook nel quale Gemini interpreta ogni mossa e decisione dell'utente, naturalmente con un'interfaccia vocale. Sarà un successone negli uffici.

Viene quasi da pensare che tutto questo impegno, a fronte di nessuna richiesta da parte del mercato, sembra avere come unico scopo quello di alzare il prezzo di un ritorno allo status quo ante, una volta che la bolla speculativa sarà scoppiata. Ma occorrerebbe essere sospettosi e pure malfidati.


Fuori dalle notizie economiche, CEO dell'Intelligenza Artificiale rilasciano a giornalisti azzerbinati interviste a ciclo continuo in cui hanno mano libera per dire senza uno straccio di indizio quanto sono importanti, e che l'Intelligenza Artificiale cambia tutto, e che il lavoro (ovviamente il nostro, non il loro) cambierà per sempre, e che siccome quello che stanno facendo è così importante, forse dovrebbe intervenire lo Stato per aiutarli se dovessero avere problemi finanziari.

Ora, delle due l'una: o vendi un prodotto che qualcuno vuole, e allora non si capisce perché dovresti avere problemi finanziari, e soprattutto perché lo Stato ti dovrebbe aiutare a superarli.

Oppure hai problemi finanziari perché da quattro anni stai vendendo a prezzi stracciati un prodotto che nessuno è disposto a pagare quanto serve per coprire i tuoi costi, e in questo caso, i problemi finanziari si chiamano "la bolla speculative dentro la quale sei cresciuto" e visto che esiste il libero mercato, te li dovresti spupazzare tu.

Giusto per ripeterci, Anthropic spende dagli 8 ai 13 dollari per ogni dollaro per ogni dollaro di incasso (e la fonte è la Harvard Business Review, non "Rivoluzione Comunista"). Fino a oggi, la differenza continua a essere coperta dai soldi degli investitori, o dalle commesse statali, tanto paga Pantalone. Ma prima o poi i sussidi finiscono, e io non vedo aziende in coda per il privilegio di spendere cinque o diecimila dollari al mese a programmatore per farli giocare con Claude.

Sappiamo da almeno due anni che i bilanci dell'Intelligenza Artificiale non stanno in piedi nemmeno con un tutore. Sappiamo da almeno due anni che i famosi "investimenti" che ci annunciano ogni settimana sono in realtà una partita di giro in cui ciascuno promette gli stessi cento miliardi di dollari, tipicamente sotto forma di crediti, e poi li mette a bilancio come introiti.
Meme da Wolf of Wall Street. Altman: Vendimi questa penna - Huang: ti presto io i soldi per comprarlaAltman: Vendimi questa penna - Huang: ti presto io i soldi per comprarla
C'è un meme che gira, riadattato da "the wolf of Wall Street". Nel primo quadro Sam Altman con una penna in mano dice "Vendimi questa penna". Nel secondo c'è Jensen Huang, CEO di NVIDIA che dice "ti presto io i soldi per comprarla."

Fa ridere, ma con la quantità di soldi che ci sono in ballo dovremmo essere terrorizzati.

Chiunque non sia in uno stato di allucinazione e senta i numeri snocciolati da Sam Altman e soci capisce immediatamente di trovarsi di fronte a un venditore di fumo. E non lo dico io: la sua stessa CFO dice che, con i conti che ha, openAI non può permettersi di tentare una quotazione quest'anno.

Stiamo vivendo in una bolla speculativa le cui dimensioni fanno impallidire perfino il 2008.
La totalità della crescita del PIL statunitense negli ultimi anni è dovuta esclusivamente alla sopravvalutazione speculativa dei titoli dell'Intelligenza Artificiale, ma finché tutti ci credono, la speculazione tiene.

Musk, che è più furbo di Altman, ha fuso xAI e le sue perdite dentro SpaceX e le sue commesse militari blindate, e con ogni probabilità si quoterà entro l'anno.

Nientemeno che il Wall Street Journal ci racconta di come S&P stia cercando di riscrivere le proprie regole per poter includere openAI, SpaceX e Anthropic in indici come lo S&P 500. L'idea è che le regole, che fino a qui imponevano di aspettare un anno dalla quotazione e soprattutto di riportare profitti per poter essere incluse nell'indice, verrebbero ignorate nel caso di Initial Public Offering sufficientemente grandi da entrare direttamente fra i primi cento titoli per valore.

Il fatto che il valore di Anthropic, xAI e openAI sia fin qui puramente immaginario, evidentemente non preoccupa nessuno.

E chi li compra i titoli compresi negli indici? I fondi di investimento e i fondi pensione. Cioè i risparmiatori.

Il Sole 24 ore di oggi, domenica 17 maggio 2026, ha ancora il coraggio di titolare:

Dal credito all'high-tech profitti su del 20%. Gli utili 2026 spingono Wall Street.


Io, che non sono pagato da Confindustria, vedo lo stesso mondo e arrivo a conclusioni leggermente diverse.

Fino a due anni fa si poteva dire, e si diceva, che i critici dell'Intelligenza Artificiale parlavano per partito preso, o che erano in malafede, i soliti luddisti nemici del progresso.

Fino a un anno fa si poteva ancora sostenere, e si sosteneva, che il livello degli investimenti indicava un'industria in espansione, specialmente ignorando che gli investimenti erano circolari.

Ma oggi gli scricchiolii vengono dall'interno dell'establishment, parliamo di banche, di assicurazioni, di borse, non esattamente gente che entra o esce da un investimento perché è di moda.
E l'establishment si sta preparando al crollo, scaricando sul pubblico titoli che perderanno il 100% del valore nel momento in cui il mercato si risveglierà dalla trance.

Come nel 2008, l'economia reale verrà polverizzata dal tracollo dei valori immaginari dell'economia speculativa. Gli Stati interverranno per salvare i colpevoli, e il conto lo pagheremo tutti quanti noi.

La nostra unica consolazione sarà ricordarci nomi e cognomi degli algopirla che hanno costruito il disastro, e degli utili idioti, cantori e politici, che gli hanno dato corda. E, stavolta, chiedergli il conto.

A tutti.


Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

313 – Hanno massacrato un vero Monet convinti che fosse AI camisanicalzolari.it/313-hanno…
Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Dentro gli allegati tecnici UE: la zona grigia delle nuove batterie smartphone

📌 Link all'articolo : redhotcyber.com/post/smartphon…

A cura di Giovanni Pollola

#redhotcyber #news #batterie #dispositivimobili #normue #ambiente #sostenibilita #ecologia #elettronica

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

L’arte del Prompting: la chiave per essere efficaci nell’era delle ai

📌 Link all'articolo : redhotcyber.com/post/larte-del…

A cura di Antonino Battaglia

#redhotcyber #news #interazioneuomocomputer #modellilinguistici #ingegneriadelpeso #intelligenzartificiale #llm

Digital Organizer Given Modern Upgrade


The media in this post is not displayed to visitors. To view it, please log in.

Remember digital organizers? They were like the lower-spec version of a PDA that couldn’t really do much more than store a few phone numbers and calendar entries. [TundraLegendZ] recently grabbed such a device from 1995 and set about transforming it into something a little more capable.

The device in question is a Casio Business Organizer Scheduling System SF-5580. The original guts have been replaced , though, with the power of a Raspberry Pi Zero. The single-board computer is hooked up to a small color LCD screen with a resolution of 480 x 800, which is tucked neatly into the spot where the original display lived. There’s also a Raspberry Pi Pico on board, which is charged with interfacing all 82 keys of the original keyboard. Power is courtesy of a 6000 mAh battery which should last a good few hours on a single charge. Hearing the buzzer hacked is fun, too. It’s more mobile phone ringtone than outright chiptune, but we still enjoyed listening to the results. Screencaps of the software show just what this setup can do with better hardware and a nicer screen than 1995 could provide. Future work is planned to give the build more capabilities with a HackRF upgrade.

We’re not convinced anyone ever got much use out of these diminutive digital organizers, but a great many were sold in the 1990s.


hackaday.com/2026/05/18/digita…

Prolog Via Pokémon


The media in this post is not displayed to visitors. To view it, please log in.

Like many people who read Hackaday, we are fairly fluent in a number of computer languages, but we have to admit it is easier to pick up languages that look like they group with things like Fortran. Sure, modern languages have all sorts of features, but the idea that you have a text file that executes in some order, variables, statements, and so on runs through most popular languages, but not all of them. Lisp and its variants are a different way of looking at things. And then there’s Prolog. [Alexander Petros] has an interesting way of explaining Prolog as a Pokémon game.

Prolog was “the next big thing” when AI meant expert systems. It is more of a specialized database where you define facts and rules that the computer can infer answers to queries. For example, if the facts say that Paul and Anna both have Mary as a parent, and a rule says that people with the same parent are siblings, then a query asking whether Paul and Anna are siblings will indicate that they are.

How does this relate to Pokémon? The classic card game pits teams of different characters against each other, and each has particular traits and moves. Prolog is well-suited to expressing situations like this, where there are many facts and rules about how they relate to one another.

In the example, characters like Bulbasaur and Squirtle are known to be pokemon. Each character can have one or more types (e.g., Bulbasaur is both a grass and poison type). Then, rules can define things like the types of moves and traits each character has. The way Prolog works, you can provide a variable as part of a query and get lists of matches, much like a database.

We didn’t see [Alex] mention the cut operator, and many people do not like to use it. There are probably other parts of Prolog left out, too, like backtracking. However, this is as good a place to start as any, and the example is exactly the sort of problem that Prolog is good at.

If you really prefer C, you can mix C and Prolog. We can’t imagine how it worked, but there was even a computer with a Prolog operating system.


hackaday.com/2026/05/18/prolog…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

New, by me: CISA Admin Leaked AWS GovCloud Keys on GitHub

Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.

krebsonsecurity.com/2026/05/ci…

Electroplating 3D Prints Without Requiring a Big Vat


The media in this post is not displayed to visitors. To view it, please log in.

Electroplating 3D prints is a good way to get a pretty nice coating on even a basic PLA part, but generally you’re expected to dunk the entire part into a big vat with electrolyte after coating it with the requisite conductive paint layer. This is great for small parts, like a ring you’d put on a finger, but gets rather silly when it’s a much larger part, such as the one in [Hendrik]’s recent video. Out of curiosity he tried to see whether rotating the part through a much smaller vat would still get you an even coating, or not.

Perhaps ironically this process required building a custom vat out of acrylic, as well as an entire rig to hold up the part and gently rotate it. This highlights the main disadvantage of this approach, in that unless you’re doing a small production run or otherwise get to re-use the rig a lot it’s a lot of extra effort.

That said, the rotation is controlled by an ESP32 and a stepper motor along with a requisite stepper driver, with the most exotic part being the whole custom PCB and enclosure, all of which can be used repeatedly. With all of that tested and confirmed working, the part to be plated was sanded, sprayed with conductive paint and hooked up to the rotating rig for an overnight run.

Following that the part’s new copper coating was polished before more layers of electroplating were applied to get the desired two different colors from different metals. Along the way no issues were found with this method of rotating electroplating, so if you regularly struggle with oversized parts to electroplate, this would seem to be a viable method.

youtube.com/embed/B2_lCMJ-_Uk?…


hackaday.com/2026/05/18/electr…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Scuola, la scelta obbligata dei manuali digitali. Un risparmio apparente che penalizza la didattica

Il passaggio al libro digitale ha costi e impatti didattici. Oltre agli studi che dimostrano i vantaggi dello studio su carta, i device sono spesso anche una fonte di distrazione. Il tutto, mentre si vieta l’uso dei telefoni a scuola

editorialedomani.it/fatti/scuo…

@scuola

Unknown parent

mastodon - Collegamento all'originale

Comandante Virgola

@mrphelz @sposadelvento @macfranc @giacomo
amica prof di matematica: il libro costa dieci sacchi, ed è sempre lo stesso da anni (così i ragazzi possono comprarlo usato) : cambiano solo le pagine degli esercizi (la Matematica ancora non è cambiata 🤭) e basta solo sfogliare un po' per trovare gli stessi esercizi anche a pagine diverse. Certo i rappresentanti delle case editrici vengono tutti gli anni con nuove edizioni, più care ovviamente, ma le copie campione finiscono in biblioteca per le cessioni in uso gratuito ai non abbienti
in reply to YetoLake

The media in this post is not displayed to visitors. To view it, please go to the original post.

devi ringraziare @Godai71 che mi ha segnalato il tuo post 😅

A questo proposito, ricordati in futuro di aggiungere l'hashtag #mastoaiuto che è fatto espressamente per mastodon, ma che può essere utilizzato per tutti gli utenti mastodon che hanno bisogno di supporto.

Inoltre puoi utilizzare anche i gruppi tematici italiani come @fediverso@feddit.it (su feddit.it) o @fediverso@diggita.com (su diggita.com) o @forum (per gli utenti Friendica)

Se non sai cosa sono i gruppi: ⬇️

informapirata.it/2025/02/03/i-…


I Gruppi del Fediverso: un modo per incontrare altri utenti Mastodon, Friendica o Pixelfed in base ai loro interessi

Il Fediverso è un luogo fatto soprattutto di interazioni sociali ma rispetto ai social commerciali non è facilissimo trovare utenti che condividano i nostri stessi interessi. Ecco come giocarsi la carta dei “Gruppi”

informapirata.it/2025/02/03/i-…

#Calabria #Campania #comunità #Fediverso #Friendica #gruppi #Lemmy #Mastodon

informapirata.it/2025/02/03/i-…


Voltmeter Clock Has The Time Dialled In


The media in this post is not displayed to visitors. To view it, please log in.

You could make a clock with three hands spinning about nested central shafts. If you did that, we probably wouldn’t publish it on Hackaday unless you really found a way to make it interesting. Make a clock out of voltmeters, however, and that usually catches our eye. [lcamtuf] has done just that.

The heart of the build is an AVR128DB28 microcontroller, an 8-bit microcontroller that is still currently in production. It runs at 8MHz, and drives a series of three Baomain 65C5 voltmeters to display hours, minutes, and seconds. Each has a custom printed face with the correct number of 13 or 61 divisions as needed. The voltmeters are driven by a continuous stream of 1-bit pulses with a software-controlled duty cycle determining exactly how far the needle moves. Yes, it’s using simple pulse width modulation, coded by hand by [lcamtuf] to do the job. All the components are wrapped up in a beautiful wooden case, with delicately kerf-bent panels to create the attractive curved lines.

We’ve featured similar builds before, too. As it turns out, hackers just really love clocks and old-school dials. Video after the break, which is worth watching for the rollover behaviour alone.

player.vimeo.com/video/1192897…


hackaday.com/2026/05/18/voltme…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

CVE-2026-42897: vulnerabilità critica XSS in Exchange Server OWA — mitigazione di emergenza disponibile
#tech
spcnet.it/cve-2026-42897-vulne…
@informatica


CVE-2026-42897: vulnerabilità critica XSS in Exchange Server OWA — mitigazione di emergenza disponibile


Cos’è la vulnerabilità CVE-2026-42897


Il 14 maggio 2026 Microsoft ha divulgato pubblicamente una vulnerabilità critica nei propri server Exchange on-premises, tracciata come CVE-2026-42897. La falla, classificata come Cross-Site Scripting (XSS), risiede nel componente Outlook Web Access (OWA) e permette a un attaccante di eseguire codice JavaScript arbitrario nel browser della vittima senza richiedere alcuna interazione complessa: è sufficiente che l’utente apra una email appositamente confezionata direttamente dalla webmail.

La vulnerabilità è già sfruttata attivamente in the wild: la CISA (Cybersecurity and Infrastructure Security Agency) degli Stati Uniti l’ha aggiunta al proprio catalogo di vulnerabilità note e sfruttate (Known Exploited Vulnerabilities) con scadenza obbligatoria di remediation al 29 maggio 2026 per le agenzie federali americane. Il rischio per le organizzazioni private è ugualmente elevato.

Versioni di Exchange Server interessate


La vulnerabilità colpisce esclusivamente i server Exchange installati on-premises. In particolare:

  • Exchange Server 2016
  • Exchange Server 2019
  • Exchange Server Subscription Edition (SE)

Exchange Online non è interessato: le organizzazioni che utilizzano esclusivamente il servizio cloud Microsoft 365 non devono intraprendere alcuna azione. Il rischio è confinato a chi gestisce ancora infrastrutture Exchange on-premises, scenario ancora comune in contesti enterprise con requisiti di compliance, residenza del dato o integrazione con sistemi legacy.

Come funziona l’attacco


Il vettore di attacco è particolarmente insidioso perché non richiede configurazioni particolari lato vittima: l’attaccante invia una email con contenuto HTML appositamente costruito. Quando il destinatario apre il messaggio tramite OWA, il payload JavaScript viene eseguito nel contesto del browser dell’utente, con accesso alla sessione OWA attiva.

Le conseguenze possibili includono:

  • Furto del cookie di sessione e hijacking dell’account
  • Esecuzione di azioni per conto dell’utente (invio email, accesso a cartelle, lettura di allegati)
  • Lateral movement verso altri sistemi integrati con Exchange (es. Active Directory, SharePoint)
  • Esfiltrazione di dati sensibili contenuti nelle caselle di posta

In un ambiente enterprise, un attacco XSS riuscito contro OWA può essere il punto di ingresso per una compromissione ben più ampia, specialmente se la webmail è accessibile dall’esterno o da reti non completamente fidate.

Mitigazioni disponibili: come intervenire subito


Microsoft ha rilasciato mitigazioni di emergenza in attesa di una patch definitiva. Esistono due percorsi principali:

1. Exchange Emergency Mitigation Service (EM Service)


Il metodo preferito è affidarsi all’Exchange Emergency Mitigation Service, che applica automaticamente una configurazione di URL Rewrite sul server IIS per neutralizzare il vettore di attacco. Il servizio EM è abilitato per default nelle installazioni supportate di Exchange Server. Se non è stato disabilitato manualmente, la mitigazione potrebbe già essere attiva.

Per verificare lo stato della mitigazione, Microsoft raccomanda di eseguire il tool Exchange Health Checker:

# Scarica ed esegui Exchange Health Checker in una Exchange Management Shell elevata
. .\HealthChecker.ps1
Invoke-HealthChecker


Il report generato indica chiaramente se la mitigazione M2 per CVE-2026-42897 è stata applicata con successo.

2. Exchange On-Premises Mitigation Tool (EOMT) per ambienti air-gap


Per i server Exchange non connessi a internet o in ambienti con restrizioni di rete, Microsoft ha reso disponibile una procedura di mitigazione manuale tramite lo strumento EOMT (Exchange On-Premises Mitigation Tool):

# Download da: https://aka.ms/UnifiedEOMT
# Eseguire da una Exchange Management Shell con privilegi elevati

.\EOMTv2.ps1 -ExchangeVersion 2019


Dopo l’applicazione, è fondamentale verificare che le regole di URL Rewrite siano state create correttamente e che il servizio IIS sia stato riavviato.

Impatto sulle funzionalità di OWA dopo la mitigazione


L’applicazione della mitigazione introduce alcune limitazioni funzionali che gli amministratori devono comunicare agli utenti:

  • Immagini inline nelle email: potrebbero non essere visualizzate correttamente nel pannello di lettura di OWA. La soluzione alternativa è inviare le immagini come allegati o usare il client Outlook desktop.
  • Stampa del calendario da OWA: la funzione potrebbe non operare. Gli utenti possono utilizzare screenshot o Outlook desktop come workaround.
  • OWA Light (interfaccia legacy): già deprecata, potrebbe smettere di funzionare completamente. Non è una perdita significativa per la maggior parte delle organizzazioni.

Queste limitazioni sono accettabili rispetto al rischio rappresentato dalla vulnerabilità non mitigata.

Patch definitiva: cosa aspettarsi


Microsoft sta lavorando a un aggiornamento di sicurezza permanente. Un dettaglio importante per chi gestisce Exchange 2016 e 2019: le patch ufficiali saranno rilasciate solo per i clienti commerciali iscritti al programma ESU (Extended Security Update). Exchange 2016 ha raggiunto la fine del supporto mainstream nell’ottobre 2025, e Exchange 2019 raggiungerà la stessa condizione nell’ottobre 2025. Le organizzazioni che non hanno sottoscritto l’ESU si troveranno senza patch definitiva e dovranno affidarsi esclusivamente alla mitigazione di emergenza, con un rischio residuo crescente nel tempo.

Questo scenario rafforza l’urgenza di pianificare una migrazione verso Exchange Server SE o Exchange Online per chi è ancora su versioni precedenti.

Checklist di risposta per gli amministratori


Se gestisci un’infrastruttura Exchange on-premises, ecco le azioni da completare nell’ordine:

  1. Verifica la versione di Exchange in uso: apri la Exchange Management Shell e lancia Get-ExchangeServer | Select Name,AdminDisplayVersion
  2. Controlla se il servizio EM è attivo: Get-Service MSExchangeMitigation
  3. Esegui Exchange Health Checker per verificare l’applicazione della mitigazione M2
  4. Se l’EM Service è disabilitato o il server è air-gapped, applica EOMT manualmente
  5. Comunica agli utenti le limitazioni temporanee di OWA
  6. Monitora il blog ufficiale di Exchange (techcommunity.microsoft.com) per il rilascio della patch definitiva
  7. Valuta l’iscrizione al programma ESU se stai usando Exchange 2016 o 2019


Conclusione


CVE-2026-42897 è un esempio concreto di come le infrastrutture on-premises legacy rimangano vettori di attacco critici anche in ambienti enterprise ben gestiti. La buona notizia è che Microsoft ha reagito rapidamente con mitigazioni di emergenza e ha reso la verifica dello stato accessibile tramite strumenti già noti come Exchange Health Checker. La cattiva notizia è che chi non ha ancora pianificato l’uscita da Exchange 2016/2019 si trova in una posizione sempre più rischiosa, non solo per questa vulnerabilità ma per tutte quelle future che non riceveranno patch ufficiali.

Applicare la mitigazione adesso, verificarne l’efficacia e pianificare la migrazione al più presto sono le tre priorità concrete da portare all’attenzione del management tecnico questa settimana.


Fonte: Microsoft Warns Exchange Server Flaw Lets Attackers Execute Code via OWA Emails – Petri IT Knowledgebase | Microsoft Tech Community – Addressing Exchange Server May 2026 vulnerability


Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

I colli di bottiglia nascosti nei microservizi in produzione: diagnostica e soluzioni pratiche
#tech
spcnet.it/i-colli-di-bottiglia…
@informatica


I colli di bottiglia nascosti nei microservizi in produzione: diagnostica e soluzioni pratiche


Il problema che non si vede finché è troppo tardi


C’è un pattern ricorrente nelle architetture a microservizi: tutto funziona in modo impeccabile per mesi, i test automatici sono verdi, il monitoraggio non mostra allarmi rilevanti, e il team è soddisfatto della solidità del sistema. Poi, spesso durante un picco di traffico ordinario o un evento previsto, qualcosa si inceppa. La latenza schizza verso l’alto, le code si allungano, i timeout si moltiplicano. Il problema non è stato causato dall’evento in sé — era già lì, nascosto sotto la superficie.

Questo articolo analizza i colli di bottiglia più insidiosi che affliggono i microservizi in produzione: quelli che non emergono nei test di carico standard e che vengono spesso diagnosticati troppo tardi.

1. Esaurimento del connection pool al database


Il problema del connection pool è forse il più comune e il meno visibile fino al momento critico. In un’architettura a microservizi, ogni istanza di ogni servizio apre e gestisce il proprio pool di connessioni al database. Il calcolo è semplice: se hai 10 microservizi con 5 istanze ciascuno e ogni istanza mantiene un pool di 10 connessioni, stai occupando 500 connessioni sul database. Scala orizzontalmente per gestire un picco di traffico, e quelle connessioni raddoppiano in pochi minuti.

La maggior parte dei database relazionali ha un limite fisico di connessioni concorrenti. PostgreSQL, per esempio, ha un default di 100 connessioni per il parametro max_connections. Superato il limite, nuove richieste di connessione falliscono con errori che spesso vengono nascosti da retry automatici, mascherando il problema effettivo fino a quando il sistema non collassa.

Come diagnosticarlo

-- PostgreSQL: connessioni attive per applicazione
SELECT application_name, count(*), state
FROM pg_stat_activity
GROUP BY application_name, state
ORDER BY count DESC;

-- Verifica il limite configurato
SHOW max_connections;


Come risolverlo


La soluzione più efficace per scenari ad alta concorrenza è l’uso di un connection pooler esterno come PgBouncer. PgBouncer opera in modalità transaction pooling: riusa le connessioni al database tra più client, riducendo drasticamente il numero di connessioni fisiche necessarie indipendentemente dal numero di istanze dei servizi.

# pgbouncer.ini — configurazione essenziale
[databases]
mydb = host=pg-primary port=5432 dbname=mydb

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20
reserve_pool_size = 5


In .NET, assicurati che il pool di connessioni Npgsql sia configurato in modo coerente con i limiti imposti da PgBouncer:
// Connection string con pool sizing esplicito
"Host=pgbouncer-host;Database=mydb;Username=app;Password=...;
 Maximum Pool Size=10;Minimum Pool Size=2;Connection Idle Lifetime=300"


2. Thread pool starvation nelle chiamate sincrone


Il thread pool starvation è un problema particolarmente subdolo nelle applicazioni ASP.NET Core o nelle applicazioni Spring Boot che mischiano codice asincrono e sincrono. Quando un thread del pool viene bloccato in attesa di un’operazione I/O (una query al database, una chiamata HTTP a un servizio dipendente, una lettura da file), quel thread non è disponibile per elaborare nuove richieste. Se questo accade su scala, il thread pool si esaurisce e le nuove richieste rimangono in coda indefinitamente.

Il sintomo tipico è una degradazione progressiva delle performance durante i picchi: il throughput crolla, i tempi di risposta salgono in modo apparentemente inspiegabile, ma il database e la CPU risultano ancora sotto carico normale.

Pattern da evitare in .NET

// ❌ SBAGLIATO: blocca un thread del pool
public IActionResult GetData()
{
    var result = _service.GetDataAsync().Result; // .Result blocca il thread
    return Ok(result);
}

// ❌ Altrettanto problematico
public IActionResult GetData()
{
    var result = _service.GetDataAsync().GetAwaiter().GetResult();
    return Ok(result);
}

// ✅ CORRETTO: il thread viene restituito al pool durante l'attesa
public async Task<IActionResult> GetData()
{
    var result = await _service.GetDataAsync();
    return Ok(result);
}


Come diagnosticare il thread pool starvation


In .NET, puoi monitorare lo stato del thread pool a runtime:

ThreadPool.GetAvailableThreads(out int workerThreads, out int completionPortThreads);
ThreadPool.GetMaxThreads(out int maxWorker, out int maxCompletionPort);

// Se workerThreads è vicino a 0 con carico moderato, sei in starvation
Console.WriteLine($"Available: {workerThreads}/{maxWorker}");


Strumenti come dotnet-counters offrono un monitoraggio continuo in produzione senza impatto significativo:
dotnet-counters monitor --counters System.Runtime[threadpool-thread-count,threadpool-queue-length] -p <PID>


3. Cascading failures per dipendenze lente o non responsive


In un’architettura a microservizi, ogni servizio dipende da altri servizi. Questa catena di dipendenze è la fonte di uno dei problemi più difficili da gestire in produzione: il cascading failure. Se il Servizio B risponde lentamente, il Servizio A che lo chiama accumula richieste in attesa. I thread del pool di A vengono occupati in attesa di B, la latenza di A aumenta, il Servizio C che dipende da A inizia a ricevere timeout, e nel giro di pochi minuti l’intera catena collassa.

La soluzione consolidata è il pattern Circuit Breaker, che interrompe temporaneamente le chiamate verso un servizio degradato e restituisce immediatamente un errore (o una risposta di fallback), permettendo al sistema di degradare in modo controllato invece di collassare a cascata.

Implementazione con Polly in .NET

// Configurazione circuit breaker con Polly v8
var circuitBreakerPolicy = new ResiliencePipelineBuilder()
    .AddCircuitBreaker(new CircuitBreakerStrategyOptions
    {
        FailureRatio = 0.5,              // Apre dopo il 50% di fallimenti
        SamplingDuration = TimeSpan.FromSeconds(10),
        MinimumThroughput = 10,          // Minimo 10 richieste nel campione
        BreakDuration = TimeSpan.FromSeconds(30), // Attende 30s prima di riprovare
        OnOpened = args =>
        {
            _logger.LogWarning("Circuit breaker aperto per {Service}", serviceName);
            return default;
        }
    })
    .AddTimeout(TimeSpan.FromSeconds(3)) // Timeout esplicito su ogni chiamata
    .Build();

// Uso
var result = await circuitBreakerPolicy.ExecuteAsync(async token =>
    await _httpClient.GetFromJsonAsync<OrderDto>("/api/orders/123", token),
    cancellationToken);


4. Mancanza di backpressure nei flussi di messaggi


I sistemi basati su message broker (Kafka, RabbitMQ, Azure Service Bus) introducono un’ulteriore classe di colli di bottiglia: quando il ritmo di produzione dei messaggi supera la capacità di elaborazione dei consumer, le code crescono indefinitamente. Questo può portare a latenza crescente nell’elaborazione, out-of-memory degli broker, e scenari in cui messaggi vengono elaborati con ore o giorni di ritardo rispetto alla loro produzione.

La soluzione è implementare la backpressure: i consumer controllano attivamente il ritmo di ricezione in base alla propria capacità di elaborazione. In Kafka, questo si gestisce configurando correttamente il numero di partizioni, il numero di consumer nel consumer group, e i parametri max.poll.records e fetch.max.bytes.

// Esempio: consumer con controllo esplicito del concurrency via MassTransit
services.AddMassTransit(x =>
{
    x.UsingRabbitMq((ctx, cfg) =>
    {
        cfg.ReceiveEndpoint("orders-queue", e =>
        {
            e.PrefetchCount = 10;        // Non prelevare più di 10 messaggi alla volta
            e.ConcurrentMessageLimit = 5; // Elabora al massimo 5 messaggi in parallelo
            e.ConfigureConsumer<OrderConsumer>(ctx);
        });
    });
});


5. N+1 queries non rilevate in produzione


Il problema delle N+1 queries è ben noto in teoria ma sorprendentemente comune in produzione, soprattutto dopo refactoring o l’aggiunta di nuove funzionalità. L’ORM carica una lista di entità (1 query), poi per ogni entità carica lazy una relazione (N query). In sviluppo, con 10 elementi nel database, il problema è invisibile. In produzione, con 10.000 elementi, si traducono in 10.001 query per ogni richiesta.

// ❌ N+1: per ogni ordine viene eseguita una query separata per i prodotti
var orders = await _context.Orders.ToListAsync();
foreach (var order in orders)
{
    // Lazy load: ogni accesso a order.Products genera una nuova query
    var productNames = order.Products.Select(p => p.Name);
}

// ✅ Eager loading: una sola query con JOIN
var orders = await _context.Orders
    .Include(o => o.Products)
    .ToListAsync();


Per rilevare le N+1 in produzione, abilita il logging delle query EF Core in ambiente di staging con soglia di warning per query lente:
// Program.cs
builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information)
           .EnableSensitiveDataLogging(false) // Mai in produzione
           .ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning)));


Monitoraggio proattivo: gli indicatori chiave


Rilevare questi problemi prima che diventino incidenti richiede un set di metriche mirate. Oltre alle metriche standard (CPU, RAM, latenza), monitora attivamente:

  • Connessioni attive al database per istanza e per servizio
  • Thread pool queue length: una coda crescente anche sotto carico moderato è un segnale di allarme
  • Circuit breaker state changes: ogni apertura di un circuit breaker è un evento da tracciare e analizzare
  • Message lag sulle code Kafka/RabbitMQ: il ritardo tra produzione e consumo
  • Slow queries: percentuale di query che superano una soglia prefissata (es. 500ms)

Strumenti come Prometheus + Grafana con i rispettivi exporter per PostgreSQL, RabbitMQ e .NET (via prometheus-net) permettono di costruire dashboard specifiche per questi pattern senza dipendere esclusivamente dai log.

Conclusione


I colli di bottiglia nascosti nei microservizi hanno una caratteristica comune: emergono sotto carico, in condizioni che i test standard non replicano fedelmente. Connection pool esauriti, thread in starvation, cascading failures, code in crescita incontrollata e N+1 queries sono problemi architetturali che richiedono attenzione già in fase di design, non solo quando il sistema è già in produzione e sotto stress.

Identificare preventivamente questi pattern, configurare correttamente i pool e i circuit breaker, e costruire un layer di osservabilità specifico per questi indicatori è l’investimento tecnico con il miglior ritorno in termini di stabilità per qualsiasi sistema distribuito di dimensioni non banali.


Fonte: The Hidden Bottlenecks That Break Microservices in Production – DZone


Cybersecurity & cyberwarfare ha ricondiviso questo.

📺 NCSC’s Ollie Whitehouse on surviving the "bugpocalypse"

risky.biz/video/ncscs-ollie-wh…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

New: NYC Health and Hospitals says a data breach earlier this year affects 1.8 million people. Hackers stole personal info, medical data, government-issued IDs, Social Security numbers — and *biometrics*, including fingerprints and palm scans.

Already one of the largest healthcare breaches of 2026.

techcrunch.com/2026/05/18/nyc-…

reshared this

Cybersecurity & cyberwarfare ha ricondiviso questo.

#Grafana confirms #GitHub token breach cybercrime group claims the attack
securityaffairs.com/192347/cyb…
#securityaffairs #hacking

Long-Range Night Vision with an Infrared Laser


The media in this post is not displayed to visitors. To view it, please log in.

A 3D-printed telescope with an infrared laser on the side is pointed out the window of a building at night.

Most consumer-grade night vision devices are basically a standard camera without the usual filter to block near infrared (NIR) light, which are then paired with a NIR light source that’s not visible to the human eye. Unlike the passive night vision provided by a photomultiplier tube, these can’t resolve objects beyond the beam of their illumination source. On the other hand, if, as [Project 326] did, you use an infrared laser to illuminate the scene, you can still get a very long range out of these devices.

[Project 326]’s device consists of a previously-built reflecting telescope focusing a distant scene in to a webcam with the infrared filter removed, with the infrared laser illuminating the scene. Finding a suitable laser took some effort: the first option, a secondhand fiber-coupled industrial laser, was accidentally over-volted and destroyed during testing. The second had a fiber output which proved extremely hard to terminate, and a third laser couldn’t be collimated correctly. The final laser was a Vertical-Cavity Surface-Emitting Laser (VSEL) diode array element driven at about two Watts and collimated by a small lens.

This illumination setup is safe at a long range, but only at a long range. The laser was strong enough to burn cardboard at close range, but out at about 500 meters, the beam had spread until it was less than a hundredth of the standard safety limit. To make sure that nothing else would get in the way of the beam, it was shone down from the top of a tall building. Testing with a power meter also showed that at a long range, the beam was weaker than expected. It turned out that the wavelength used (940 nm) is attenuated by water vapor, to the point that up to 70% of the beam’s strength was lost before reaching the target. Despite this, and despite a rather linear beam profile, a somewhat dark image was still visible at 650 meters.

If you’re looking for a somewhat more versatile long-range night vision device, check out one based on a photomultiplier tube. Another approach is to use a very high-sensitivity camera.

youtube.com/embed/hhS44J2Wpo8?…

Thanks to [Keith Olson] for the tip!


hackaday.com/2026/05/18/long-r…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici
#CyberSecurity
insicurezzadigitale.com/uat-86…


UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182


Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde


Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

  • Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
  • Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
  • Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
  • Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.


Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione


Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

  • SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
  • Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
  • Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
  • Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
  • Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.


Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi


CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori


Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

  • Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
  • Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
  • Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
  • Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
  • Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.


CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI
#CyberSecurity
insicurezzadigitale.com/mini-s…


Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza


Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione


La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso


Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali


Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche


OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack


L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

How To Make Steel That Breathes


The media in this post is not displayed to visitors. To view it, please log in.

There are plenty of porous materials out there that we’re all readily familiar with. Fabrics and wood are great examples, allowing liquids or gases to pass through to a certain degree—a property which is useful or problematic depending on the application.

Metals, however, are not something we would readily consider to be porous. They are solid, unyielding, and impermeable. However, with the right techniques, it is possible to produce so-called “breathable” steel, which has particularly interesting applications in the molding industry.

Breathe Into Me And Make Me Real


Imagine you’re making tooling for an injection molding operation. You’re using steel, of course, because you need a hard, resilient material that can deal with the high temperatures and pressures involved. It’s tough, and readily able to be machined into the desired geometry for your application. Of course, it doesn’t let liquid or gas pass, since it’s a solid impermeable material. This means that when you inject your mold full of hot plastic, you need to find somewhere for the air inside to go. Otherwise, the gas in the mold will end up dissolved in the molten plastic, causing voids, surface imperfections, and other irregularities. Chasing away gas porosity defects in finished parts is one of the major jobs of casting engineers the world over, an endless battle against the forces of heat transfer and fluid mechanics.

Traditionally, this is deal by designing a mold with exhaust ports or vacuum hookups to allow the air to vent out as needed. This takes a great deal of work to get right, particularly when it comes to getting your defect rates as low as possible in mass production. If your gas can’t vent fast enough, or if there are areas where it gets trapped, you end up with defects, and you have to go back to the drawing board.

Breathable mold steel attempts to solve this problem by venting gas through the tooling itself. It allows the creation of a steel mold that is full of tiny little pores that allow air to pass through, while still acting largely impermeable to the molten plastic being molded.

View this post on Instagram


Breathable mold steel is quite something to behold, behaving quite unlike a normal steel part in this regard.

As you might imagine, it’s quite difficult to make a steel mold with complex geometry that also has lots of tiny contiguous holes that allow gases to pass through. It is possible, however, by using some tricky additive manufacturing techniques.
By mixing a foaming agent into powder metal for selective laser melting (SLM) printing, it’s possible to generate interconnected micrometer-scale pores in steel that allow it to ‘breathe’. The pores are generated by the gas released during the heat-based decomposition of the foaming agent. Credit: research paper
As outlined in one research paper, it’s possible to produce breathable steel via selective laser melting (SLM) 3D printing techniques. This involves using a high-powered laser to fuse metal powder together, layer by layer, to produce a final part. Combining a foaming agent with the metal powder enables the creation of 3D-printed metal parts with incredibly fine interconnected pores.

The pores need to be particularly small, on the order of 80 micrometers or less, such that they allow gas in the mold to pass freely while blocking the flow of the larger polymer molecules of the injected plastic.

Chromium nitride is one foaming agent typically used, for the fact that the Cr and N released during its decomposition both lend beneficial properties to the steel of the finished product. The foaming agent is mixed in with the steel powder, and melts along with it as the part is being produced. The breakdown of the foaming agent releases gas bubbles which creates pores in the steel part as it is produced in a relatively predictable manner.
Microscope images of breathable steel samples produced with 3% CrNx and 5% CrNx foaming agent, respectively. Credit: research paper
The level of porosity can be controlled by the amount of foaming agent mixed in to the steel powder, as well as the laser settings. Lower melt pool temperatures caused by faster scanning speeds or lower laser powers tend to favor more porous structures, due to the fluid mechanics involved and how the cooler liquid steel flows into existing pores.

There have been earlier attempts to vent molds with special breathable steel inserts in the past. These consist of premade rectangular inserts or round bars which have been made with so-called “ventilated steel” like PM-35. This material is made by sintering steel powders together in such a way to create a porosity of 20-30%. However, this process isn’t always great for advanced geometry that one might find in a injection mold. Thus, the creation of breathable rods and bars that can be used as an insert in a larger mold, acting as a localized vent. It’s a useful technique, but comes with more constraints on mold and part geometry than being able to simply create the whole mold itself out of breathable steel.
Micro-CT images of a breathable steel sample. Credit: research paper
There are other powder metal techniques that allow the production of more complex vented parts, but they can be expensive and difficult to execute well down to smaller pore sizes, especially compared to the simplicity of SLM printing with an additional foaming agent. The 3D-printing based process has also proven to have more admirable mechanical properties compared to products like PM-35 steel in some cases, with impressive compressive strength as well as hardness and corrosion resistance.

Breathable steel is probably not something you’ll come across in your everyday life unless you happen to work in particular manufacturing fields. Still, if you have the expensive 3D printing hardware on hand to work with metal powders, and you really want to make a complex metal part that’s also porous, this is a great way to go. You could probably use it to make some very weird magic tricks at the very least. Ultimately, it just goes to show that modern material processing techniques can upend everything we think we know about a common material like steel. It’s amazing what can be done!


hackaday.com/2026/05/18/how-to…

The media in this post is not displayed to visitors. To view it, please log in.

Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


@Informatica (Italy e non Italy)
Tra il 11 e il 14 maggio 2026, il gruppo TeamPCP ha compromesso oltre 160 pacchetti npm e 2 PyPI in un supply chain attack di nuova generazione


Mini Shai-Hulud: TeamPCP compromette 160+ pacchetti npm e PyPI in un supply chain attack che ha colpito TanStack, Mistral AI e OpenAI


Tra il 11 e il 14 maggio 2026, un attore di minacce tracciato come TeamPCP ha sferrato uno dei supply chain attack più sofisticati mai documentati nell’ecosistema open source: oltre 160 pacchetti npm e 2 pacchetti PyPI compromessi, tra cui componenti del popolare framework TanStack, librerie di Mistral AI e UiPath, e il fondamentale pacchetto node-ipc con 822.000 download settimanali. L’operazione, ribattezzata “Mini Shai-Hulud” dai ricercatori di Wiz, ha colpito le pipeline di sviluppo di migliaia di organizzazioni — inclusi due dipendenti di OpenAI — e ha dimostrato come un singolo punto debole nelle GitHub Actions possa trasformarsi in una bomba a orologeria lungo tutta la catena del software.

L’innesco: tre vulnerabilità GitHub Actions in sequenza


Il vettore iniziale dell’attacco non è stato una vulnerabilità nei pacchetti stessi, ma nell’infrastruttura CI/CD che li gestisce. TeamPCP ha sfruttato una catena di tre vulnerabilità nelle GitHub Actions, secondo quanto ricostruito dai ricercatori di Wiz e Orca Security. L’attaccante ha creato un fork del repository TanStack/router, ha aperto una pull request che ha innescato un workflow pull_request_target — una tipologia di workflow che, a differenza di pull_request, viene eseguita con i permessi completi del repository originale anche per PR da fork esterni — e ha avvelenato la cache pnpm di GitHub Actions con un payload malevolo.

Una volta avvelenata la cache, il malware si è auto-propagato: ogni volta che il workflow legittimo veniva eseguito, invece di scaricare le dipendenze originali recuperava le versioni compromesse dalla cache infetta. Questo meccanismo di auto-propagazione — il “worm” di Mini Shai-Hulud — ha permesso la compromissione a cascata di tutti i namespace associati al progetto.

I 373 pacchetti compromessi: la portata dell’operazione


La scala dell’attacco è stata eccezionale. In totale, 373 versioni malevole sono state pubblicate su npm, distribuite su 169 nomi di pacchetti distinti. I namespace colpiti includono @tanstack (83 voci: router, start, devtools e adapter packages), @uipath (66 voci), @squawk (87 voci), @mistralai, @tallyui, @beproduct e numerosi pacchetti non con scope. Su PyPI, i pacchetti colpiti sono stati guardrails-ai 0.10.1 e mistralai 2.4.6.

La natura cross-namespace dell’attacco è significativa: le organizzazioni che utilizzavano librerie di vendor diversi (UiPath per l’automazione, Mistral AI per i modelli LLM, TanStack per il routing frontend) erano tutte vulnerabili nello stesso intervallo temporale, senza che esistesse un singolo punto di allerta evidente.

node-ipc: il payload più insidioso


Parallelamente alla compromissione via GitHub Actions, TeamPCP ha eseguito un attacco separato ma correlato contro node-ipc, un pacchetto fondamentale di Node.js per la comunicazione inter-processo con oltre 10 milioni di download settimanali. Tre versioni malevole (9.1.6, 9.2.3 e 12.0.1) sono state pubblicate il 14 maggio 2026 tramite un account maintainer compromesso attraverso una tecnica di account takeover mirata.

L’attaccante aveva re-registrato il dominio atlantis-software.net — scaduto il 10 gennaio 2025 — il 7 maggio 2026 tramite Namecheap, e aveva utilizzato la procedura standard di reset password di npm per ottenere i permessi di pubblicazione senza che il maintainer originale venisse avvisato. Le versioni malevole contenevano un payload da 80 KB, fortemente offuscato, che veniva iniettato come IIFE (Immediately Invoked Function Expression) alla fine del file node-ipc.cjs.

Cosa rubava il malware: 90+ categorie di credenziali


Una volta caricato tramite require('node-ipc'), il payload eseguiva silenziosamente un harvesting massiccio di credenziali: chiavi AWS, Azure e GCP, chiavi SSH private, token Kubernetes, configurazioni GitHub CLI, impostazioni di Claude AI e dell’IDE Kiro, stati Terraform, password di database, cronologia della shell e molto altro — oltre 90 categorie di segreti in totale. I dati venivano compressi in un archivio gzip e esfiltrati verso un server controllato dagli attaccanti che si mascherava da infrastruttura Azure.

Prima di procedere, il payload effettuava un fingerprint SHA-256 dell’ambiente, confrontandolo con un hash hardcoded assemblato da otto frammenti offuscati presenti nel codice — presumibilmente per evitare l’esecuzione in sandbox di analisi. Le versioni malevole sono rimaste attive sul registry per circa due ore prima del rilevamento e della rimozione da parte di npm. Qualsiasi progetto che abbia eseguito npm install o aggiornato automaticamente le dipendenze in quella finestra temporale deve essere considerato potenzialmente compromesso.

OpenAI e Mistral AI tra le vittime: le implicazioni sistemiche


OpenAI ha confermato che due dispositivi di dipendenti nel suo ambiente aziendale sono stati compromessi nell’attacco. L’azienda ha ingaggiato una società di incident response, ha ruotato i certificati di firma del codice per le applicazioni macOS e ha dichiarato di non aver trovato evidenze di accesso a dati utente, sistemi di produzione o proprietà intellettuale. Mistral AI ha visto le sue librerie ufficiali compromise, sollevando preoccupazioni immediate tra gli sviluppatori che le utilizzano per integrare capacità AI nei loro applicativi.

Il fatto che TeamPCP abbia preso di mira specificamente pacchetti di aziende AI leader — Mistral AI, e indirettamente OpenAI attraverso i suoi sviluppatori — non è casuale: i developer che lavorano con questi strumenti hanno tipicamente accesso a chiavi API di alto valore, ambienti cloud critici e codice sorgente sensibile. I repo di Mistral AI rubati sono stati successivamente messi in vendita da TeamPCP, confermando la doppia finalità dell’operazione: furto di credenziali e esfiltrazione di proprietà intellettuale.

Difendersi dalla nuova generazione di supply chain attack


L’attacco di Mini Shai-Hulud rappresenta una nuova classe di minaccia per la quale molte organizzazioni non sono ancora attrezzate. La compromissione non avviene attraverso vulnerabilità nel codice stesso, ma nell’infrastruttura di distribuzione. Alcune misure pratiche per i difensori includono il pinning delle versioni esatte dei pacchetti (evitando range semver come ^1.2.3 o ~1.2.3), l’utilizzo di un lockfile verificato e mantenuto nel controllo versione, l’auditing regolare delle dipendenze con strumenti come npm audit o Snyk, e la verifica dell’integrità dei pacchetti tramite hash SHA-512 dove disponibili.

Sul fronte CI/CD, è fondamentale limitare i permessi dei workflow GitHub Actions, evitare l’uso di pull_request_target con checkout del codice della PR, e implementare cache poisoning prevention attraverso la verifica dell’integrità della cache. Le organizzazioni che hanno eseguito build tra il 11 e il 14 maggio 2026 utilizzando i namespace colpiti dovrebbero effettuare una revisione completa dei secret esposti.

Indicatori di Compromissione (IoC)

# Mini Shai-Hulud / TeamPCP Supply Chain Attack - Maggio 2026
# Fonti: Wiz, Orca Security, Snyk, StepSecurity

# Pacchetti npm malevoli (esempi principali)
node-ipc: 9.1.6, 9.2.3, 12.0.1
@tanstack/router: versioni pubblicate 11-14 maggio 2026
@mistralai/mistralai: 2.4.6 (correlato)

# Pacchetti PyPI malevoli
guardrails-ai==0.10.1
mistralai==2.4.6

# Account maintainer compromesso (node-ipc)
npm user: atiertant (a.tiertant@atlantis-software.net)
Dominio re-registrato: atlantis-software.net (7 maggio 2026)

# Tecniche MITRE ATT&CK
T1195.001 - Supply Chain Compromise: Compromise Software Dependencies
T1059.007 - Command and Scripting Interpreter: JavaScript
T1552.001 - Unsecured Credentials: Credentials in Files
T1041     - Exfiltration Over C2 Channel (verso infrastruttura Azure-like)

# Indicatori comportamentali
- Processi Node.js che effettuano richieste HTTP inattese post-installazione
- Archivi gzip creati in directory temporanee durante npm install
- Chiamate a endpoint Azure non riconosciuti da processi build

# Verifica hash (node-ipc versioni legittime)
SHA-256 v9.1.5 legittima: verificare su https://registry.npmjs.org/node-ipc/9.1.5

Fonti: Wiz Blog, Orca Security, The Hacker News, BleepingComputer, OpenAI Blog

The media in this post is not displayed to visitors. To view it, please log in.

UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


@Informatica (Italy e non Italy)
Un threat actor altamente sofisticato, UAT-8616, sfrutta CVE-2026-20182 — vulnerabilità critica CVSS 10.0 nel Cisco Catalyst SD-WAN — per compromettere organizzazioni governative, diplomatiche e


UAT-8616: il gruppo d’élite sfrutta il sesto zero-day Cisco SD-WAN e prende di mira governi europei e asiatici


Un threat actor di altissimo livello, tracciato da Cisco Talos come UAT-8616, sta sfruttando attivamente una vulnerabilità critica nei controller Cisco Catalyst SD-WAN — la sesta zero-day sfruttata su questa piattaforma nel solo 2026. Con un CVSS di 10.0, la falla consente a un attaccante non autenticato di ottenere privilegi amministrativi completi su dispositivi SD-WAN esposti su internet, prendendo di mira settori governativi, diplomatici e della difesa in Europa e Asia Centrale.

La Sesta Zero-Day in Sei Mesi: CVE-2026-20182


Il 15 maggio 2026, la CISA (Cybersecurity and Infrastructure Security Agency) ha aggiunto CVE-2026-20182 al suo catalogo di vulnerabilità attivamente sfruttate (KEV — Known Exploited Vulnerabilities), imponendo alle agenzie federali civili statunitensi di applicare la patch entro il 17 maggio. La vulnerabilità risiede nel processo di handshake del controllo peering via protocollo DTLS sulla porta 12346 del Cisco Catalyst SD-WAN Controller e Manager.

In termini pratici, un attaccante remoto e non autenticato può autenticarsi come peer interno ad alto privilegio, bypassando completamente l’autenticazione e acquisendo controllo amministrativo sull’appliance bersaglio. Il punteggio massimo CVSS (10.0) riflette la semplicità di sfruttamento combinata alla gravità dell’impatto: nessuna credenziale, nessuna interazione utente richiesta.

Il Profilo di UAT-8616: Un Attore Sofisticato con Radici Profonde


Cisco Talos ha tracciato questa campagna sotto la denominazione UAT-8616, classificandolo con alta confidenza come un “highly sophisticated cyber threat actor”. Sebbene Talos non abbia ancora rilasciato un’attribuzione definitiva a uno stato-nazione specifico, diversi elementi indicativi emergono dall’analisi:

  • Longevità operativa: le prime tracce di attività malevola risalgono al 2023, almeno tre anni prima della divulgazione pubblica — segnale che il gruppo operava con una zero-day tenuta segreta per molto tempo.
  • Sovrapposizione con ORB network: l’infrastruttura di UAT-8616 si sovrappone a reti di relay operazionali (Operational Relay Boxes) precedentemente associate a operazioni di cyber-spionaggio di attori China-nexus, secondo quanto documentato da Mandiant/Google.
  • Target geopoliticamente selettivi: il profilo dei bersagli — governo, diplomazia, difesa in Europa e Asia Centrale — è coerente con operazioni di intelligence offensiva state-sponsored.
  • Connessione con endpoint Gamaredon (Aqua Blizzard): la CISA ha segnalato sovrapposizioni con endpoint già compromessi da Gamaredon, il gruppo russo legato all’FSB che storicamente prende di mira organizzazioni ucraine e dell’Europa orientale.


Anatomia dell’Attacco: Dal Bypass all’Esfiltrazione


Le tecniche post-compromissione documentate da Talos rivelano un playbook operativo sofisticato, progettato tanto per la persistenza quanto per l’evasione forense:

  • SSH key injection: aggiunta di chiavi SSH nei file authorized_keys per garantire accesso permanente anche dopo il reboot o il cambio di credenziali.
  • Escalation a root via CVE-2022-20775: sfruttamento di una tecnica di downgrade della versione software per scalare i privilegi fino a root.
  • Manipolazione NETCONF: modifica delle configurazioni di rete tramite il protocollo NETCONF per alterare il traffico o creare tunnel nascosti.
  • Creazione di account malevoli: creazione di utenti backdoor per accesso persistente.
  • Anti-forensics sistematico: cancellazione di log da syslog, wtmp, lastlog, bash_history e cli-history per coprire le tracce dell’intrusione.


Un Pattern Preoccupante: Sei Zero-Day in Sei Mesi


CVE-2026-20182 non è un caso isolato. Come documenta SecurityWeek, si tratta della sesta vulnerabilità zero-day sfruttata attivamente sulle piattaforme Cisco SD-WAN nel corso del 2026, un dato che solleva interrogativi profondi sulla sicurezza dell’infrastruttura di rete enterprise. Gli SD-WAN sono sistemi critici che gestiscono il traffico di rete tra sedi aziendali distribuite, data center e cloud — la loro compromissione offre all’attaccante una visibilità strategica sull’intera architettura di rete della vittima.

La tendenza è chiara: i dispositivi di rete edge — firewall, VPN concentrator, SD-WAN controller — sono diventati il principale vettore di accesso iniziale per i gruppi APT più sofisticati al mondo. A differenza degli endpoint tradizionali, questi dispositivi raramente eseguono soluzioni EDR e spesso hanno cicli di aggiornamento lenti nelle organizzazioni.

Implicazioni Geopolitiche e per i Difensori


Il targeting di settori governativi e della difesa in Europa e Asia Centrale suggerisce una campagna di cyber-spionaggio strategico. Le sovrapposizioni infrastrutturali con attori Russia-linked come Gamaredon/Aqua Blizzard complicano ulteriormente l’attribuzione, un fenomeno sempre più comune nelle operazioni moderne dove la condivisione di infrastrutture (ORB network) oscura deliberatamente le responsabilità.

Per i team di sicurezza, le priorità immediate sono chiare:

  • Patching urgente: applicare immediatamente le patch Cisco per CVE-2026-20182 su tutti i Catalyst SD-WAN Controller e Manager esposti.
  • Audit delle authorized_keys: verificare l’integrità dei file SSH authorized_keys su tutti i sistemi SD-WAN.
  • Revisione account: identificare e rimuovere eventuali account non autorizzati creati sui sistemi.
  • Log integrity check: data la tendenza del gruppo a cancellare i log, implementare forwarding immediato su SIEM centralizzato.
  • Network segmentation review: limitare l’accesso amministrativo ai controller SD-WAN tramite reti di gestione dedicate e isolate.


CVE e Riferimenti Tecnici

CVE-2026-20182 — Cisco Catalyst SD-WAN Controller / Manager
CVSS Score: 10.0 (Critico)
Tipo: Authentication Bypass
Vettore: DTLS porta 12346 (handshake peering)
Impatto: Accesso amministrativo non autenticato

CVE correlati campagna UAT-8616:
- CVE-2026-20127 (zero-day precedente, sfruttato da febbraio 2026)
- CVE-2022-20775 (privilege escalation, usato per escalation a root)

Indicatori di Compromissione (comportamentali):
- SSH keys non autorizzate in authorized_keys
- Account di sistema inattesi
- Assenza di voci nei log syslog/wtmp/lastlog (log wiping)
- Configurazioni NETCONF alterate
- Traffico anomalo su porta DTLS 12346

Fonti: Cisco Talos, CISA KEV, SecurityWeek, Help Net Security, Tenable, Dark Reading

Cybersecurity & cyberwarfare ha ricondiviso questo.

Oggi è la #GiornataInternazionaledeiMusei.
Tema di questo 2026: Musei che uniscono un mondo diviso.

Mi ci ritrovo, e parecchio.
Il mio primo museo l'ho avuto in casa, la libreria di papà, libri sparsi su 2 piani, locandine, mostri di cera, una biblioteca che era una piccola Wunderkammer.

Il secondo è stato, nemmeno a dirlo, l'amore della mia vita: gli #Uffizi, un amore cominciato al Salone dei 500 in Palazzo Vecchio, proprio di fronte all'ufficio di mamma.
La strada che porta da Piazza della Signoria al museo è tutta dritta, sfocia sul Lungarno De' Medici, uno dei migliori dopo il Lungarno Serristori; il Piazzale degli Uffizi ospita anche uno storico mimo che interpreta Dante e la sua agonia - ragalategli un obolo e un sorriso, merita!

Se devo misurare il gradimento dei musei sul mio "museometro", posso spostare il cuoricino anche sul Grand Egyptian Museum del Cairo, uno spettacolo di cultura da fare gola a Fantomius!

L'ultimo, in ordine di tempo, è il Piccolo Museo del Purgatorio a Roma (di quello ne ho parlato in uno speciale di RdF).

In mezzo, parecchi altri.
Anche di questi, prima o poi, scriverò.

Small Engine Gets DIY EFI Upgrade


The media in this post is not displayed to visitors. To view it, please log in.

Small internal combustion engines usually keep things simple, relying on carburetors to handle metering the correct amount of fuel and air. Recently, [Carlos Takeshita] decided his small engine could use an upgrade in the form of electronic fuel injection (EFI).

The build began with a Predator 212, a popular gasoline engine from Harbor Freight. [Carlos] set about kitting it out with a missing tooth trigger wheel to measure the crankshaft position with a hall effect sensor. The engine also scored a custom-built aluminium fuel cell, complete with a high-pressure fuel pump and regulator suitable for driving the solitary fuel injector installed in the custom intake manifold. A Teensy 4.0 is charged with monitoring a manifold air pressure (MAP) sensor and the crank position, and choosing when and how long to fire the injector to dose the engine with the correct amount of fuel. Files are on GitHub for those eager to dive deeper.

It can be quite a job to convert an engine to run with electronic fuel injection, but you’re certain to learn a lot during the install and tuning process. We’ve featured similar builds many times over the years.

youtube.com/embed/ApN0I983zUQ?…


hackaday.com/2026/05/18/small-…

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile
#CyberSecurity
insicurezzadigitale.com/kazuar…


Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P


Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker


Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

  • Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
  • Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
  • Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti


Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina


Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori


Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

The media in this post is not displayed to visitors. To view it, please log in.

Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


@Informatica (Italy e non Italy)
Il gruppo russo Secret Blizzard (Turla/FSB) ha trasformato il malware Kazuar in una botnet peer-to-peer con tre moduli distinti (Kernel, Bridge, Worker) e 150 parametri di configurazione. La


Kazuar si evolve: Secret Blizzard (Turla) trasforma il suo backdoor storico in una botnet P2P modulare invisibile


Si parla di:
Toggle

Il gruppo russo Secret Blizzard, operativo per conto dell’FSB (Federal Security Service) russo e meglio conosciuto come Turla, ha trasformato il proprio storico malware Kazuar in una botnet peer-to-peer modulare, progettata per mantenere accessi persistenti e praticamente invisibili nelle reti governative. La rivelazione arriva da Microsoft Security, che il 14 maggio 2026 ha pubblicato un’analisi approfondita dell’architettura del malware — descrivendo quello che è a tutti gli effetti un salto evolutivo nella sofisticazione operativa di uno dei gruppi APT più longevi al mondo.

Da backdoor tradizionale a ecosistema P2P


Kazuar è attivo almeno dal 2017 ed è stato impiegato in decine di campagne di cyberspionaggio contro governi, ambasciate e organizzazioni della difesa in Europa, Asia Centrale e Ucraina. La versione analizzata da Microsoft nel 2026 rappresenta però un cambio di paradigma: il malware non è più un semplice backdoor controllato centralmente, ma un ecosistema distribuito composto da tre moduli distinti che collaborano per garantire resilienza, persistenza e stealth.

La riorganizzazione è eloquente: non ogni macchina compromessa comunica con il server di comando e controllo (C2). Invece, un unico nodo “leader” — eletto dinamicamente dal modulo Kernel tra i sistemi infetti presenti nella stessa rete o segmento di rete — assume il ruolo di proxy verso l’infrastruttura esterna. Gli altri nodi entrano in modalità “silent”, eliminando quasi completamente il traffico verso l’esterno e riducendo drasticamente la superficie di rilevamento per i team di incident response.

Architettura modulare: Kernel, Bridge e Worker


Microsoft descrive tre componenti fondamentali della nuova architettura Kazuar:

  • Modulo Kernel: È il coordinatore centrale. Gestisce i task, controlla gli altri moduli, elegge il nodo leader e orchestra le comunicazioni e il flusso di dati attraverso la botnet.
  • Modulo Bridge: Agisce come proxy tra il nodo leader Kernel e il server C2 remoto. Filtra e instrada il traffico, permettendo ulteriore separazione tra i sistemi compromessi e l’infrastruttura degli attaccanti.
  • Modulo Worker: È il componente operativo. Registra i tasti premuti (keylogging), aggancia gli eventi Windows, traccia i task, raccoglie informazioni di sistema, listing di file e dettagli MAPI — incluse caselle email di Exchange.

Questa separazione funzionale non è casuale: in caso di rilevamento di un Worker, i nodi Kernel restano inalterati e possono continuare a operare silenziosamente. L’architettura è progettata per sopravvivere a rimozioni parziali.

150 parametri di configurazione: granularità operativa senza precedenti


Uno degli aspetti più rilevanti della nuova versione è il sistema di configurazione esteso: Kazuar supporta ora più di 150 parametri che gli operatori possono personalizzare per ogni campagna o vittima specifica. Questi parametri controllano metodi di esecuzione e persistenza (scheduled task, servizi Windows, chiavi di registro), bypass di AMSI e ETW, timing dell’esfiltrazione e dimensione dei chunk di dati, process injection e tecniche di lateral movement, e protocolli di comunicazione multipli: HTTP, WebSocket ed Exchange Web Services (EWS).

L’uso di EWS per mascherare le comunicazioni C2 nel traffico legittimo di Exchange è particolarmente insidioso: in ambienti enterprise dove Exchange Server è ubiquo, questo canale risulta quasi impossibile da distinguere dal traffico normale senza ispezione profonda dei payload.

Targeting: governi, ambasciate e settore difesa in Europa e Ucraina


Secret Blizzard (alias Turla, Uroburos, Venomous Bear) è noto per campagne di spionaggio ad altissimo valore strategico. Le vittime documentate includono ministeri degli esteri, ambasciate diplomatiche, dipartimenti della difesa e organizzazioni governative in Europa Orientale, Asia Centrale e — con intensità crescente — Ucraina nel contesto del conflitto in corso.

L’evoluzione di Kazuar verso un’architettura P2P suggerisce che il gruppo abbia tratto lezione dalle operazioni di takedown condotte negli ultimi anni contro infrastrutture di malware centralizzate. La distribuzione del controllo rende un’eventuale disruption dell’infrastruttura C2 molto meno efficace: rimuovere il server C2 non smantella la botnet, poiché il leader può essere eletto nuovamente tra i nodi sopravvissuti.

Due righe per i difensori


Microsoft raccomanda di concentrare il rilevamento su indicatori comportamentali piuttosto che su signature statiche. I team di sicurezza dovrebbero monitorare attività IPC insolite tra processi non correlati, rilevare pattern di elezione del leader nella rete interna tramite comunicazioni laterali anomale, identificare esfiltrazione dati staged e frammentata con timing irregolare, e controllare accessi anomali a EWS da processi non di posta elettronica. Dato il targeting storico di Secret Blizzard su entità diplomatiche e governative europee, le organizzazioni in questi settori dovrebbero considerare una revisione urgente dei log di rete e degli endpoint.

Indicatori di Compromissione (IoC)

# Kazuar - Secret Blizzard (Turla) - Maggio 2026
# Fonte: Microsoft Security Blog, 14 maggio 2026

# Tecniche MITRE ATT&CK associate
T1574.001 - DLL Search Order Hijacking
T1055     - Process Injection
T1071.001 - Application Layer Protocol: Web Protocols (HTTP/WebSocket)
T1071.003 - Application Layer Protocol: Mail Protocols (EWS)
T1030     - Data Transfer Size Limits (staged exfiltration)
T1053.005 - Scheduled Task/Job (persistence)
T1562.001 - Impair Defenses: Disable/Modify Tools (AMSI/ETW bypass)

# Comportamenti anomali da monitorare
- Comunicazioni IPC anomale tra processi non correlati
- Accessi Exchange Web Services (EWS) da processi non di posta
- Traffico P2P laterale interno su porte non standard
- Esfiltrazione dati in chunk temporizzati verso IP non categorizzati
- Moduli .NET iniettati in processi di sistema legittimi

# Referenza completa IoC
https://www.microsoft.com/en-us/security/blog/2026/05/14/kazuar-anatomy-of-a-nation-state-botnet/

Fonti: Microsoft Security Blog, BleepingComputer, The Hacker News

Cybersecurity & cyberwarfare ha ricondiviso questo.

The media in this post is not displayed to visitors. To view it, please go to the original post.

Someone sent me these pics from the Epsilon party at @offensivecon in Berlin.

Nice trolling on Trenchant's zero-day thief Peter Williams and on us with the now classic "Sun, Seafood, and Spyware" tagline. Thanks for reading!

This Week in Security: Android Exposes ADB, ShinyHunters Get Paid, Robot Dogs, and More


The media in this post is not displayed to visitors. To view it, please log in.

Google has patched an Android ADB bug in the May security patch set. If you have a Pixel phone you should already have the patches, and most other major manufacturers should be close behind. Unfortunately, the biggest risk from this patch will be to the vendors who are also the least likely to release timely – or any – security updates.

ADB, the Android Debug Bridge, is the main tool for installing apps during development and debugging apps while they’re running. It can also be used to side-load apps from a PC. While most normal users are unlikely to ever enable it, developers typically do and some power users might when jailbreaking a device or setting parameters not exposed in the Android UI. Debugging can be done locally via USB, or optionally over the network. To protect the device, the user must unlock the Android device and authorize each new debug agent.

Covered by Risky.Biz, a bug introduced in 2020, and present in every Android release since, allowed bypassing authorization entirely if network debugging was enabled and at least one connection had been made to the ADB service in the past. This happens because ADB compares the certificate of the incoming debug connection with the list of saved certificates. If the certificate type does not match — for instance supplying an Ed25519 certificate instead of a RSA certificate — ADB has been incorrectly handling the error code, and allowing the connection.

In most programming languages, false is considered zero, and true is considered anything not zero. The certificate API returns a 1 for a valid match, a zero for an invalid match, and a negative-one for a type mismatch. Negative one is not zero, so when treated as a boolean value, it becomes true.

To exploit the bug, ADB must be enabled in wireless mode, and there must be at least one trusted device in the ADB configuration. For the average user this is an unlikely combination, but for developers, the time to update is now.

Mythos Finds a Curl Bug


Daniel Stenberg of Curl posts about recent interactions with the Mythos AI model finding vulnerabilities – or rather a singular vulnerability – in Curl. Curl, and the companion library libcurl, run in an estimated 20 billion instances, so any security issue could be critical.

After some confusion about access to the model, five vulnerabilities found were ultimately condensed to a single new vulnerability. Classified as “not particularly dangerous”, the issue will be assigned a CVE and be fixed in an upcoming patch.

Daniel’s post contains a wealth of additional information and commentary about the experience with Mythos. The lack of findings from Mythos may be more a reflection on the maturity of the Curl codebase than anything else; the Curl code is an excellent example of the impact of continual auditing, by all types of tools.

XBow Finds an Exim Bug


XBow has found a vulnerability in Exim using AI tooling. Exim is an open-source message transport agent (MTA, or email server to most of us) like Postfix and Sendmail. Classified as CVE-2026-45185, it has a 9.8 CVE score (out of 10), allowing arbitrary code execution without authentication.

The bug is one of the “use after free” class of mistakes: after allocating memory, using it for some task, then releasing the memory (freeing it), Exim forgets the memory has been freed and continues to use it. In this case, memory allocated as part of a TLS encrypted connection is freed when the TLS connection is ended, but the handler for incoming email data may still write to the now-destroyed buffer, which in turn allows corruption of the memory management system inside Exim and, ultimately, running arbitrary code.

Arbitrary code execution vulnerabilities are typically just as bad as they sound – the ability to run arbitrary code is essentially the ability to run anything on the system, including running system commands as if logged in. Combined with the recent collection of local privilege escalation vulnerabilities like CopyFail (and more on this later), unauthenticated code execution is a short path to full root control of the system.

The Internet indexer Shodan currently shows 2.5 million installs of Exim globally. If you run Exim anywhere, hopefully you’ve already updated – and update immediately if not!

CopyFail Three-quel


It’s the three-quel nobody wanted; being named “CopyFail 3.0” and “Fragnesia”, another vulnerability that is extremely similar to those used in CopyFail and DirtyFrag has been found and patches have begun on the Linux kernel. Like the previous bugs, this one lies in the Linux kernel handling of IPSec ESP encryption, and allows modifying the in-memory page cache used for accelerating disk IO.

Fortunately, because this uses the same kernel modules as previous vulnerabilities, any system with the mitigations for DirtyFrag in place — essentially disabling IPSec functionality — should not be impacted, however any system patched for DirtyFrag with the IPSec kernel modules available will need to be patched again!

It’s Patch Tuesday!


It’s Microsoft Patch Tuesday again! Brian Krebs has the roundup, calling out three patches in particular that allow privilege escalation to admin or system, and one remote code execution bug in the Microsoft DHCP client.

If you’re a Microsoft user, or run IT in a Microsoft shop, you already know the balancing act – update immediately because of the security implications, or wait and see if this set of patches breaks basic functionality again?

More Windows 0-Days


It seems like it wouldn’t be a Patch Tuesday without additional drama – the author behind previous Windows zero-day exploits the past two months follows up this month with two more, seemingly still upset with the Microsoft security teams responses.

The YellowKey vulnerability consists of nothing more than specifically named files on a USB stick. When booted in recovery mode, the files trigger a Windows 11 recovery image to launch a shell with Bitlocker disk encryption turned off. It’s unclear if this functionality is a deliberate backdoor or some sort of debug functionality accidentally left in the builds, but it is extremely odd.

GreenPlasma is a privilege escalation vulnerability, allowing elevation to system level privileges, which would give access to the system credentials database, among other bad results. Similar issues were patched in this months Patch Tuesday set, but not this one.

Criminals Use Tools for Crime


Google is trying to hype what is claimed to be the first use of AI to write an exploit caught in the wild. This seems extremely unlikely given the past year or more of development on the AI front.

Treating news as boring is never fun, but it seems unsurprising that criminals are going to use the tools available to continue being criminals. This feels like less of a revelation than a continuation of obvious trends: groups who have not been able to develop in-house tooling have always purchased tools, stolen tooling from other groups, or used commoditized exploits, easily as far back as the Anonymous “Low Orbit Ion Canon” tool in 2005 to allow recruitment and participation by less technical users.

Attack and exploit code doesn’t need to worry about the technical debt or repeatability challenges of AI generated code, and it seems obvious that attackers will minimize their own effort whenever possible.

Malware and Residential Proxies


Bitsight Research published a paper on the relationships between malware infections and residential proxy networks.

Proxy networks act similarly to a VPN, taking traffic from one source and tunneling it to appear to come from a different source. Made up of typically unwitting home users, residential proxy networks are often resold as cheap commercial VPN services. (Not all commercial VPN providers are equal, while some are completely legitimate, many are not.) Proxy networks can also be leveraged to allow attackers to operate inside a different country, obfuscating the true attack location or bypassing login restrictions or alerts to detect if a user has an impossible location or travel pattern. Proxy networks are also often involved in advertisement click fraud, appearing as an army of normal home users who are really interested in click on ads, and are also used to pivot into the internal home network, where devices are often completely unprotected.

Bitsight tracked over 53 million IPs acting as residential proxy devices over a two-month period, split between several proxy network brokers reselling access, typically with over eight million nodes available daily, with strong ties between malware infections and remote access proxy tool installation.

FCC Extends Router Deadline


The FCC has announced it is extending the initial timeline for foreign-made routers. Previously the FCC had declared that not only would nearly all new consumer router hardware be banned from FCC certification, it would no longer be allowed to receive software updates as of early 2027.

Possibly noticing the conflict in the stated goal of increased security while prohibiting security patches, the deadline has been extended for consumer routers and drones to receive software updates until 2029.

SMS Spammers Arrested


You might rightly assume that most SMS spam comes from compromised phones or Internet-connected SMS bridges, but TechCrunch reports on the arrest of three men in Toronto for operating a mobile SMS-spamming cell tower.

The spammers ran the spoofed cell tower in the back of a car while driving around the city. Once a phone connected to the false tower, the tower bombarded it with SMS messages with phishing lures for credential and banking theft.

Operating a fake cell tower is extremely illegal in almost all countries, in no small part because it actively interferes with emergency services such as E911. Police estimate that over a million SMS messages were sent by the trio since November, 2025.

Robot Dog Malware


A paper in IEEE Spectrum from November, 2025 covers discoveries of a potentially wormable vulnerability in the Unitree robotics platform used for canine and humanoid robots. Unitree robots are sometimes used as security or even military devices.

This week, Benn Jordan published a YouTube video exploring some of the vulnerabilities in his personal robots, referencing the GitHub of the original researchers.

Multiple vulnerabilities have been found in the robotics platform that allow overriding the safety mechanisms of the robots, as well as running arbitrary code on the robot, scanning for WiFi and Bluetooth devices, and mechanisms the robots use to communicate with various servers, some in foreign countries.

The research suggests that at least one vulnerability – the ability to gain root on the device from an unauthenticated Bluetooth Low-Energy connection – could be turned into a worm, where one infected robot could use the on-board Bluetooth to infect other nearby devices.

Benn Jordan has previously been influential in the public outcry against monitoring platforms like Flock, so highlighting vulnerabilities in a platform used by police, private security, and military seems a reasonable continuation.

TCLBANKER Trojan


A WhatsApp based worm is targeting users of banking, crypto, and fintech services. The TCLBANKER malware hijacks WhatsApp web and Outlook email accounts to spread a zip file which uses a legitimate signed Logitech tool but injects the payload into the install process.

Once infected, the user is presented with a series of falsified UI screens, including fake system updates, which hides the actual activity of the infection and tricks the user into clicking on hidden elements of the true UI to authorize actions.

The TCLBANKER worm attempts to hide from analysis by downloading encrypted payloads keyed to a hash of the environment. If analysis tools like a debugger are installed, the payload will not decrypt.

ShinyHunters Get Paid


Last week, the group known as ShinyHunters made news by compromising the Canvas educational platform and threatening to leak the personal data and messages of millions of students. The attack culminated with ransom notes taking over the portals of hundreds of schools, and the Canvas platform being shut down “for maintenance” during finals week for many schools.

This week, it appears the ransom was paid, with ShinyHunters promising to destroy the stolen data.

Paying ransom is a hot-button issue: nobody wants to see the ransomware model continue as a profitable venture, but it is tough to argue that millions of students with no voice in the choice of educational platforms should have their data released.

Token Stealer Doesn’t Want to Leave


Trojaned packages continue to be a problem for NPM and other ecosystems, as automated supply chain infections continue to infect high-profile projects.

This time, the TanStack application framework used for developing web applications was compromised by a supply chain worm, “Mini Shai Halud”, a variant of the Dune-themed “Shai Halud” worm infecting packages since March.

The worm spreads via NPM and PyPi and infects packages, developer systems, and GitHub actions, targeting service keys for package repos, cloud resources, AI platforms, and GitHub. The worm also installs services on infected developer systems to capture future service tokens when they are added, and further investigation by the TanStack team uncovered additional services which monitor the stolen credentials and attempt to wipe infected systems using rm -rf / if the stolen credentials are revoked.

Prescription Drug Ransomware


A ransomware attack has hit West Pharmaceutical in Pennsylvania, USA, with filings indicating the attack disrupted the company globally.

West Pharmaceuticals manufacturers packaging for drugs and healthcare items, so a global shutdown of manufacturing and shipping could have a much longer impact on drug availability.

[Editor’s note: Sorry this one runs late! Hackaday Europe was on and it slipped through the cracks. The next installment of This Week in Security will be hitting the pages on Friday as usual.]


hackaday.com/2026/05/18/this-w…

Cybersecurity & cyberwarfare ha ricondiviso questo.

#ShinyHunters hack 7-Eleven: franchisee data and Salesforce records exposed
securityaffairs.com/192336/dat…
#securityaffairs #hacking