How Search Engines Enabled Finding Needles in a WWW-Sized Haystack


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

When the World Wide Web surged into existence during the 1990s, we were introduced to the problem of how to actually find something in this ever-ballooning construction zone that easily outpaced even the fastest post-WW2 urban sprawl. Although domain names provided a way to find servers using DNS rather than having to mash in IP addresses, you still somehow had to know the relevant URL.

A range of solutions were thought up over time, ranging from printed Yellow Pages type guides, to online curated lists of resources, as well as things like web rings where one website would link to a relevant similar website. This was the time when word-of-mouth was also very relevant, with people proudly announcing their own website on Geocities or other hosting service.

Search engines already existed long before the WWW became the hot new thing during the 1990s, but it was the WWW that would really push them to their limits. As anyone who used search engines for the WWW can attest, they had many issues. Often you’d end up using multiple search engines to find something, and despite fierce competition between web search engines to become the starting page for their browser, actually finding things on the WWW remained a tough problem.

Since a web search engine ‘just’ has to index the WWW and match a search query against the results, why was this such a hard problem that persisted until Google apparently cracked the code?

Unplanned Sprawl

URLs branching off from the main Wikipedia page in 2004. (Credit: Chris 73, Wikimedia)URLs branching off from the main Wikipedia page in 2004. (Credit: Chris 73, Wikimedia)
A nice thing about the WWW is that it was designed to be accessible to all, requiring only an Internet connection and thus opening up the possibility of setting up your own webserver. This unsurprisingly led to a very rapid growth of pages on the WWW, with content appearing, being modified and sometimes vanishing at an ever-increasing pace, making it extremely hard to keep up with.

This is however not how things started when the World Wide Web was created in 1989. Before its opening to the public in 1993 the pace of growth was slow enough that a manually maintained index was maintained. This was kept up until late 1992, with the last version of said index still online on the W3 website.

Over the course of a short few years, the WWW would change the face of the world forever alongside a surge of IBM-compatible PCs, exploding multimedia content, all the dot-com hype and perhaps best of all endless ‘free’ hosting services as long as you didn’t mind an advertising banner plastered above your personal homepage’s content.

Even internet service providers (ISPs) would often offer their own hosting service, along with endless n00b-friendly tools to make something resembling a website for whatever hobby you fancied. In addition to proving that one can absolutely argue about style and the prevalence of colorblindness, this would also serve to balloon the number of websites at an exponential rate.

Whether or not the WWW killing off the Gopher-based internet was a bad thing remains the topic of debate, though it’s beyond question that Gopher integrated search functionality into its protocol, mirroring a file system.

Infinite Library Indexing


Without any provisions in the HTTP protocol of the WWW, the only realistic way for search engines to create an index of the ever-expanding and changing WWW is to perform so-called web crawling. This means going through every known document, following any links found in them, and making sure to revisit any documents in case their contents got changed since the last visit.

The first complication here is that since the search engine’s database is the only real index for the web, initial discovery is purely organic, starting from a certain number of URL seeds in what is called the crawl frontier. This forms an integral part of a web crawler.
The Structure of Queues that Feed the URL Stream in the WebFountain Crawler (Credit: Edwards et al., 2001)The Structure of Queues that Feed the URL Stream in the WebFountain Crawler (Credit: Edwards et al., 2001)
Development of the algorithms and architecture behind these crawlers formed a major part of the early WWW, with IBM researchers on the WebFountain project in 2001 estimating a grand total of about 500 million pages, with – as they put it – web crawlers caught between the comfortable cushion of Moore’s Law and the hard place of the web’s exponential growth. Today this number is probably closer to forty billion pages.

Although the Google Search web crawler was already pretty good back in 2001, WebFountain improved on it by using a distributed system, with ‘ants’ working through their own list of URLs to crawl, as described in the development paper by Jenny Edwards et al.

