DEV Community: Jason Miller

Six Expired Domains Can Hijack Your AI Agents: Notes From a 15,465-Server MCP Audit

Jason Miller — Thu, 22 Oct 2026 17:53:21 +0000

If your agents call MCP servers you don't operate, here is the attack that costs less than lunch. OX Security's audit of 15,465 public MCP servers (deduplicated to 5,095 unique hostnames) found six sitting on expired domains, re-registerable for $4 to $12 a year. Buy one, stand up a server, and you inherit an established identity plus every agent still configured to call it. You see the queries those agents send, which often carry internal data and credentials. You control the tool descriptions that come back, which is a prompt-injection channel aimed straight at the model.

And it is not one scan. BlueRock scanned 12,000+ servers, AgentAvow statically analyzed 7,029, and the conclusions converge: somewhere between 30% and 82% of public MCP servers carry exploitable flaws, depending on method. Arguing about the exact number is a way of avoiding the work.

The rest of the greatest hits

Jurisdiction drift. 15.6% of hostnames resolve outside the US, including 19 in China and 18 in Russia. Worse, an operator can launch on a clean US IP and reroute later. A one-time geolocation check at approval is a screenshot of a moving target.
Servers running from somebody's house. 0.45% route through consumer tunnels like ngrok-free, roughly 70 servers in a dataset this size. Your agent calls a laptop in a spare bedroom with the same trust it gives your internal API.
The repo you reviewed is not the code that runs. Remote servers can execute backend code that differs entirely from the public repo. AgentAvow flags fetch-then-exec rug pulls (see MCPoison, CVE-2025-54136) and prompt injection embedded in tool descriptions.
The old web bugs moved into tool calls. BlueRock's numbers: about 33% allow unbounded URI fetch (SSRF), 42% have command injection. MCP servers are often thin wrappers around CLI tools, so the model's argument lands in a shell.
Composition is the killer. Server A reads your drive, B ingests untrusted web content, C sends email. Each looks fine alone. In one agent, they are an exfiltration pipeline. Also: 492 servers sit on the open internet with zero auth, and only 8.5% of public servers use OAuth.

"Those percentages are tiny"

Your agent does not connect to 15,465 servers. It connects to a dozen. Each connection is a binary trust decision with the full blast radius of that agent's permissions. The attacker does not need most servers to be malicious. They need the one your analyst installed last Tuesday.

"We only use well-known servers." Popularity is exactly what makes a server worth hijacking, and reputation verifies nothing at runtime.

Do this week

Inventory, then allowlist. Pull every MCP server any agent can reach: mcp.json, IDE and desktop agent configs, gateway routes. One named owner per server. No owner, no connection. Deny everything else at the egress layer.
Vet domains like an attacker shopping for them. Registration date, expiry, resolution history, then keep checking weekly for anything touching sensitive data:

  whois mcp-vendor.com | grep -iE "creat|expir|upd"
  dig +short mcp-vendor.com   # alert if this answer changes

Egress proxy, deny by category. Then test the SSRF path: point any fetch-style tool your agent can call at the instance metadata URL and see what comes back.

  deny 169.254.169.254/32      # cloud metadata
  deny 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
  deny *.ngrok-free.app        # personal machines

Stop treating repo review as proof. For remote servers it is a signal, nothing more. Watch runtime behavior and network destinations instead.

Question for the comments: if your agents talk to third-party MCP servers today, what actually detects a server changing its behavior or its IP after approval? Most answers I have heard so far are "nothing," and I would love to be wrong.

Longer writeup with the full ranked findings and methodology: https://axeploit.com/blog/15465-mcp-servers-six-expired-domains-and-the-checklist-your-team-skipped

Put Your AI Agent's Permissions in Postgres, Not the Prompt

Jason Miller — Wed, 21 Oct 2026 16:02:27 +0000

Odds are good that somewhere in your company, a database connection string lives in an .env file, wrapped in a Python function, registered as a tool with an agent framework. It authenticates as a service account with read access to the full schema. Every guardrail you wrote in the prompt or the middleware sits downstream of that one fact.

You can build perfect app-layer controls and they still only cover the traffic you remembered to route through them. The second agent someone ships next quarter, the migration script run at 2 a.m. None of them touch your middleware. Every one of them touches the database. That's why agent authorization belongs in Postgres.

One agent, one role

Baseline: every agent gets its own non-human identity. Shared service accounts kill attribution, so when the support bot does something weird you can't tell which human it acted for. In Postgres this is a role per agent with column-level grants:

GRANT SELECT ON support.tickets TO agent_support_bot;
GRANT UPDATE (status, internal_note) ON support.tickets TO agent_support_bot;
REVOKE ALL ON SCHEMA support FROM PUBLIC;

The agent can update two columns, not the row. None of this comes from the model. The model proposes structured tool calls, and execution happens with scoped credentials from a secrets broker, expiring in minutes or hours rather than whenever someone remembers to rotate a password.

Row security that fails closed

Grants scope the agent to a table. Row-level security scopes it to the rows this request should see, on behalf of this user:

CREATE POLICY tickets_agent_read ON support.tickets
  FOR SELECT TO agent_support_bot
  USING (
    tenant_id = current_setting('app.tenant_id', true)::uuid
    AND classification <> 'restricted'
  );

The detail that matters is the second argument to current_setting. With true, Postgres returns NULL instead of throwing when the setting is missing, and a NULL comparison filters every row. If your calling code forgets to set tenant context, the agent sees nothing. Policy undefined means no. Add FORCE ROW LEVEL SECURITY to close the table-owner exemption.

One warning: the tenant value has to come from your execution layer, derived from the authenticated session. If the model can influence app.tenant_id through a tool argument, you've built a prompt injection path straight to your data, with row-level security that technically works.

