⚠️ CRITICAL React2Shell RCE (CVSS 10.0, CVE-2025-55182) is being actively exploited! Affects React Server Components & frameworks (Next.js, Vite, etc). Patch to React 19.0.1+ ASAP. Monitor for AWS credential theft & miner activity. https://radar.offseq.com/threat/critical-react2shell-flaw-added-to-cisa-kev-after--ea2329c0 #OffSeq #React #Infosec

L’interruzione di Cloudflare del 5 dicembre 2025 dovuta alle patch su React Server. L’analisi tecnica

Cloudflare ha registrato un’interruzione significativa nella mattina del 5 dicembre 2025, quando alle 08:47 UTC una parte della propria infrastruttura ha iniziato a generare errori interni. L’incidente, che ha avuto una durata complessiva di circa 25 minuti, si è concluso alle 09:12 con il ripristino completo dei servizi.

Secondo l’azienda, circa il 28% del traffico HTTP gestito globalmente è stato coinvolto. L’impatto ha riguardato solo clienti che utilizzavano una combinazione specifica di configurazioni, come spiegato dai tecnici.

Cloudflare ha chiarito che il disservizio non è stato collegato ad alcuna attività ostile: nessun attacco informatico, tentativo di intrusione o comportamento malevolo ha contribuito all’evento. A causare il problema è stato invece un aggiornamento introdotto per mitigare una vulnerabilità recentemente resa pubblica e legata ai componenti React Server, identificata come CVE-2025-55182.

Come si è arrivati all’incidente

Il disservizio è nato da una modifica al sistema di analisi dei body delle richieste HTTP, parte delle misure adottate per proteggere gli utenti di applicazioni basate su React. La modifica prevedeva l’aumento del buffer di memoria interno del Web Application Firewall (WAF) da 128 KB a 1 MB, valore che si allinea al limite predefinito nei framework Next.js.

Questa prima variazione è stata diffusa con un rollout progressivo. Durante l’implementazione, i tecnici hanno rilevato che uno strumento di test WAF interno non era compatibile con il nuovo limite. Ritenendo quel componente non necessario per il traffico reale, Cloudflare ha proceduto con una seconda modifica destinata a disabilitarlo.

È stata questa seconda modifica, distribuita con il sistema di configurazione globale – che non prevede rollout graduali – a generare la catena di eventi che ha portato agli errori HTTP 500. Il sistema ha raggiunto rapidamente ogni server della rete in pochi secondi.

A quel punto, una particolare versione del proxy FL1 si è trovata a eseguire una porzione di codice Lua contenente un bug latente. Il risultato è stato il blocco dell’elaborazione di alcune richieste e la restituzione di errori 500 da parte dei server coinvolti.

Chi è stato colpito

A essere interessati, riportano gli ingegneri di Cloudflare, sono stati i clienti che utilizzavano il proxy FL1 insieme al Cloudflare Managed Ruleset. Le richieste verso i siti configurati in questo modo hanno iniziato a rispondere con errori 500, con pochissime eccezioni (come alcuni endpoint di test, ad esempio /cdn-cgi/trace).

Non sono stati invece colpiti i clienti che utilizzavano configurazioni differenti o quelli serviti dalla rete Cloudflare operante in Cina.

La causa tecnica

Il problema è stato ricondotto al funzionamento del sistema di regole utilizzato dal WAF. Alcune regole, tramite l’azione “execute”, attivano la valutazione di set di regole aggiuntivi. Il sistema killswitch, utilizzato per disattivare rapidamente regole problematiche, non era mai stato applicato fino a quel momento a una regola con azione “execute“.

Quando la modifica ha disabilitato il set di test, il sistema ha saltato correttamente l’esecuzione della regola, ma non ha gestito l’assenza dell’oggetto “execute” nella fase successiva di elaborazione dei risultati. Da qui l’errore Lua che ha generato gli HTTP 500.

Cloudflare ha precisato che questo bug non esiste nel proxy FL2, scritto in Rust, grazie al diverso sistema di gestione dei tipi che evita questi scenari.

Collegamento con l’incidente del 18 novembre

La società ha ricordato come una dinamica simile si fosse verificata il 18 novembre 2025, quando un’altra modifica non correlata causò un malfunzionamento diffuso. In seguito a quell’episodio erano stati annunciati diversi progetti per rendere più sicuri gli aggiornamenti di configurazione e ridurre l’impatto di singoli errori.

Tra le iniziative ancora in corso figurano:

• un sistema più rigido di versioning e rollback,
• procedure “break glass” per mantenere operative funzioni critiche anche in condizioni eccezionali,
• una gestione fail-open nei casi di errore di configurazione.

Cloudflare ha ammesso che, se queste misure fossero già state pienamente operative, l’impatto dell’incidente del 5 dicembre sarebbe potuto essere più contenuto. Per il momento, l’azienda ha sospeso ogni modifica alla rete finché i nuovi sistemi di mitigazione non saranno completi.

Cronologia essenziale dell’evento (UTC)

• 08:47 – Inizio dell’incidente dopo la propagazione della modifica di configurazione
• 08:48 – Impatto esteso a tutta la parte di rete coinvolta
• 08:50 – Il sistema di alerting interno segnala il problema
• 09:11 – Revoca della modifica di configurazione
• 09:12 – Ripristino completo del traffico

Cloudflare ha ribadito le proprie scuse ai clienti e ha confermato la pubblicazione, entro la settimana successiva, di un’analisi completa sui progetti in corso per migliorare la resilienza dell’intera infrastruttura.

L'articolo L’interruzione di Cloudflare del 5 dicembre 2025 dovuta alle patch su React Server. L’analisi tecnica proviene da Red Hot Cyber.

Bonus Drop #104 (2025-12-06): Places, Pages, And Packets

Digging Coordinates; Gitmal; A Different Kind Of Packets For IPv6

This has been a week. My entire Thursday and Friday were consumed with React2Shell. If you have no idea what that is, don’t click the link. You are better off being in blissful ignorance of this most recent tech debacle. If, however, you like chaos, this is being updated a couple of times a day.

So, I’m chillin’ as much as possible this weekend, which leave plenty of time to make up for two missed Drops with what is hopefully a solid Bonus Drop.

Subscribe

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop. This week, I have been — for lack of a better word — forced into using Gemini, so today’s summary was provided by that model. Sigh.)