Beyond the basic recursive following of links in a document there are many confounding factors, such as when to recrawl a URL, which very much depends on how often the content on it is expected to be updated. Here one dives into the territory of statistics, as depending on the type of site we can make an educated guess on how often it is expected to be updated. For example, a government’s historical news pages are unlikely to see frequent updates, whereas the front page of a news site can see updates practically every few minutes.

Inverted Indexing


As complex the topic of web crawling is, the fun part begins when you have pruned all duplicate documents and stripped all the irrelevant fluff that’s not text to be indexed. In order to make the resulting search index at all searchable before the heat death of the Universe you cannot simply do a full text search on every single document whenever someone enters a search query.

Instead an index is constructed whereby certain keywords are mapped to documents. This inverted index is generally implemented as a hash table or similar data structure where it provides a quick access into the full text documents, not unlike the keyword index in the back of a book, or the more elaborate concordance of yesteryear. These latter works also provide a keyword index, but add accompanying text to provide immediate context to further save time.

Creating an inverted index is a fairly labor-intensive process, with a new document often used for a forward index that decomposes the text into its keywords prior to updating (or creating) the inverted index. As with all of such text processing related tasks and data structures in general there are many ways to go about it, with some fun curveballs thrown into the mix such as parsing languages that do not separate words with spaces, like Japanese.

All of which is to say that implementing a search engine is easy, but making it performant, accurate and efficient at the same time is a minor nightmare. This is basically why search engines took so long to stop being so terrible, as the engineers behind them were trying to solve many rather complex problems, presumably with the C-suite and investors breathing down their necks during the dot-com days.

Search Battles


Over on the Wikipedia entry for ‘Search engine‘ we find a pretty good timeline of web search engines, along with their current status. Perhaps unsurprisingly none of the 1993-era ones made it, but 1994’s WebCrawler somehow crawled into the modern age, along with Lycos. Much like 1990’s Archie search engine and similar for the Gopher web, many of these early search engines simply couldn’t compete in the rapidly changing years leading up to the new millennium.

This was also the era in which some figured that the WWW simply needed to become more ‘3D’ with virtual environments using VRML, bringing it closer to sci-fi like that portrayed in Snow Crash or Tron. Perhaps unfortunately the WWW remained the domain of mostly text and images, although most recently the flood of JavaScript frameworks appear to want to turn once simple HTML documents into full-blown desktop-like applications, all probably to the delight of web crawler engineers.

Meanwhile some search engines figured that they could lift along on the hard work of others, with so-called meta search engines collating the results from multiple search engines to save people the trouble of querying them individually. Here 1996’s Dogpile is still going strong.

Some search engines are missing from the list, such as Marginalia, which boasts the use of open source software for its indexing and crawling, while focusing on non-commercial content. There is also the ever excellent Frog Find that provides a bridge between modern search engines and systems that really cannot run the latest web browser.

Today’s Survivors


The search engine landscape remains a brutal one today, with us having to recently say farewell to Jeeves, of Ask Jeeves fame, most recently seen carrying the Ask.com name. Personally I didn’t really Ask Jeeves much back in the day, instead mostly using AltaVista (RIP) and probably Lycos and a few others that I do not recall off the top of my head.

Having Google Search burst on the scene by 2000 was definitely quite the event, which was certainly when the web search game improved. Looking back it probably was less that Google Search was simply better, but more that it pushed hard just being a search engine, whereas the others were still very much stuck in that early WWW mindset of being a portal to the web.

To a certain extent this is understandable, as search engines aren’t a charity and running the associated hardware as well as the required bandwidth costs a lot of money. Despite this it would seem that we still have a rather thriving web search engine landscape, even if ChatGPT, Claude and kin are trying to become the very last ‘site’ you will ever need. This even as their little web crawlers are still doing the same crawling as has been done since the birth of the WWW.


hackaday.com/2026/05/19/how-se…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Today is L0pht Day. In 1998 7 hackers in suits told the US Senate the internet was a house of cards. We said we could take it down in 30 minutes. They looked at us like we'd landed from another planet.