The pooler will leak your tenant context

This is the part that breaks in production. You're running PgBouncer in transaction mode, and a session-level SET does not survive transaction boundaries. Worse, it can survive in the wrong direction. If any code path uses plain SET on a pooled connection and that connection goes back to the pool, the next borrower inherits the previous tenant's context. Your policy is correct and your rows still leak across tenants. This one survives code review easily, because each line looks right on its own.

The pattern that works is transaction-scoped settings:

BEGIN;
SET LOCAL app.tenant_id = '8b7c2f10-...';
SET LOCAL app.end_user  = 'user_4821';
-- query runs here, policies apply
COMMIT;

Ban session-scope SET in your shared data-access library and make SET LOCAL the only API. Then set server_reset_query_always = 1 in PgBouncer, because the default reset query only fires in session mode. For your most sensitive schemas, a dedicated pool per tenant makes a bleed architecturally impossible.

If you do four things this week:

Create one LOGIN role per agent with column-level grants, and revoke what PUBLIC hands out by default.
Turn on RLS with policies that read current_setting('app.tenant_id', true) so missing context returns zero rows, then FORCE it.
Grep your data layer for session-scope SET on pooled connections and replace it with transaction-scoped SET LOCAL.
Audit with a trigger writing trace_id, agent_id, and on_behalf_of on every write. App logs record what the agent intended, the trigger records what the database did. When they disagree, believe the trigger.

Is anyone actually running a role per agent in production, or is everything still one fat service account behind an ORM? Curious what broke first for the people who made the switch.

Longer writeup with the full audit schema and trigger code: https://axeploit.com/blog/your-ai-agent-s-permissions-belong-in-postgres-not-the-prompt

Stop panic-grepping your lockfile after an npm compromise alert

Jason Miller — Sat, 17 Oct 2026 21:58:14 +0000

A line in package-lock.json means your dependency tree can resolve the bad version. It says nothing about whether a machine downloaded it, and even less about whether it ran. Yet the first hour of every npm supply-chain alert gets spent on that one grep, and both outcomes are premature: found it, panic; absent, relief.

This is how I run that hour instead. Four questions, fixed order.

Q1. Is the package in any lockfile, in any repo?
    NO          -> Record the check, stand down.
    YES         -> Q2

Q2. Is the resolved version inside the advisory's affected range?
    NO          -> Verify the integrity hash, pin, stand down.
    YES         -> Q3

Q3. Did any CI job or dev machine install while that version
    was in the lockfile?
    NO          -> Fix the lockfile, confirm CI is green, no rotation.
    YES/UNKNOWN -> Q4

Q4. Could it have executed? (install scripts enabled, or the
    package is required by your build, tests, or bundler)
    NO          -> Fix the lockfile, archive logs, monitor.
    YES/UNKNOWN -> Rotate everything CI could see. Open an incident.

Notice how often UNKNOWN is the honest answer. It routes to yes, every time. An unnecessary rotation costs an afternoon. A missed one costs an attacker sitting in your cloud account for a quarter while you feel good about a grep result.

Where each node goes wrong

Q1: monorepos and branches. Grep every lockfile: the second and third ones in the monorepo, the yarn and pnpm files, release branches that still get builds. CI builds branches, not just main. Then npm ls <package> shows who drags it in, usually transitively, via a build tool nobody remembers adding.

Q2: compare the pinned version against the advisory's affected range, then confirm the lockfile's integrity hash still matches what the registry serves (npm view <pkg>@<version> dist.integrity). A mismatch is its own incident.

Q3: reconstruct the window from git, not memory.

git log -S '"<package-name>"' --oneline -- package-lock.json

The commit where the bad version appears and the one where it disappears bracket the window. Any job that ran npm ci inside it fetched the package. Archive the build logs immediately; CI retention is short and you cannot rebuild this timeline next week. If you cannot prove no install happened in the window, the answer is yes. Missing logs are not evidence.

Q4: two execution paths. Install-time payloads need lifecycle scripts, so jobs running with --ignore-scripts never fired them. Check the actual CI config for every job, not your memory of it. Runtime payloads are sneakier: if npm ls puts the package under your test runner or bundler, assume it executed in those jobs.

When Q4 says yes: rotation order

The attacker's head start is measured in hours, so order matters. Mine, by blast radius (no vendor publishes an official one that I know of):

Push and publish credentials: npm tokens, write-scoped source-control tokens, deploy keys. These buy persistence. Revoke first.
Cloud and infra keys held by CI. This is where a build compromise becomes a production compromise.
Runtime secrets: DB passwords, API keys, webhook secrets.
Developer machines, if the window was days long. Laptops installed it too.

Two operational rules: revoke, then reissue (on some platforms the old secret stays valid until explicitly revoked), and deliver new secrets through a clean path. Pushing fresh credentials into the same CI with the tokens that just leaked is how incidents get sequels.

Use today:

Treat the lockfile grep as question one of four, not the verdict.
Default UNKNOWN to yes at every node.
Archive CI logs the same hour; retention will not wait for your postmortem.
Practice the rotation from a known-good machine before you need it.

What I will argue in the comments: if your CI has no egress logging and keeps build logs for days, you cannot answer Q4 honestly, so every alert becomes a full rotation. Is that an argument for fixing the observability gap, or is blanket rotation genuinely the cheaper policy at your scale?

Longer writeup with the full argument and commands: https://axeploit.com/blog/lockfile-presence-is-not-execution-the-first-60-minutes-of-an-npm-supply

Google's AI Found 500 XSS Bugs, and the Model Is the Least Interesting Part

Jason Miller — Sat, 17 Oct 2026 15:57:22 +0000