• The LOC DNS record, defined in RFC 1876 in 1996, allows for publishing the geographical coordinates (latitude, longitude, and altitude) of hosts, networks, and subnets, although its adoption is limited as most systems prefer IP geolocation databases for scale and privacy concerns (https://www.rfc-editor.org/rfc/rfc1876.html).
• Gitmal is a fast, theme-supported tool for self-hosting Git repositories that generates browseable file trees, nicely rendered markdown, and commit history pages, providing a much prettier alternative to the default rendered git pages (https://github.com/antonmedv/gitmal).
• A new IETF draft proposes allocating the IPv6 address block 44::/16 to the amateur radio (ham) community to replace their historical 44.0.0.0/8 IPv4 allocation, preserving their globally coordinated and routable address space for non-commercial and emergency communications (https://datatracker.ietf.org/doc/draft-ursini-44net-ipv6-allocation/).

Digging Coordinates

We Drop denizens loves us some RFCs, and way back in the before-times (in this case, January 1996), some smart, adorable technologists thought it would be a great idea to lay the foundations for our modern surveillance state by introducing a means of telling the world exactly where your “thing” was with a DNS record. Said record is LOC, and is intended to “describe a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. Such information for a small subset of hosts is currently contained in the flat-file UUCP maps. However, just as the DNS replaced the use of HOSTS.TXT to carry host and network address information, it is possible to replace the UUCP maps as carriers of location information.”

Thankfully, nobody really adopted use of LOC, since most systems that care about geography rely on IP geolocation databases (like MaxMind) instead of asking DNS for coordinates. It’s just easier to manage that data at scale and fits how routing and targeting are typically done. There’s also a real hesitation to publish precise latitude, longitude, and altitude in public DNS, since that can create privacy or security headaches. And for most services, exact physical coordinates just aren’t that useful anyway: CDNs and other geo-aware systems usually make decisions based on IP-derived signals, not “this server is at these coordinates.” One more practical detail is that the LOC record’s defining document, RFC 1876, was published as experimental rather than as an full internet standard, which tends to limit adoption. That said, LOC records do show up occasionally in niche situations, like internal network documentation and mapping, novelty “Easter egg” uses, or specialized cases where someone has a specific reason to publish precise location data in DNS.

There are a handful of them out there, and bo0tzz decided to map them all. One of them is even setup by my state (O_o):

Full source is available, and the folks working on it have even bothered to credit Claude (so, if “AI”-assisted coding and resultant apps are anathema to you, you can avoid tapping any of the links).

Gitmal

I’m seeing a very positive trend in the increasing number of clever folks abandoning GitHub. Many of them are going to Codeberg, with a smattering of others picking different new homes. However, we’ve noted on many an occasion that you can just use SSH to keep a remote Git repo up-to-date and rely solely on self-hosting. This puts more of a burden on you for things like CI/CD, but at least Git-proper comes with some tooling to generate websites so you and others can use a browser to introspect the source and other artifacts.

However, the default rendered git pages are not exactly easy on the eyes.

While there are many “git pages” generators to pick from if you want prettier output, Gitmal is a relatively recent one that is fast, has support for scads of themes, and focuses on the core problem to solve:

$ gitmal -hUsage: gitmal [options] [path ...]  -branches string        Regex for branches to include  -default-branch string        Default branch to use (autodetect master or main)  -gzip        Compress all generated HTML files  -minify        Minify all generated HTML files  -name string        Project name  -output string        Output directory for generated HTML files (default "output")  -owner string        Project owner  -preview-themes        Preview available themes  -theme string        Style theme (default "github")

When you run the main command, it scans your local repository and automatically generates pages for everything: a browseable file tree, nicely rendered markdown for your READMEs, and syntax-highlighted code for all your source files. It even creates pages to walk through the commit history of the repository, making the whole timeline super easy to explore.

While it’s designed to work out of the box, you have plenty of ways to tailor the output to your specific needs (as evidenced by the help block, above). Say you want to make sure your site loads as fast as possible. You can use the -minify option to shrink the HTML files and the -gzip option to create compressed versions. For aesthetics, gitmal defaults to a familiar “github” style theme, but you can easily pick a different one using the -theme option, or even use the -preview-themes flag to see all the available looks before you decide (it’ll give you a localhost URL to hit to preview them).

Did I mention it’s fast?

$ time gitmal \  --default-branch=batman \  --output /tmp/ja4-mcp \  -minify \  -name "JA4 MCP Server" \  -owner "hrbrmstr" \  -theme=evergarden> JA4 MCP Server: 1 branches, 0 tags, 2 commits> [1/1] JA4 MCP Server@batman[########################]   16/16   (100%) blobs for batman[########################]    1/1    (100%) lists for batman[########################]    1/1    (100%) commits for batman> generating commits...[########################]    2/2    (100%) commits> post-processing HTML...[########################]   23/23   (100%) minifyreal    0.26suser    0.53ssys     0.27s

You can preview that at https://rud.is/gitmal/ja4-mcp/.

This is also a well-organized and well-crafted Golang project, so I also recommend poking at the source if you’re even just a tad Go-curious.

A Different Kind Of Packets For IPv6

There’s a quiet corner of the Internet that’s built entirely on goodwill, volunteer effort, and radio waves. It’s the world of amateur radio, or ham radio, and its operators have been networking long before most folks ever heard the term. Back in the early 1980s, when the modern internet was just being stitched together, these pioneers were given a huge gift: the entire IPv4 address block of 44.0.0.0/8. That’s sixteen million addresses, known as 44Net, dedicated solely to non-commercial experimentation, education, and public service communications carried over radio links. It was a globally unified digital playground that helped the Internet grow up.

Fast forward four decades, and things quite different. We’ve run out of those original IPv4 addresses, and the internet has largely (I’m being generous) shifted to the much, much larger address space of IPv6. This shift has created a problem for the ham community. Their special, globally coordinated address space has no equivalent in the IPv6 world.

That’s where a new IETF draft proposal steps in. It asks for a specific allocation from the IPv6 global pool: the block known as 44::/16. Choosing the number 44 is a clear nod to their legacy, and provides a way of preserving the community’s identity as they transition into the future.

The idea is super straightforward: just as they had a single, recognizable address space for IPv4, they need one for IPv6. This is crucial because, unlike your home network, amateur radio networks often need to be globally routable and publicly reachable so they can interconnect, facilitate research, and provide crucial communications during emergencies or disasters. Isolating them onto non-routable, private addresses would defeat the whole purpose of their long-standing work.

But making this request today is complicated. The process for handing out addresses has changed drastically since the 1980s. Now, most allocations go through the Regional Internet Registries, or RIRs, which manage addresses in different parts of the world. The proposal doesn’t want to bypass the RIRs entirely; instead, it asks IANA, the global coordinator, to reserve the 44::/16 block and then distribute it through the RIRs under a common policy framework. This is their way of trying to maintain that global cohesion and consistency—a single block that means “amateur radio” everywhere—without undermining the current governance structure.

The request has definitely sparked some interesting conversations within the technical community. It brings up questions about whether an organization can ask for a block with such specific historical and social context when the modern system is designed for broad, regional distribution. However, the proposal’s heart is in the right place. Ensuring that a dedicated, non-commercial community of tinkerers, educators, and first-responders can continue their important work in the IPv6 era is, IMO, a worthy goal/mission.

If you’re interested in this effort or want to tap into it, just start following the working group comms and, perhaps, offer up some of your own opines.

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️

CVE-2025-55182
CVSS score of 10 (maximum possible)

Coreruleset patch to block (some?) CVE-2025-55182 exploit attempts:

https://github.com/coreruleset/coreruleset/pull/4372

#CVE_2025_55182 #modsecurity #coreruleset #react2shell

GlobalProtect di Palo Alto Networks è sotto scansioni Attive. Abilitate la MFA!

Una campagna sempre più aggressiva, che punta direttamente alle infrastrutture di accesso remoto, ha spinto gli autori delle minacce a tentare di sfruttare attivamente le vulnerabilità dei portali VPN GlobalProtect di Palo Alto Networks.

Il 5 dicembre Palo Alto Networks ha emesso un avviso urgente, esortando i clienti ad adottare l’autenticazione a più fattori (MFA), a limitare l’esposizione del portale tramite firewall e ad applicare le patch più recenti.

In base alle risultanze del report sulle attività di monitoraggio condotto da GrayNoise, che ha rilevato scansioni e sforzi di sfruttamento condotti da oltre 7.000 indirizzi IP unici a livello globale, le organizzazioni che utilizzano la popolare soluzione VPN per garantire la sicurezza del lavoro remoto sono state messe in allarme.

Targeting osservato da Ip (Fonte: GreyNoise)

A partire dalla fine di novembre 2025, sono stati rilevati attacchi che sfruttano le vulnerabilità dei gateway GlobalProtect, soprattutto quelle accessibili pubblicamente attraverso la porta UDP 4501.

GlobalProtect di Palo Alto Networks è da tempo un obiettivo primario a causa della sua onnipresenza negli ambienti aziendali. Difetti storici, come CVE-2024-3400 (una vulnerabilità critica di command injection, risolta nell’aprile 2024 con punteggio CVSS 9,8), continuano a perseguitare i sistemi non ancora patchati.

Le ondate recenti sfruttano configurazioni errate che consentono l’accesso pre-autenticazione, incluse credenziali predefinite o portali di amministrazione esposti. Gli aggressori utilizzano strumenti come script personalizzati che imitano i moduli Metasploit per enumerare i portali, effettuare accessi con forza bruta e rilasciare malware per la persistenza.

Secondo i dati di Shadowserver e di altri feed di intelligence sulle minacce, le fonti IP comprendono proxy residenziali, provider di hosting Bulletproof e istanze VPS compromesse in Asia, Europa e Nord America.

Gli indicatori di compromissione includono picchi anomali di traffico UDP sulla porta 4501, seguiti da richieste HTTP agli endpoint /global-protect/login.urd. Nelle violazioni confermate, gli intrusi hanno esfiltrato token di sessione, consentendo il movimento laterale nelle reti aziendali.

L'articolo GlobalProtect di Palo Alto Networks è sotto scansioni Attive. Abilitate la MFA! proviene da Red Hot Cyber.

Moved from webp-express to avif-express on my Wordpress site because the former has a security vulnerability (CVE-2025-11379) and looks unmaintained.

#CVE_2025_11379 #webp #avif #wordpress

🔎 CVE-2025-14141: HIGH severity buffer overflow in UTT 进取 520W (v1.7.7-180627) via /goform/formArpBindConfig. No patch; public exploit available. Isolate devices, restrict access, monitor traffic. https://radar.offseq.com/threat/cve-2025-14141-buffer-overflow-in-utt-520w-c6cc8954 #OffSeq #Vuln #NetSec #Exploit

Security researchers reveal critical security vulnerability in King Addons for Elementor WordPress plugin

Vulnerability:
CVE-2025-8489 - Improper validation of user roles during registration

Impact:
- Allows attackers to register themselves with admin role and gain full control of the website

Remediation: Update to a fixed version ASAP

#cybersecurity #WordPress #KingAddons #vulnerabilitymanagement

https://thehackernews.com/2025/12/wordpress-king-addons-flaw-under-active.html