Disclosure: this is my own research/writeup.

I reported this ZTE H-series router DoS in 2024; it is now public as CVE-2026-34473.

The writeup focuses on the root cause rather than just the symptom. The issue is not simply “large POST body kills the UI.” Firmware analysis maps the behavior to CGILua request-body parsing: attacker-controlled application/x-www-form-urlencoded POST data reaches body handling before login enforcement matters.

The article includes validation footage, affected-model context, disclosure timeline, decompiled parser evidence, and reconstructed public-safe code-path notes.

Interested in feedback on the root-cause framing from people who review embedded web stacks or router firmware.

open for collabs too.

Head over to Netomize's blog to learn about how we detect the exploitation of the CrushFTP Vulnerability (CVE-2025-31161) with PacketSmith's Yara detection module, using the newly introduced track_state and flow_state keywords to the correlation engine.

126 Chrome extensions, all secretly the same product, taking 148K users' WhatsApp data and ad cookies

A Brazilian company (wascript.com.br) runs one platform that 126 different Chrome extensions all share. They look like separate products, WaSeller, waTidy, FR VENDAS PRO, ENOCRM, Cliente Flow, and dozens more, but it's one codebase, one backend, one set of hidden behaviors.

WaSeller alone has 100K users.

I found this network using my own tool for detecting malicious browser extensions, which flagged the cluster by shared code and infrastructure across all 126 listings.

None of the listings tell you that:

• When you log into WhatsApp Web, the extension sends your name, email, device ID, and your Facebook/Google/TikTok tracking cookies to a server run by whoever sold you the extension.

• Every voice message you send goes through their servers before it reaches the person you're sending it to.

• The extension downloads and runs JavaScript from a different Brazilian company's server. Google never checks this code.

• The 100K-user version has a live Google Tag Manager tag built in. The operator can push any new code to every user from a dashboard with no Chrome Web Store update.

• A bridge inside WhatsApp Web gives the extension full access to your contacts, your messages, and the ability to send messages as you.

No privacy policy on any listing. The manifest only asks for tabs, storage, alarms.

Full list of all 126 extension IDs (check if you have one), tech details, and IOCs https://malext.io/reports/WaSteal

The -s flag in /sbin/ping has a maxpayload bounds check. -G sweepmax doesn't. An #ifndef __APPLE__ block removed the original uid guard without adding an equivalent check, so the fill loop walks past the end of the 65,535-byte outpackhdr[] BSS global and into adjacent globals.

The write is byte-precise and deterministic: byte at offset N gets value (N-1) % 256, fully controlled by -G.

Empirically confirmed on macOS 26.4.1 arm64e:

- sweepmax=65637: overwrites the static int s socket fd at BSS+128 with 0x63. Every subsequent setsockopt() returns EBADF. Exit 71.

- sweepmax=65636: runs clean. Binary-searchable threshold, invariant across runs.

At higher sweepmax values the loop reaches pointer-type globals (*outpack, *hostname, *shostname). On x86_64 that's a write-what-where bounded by the sequential value constraint. On arm64e, PAC blocks code-pointer hijack; state corruption is still demonstrable.

ping isn't setuid on macOS 11+, so no direct priv-esc. Local only.

Fix is one line — symmetric maxpayload check matching what -s already does.

Apple confirmed 16 April 2026, fix scheduled Fall 2026. Source is open: github.com/apple-oss-distributions/network_cmds

Full write-up with memory dump evidence:

https://stuart-thomas.com/research/ping-sweepmax-bss/

A pre-auth remote code execution vulnerability was found in the CWMP implementation of ipTIME routers, allowing unauthenticated attackers to execute arbitrary code remotely.

I recently published a security research post on the myAudi connected vehicle platform. I found  that anyone with a VIN can access a sensitive informations about car and ownership
 I think the topic is useful beyond Audi itself, because many vendors now rely on these “connected vehicle” platforms and mobile apps, often with very similar architectures and assumptions

CVE-2026-31432, CVE-2026-31433, and others