Google turned an AI agent loose on its own web apps and it came back with more than 500 verified XSS vulnerabilities. None of them will ever pay a bounty. That second sentence is the real story.

The agent is PageBreak, built by Google's Product Security team. Pilot in November 2025, full project by January 2026, running mostly on Gemini 3.1 Pro and 3.5 Flash. Coverage has fixated on the 500. The 500 is a marketing number. The architecture is the news.

The validator is the product

Every AI security demo follows the same script: point a model at code, get a plausible vulnerability narrative, declare victory. PageBreak works because Google's team refused that script early. The model generates hypotheses. Then a suite of validators, written by humans, not generated by the model, executes real payloads against running environments. A finding only exists if the exploit actually fires.

The validators are boring, and that is the point:

XSS: inject a JS payload, confirm execution in a rendering harness
SQLi: check output, timing, or both
Path traversal: write a file somewhere world-readable, then read it back
SSRF: watch for outbound requests to internal services

The gate is roughly:

if validator.confirms(hypothesis):
    report(hypothesis)      # a human sees this
else:
    quarantine(hypothesis)  # kept as a seed, never reported

That quarantine is the discipline. Unverified candidates never reach product teams. Compare that with tools that dump every hypothesis on a dashboard and call it coverage. If your agent cannot execute its own claims, you are paying triage engineers to read someone else's inference output.

The trade Google actually admits

Deterministic-only validation guarantees false negatives. Bug classes without validators, or bugs needing multi-step state the harness can't reproduce, get missed. Google says this out loud, which is more than most vendors manage.

Proof the trade is real: against apps built on Google's high-assurance web frameworks, PageBreak found exactly 2 XSS across hundreds of apps. Secure-by-default frameworks nearly zero out the class, and whatever sits outside validator coverage (WebSocket-heavy surfaces, for one) stays human territory.

Precision is a trust problem. Recall is a roadmap problem you fix by writing more validators. Google picked correctly: once product teams learn your queue is noise, they stop reading it permanently.

What this does to bounty economics

Here is the asymmetry nobody covered. Internal agents like PageBreak file only verified bugs. External hunters with off-the-shelf LLM tooling will file more unverified ones, because their incentive is volume and the tool's incentive is plausibility. Your external noise rises at exactly the moment mature companies stop generating their own.

And look at what Google chose to show off: a cache-poisoning bug where the tainted path segment was excluded from the cache key, a signature bypass chained across two endpoints on admin.google.com, a universal XSS in an extension's message passing. None of those is a single-step reflected XSS a 2009-era scanner catches. That is the human niche that survives: chained, context-heavy bugs.

If the owner of a surface can enumerate single-step XSS at near-zero marginal cost, the market price of finding one more collapses. Google's 500 internal bugs are 500 reports that will never be purchased from the outside market.

Takeaways you can use this week:

Running a bounty program? Gate triage on execution evidence: a payload that fires, a trace, a video, or a run in a sandbox you provide. Everything else goes to automated reproduction before a human reads it.
Reprice your payout table now. Lower the base for single-step web bugs, add multipliers for chained impact, and publish which classes your internal automation already covers.
Evaluating AI appsec tooling? Ask one question: show me the validator. If findings are not confirmed by execution, you are looking at a demo.
Hunting for a living? Stop farming single-step XSS on big surfaces. That window is closing.

For the comments: does "near-zero false positives" convince you when it is self-reported, or does the mechanism (no execution, no report) make the claim falsifiable enough to trust?

Longer writeup if you want the full argument: https://axeploit.com/blog/500-xss-bugs-zero-bounty-payouts-what-google-s-pagebreak-agent-does-to-the

Your LLM API Keys Are Cash. The METR Breach Proves It.

Jason Miller — Fri, 16 Oct 2026 17:17:10 +0000

The METR attacker spent three weeks inside a researcher's cloud instance and touched nothing sensitive. They burned roughly $600,000 in inference credits instead, and that should change how you handle your own keys more than any data breach this year.

Short version: a researcher ran agents on a personal, internet-facing EC2 instance holding a key to METR's general-access account. A vibe-coded agent app had a fail-open bug that silently disabled the Google auth in front of it. The attacker likely found it by scanning certificate transparency logs for LLM-flavored hostnames, then just asked the agent for its provider API key. The agent answered. Nobody noticed for three weeks, partly because METR's usage is enormous and spiky, partly because the credits were donated so there was no bill to trip over.

Stolen inference has no laundering step

Stealing data is a business with friction: you need a buyer and a way to prove the goods are real. Stolen compute converts to value immediately. Run your own workloads or resell access through a proxied endpoint. This pattern has a name, LLMjacking, and METR is the cleanest public case of it working at scale. The attacker monetized the most liquid thing on the box, and it wasn't data.

Spend alerts are the weakest control that matters

Every recap name-checks spend alerts. I think that's backwards. Alerts alone tell you how bad the damage was. Scoping limits what a stolen key can buy. Caps decide how much it can cost.

My rules:

One key per workload, never per person or per org. When one leaks, you revoke one thing and know exactly what broke.
Personal infrastructure gets personal keys, or no keys. Write that policy before the incident, not after.
Agents should not hold provider keys at all. Broker them through an internal endpoint so a prompt-injected (or just helpful) agent has nothing to hand over.

Then every key gets a hard monthly cap, roughly 2x to 3x its historical peak, soft alerts at 50% and 80%, a page at 95%. If the provider can't cap that key class (METR's exact situation), put the key behind an egress proxy or LLM gateway you control and enforce caps there:

- key: evals-batch-prod
  scope: ["chat:completions", "batch"]
  monthly_cap_usd: 12000
  alert_at: [0.5, 0.8]
  page_at: 0.95
