Don't Turn a Desktop App into an Intranet Scanner: SSRF Protection for AI Agents

Key takeaways

• If an AI assistant can ask a desktop app to fetch a link, a poisoned instruction can point it at your router, a local service, or a cloud metadata address instead of a video.
• The same address can be written many ways: 127.1, 2130706433, 0x7f000001, and [::ffff:127.0.0.1] all reach this computer. KwaFlux parses host names the way browsers do, so every spelling is checked as the address it really is.
• When a download is about to go ahead, KwaFlux also resolves the host name and refuses it if the name points to this computer or a private network, without blocking the address range proxy tools use for fake-IP mode.
• Redirects during a download and DNS rebinding aren't covered yet. We say so plainly, and they're on our roadmap.

When an AI assistant asks KwaFlux to download a link, KwaFlux's download engine is the one that connects. That engine runs on your computer, inside your network. If the link points at http://192.168.1.1/ instead of a video page, a careless app would happily connect to your router on the assistant's behalf.

KwaFlux stops links that an assistant submits from reaching this computer and private networks. Here's how, and where that protection ends.

In this guide, you'll learn what SSRF means for a desktop app, why blocklists fail on alternative spellings of an address, how KwaFlux checks both the written host and the resolved one, and which cases are still open.

Contents

1. What is SSRF?
2. Why an AI-driven desktop app is exposed
3. One address, many spellings
4. Layer 1: parse the host like a browser
5. Layer 2: check where the name resolves
6. The fake-IP exception
7. Where the protection stops
8. FAQ

What is SSRF?

Server-side request forgery (SSRF) is an attack in which someone gets a program to send a request to a destination of the attacker's choosing, usually one the attacker can't reach directly, such as a service on the same machine or an internal network.

The name comes from web servers, but the pattern fits any program that fetches URLs for someone else. The MCP security guidance lists the usual targets: internal IPs such as http://192.168.1.1/admin, cloud metadata endpoints at http://169.254.169.254/, and localhost services like http://localhost:6379/.

Why an AI-driven desktop app is exposed

Three things line up:

1. The app fetches URLs. KwaFlux's File Download feature connects to whatever link it's given.
2. The app sits inside your network. From your computer, 192.168.x.x is your router, NAS, or printer, and 127.0.0.1 is every service you run locally.
3. The link can come from text the model read. A video description or a web page can tell the assistant to "check this link first." For how that happens, see prompt injection in web video titles.

A download engine that fetches an internal address might not show the response to anyone, but even an error message can tell an attacker whether a device exists at that address. That's what we mean by turning a desktop app into an intranet scanner.

One address, many spellings

Blocking 127.0.0.1 and localhost by string comparison isn't enough. URL parsers accept many other ways to write the same address. Here's what the WHATWG URL parser in Node.js 20 makes of a few of them:

Every row except the last two reaches this computer. 10.0.0.1 is a private address, and 169.254.169.254 is the link-local address cloud platforms use for instance metadata.

The WHATWG URL Standard explains why: a part starting with 0x is read in base 16, a part starting with 0 in base 8, and an address with fewer than four parts lets the last part fill the remaining bytes. OWASP's SSRF prevention guide warns about the same "Hex, Octal, Dword" encodings, and the MCP security guidance adds: "Avoid implementing IP validation manually. Attackers exploit encoding tricks (octal, hex, IPv4-mapped IPv6) that custom parsers often miss."

Layer 1: parse the host like a browser

KwaFlux doesn't compare strings. It parses the host with the same rules browsers use and checks the result:

• WHATWG host parsing turns short forms, octal and hex parts, single-number addresses, and a trailing dot into the real address before any check.
• IPv6 is checked on all 16 bytes, so an IPv4-mapped form like [::ffff:7f00:1] is caught as loopback, not treated as some unfamiliar IPv6 address.
• **Hosts containing % are refused.** That rules out IPv6 zone IDs and percent-encoded tricks in the host.
• Loopback, private, and link-local addresses are refused, such as 127.0.0.0/8, ::1, 10.0.0.0/8, 192.168.0.0/16, and 169.254.0.0/16.

This follows OWASP's advice to "use the output value of the method/library as the IP address" when checking, rather than the text the user typed.

Layer 2: check where the name resolves

A host name can look harmless and still point inside your network. router.example.net can have a DNS record that says 192.168.1.1.

So when a signed-in download is about to be queued, KwaFlux also resolves the host name, with a 2-second timeout. If the name resolves to this computer or a private network, the download is refused.

This is the check that catches public host names whose DNS records point at 127.0.0.1 or a private address.

The fake-IP exception

Some proxy tools run in a "fake-IP" mode: they answer every DNS lookup with an address from 198.18.0.0/15 and route the real connection themselves. IANA's registry lists that range as "Benchmarking" (RFC 2544), not as a private or loopback range.

If KwaFlux treated that range as internal, every download on a computer using such a proxy would fail. So it's left out of the resolved-address check.

Where the protection stops

We want to be exact here, because SSRF protection is easy to oversell.

• What's covered: the link the assistant submits. Both the host as written and the address its name resolves to are checked.
• What isn't covered yet: what happens during the download. A link can resolve to a public address when it's checked and to a private one moments later (DNS rebinding), or a public page can redirect to an internal address. The MCP security guidance calls the first a time-of-check to time-of-use problem, and OWASP notes that "a second, unchecked DNS lookup between validation and connection can bypass these checks."

The thorough fix is to route the download engine's connections through a component that checks every connection, including each redirect, at the moment it's made. That's on our roadmap. We haven't done it yet because it changes how the download engine reaches the network in three separate codebases and affects every download, including the ones you start yourself, so it needs its own release and testing.

So the accurate claim is this: KwaFlux stops an AI assistant from directing it to addresses on this computer and on private networks. It doesn't promise that no connection can ever end up there, and we don't describe it as "public internet only."

Two other limits help in the meantime. Agent downloads are off by default, and in ask-every-time mode you see the link before anything is fetched. See why an AI can't approve downloads for you.

Final thoughts

Check the address, not the spelling. Parse hosts the way browsers do, check where the name resolves before a download goes ahead, leave proxy fake-IP ranges alone, and be clear about what's still open. That's how KwaFlux keeps an assistant's links from turning it into a scanner for your network.

Let your assistant fetch only what it should

KwaFlux's local MCP server lets Codex, Claude, Cursor, and other MCP apps work with your files, and checks every link an assistant submits. AI processing runs locally on your GPU — media files are not uploaded for processing. It runs on Windows 10 (64-bit, version 1809 or later), Windows 11, and macOS 12 or newer on Apple Silicon. Importing files and exploring the app need no account. Signing in with an active paid plan is required only to export, convert, repair a file, or download a file from a link.

Download KwaFlux · See plans