r/netsec

The entry point wasn’t a CVE. It was a VS Code extension.

One GitHub employee installed a malicious extension. That single install gave attackers access to secrets on the device. Those secrets were used to move laterally into ~3,800 private internal repositories. GitHub’s own investigation called the number “directionally consistent.”

The threat actor didn’t need elevated privileges or a network exploit. The extension ran with the same permissions as the IDE — which on most developer machines means direct access to env files, git credentials, SSH keys, and workspace secrets. Private repo access control is only as strong as the tokens protecting it.

TeamPCP (UNC6780) listed the stolen source code on Breached for $50K+.

The part that actually concerns me: most teams have zero visibility into what extensions are running across developer machines. It’s been an unaudited attack surface for years.

Genuine questions for the thread:

Anyone enforcing extension allowlisting in their org without killing dev workflow?

Are teams still treating private repos as a security boundary for secrets storage?

Does developer workstation hardening belong in your threat model the same way servers do?

GitHub’s internal repositories were breached by a malicious VSCode extension:

https://xcancel.com/github/status/2056949168208552080

Microsoft closed an earlier request for update cooldowns as not planned but hopefully they’ll reconsider that:

https://github.com/microsoft/vscode/issues/272765

The current attempt:

https://github.com/microsoft/vscode/issues/316867

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.