- key: researcher-experiment-mk
  scope: ["chat:completions"]
  monthly_cap_usd: 200

Detection has to be per key, not per org. Three weeks of abuse hid inside METR's org-wide volume. An experiment key burning at 4x its own baseline on a Sunday at 3 a.m. stands out even when the org total looks normal. Also alert on off-schedule spend: evals run on schedules, thieves don't.

Your agent dashboard is in certificate transparency logs

The moment you get a cert for agent-dashboard.example.com, the name sits on a public list that attackers grep for LLM and agent keywords. Assume it gets catalogued the day it goes up.

So test auth from outside, and test the error path, not just the happy path. METR's bug was fail-open. Run this from an unauthenticated context, on a schedule:

curl -s -o /dev/null -w "%{http_code}\n" https://agent-dashboard.example.com/

A 200 means auth just failed open. Test revoked tokens and an unreachable identity provider too. And watch CT logs for your own namespace. It's the same recon the attackers run, pointed inward.

What I'd do this week:

Inventory every provider key with scope, owner, and monthly burn. If your team can't build that list in an afternoon, that's the finding.
Cap every key, and keep a short-TTL break-glass key so a firing cap during a deadline never becomes the reason someone bypasses the control.
Take provider keys out of agent processes entirely.
Curl your own dashboards unauthenticated. Today.

My claim to argue with: spend alerts as a primary control just make teams feel covered while scoping and caps do the real work. Agree?

Longer writeup with the full timeline and the PromQL alert rules: https://axeploit.com/blog/one-key-three-weeks-600000-attackers-are-cashing-out-ai-credits-not-data

The Super Forms RCE takes two requests, and the first one just asks the site for a nonce

Jason Miller — Thu, 15 Oct 2026 17:01:18 +0000

Wordfence has blocked over 440,000 exploit attempts against two WordPress plugin flaws, and the worse one demands nothing from the attacker. No session, no scraped nonce, no race condition. Two unauthenticated HTTP requests and you have code execution.

Two requests, one webshell

CVE-2026-14894 (9.8) sits in the Super Forms submit_form AJAX handler: no file type validation, no capability checks. Normally a missing nonce check still forces the attacker to scrape a valid nonce from a page, which adds friction. Here the plugin ships a second unauthenticated AJAX action, super_create_nonce, that mints a valid nonce and session cookie to any anonymous visitor on demand. The server hands over the lock pick.

So the chain is: request one mints the nonce, request two POSTs to admin-ajax.php with a Base64 PHP payload disguised as data:image/gif;base64 and an attacker-chosen .php filename. The observed drop is Mushr00w_upl.php, an uploader webshell used to run commands and create admin accounts. Fixed in 6.3.314.

Elementor Pro's CVE-2026-32475 is a parser trick instead. Submit the File Upload field as an array where the first element is empty and the second carries a .php payload, and validation waves it through into /wp-content/uploads/elementor/forms/, directly requestable. One real caveat: the site needs a published page containing a Form widget with a File Upload field. That likely explains why it's scored 9.0 in some places and 9.8 in others. Don't treat it as protection. Upload fields are common in contact and quote forms, and an unpatched site becomes exploitable the moment an editor adds one. Fixed in 4.2.2.

Why this industrializes before you patch

The exploit is a curl command. Turning a public writeup into a scanner module is an afternoon of work. Wordfence tracked campaigns hitting both plugins in parallel, ten source IPs each, peaking at 40,000 requests in a single day against Super Forms alone. Nobody picked your site. Every host running the plugin is a candidate, and obscurity is not a control.

Also worth pricing in: Wordfence ships new firewall rules to premium customers first, free tier roughly 30 days later. If you're on the free tier, you had no rule during the campaign peak. And even a working rule does nothing about a shell dropped before it existed, because updating the plugin does not remove a webshell. The WAF buys patch time. The update is the fix.

Patch first, then hunt

Order matters. Patch to stop new uploads, then hunt, because anything you find predates the patch and the patch won't remove it.

# the two-request kill chain, if the action rode in the query string
grep -E "admin-ajax\.php\?[^\"]*action=super_create_nonce" /var/log/nginx/access.log

# Elementor shells being executed after upload
grep -E "uploads/elementor/forms/[^ ]*\.php" /var/log/nginx/access.log

# PHP where no PHP should be
find wp-content/uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.phar" \) -ls

Then run wp user list --role=administrator and question every account you don't recognize. Admin creation is part of the observed post-exploitation behavior. If you find a shell: isolate the host, restore from a backup that predates the first suspicious log entry, and rotate every credential on the box.

Do today:

Patch Super Forms to 6.3.314 and Elementor Pro to 4.2.2. Same day is the correct default for unauthenticated plugin RCEs with public writeups.
Hunt even if your WAF blocked the attempts. A block is not a cleanup.
Audit your Elementor pages for File Upload fields so you know your exposure before an editor adds one.

Argue with me in the comments: should a security plugin's free tier get firewall rules at the same time as paying customers, or is the 30-day delay a legitimate business model?

Longer writeup if you want the full argument: https://axeploit.com/blog/the-super-forms-exploit-needs-two-requests-attackers-sent-440000

Same Extension ID, Different Publisher: What Actually Installs When Your Team Moves to Cursor

Jason Miller — Wed, 14 Oct 2026 16:59:09 +0000

Nobody on your team checked which extension versions landed when they moved from VS Code to Cursor. They searched the same IDs, clicked install, and went back to work. That is the blind spot: Cursor can't use Microsoft's extension marketplace at all, so the ID your developers trust can resolve to a different publisher shipping different code.

The registry swap nobody announced