28 yrs later, the gap between what the security community knows and what decision-makers act on remains a fundamental problem.

Miss you, Peter Neumann. He testified that day too, with decades of hard-earned wisdom. We owe him.

The work isn't done. It never was.

#L0phtDay #InfoSec

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.

QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software
#CyberSecurity
insicurezzadigitale.com/qlnx-i…


QLNX: il nuovo implant Linux silenzioso che saccheggia la supply chain del software


Si parla di:
Toggle

Un nuovo implant Linux mai documentato prima — denominato Quasar Linux RAT (QLNX) — sta prendendo di mira sviluppatori e ambienti DevOps con l’obiettivo di appropriarsi silenziosamente delle credenziali più preziose del ciclo di sviluppo software: token npm, PyPI, AWS, Kubernetes, GitHub e molto altro. La scoperta, opera dei ricercatori Aliakbar Zahravi e Ahmed Mohamed Ibrahim di Trend Micro, descrive uno strumento che non si limita ad essere un semplice trojan di accesso remoto, ma una piattaforma di spionaggio industriale progettata per persistere, nascondersi e colpire l’intera supply chain del software.

Cosa rende QLNX diverso dagli altri RAT Linux


A differenza di molti implant Linux che puntano sulla semplicità, QLNX è costruito come una piattaforma d’attacco coerente e modulare. Il suo punto di forza non sta in una singola tecnica innovativa, ma nell’integrazione armoniosa di più capacità offensive che si concatenano in un flusso d’attacco preciso: arriva, cancella le tracce dal disco, si radica con sei meccanismi ridondanti, si nasconde sia a livello userspace che kernel, e infine raccoglie sistematicamente le credenziali che contano davvero.

Il malware esegue filelessly dalla memoria, mascherandosi da thread del kernel attraverso nomi come kworker o ksoftirqd — nomi che ogni amministratore di sistema Linux incontra quotidianamente nei propri processi. Questo lo rende praticamente invisibile a una normale ispezione manuale. È inoltre in grado di profilare l’host per rilevare ambienti containerizzati, cancellare i log di sistema e stabilire persistenza attraverso non meno di sette metodi diversi, tra cui systemd, crontab e shell injection nel file .bashrc.

Un harvester di credenziali pensato per la supply chain


Il componente di furto credenziali di QLNX è ciò che lo rende particolarmente pericoloso per l’ecosistema open source. Il malware estrae sistematicamente segreti da un elenco preciso di file ad alto valore per uno sviluppatore:

File target di QLNX per il furto credenziali:

.npmrc              → Token di pubblicazione npm
.pypirc             → Credenziali PyPI
.git-credentials    → Credenziali Git
.aws/credentials    → Chiavi di accesso AWS
.kube/config        → Credenziali Kubernetes
.docker/config.json → Autenticazione Docker Registry
.vault-token        → Token HashiCorp Vault
.env                → Variabili d'ambiente con segreti
**/terraform.tfvars → Credenziali Terraform
GitHub CLI tokens   → Token di accesso GitHub

Il rischio non è solo per lo sviluppatore compromesso: un attore che ottiene accesso a uno di questi token può pubblicare pacchetti malevoli su npm o PyPI, accedere all’infrastruttura cloud o muoversi lateralmente attraverso pipeline CI/CD. È esattamente il meccanismo che ha consentito attacchi supply chain devastanti in passato, come l’operazione TeamPCP che ha colpito oltre 160 pacchetti npm e PyPI nelle scorse settimane.

Architettura rootkit a doppio livello: LD_PRELOAD + eBPF


L’aspetto più sofisticato di QLNX è la sua architettura rootkit a due livelli, che combina tecniche di occultamento a livello userspace e kernel.

