r/netsec

I run a few n8n workflows in prod and I've been pulling templates from n8n website and GitHub. Last month I got curious about how safe they actually are if I just import them and wire my credentials. So I wrote a scanner and ran it on all of them.

12,750 templates total. 1,000 from n8n website (the top by views), 11,752 unique from the 8 biggest community repos on GitHub (88k combined stars, the ones you find when you Google "awesome n8n").

2,488 of them have at least one path where a request from the public internet ends up in a sensitive place: shell command, SQL query, AI prompt, HTTP request to an attacker-picked host. No login needed. Anyone who finds the webhook URL can hit them.

Some examples I tested end-to-end against my own synthetic targets:

What I learned that I wish someone had told me sooner: A template is not a finished product. It's a JSON file an author tested with their own credentials, on their own network, against their own threat model. None of that comes with it when you import. The view counter does not measure safety.

Before activating any community template, the two things to check first:

1. Every HTTP Request node's URL field. If it has `={{ $json.x }}` anywhere in the host part, that's an SSRF. Hardcode the host, put the dynamic part in path or query, validate it.

2. Every database node's query field. If the query string has `{{ }}` inside it, switch to the parameterised binding the node already supports.

The agent generating the SQL is not a real boundary.

Also: if the trigger is a public webhook, a public form, or a Telegram/chat bot, anyone on the internet is in your threat model. The README walkthroughs almost never say this.

If you've imported a template and now you're nervous, the post has a "what to check" section at the end. If you've shipped a template yourself, the same section is the patch list.

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.

Interesting new research you may have heard of on attacking large audio language models. The attack is called AudioHijack and the part worth paying attention to is that adversarial clips built against open models transferred to commercial Microsoft and Mistral systems sharing the same architecture. OpenAI and Anthropic are harder targets but the team thinks shared open-source audio encoders are a viable path in, and they're working on it.

The manipulations are shaped to sound like natural reverberation instead of added noise, so you can't really hear them. Threat model only requires controlling the audio the model processes, not the user's prompt. So: poisoned YouTube clips, music, voice notes, Zoom audio fed to transcription, and the team also says they've gotten this working against live voice chats in real time (unpublished).

Six attack categories demonstrated. Refusing user requests, returning false info, inserting malicious links, swapping persona, claiming it can't process audio, and triggering unauthorized tool use.

On the technical side, two things stood out to me. First, generative audio models tokenize the input, which kills the fine-grained gradient signal older adversarial audio work relied on, so they approximated it. Second, they explicitly hijack the attention mechanism by scoring how much attention the model pays to the adversarial audio vs. the user instruction and feeding that back into the optimization.

Defenses are where it gets bleak. Few-shot prompting with examples of malicious instructions cut attack success by 7%. Self-reflection caught 28%. Monitoring internal attention patterns was the only thing that actually worked, and an attacker who knows about it can dial back the attention manipulation and take a small hit to success rate to evade it.

Microsoft acknowledged the work and pointed at developer-side mitigations. Mistral didn't respond.

Text prompt injection at least leaves visible artifacts. Audio doesn't, and we don't really have a good story for this yet.

Thoughts?

Attacking Cloud Service Providers (ACSP) is an interactive textbook on control-plane intrusion and breaking cross-tenant isolation, built from 275 real-world cloud service provider(CSP) vulnerabilities.

This book is about hacking the cloud provider itself — breaking into the control plane, defeating cross-tenant isolation, and exploiting provider-side services and trust boundaries. It is not a guide to pentesting a single customer's cloud account. The target is the provider; the prize is everyone else's tenant. If your mental model of "cloud security" is misconfigured S3 buckets, this book will rebuild it.

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