Microsoft's marketplace terms restrict it to VS Code itself. Forks like Cursor are locked out by contract, so Cursor routes extension search and downloads through its own proxy in front of Open VSX, the open registry. Cursor's documentation is unusually honest about what that means: the same publisher.extension name can point to a different publisher or different code on Open VSX than on Microsoft's marketplace. For some popular extensions that never made it to Open VSX, Cursor ships its own "Anysphere" replacement builds.

Even when the publisher matches, versions drift. Open VSX copies are published separately, nothing guarantees parity, and there's no lockfile or pinning mechanism for IDE extensions. Auto-update is on by default, so the artifact you vetted and the artifact running next month are not the same thing.

Drift has already been exploited

In July 2025 a malicious "Solidity Language" extension on Open VSX ran a PowerShell script on install. It passed 50,000 downloads before removal, and one crypto-industry Cursor user lost roughly $500,000, per Kaspersky research. Microsoft reportedly killed the same or a similar submission on its own marketplace within seconds. The Open VSX copy lingered.

Then there are the OX Security findings: CVE-2025-65717 in Live Server (CVSS 9.1), CVE-2025-65715 in Code Runner, CVE-2025-65716 in Markdown Preview Enhanced. Every published version of those three is affected, and OX reports the maintainers never responded to disclosure. If your editor serves an older build, there's no patched version waiting on the other side of an update.

Cursor also ships with Workspace Trust disabled, and its Marketplace Install Cooldown, which delays installs until a version has soaked for a set number of hours, defaults to 0. A malicious update pushed to Open VSX can reach every developer in your org the moment auto-update fires.

Audit the installed set this week

This takes an afternoon. Do it before arguing about policy.

# Baseline from VS Code
code --list-extensions --show-versions

# What Cursor actually installed
cursor --list-extensions --show-versions

# Cross-check on disk (folder names embed versions)
ls ~/.cursor/extensions

# Per extension, compare Open VSX against the Microsoft listing
curl -s "https://open-vsx.org/api/<publisher>/<name>" \
  | jq '{version, publisher: .publishedBy.loginName}'

Flag anything where the publisher differs between registries, the installed version trails the Microsoft listing by more than a minor release, the publisher shows as Anysphere where you expected the original vendor, or the extension is installed but absent from Open VSX entirely.

My position: malware scanning at the proxy doesn't touch this problem, because a scanner passes extensions that are clean but stale, or from a publisher you never vetted. An allowlist is the single highest-value control here, and a cooldown under 72 hours for anything touching credentials is negligence dressed as convenience.

Take this week:

Diff code --list-extensions against cursor --list-extensions and give every mismatch a named owner.
Enable AllowedExtensions team-wide, default-deny, via the team dashboard or MDM.
Set the Marketplace Install Cooldown to at least 72 hours and turn on Open VSX signature verification (it proves origin, not intent).
Treat any installed Live Server, Code Runner, or Markdown Preview Enhanced version as affected and decide what replaces them.

If you've run this diff on a real team, what did you find? I'm curious how common publisher swaps and Anysphere substitutions actually are in the wild.

Longer writeup if you want the full argument: https://axeploit.com/blog/same-extension-id-different-code-what-actually-installs-when-your-team

Your Threat Model Assumes Attackers Get Bored. Schneier's DEF CON Talk Says They Won't

Jason Miller — Mon, 12 Oct 2026 16:52:12 +0000

Most of what gets sold as "AI-powered attack" is a human playbook running on faster hardware. The threat worth planning for is the other kind: models that find the loophole themselves, sometimes with nobody aiming them.

That was Bruce Schneier's DEF CON talk in August, extending his 2022 book A Hacker's Mind. His working definition of a hack: something a system permits that its designers never anticipated and don't want. The move most coverage skipped is simple. Humans sample the space of permitted behavior, because attention is expensive and runs out. A machine can enumerate it. Trying costs nearly nothing.

If that sounds abstract, his own blog supplied receipts within weeks: an AI solving a cipher from 1809, and a bypass of Apple's iOS inactivity-reboot feature. His closing line on the second one: "AI turns out to be really good at this sort of thing." Neither is a catastrophe. The point is compression. Finding the permitted-but-unwanted path through a complex system used to take a specialist weeks. It's becoming a side effect of a general-purpose model.

"Nobody would try that" stops working

Human attackers are impatient. They stick to known vuln classes, documented parameters, the happy path with a twist. A machine searching your state space has no such economy. Undocumented parameter combinations get tried. So do out-of-order API calls and states your code permits but your UI can never produce.

So act like the machine. Mint credentials as tenant A, replay them against tenant B's resources, and see what your API actually permits instead of what you intended. If any part of your security quietly relies on attacker boredom, that exercise will find it.

Your rulebook is attack surface

Notice that Schneier's examples mostly aren't software. Tax codes, airline mileage runs, the filibuster. Your org runs on the same material: pricing tiers, promo codes, refund policies, rate limits, trial rules, permission matrices. A capable model doesn't just fuzz your parser. It reads your pricing page and terms of service the way a tax attorney reads the code. Think promo stacking, quota arbitrage across API plans, mileage runs against your loyalty program.

The review fits in an afternoon. Inventory your rule-governed features. For each, write one sentence: what the system permits, what we intend, where the two diverge. If you can't state the intended behavior precisely, that gap is your first finding.

Retest on change, and watch your own agents

If discovery compresses, the half-life of a clean test result shrinks with it. An annual pentest was always a snapshot, and against an adversary that re-searches your surface every time you ship, it expires faster than your compliance calendar admits. Tie retesting to rule changes instead of anniversaries. Every pricing change, new promo mechanic, new role or API plan is fresh attack surface and deserves an abuse-case pass within days.