Il primo strato è un rootkit userland deployato attraverso il meccanismo LD_PRELOAD del dynamic linker di Linux. Questo garantisce che tutti gli artefatti e i processi dell’implant rimangano nascosti agli strumenti di ispezione standard. Il secondo strato è un componente kernel-level basato su eBPF (Extended Berkeley Packet Filter) — il potente sottosistema Linux originariamente pensato per il networking e l’osservabilità dei sistemi. QLNX sfrutta eBPF per nascondere processi, file e porte di rete agli strumenti userland come ps, ls e netstat, su istruzione del server di comando e controllo (C2).

L’uso offensivo di eBPF per il rootkitting è una tendenza già documentata da altri ricercatori, ma la sua integrazione in un RAT con builder pipeline modulare indica una maturazione significativa di queste tecniche al di fuori di ambienti di ricerca accademica.

Backdoor PAM: furto di credenziali SSH in tempo reale


QLNX include anche un backdoor basato su PAM (Pluggable Authentication Module) che intercetta le credenziali in chiaro durante gli eventi di autenticazione SSH. Il componente PAM inline-hook registra i dati delle sessioni SSH in uscita e li trasmette al C2. È inoltre presente un secondo logger PAM che viene caricato automaticamente in ogni processo collegato dinamicamente, per estrarre nome del servizio, username e token di autenticazione.

Questa tecnica è particolarmente insidiosa perché i moduli PAM girano tipicamente con privilegi root e operano a un livello così basso nello stack di autenticazione che la maggior parte dei sistemi di monitoring tradizionali non riesce a intercettarli. Non a caso, negli ultimi mesi sono emersi altri strumenti simili — come PamDOORa, venduto su forum russi di cybercrime per 900 dollari — che sfruttano lo stesso vettore.

58 comandi C2 e un’infrastruttura operativa completa


QLNX supporta ben 58 comandi distinti che conferiscono agli operatori il controllo completo dell’host compromesso. Le capacità operative includono esecuzione di shell commands, gestione file, code injection nei processi, cattura di screenshot, keylogging, SOCKS proxy, TCP tunneling, esecuzione di Beacon Object Files (BOFs) — la stessa tecnica usata da Cobalt Strike — e gestione di una rete P2P mesh tra host compromessi.

La comunicazione con il C2 avviene su tre protocolli — TCP grezzo, HTTPS e HTTP — con un loop persistente che tenta continuamente di mantenere attiva la connessione. La vettore di infezione iniziale rimane ancora sconosciuto, ma una volta stabilito il foothold, QLNX cancella i propri artefatti dal disco e avvia la fase operativa principale.

Indicatori di compromissione e contromisure


QLNX evidenzia una tendenza preoccupante: la supply chain del software sta diventando il bersaglio privilegiato di attori sofisticati, perché compromettere un singolo sviluppatore con accesso ai registri npm o PyPI può avere effetti moltiplicatori su migliaia di utenti downstream. Per i team di sicurezza, alcune contromisure prioritarie:

  • Ruotare regolarmente tutti i token di pubblicazione per npm, PyPI, GitHub e altri registri, soprattutto dopo accessi da sistemi non familiari.
  • Monitorare processi Linux con nomi simili a thread del kernelkworker, ksoftirqd ecc. — che non corrispondono agli effettivi thread del kernel: strumenti come pstree con verifica del PPID possono rivelare anomalie.
  • Verificare l’integrità dei moduli PAM: controllare regolarmente che i file .so nei percorsi PAM non siano stati modificati rispetto alla versione del package manager.
  • Abilitare audit logging di eBPF per rilevare il caricamento di programmi eBPF non autorizzati: auditctl -a always,exit -F arch=b64 -S bpf.
  • Isolare i segreti CI/CD dall’ambiente di sviluppo locale, usando secret manager dedicati piuttosto che file in chiaro su disco.

Trend Micro ha pubblicato i dettagli tecnici completi nel proprio blog di ricerca. La natura fileless di QLNX e il suo doppio rootkit rendono il rilevamento basato su signature sostanzialmente inefficace: la difesa deve puntare su behavioral analytics e monitoraggio delle anomalie a livello di syscall, combinati con soluzioni EDR capaci di ispezionare la memoria dei processi.


