demo · v141

Router CSRF Attempt

The motivating attack: a public website fires off CSRF requests at common router admin endpoints (192.168.0.1, 192.168.1.1, 10.0.0.1) hoping the user is signed in. Chrome 141 gates every such request behind a Local Network Access prompt — even for plain img probes. This demo fires the same requests and shows you the new failure mode.

Heads up Requires Chrome 141+. Older browsers happily fired these requests. Now you'll see either a permission prompt or a CORS / network error in DevTools. The site never sees the response either way — this is by design.
checking support…

Click any target — the page attempts the request and reports what happened. Nothing is actually exploited; if there were a router at that address, Chrome would prompt before letting the request through.

192.168.1.1 — common admin gateway

Default address for many ISP-issued routers (Linksys, BT, Sky). A CSRF payload would POST a DNS-rebinding config.

not run

192.168.0.1 — TP-Link / D-Link default

Equally common. Routers historically shipped without CSRF tokens on admin endpoints.

not run

10.0.0.1 — corporate / Apple AirPort

Another common gateway. Same drill.

not run

127.0.0.1:5984 — local CouchDB

Loopback access from a public site. Old attack vector: probe whether the user has CouchDB / dev tools listening.

not run

the (now-failing) attack

// Pre-141, this fired silently from any page on the web.
// In 141, Chrome surfaces a prompt for the first such request from this origin.
// Without permission, the request fails with TypeError before reaching the router.
await fetch("http://192.168.1.1/setting/setLanguage?lang=evil", {
  method: "POST",
  mode: "no-cors",          // attacker doesn't need to read response
  credentials: "include",   // ride existing router auth cookie
  body: "…",
});

why this angle

The WICG explainer leads with the router-CSRF scenario because it's been one of the most pervasive real-world attacks against home networks for over a decade — papers from 2008 onwards. The "confused deputy" framing is exactly right: the user's browser, sitting inside the network with router admin cookies, is the only available attacker vector. Permission-gating these requests is a hard cut: an attacker can't even probe for whether you have a vulnerable router without you seeing a prompt first.

see also