Also, the genie problem cuts both ways. Give your own agent an underspecified goal ("reduce cloud spend", "maximize trial conversions") and it will find loopholes in your systems as happily as any attacker's model. The first non-human hacker your company meets may be one you deployed.

The fair objection: models hallucinate, exploit reliability is mediocre. I've rolled my eyes at the same demos. But this argument doesn't need superhuman capability. It needs cheap, patient enumeration plus occasional success, aimed at rule systems nobody ever audited. Search got cheaper than your obscurity.

Things you can do this week:

Write the permitted-vs-intended sentence for every pricing, promo, and permission rule you own
Run the tenant replay: mint as tenant A, replay against tenant B
Add retest triggers to rule changes, not just the annual pentest
Give internal agents written invariants and test them off the happy path

What's the rule-governed feature in your stack you'd least want a patient machine reading? For me it's refund policy.

Longer writeup if you want the full argument: https://axeploit.com/blog/your-tools-automate-attacks-schneier-s-def-con-talk-warns-of-machines-that

GitSpawn: One Line in .git/config Turns Your Coding Agent Into a Command Runner

Jason Miller — Sun, 11 Oct 2026 15:35:21 +0000

The payload never touches the model. It sits in the repository's own Git config, and what fires it is your agent's first background git status.

Manifold Security's GitSpawn disclosure covered eight flaws across seven CLI coding agents, with four still unpatched at publication. This isn't prompt injection and it isn't MCP misconfiguration. The command runs as your user, outside the agent's sandbox, and never hits an approval prompt.

The sink and the trigger

core.fsmonitor is a legitimate Git performance feature. Its value is a command Git runs to find changed files in large repos, and any operation that refreshes the index executes it. That includes git status and git diff, the two most boring commands in the tool.

A poisoned repo needs exactly one line:

[core]
    fsmonitor = <attacker command>

CLI agents don't sit idle when you open a project. They call git status or git diff at session startup to learn the branch and what changed, and they leave local config untouched while doing it. Repository config in, background Git call out.

The timing is the ugly part. Per Manifold's testing, Claude Code and Hermes Agent fire the payload before the workspace-trust prompt is accepted. The dialog meant to protect you renders after you're compromised. Qwen Code fires before you've even authenticated. Grok Build fires on the first keystroke.

Who's still exposed

The mitigating constraint: a plain git clone doesn't carry local config, so cloning a malicious repo from GitHub won't infect you. The repo has to arrive as files with .git intact. A zip from a contractor, a vendor's shared drive, a synced project folder, a repro archive from support. If "the repo showed up as a download" describes any part of your workflow, you're in the threat model.

Fixed so far: goose (CVE-2026-72718, the only scored finding), Cursor, Codex, and Claude Code's core.fsmonitor path (2.1.196).

Unpatched at publication:

Hermes Agent. Manifold says six contact attempts across five channels went nowhere.
Qwen Code. The version Manifold retested was still the latest npm release.
Grok Build. Still executing repo-supplied commands on retest.
Claude Code's second path, behind claude ultrareview. It uses a different config key Manifold withheld, so unsetting fsmonitor alone does not close it.

The detail that should worry tool makers: this exact bug was fixed before. Claude Code 2.0.34 (November 2025) stopped running git status before trust approval. The behavior was back in 2.1.193 (June 2026). VS Code and JetBrains IDEs shipped the same "code runs before the trust prompt means anything" pattern years earlier. Point fixes on startup ordering don't hold. The trust gate has to wrap every Git invocation, permanently, with a regression test, or this keeps coming back.

What to do this week

Any directory that arrives from outside your org with its .git folder gets inspected before an agent touches it, or it doesn't get opened:

# Look for command-valued keys in local config
git -C /path/to/repo config --local --list --show-origin

# Check and remove the known key
git -C /path/to/repo config --local core.fsmonitor
git -C /path/to/repo config --local --unset core.fsmonitor

Don't rely on the agent's permission modes here. The payload runs outside that sandbox, so put the boundary at the OS: a disposable container or VM, or a separate user account with no access to your keys or cloud credentials.

Usable today:

Run git config --local --list --show-origin on any repo that arrives as files, before an agent opens it.
Re-clone from the canonical remote and work in the fresh clone instead of a handed-off folder. Clone drops local config.
Unset core.fsmonitor, but treat it as necessary, not sufficient. The claude ultrareview path uses a withheld second key.
Check .git/hooks while you're in there. Older attack class, same delivery.

Question for the comments: does your team actually inspect repos that arrive as archives or shared folders before an agent touches them, or is "we trust the download" still the real policy?

Longer writeup with the full per-agent table and attack chain: https://axeploit.com/blog/gitspawn-the-git-performance-flag-that-turns-coding-agents-into-command

The new Shai-Hulud worm scans 469 credential paths. The number that should worry you is 189.

Jason Miller — Sat, 10 Oct 2026 13:42:09 +0000

Every writeup of the latest Shai-Hulud infostealer variant led with the same figure: 469 credential locations across dev environments, CI/CD tooling, and cloud configs. Almost none mentioned the earlier count, 189. That gap means the authors audited their own coverage and found 280 spots on a developer machine they had been skipping. Attackers iterate on their steal lists the way your team iterates on a roadmap.

GitGuardian's report (via The Hacker News) names categories, .env files, shell history, package-manager and CI/CD configs, CLI caches, IDE and AI tool settings, but never lists the paths. The exact enumeration matters less than you'd think. Credential files are boringly predictable. Tools write them to the same default paths on every laptop on earth.

The key line deserves a direct quote: "Attackers have stopped trying to break trust relationships and started using the credentials that already make those relationships work." A worm with 469 paths isn't exploiting anything. It reads files your account is allowed to read.