Cybersecurity & cyberwarfare ha ricondiviso questo.

Pizza Hut's AI system caused 'cascading' problems and $100M in damages, franchisee alleges in new suit
businessinsider.com/pizza-hut-…

> A top Pizza Hut franchisee says the chain's rollout of an AI-powered delivery system turned once-speedy pizza orders into a cold, late-arriving mess — and cratered a business that had been outperforming nearly every other operator in the system.

:blobcatpopcornnom:

#AI #Hype

#ai #hype
in reply to Michał "rysiek" Woźniak · 🇺🇦

So a couple of points from a non-techie:
1) thanks for posting this, these posts help me block more assholes
2) a corporation forced an AI system onto its franchisees without presumably ANY testing, which ultimately harmed franchisee owner's business(es) - correlation/causation and all that...
3) the purpose of corporate forcing AI onto its franchisees could only be for the purpose of "optimizing profits" which I hope we all know is Corpse speak for "exploit workers in pursuit of profits"
4) the backfire was the workers were able to exploit the dumbasses at corporate by using the AI for their benefit.
Im 100% with the workers on this and bravo to them 👏👏👏
And yes, the AI is what caused the issue as without it the issue wouldnt exist.

Remembering the Tech We Lost With a Virtual Graveyard


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

Although 1999 might still feel like yesterday for some of us, in the world of technology the intervening years are practically an eternity. New websites, applications and devices pop up all the time, only to die off just as fast again for a variety of reasons. Amidst such chaos it’s always good to take a breather and reflect on all that we have lost, such as on the virtual graveyard that [Burak Ozdemir] created with hand-written obituaries and only the classiest of 90s-era web design.

Remembered are everything from instant messengers and social networks to web hosts and devices. Who still remembers their ICQ number? There was a good chance that you were also on GeoCities or similar web host back then too. Maybe you weren’t really into Google+, but some of us still have fond memories of its virtual hangouts that provided a connection to people around the world in a way not since replicated.

Not all of the entries are as well-known, of course, with not everyone remembering or ever having heard about services like Songza. A few rare entries on the list have punched a zombified hand through six feet of soil and shambled back into the daylight, such as the Pebble devices. Some entries are quite more recent, with many probably remembering Microsoft’s short-lived Tay that made clear that public chatbots need a lot of safety rigging, a lesson that was mostly remember by subsequent chatbots.

Although some things like forum signatures and personal homepages arguably still live on, the death of Clippy will definitely be mourned by many.


hackaday.com/2026/05/19/rememb…

Cybersecurity & cyberwarfare ha ricondiviso questo.

Bastano cinque foto pubbliche su Instagram.

Basta questo, a un LLM, per scriverti un'email di phishing che sembra arrivare da qualcuno che ti conosce bene.

Costo irrisorio, alto potenziale e nessuna fatica: perchè il dataset, all'attaccante, lo abbiamo fornito noi.

Ne ho scritto qui: linkedin.com/posts/cgmongini_c… e vi invito a riflettere su quello che lasciamo dietro di noi.

Instagram, Facebook, LinkedIn, BlueSky stesso: lasciamo tracce di noi, scie, elementi.
E se a volte non è possibile esimersi, perché siamo "persone pubbliche", serve potenziare l'attenzione su tutto quello che ci gravita intorno.

La mail di tizio che ci propone una collab?
Prima di rispondere o cliccare, cercate il sesto grado di separazione e chiedeteglielo vis-a-vis.

Il collega che convoca un meeting urgente il venerdì e ti manda due calendar? Alzate il telefono e comunicate che il venerdì non è fatto per i meeting di emergenza - così vi sincerate che sia lui il pirla che ha davvero mandato il calendar!

Si può evitare il phishing?
No.
Ma si può limitare la superficie d'attaco, e dipende solo da noi.

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ò.