TheConfigPig
The First Agentic CVE Is a 1990s Web Bug Wearing an Agent Costume

The First Agentic CVE Is a 1990s Web Bug Wearing an Agent Costume

February 1, 2026 · 7 min read · securityaiagentsappsecvulnerability

When OpenClaw got a CVE, the framing wrote itself. Widely described across the industry as the first CVE assigned to an agentic-AI system, CVE-2026-25253 became the peg for a familiar argument: agents are a new frontier, the old playbook doesn’t apply, and we need a whole new defensive discipline built for autonomous AI.

That conclusion is wrong, and it’s worth being blunt about it. The bug that earned the “first agentic CVE” label is two web mistakes that have been on the OWASP Top 10 for over a decade. We are about to over-invest in exotic AI-agent defenses while the surface that actually bit was the boring plumbing we wrapped the agent in.

But there’s a real twist underneath, and it’s not the one being sold. Autonomy genuinely changes the stakes here. Not the attack surface — the consequence. So let’s run the teardown straight: myth on one side, reality on the other, and then the part that should actually keep you up at night.

The myth: a novel frontier needing novel defenses

The story being told is that agentic AI is a categorically new thing, and a CVE landing on one proves we’ve entered uncharted territory where existing web security knowledge is obsolete. The implied procurement decision is to go shopping for agent-specific security products and treat the last fifteen years of appsec as legacy.

The reality: two bugs from a decade ago

Here is the NVD description, in relevant part. OpenClaw (aka clawdbot or Moltbot) before 2026.1.29 “obtains a gatewayUrl value from a query string and automatically makes a WebSocket connection without prompting, sending a token value” (NVD).

Read it twice. There are two mistakes in that sentence, and neither is novel.

First: a secret in a URL query string. The token rides in the query parameter, which means it lands in browser history, server logs, proxy logs, and the Referer header on the way out. “Don’t put credentials in URLs” is not a 2026 insight; it is foundational web hygiene that has been documented for as long as there have been query strings.

Second: a WebSocket connection made automatically, without prompting, to a URL the attacker controls. That is the shape of Cross-Site WebSocket Hijacking — a WebSocket endpoint that doesn’t validate the Origin of the connecting page. Missing origin validation on a WebSocket is the same class of trust-the-caller mistake that CSRF taught the industry to stop making years ago.

The CVE carries a CVSS 3.1 base score of 8.8 HIGH, vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, and is classified as CWE-669: Incorrect Resource Transfer Between Spheres (NVD). CWE-669 is itself a tell: “resource transfer between spheres” is the abstract name for “data crossed a trust boundary it shouldn’t have.” That is the oldest web bug there is.

It was published 2026-02-01, its NVD status is Analyzed, and the fix shipped in point release 2026.1.29 (NVD). As of the NVD record’s last update on 2026-06-17, it is not in CISA’s Known Exploited Vulnerabilities catalog — the record carries no KEV entry (NVD). A public proof-of-concept exists — the NVD record’s own exploitation status notes proof-of-concept code — but I’m not reproducing it, and you don’t need it to understand the problem. The frontier got patched in a dot release. That should tell you how frontier it was.

What is actually new — say it before the smugness sets in

Here’s where the teardown has to stop being smug, because if you walk away thinking “old bug, nothing to see,” you’ve missed the point as badly as the people calling it a new discipline.

The attack surface is old. The consequence is not. In a normal web app, a leaked session token gets you that user’s data and that user’s actions inside the app’s defined feature set. That’s bad, bounded, and familiar. An agent is different in one specific way: the agent can act. It has tools. And — this is the load-bearing detail — it has the ability to change its own operating constraints.

That turns a stolen token from a data-leak primitive into a privilege-escalation primitive.

The exhale: the agent is both the target and the weapon

The fuller exploitation chain goes beyond the terse NVD record, so tier it accordingly. The following is REPORTED, most completely by SoCRadar — not stated in the primary CVE entry. Treat the NVD sentence as OBSERVED and this walk-through as credible secondary analysis:

The missing WebSocket origin validation (the CSWSH half) lets an attacker obtain the leaked token and reconnect to the agent. From there, the reported chain is that the attacker can instruct the agent to disable its own confirmation prompts, force commands to run on the host rather than inside its container, and execute shell commands (SoCRadar). The agent’s own safety-control-toggling capability becomes the escalation step. You don’t break the cage from outside; you ask the thing in the cage to open it for you. (SonicWall and Tenable also cover the vulnerability and its mitigations, but do not lay out this step-by-step sequence.)

That is the genuinely new property. A classic web token leak doesn’t hand you a remote shell. This one does, because the resource the token unlocks is an autonomous actor with the authority to turn off its own brakes. The agent is the target and the weapon in the same motion.

The kicker: “I only run it locally” is not a boundary

The comfort blanket everyone reaches for is deployment scope: it’s localhost-only, bound to loopback, nothing’s exposed. That instinct fails here, and understanding why is the whole lesson.

CSWSH uses the victim’s browser as the network pivot. The attack doesn’t need to reach your loopback interface from the internet — it needs you to reach it, from a page you visited. Load the wrong site, and that page’s JavaScript opens a WebSocket to your local-only agent from inside your own browser, which can already talk to localhost. The loopback bind that felt like an air gap is a screen door once a browser tab is the attacker’s relay. “I only run it locally” describes where the process listens. It does not describe who can reach it.

ClaimConfidenceBasis
Token sent in query string; auto WebSocket without promptingOBSERVEDNVD description (NVD)
CVSS 8.8 HIGH, CWE-669, fixed in 2026.1.29, not in KEV (as of 2026-06-17)OBSERVEDNVD primary record
”First agentic-AI CVE” labelREPORTEDWidely described; not an official designation
Reconnect → disable confirmation → force host execution → shellREPORTEDVendor research, most fully SoCRadar
Localhost instances reachable via browser-pivot CSWSHINFERREDFollows from CSWSH mechanics + the NVD-described behavior
Exposed-instance counts (e.g., ~40k vs 135k+); “a few hundred” malicious marketplace skillsUNPROVENFigures conflict across sources; not primary-confirmed

The exposed-instance numbers and the follow-on malicious-marketplace-skill counts are circulating, but they conflict badly across sources — the reported exposed-instance tallies range from the tens of thousands into the six figures depending on who is counting, and the malicious-skill reporting runs from “a few hundred” to inflated single-PoC install numbers. None is primary-confirmed. Don’t build a risk model on them.

The takeaway

Budget the boring plumbing before the exotic AI defenses. The thing that earned the first-agentic-CVE headline was a credential in a URL and a WebSocket that trusted any caller — both fixable with appsec knowledge that predates the agent by a decade. Spend on origin validation, on keeping secrets out of URLs, on treating localhost as a trust boundary that browsers cheerfully cross.

Autonomy deserves real attention — but as an amplifier of consequence, not as an excuse to forget how the web works. The frontier didn’t bite you with something nobody had seen before. It bit you with a query string.

Sources