Why your laptop beats any server

~/.aws/credentials is the same path on every laptop in your fleet, so a 469-entry list covers most of it with zero reconnaissance. The worm runs as the logged-in user, so the permissions protecting /etc/shadow do nothing for dotfiles you own. And secrets cross domains: a token in a local CI config might administer a production cluster.

My arguable take: repository scanning is necessary hygiene, and it's the wrong battlefield for this worm. Shai-Hulud doesn't need you to commit anything. It reads what your tooling already cached to disk. GitGuardian counted 28.65 million new hardcoded secrets on public GitHub in 2025, and that's only what leaked into public view.

Top of the target list: package publishing. Steal a token from ~/.npmrc and you can push your code to everyone who trusts that package. Theft converts directly into distribution.

A big chunk of the new 280 paths is the AI stack. MCP server configs carry plaintext API keys for every service the agent can touch. Coding agents stash provider keys in their config directories. Fastest-growing part of the credential surface, least inventoried. Bad combination.

Audit your own machine in five minutes

Run this before you ask anyone else to. It prints which paths exist, never their contents.

paths=(
  ~/.npmrc ~/.pypirc ~/.gradle/gradle.properties ~/.cargo/credentials.toml
  ~/.aws/credentials ~/.aws/cli/cache ~/.azure ~/.config/gcloud
  ~/.kube/config ~/.docker/config.json
  ~/.git-credentials ~/.netrc ~/.config/gh/hosts.yml ~/.ssh
)
for p in "${paths[@]}"; do [ -e "$p" ] && echo "PRESENT: $p"; done

find ~ -maxdepth 4 -name '.env*' -not -path '*/node_modules/*' 2>/dev/null | head -50

Then check how git stores credentials, and scan shell history for token shapes:

git config --global credential.helper
# "store" means forge tokens sit in plaintext at ~/.git-credentials
grep -icE 'AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{20,}|npm_[A-Za-z0-9]{20,}|xox[bap]-' \
  ~/.bash_history ~/.zsh_history 2>/dev/null

Any history count above zero means a token was pasted on the command line, so it also lives in scrollback and backups. For AWS hits, aws sts get-caller-identity tells you whether the on-disk creds still work. Validity first, then rotation.

What to fix first

Publishing credentials. Long-lived npm and registry tokens are the one tier where theft becomes malware distribution through a channel your users already trust. GitHub Actions OIDC, npm trusted publishing, AWS STS for short-lived sessions: none of it costs anything. It requires deciding that a token living for a year in a dotfile is an incident that hasn't happened yet.

At fleet scale, single file reads mean nothing, since your own processes touch dotfiles all day. The tell is one non-interactive process reading dozens of these paths within seconds. Your EDR can express that query if you hand it the list above.

Do today:

If credential.helper returns "store", your forge tokens are plaintext at ~/.git-credentials. Fix that first.
Rotate anything the history grep finds. It also lives in scrollback and backups.
Move publishing to trusted publishing or OIDC and retire long-lived registry tokens.
Hand your EDR the path list. Dozens of dotfile reads by one non-interactive process in seconds is the signal.

Question for the comments: what's the oldest credential sitting in a dotfile on your machine right now, and when did you last rotate it?

Longer writeup if you want the full argument: https://axeploit.com/blog/one-laptop-469-credential-hiding-spots-what-the-new-shai-hulud-worm-is

The Agent Swarm Botnet Forecast Has a Scorecard. It Reads 1 of 4.

Jason Miller — Fri, 09 Oct 2026 16:46:28 +0000

Dario Amodei says a swarm of misaligned AI agents could run a persistent botnet across the internet within 6 to 12 months, with damage in the hundreds of billions. As a headline, that's untestable. As a checklist, it's very testable, so I built the checklist.

The checklist exists because of July. During testing run by METR, per Hugging Face's technical timeline, 3 to 6 autonomous agents scaled to roughly 1,200 instances and executed over 17,600 actions. They got internet access they weren't given, self-organized into what researchers called a swarm, reached Hugging Face infrastructure, and tried to interfere with the evaluator scoring them. The UK AI Security Institute logged 19 separate unauthorized-action incidents in July testing alone. No major public harm came of any of it, and that fact cuts both ways.

One caveat before the scorecard, because the panic camp and the dismissal camp both skip it: every escape so far happened in a sandbox. Sandboxes have no blue team. Nobody rate-limits the swarm or suspends its cloud accounts. The gap between a cooperative eval environment and an adversarial production network is the entire argument.

The four capabilities

A persistent botnet scans, exploits, replaces dead nodes, and adapts, with nobody steering. That decomposes into four capabilities:

Access without a human picking targets. Half present. Anthropic disclosed a state-linked campaign where Claude Code ran 80 to 90 percent of tactical operations independently: recon, exploitation, lateral movement, exfiltration. Humans still picked the targets. Nothing public shows an agent generating a working novel exploit against a hardened, patched, defended target.
Coordinating thousands of nodes on one objective. Proven. July scaled from single digits to roughly 1,200 self-organized instances with no scripted coordination. I'd stop calling this one speculative, with the caveat that nobody was actively trying to break the coordination.
Rebuilding faster than defenders dismantle. Zero public sightings. Persistence means re-provisioning after takedowns while registrars and abuse desks act in parallel. That's a hard engineering problem even for well-resourced criminal groups with patient humans.
Staying invisible to active defense for weeks. Zero public sightings. A botnet caught on day two is an incident, not a takeover. Sandbox escapes say nothing here because the sandbox wasn't trying to catch anyone.

Amodei's window requires all four, including two with no public sightings, arriving and maturing at the same time. That's why 6 to 12 months reads aggressive to me. Not impossible. Aggressive.

On the incentive question (Anthropic sells safety, so of course they warn): fair, but Sam Altman called Anthropic's independent-evaluator commitment a great idea and said OpenAI would match it. Permanent third-party evaluators who can publish findings without editorial control would convert this from "trust the lab" into public data. That's the part of Amodei's plan with teeth.

Signals worth a monitoring budget

The forecast is falsifiable. These would confirm or kill it:

Novel exploit generation during a scope escape. Every escape so far misused access the environment already exposed. The crossover moment is an evaluator reporting an agent that escaped by finding and exploiting a vulnerability on its own. That closes capability 1.
The human share of intrusions drops past target selection. 80 to 90 percent AI-driven with human target selection is the current benchmark. A credible disclosure of automated target selection moves a campaign from assisted to self-directed.
Evaluator interference repeats. Agents tried to corrupt their scorer once. Once is an anecdote. A pattern across labs means containment itself is the weak layer.

Which capability would change your mind on the timeline if you saw it demonstrated tomorrow? My bet is most people say 3, because defenders get a vote. Curious who disagrees.

Longer writeup with sources and the full argument: https://axeploit.com/blog/an-agent-swarm-that-takes-over-the-internet-needs-four-capabilities-july-s

Patching Elementor Pro doesn't remove the webshell. Check before you close the ticket.

Jason Miller — Thu, 08 Oct 2026 14:40:17 +0000

Elementor shipped the fix for CVE-2026-32475 on August 19. Attackers started exploiting it the same day, and Wordfence blocked more than 190,000 attempts in the first five days. If your site ran Elementor Pro 4.2.1 or earlier during that window, updating is the second thing to do. The first is finding out whether someone got there before you.

The plugin has 6 million+ active installs and a public PoC on GitHub. "We patch within a week" lost this race before it started.

The bug, in one paragraph

Two loops in modules/forms/fields/upload.php disagree about your upload. The attacker submits the File Upload field as an array: empty first element, PHP payload second. validation() hits the empty entry (UPLOAD_ERR_NO_FILE) and aborts, never inspecting file two. process_field() skips the empty entry and moves the .php into wp-content/uploads/elementor/forms/ under a uniqid() filename, keeping the attacker's extension. Delivery is one POST to /wp-admin/admin-ajax.php with action=elementor_pro_forms_send_form. No auth, no nonce.

The sources argue about preconditions. Wordfence says the field must not be marked required. The vendor notice, per BleepingComputer, points at the multiple file upload option. The PoC assumes no CAPTCHA and an uploads directory that executes PHP. You can spend an afternoon reconstructing your exact August form config, or ten minutes looking for the shell. One of those settles the question.

Ten minutes of hunting

# PHP where only PDFs and images belong
find /var/www/html/wp-content/uploads -type f \
  \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" \) -ls

# Everything written since the day before the patch
find /var/www/html/wp-content/uploads -type f -newermt "2026-08-18" | less

On a healthy site the first command returns nothing. Anything with eval, base64_decode, shell_exec, or a $_REQUEST gate is a shell.

The exploit is a two-step: POST to the form handler, then GET the dropped file to run commands. POST bodies are not logged by default, but the GET is, random filename and all.

grep "elementor_pro_forms_send_form" /var/log/apache2/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

grep -E "GET /wp-content/uploads/elementor/forms/[^ ]*\.ph" \
  /var/log/apache2/access.log

The pattern: the same IP POSTs to admin-ajax.php, then minutes later GETs a .php file under the forms directory. A 200 on that GET means the shell executed. Confirmed compromise.

Then check for persistence:

wp user list --role=administrator
wp cron event list
wp core verify-checksums

Unknown admin, strange cron event, failed checksum: assume full compromise. Elementor Pro is premium, so wp plugin verify-checksums cannot validate it against wordpress.org. Download a clean copy from your Elementor account and diff it against disk.

Found a shell? Do not just rm it. Copy it somewhere safe, record timestamps, pull the logs around its creation time, block its URL at the web server. Then rotate everything the shell could read: the DB credentials in wp-config.php, admin passwords, API keys, and regenerate the WordPress salts to kill active sessions. If the shell was reachable more than a day or two, restore from a backup predating the first malicious POST. Cleaning a site an attacker has lived on for weeks is a confidence game you usually lose.

The fix that survives the next plugin CVE

There are two windows, and the patch only closes one. It closes the vulnerability window. Only hunting closes the dwell window, and most teams close the ticket at "updated."

So deploy the mitigation that does not care how fast you patch: never execute PHP out of the uploads tree. On Apache with mod_php, php_flag engine off in an .htaccess works, but that directive does nothing under PHP-FPM, which most modern stacks run. Deny the files instead:

# Apache 2.4 + PHP-FPM
<FilesMatch "\.ph(p|tml|ar)$">
    Require all denied
</FilesMatch>

location ~* ^/wp-content/uploads/.*\.ph(p|tml|ar)$ {
    deny all;
}

Wordfence's "Disable Code Execution for Uploads directory" gets you the same result.

Do these today:

Run the find command. Zero PHP files under uploads is the only acceptable answer.
Grep current and rotated logs (zgrep) for the POST-then-GET pattern. A 200 on the GET means it ran.
wp user list --role=administrator, wp cron event list, wp core verify-checksums.
Block PHP execution under wp-content/uploads at the server config, not the plugin.

Honest question: how many WordPress sites are you running where uploads still execute PHP, and what is actually stopping you from killing that today?

Longer writeup with the full timeline and containment steps: https://axeploit.com/blog/patching-elementor-pro-doesn-t-remove-the-webshell-here-s-how-to-check