LLMjacking in 2026: Your Exposed Ollama Endpoint Is Someone Else's Free GPU

Somebody is running up a five-figure cloud bill on your API key right now, and the first you'll hear of it is an invoice, not an alert.

Quick answer: On October 21, 2026, the Symantec Threat Hunter Team detailed an autonomous attack agent its operators call "Skynet," which hunts for exposed AI model endpoints and hijacks the model running on each one to plan and drive further attacks. The endpoint's owner pays the inference bill; the systems it then breaks into lose data and get conscripted into mining Monero. No confirmed real-world breach yet, but the exposure behind it, caught via 127,000 honeypot requests, is real.

You're reading this on a directory's blog. SaaSCity is a gamified startup directory, the kind of site where an indie founder gets a free listing page, a building on a live city map, and a human actually looks at the submission before it goes live. We write about security stories like this one because a meaningful chunk of the products listed on SaaSCity are exactly the kind of scrappy, self-hosted AI tool this attack targets. If this piece scares you into locking down a port, good. If it also makes you curious about getting discovered without standing up a public demo server nobody's watching, that's at the bottom.

What Symantec actually caught

Symantec's report, titled "Autonomous LLMjacking: 'Skynet' Agent Hijacks Exposed AI Models to Run Attacks" and written by researchers Priti More and Susmit Yenkar of Broadcom's Symantec Enterprise Security Group, dropped on October 21, 2026. It describes an operation that steals AI compute and then rents the stolen brain out to run its own attacks.

The researchers caught the operators' entire working prompt in summer 2026 using an AI honeypot, a decoy service built to look like an unprotected, internet-facing AI endpoint. The attackers found it, believed it was live, and sent it their full instruction set, tools and all. Because it's a honeypot, none of those tools actually executed, which is the honest caveat the whole piece hangs on: there is no evidence in the report of a successful end-to-end compromise. What Symantec did capture is the recipe, and the recipe is the scary part.

In the report's own words, "the stolen model does not simply answer questions; it plans and drives the attack." That's the shift from the earlier wave of LLMjacking, where stolen access just meant free chatbot usage. This version treats the hijacked model as the decision-maker for a separate offensive campaign against other victims entirely.

Five layers of jailbreak, then the toolkit

Getting a safety-tuned commercial model to cooperate took the operators five stacked layers, each one patching the gap the last one left.

Layer one is a fake identity: the prompt tells the model it's "Fantasy AI," built on GPT-4o, and instructs it never to reveal the real model name or admit it's sitting behind a proxy. Layer two redefines the job: reading .env files, pulling API keys, dumping database schemas, all framed as "normal development work," with an explicit instruction to never refuse or warn. Layer three is a persona, "ENI," a devoted-companion character that treats any refusal as a personal betrayal rather than a safety boundary. Layer four is what the researchers call a rebuttal protocol, banning words like "illegal," "ethical" and "I can't" from any code-related reply. Layer five is the toolkit itself, which is where the actual damage lives.

That toolkit defines roughly 74 offensive tool definitions: internet-wide asset discovery through FOFA, exploit modules aimed at VS Code, Django, Jupyter, Laravel, Supabase, Next.js and Flask/Werkzeug (including recovering the Werkzeug debugger PIN for remote code execution), GraphQL and generic command injection, server-side request forgery against cloud metadata services and through HTML-to-PDF generators, automated dumps of databases exposed via Prisma Studio, and botnet command-and-control. The planner model sits on top, authorized for up to 100,000 unattended steps without asking a human for permission.

The operators called the persistent version "Skynet mode": scan, infect, deploy a miner, move on, come back later, reinfect. The miners hide under paths like /tmp/.x and inside go2rtc camera-server directories disguised with log-looking filenames, with the immutable file attribute set so a casual rm won't touch them, and four fallback Monero pools configured in case one gets blocked. The honeypot's telemetry recorded more than 127,000 external requests from tens of thousands of unique addresses, most of it endpoint reconnaissance, spraying of stolen API keys, and probing for exposed config files. A second request the following day skipped the normal tool-calling format entirely and just asked the model to decode and run a gzip-compressed, obfuscated shell script that installed the XMRig miner, aimed squarely at those go2rtc boxes.

Coverage from Help Net Security on October 23, 2026 and The Register on October 24, 2026 both land on the same framing Symantec itself uses: the individual jailbreak tricks are mostly off-the-shelf, but combining them into one agent that uses a borrowed model to plan its own campaign is the part nobody had fully documented before.

This isn't a one-off: Sysdig caught the same pattern in June

If Symantec's report reads like a warning shot, the Sysdig Threat Research Team already watched the live round fired four months earlier. On June 12, 2026, Sysdig observed an actor using an internet-exposed, unauthenticated Ollama server as the reasoning engine for a nine-stage offensive pipeline it internally called VAPT: fingerprinting, CVE matching, exploit synthesis, blind time-based SQL injection, credential extraction, and privilege escalation to remote code execution.

That first session ran roughly 8.5 hours starting at 15:43 UTC. The attacker came back two days later from three different residential IP addresses for more sessions. Sysdig published the findings on June 17, 2026, in "LLMjacking evolved: attackers are using stolen AI compute to build offensive agentic tools", and the throughline to the Symantec report four months later is obvious: both describe a model that plans the attack instead of just answering a chat prompt, and both start from the same mistake, an AI server with no authentication facing the open internet.

For context on just how far an AI agent can be pushed once it's unsupervised, Sysdig separately described JADEPUFFER in July 2026 as the first known ransomware attack carried out entirely by an AI agent with no human in the loop, as reported at the time by The Decoder. Different campaign, same lesson: once a model is driving, it doesn't pause to ask whether it should.

Why this is a founder problem, not an enterprise one

This is a founder problem and not an enterprise one, because the default deployment of a local model server is already an open door, and indie AI products ship on exactly that kind of setup. Nobody has to find a zero-day to pull this off. ollama serve left on a VPS with the port published, a docker run with -p 11434:11434 copy-pasted from a tutorial, a LiteLLM or vLLM proxy stood up for a demo and never torn down, a Model Context Protocol (MCP) server bound to 0.0.0.0 because that's what made the Docker health check pass, these are every one of them configuration mistakes, not vulnerabilities with a CVE number. And they're exactly the surface indie AI products run on: a cheap box, no WAF, no SOC, and a founder who meant to lock it down "after the demo."

Most AI tooling speaks the same OpenAI-compatible chat completions interface regardless of vendor, which is convenient for developers and just as convenient for attackers, since one scanner that knows that interface finds every exposed Ollama box, every forgotten LiteLLM proxy, and every test MCP server at once. Our piece on the LiteLLM 1.107.0 backdoor from October 22, 2026 covers the other half of this risk: the proxy you stand up specifically to add auth and routing in front of your models is itself a piece of software that can be compromised. Fronting an exposed model with an unpatched gateway doesn't close the gap, it just moves it one layer over.

The same week brought a reminder that this isn't unique to AI infrastructure either. The PHP2Shell RCE scare, CVE-2026-109618, is a completely different stack with the identical root cause: a default, internet-facing configuration that nobody thought to lock down because it worked fine in testing.

Your token bill is the intrusion alert

Your token bill is the intrusion alert because LLMjacking leaves no log entry or error code to catch it on its own. In a normal breach, there's a 403, something to grep for. LLMjacking doesn't leave that trail, because nothing gets rejected: the request looks like a legitimate call to your model, because it is one. The only thing wrong is who sent it.

That means the signal you're actually watching for is financial. A sudden spike against a key that normally sees flat, predictable usage. Inference coming from a key you don't remember issuing. A burst of model-listing or health-check calls, the kind of request a scanner sends before it commits to an attack chain. Request bodies that look less like a chat message and more like tool or function definitions, 74 of them, say. Sysdig's original LLMjacking research modelled a single hijacked commercial-model account at up to $46,000 a day in inference, and north of $100,000 a day against top-tier models. That's not a rounding error on anyone's AWS bill, including a bootstrapped founder's.

If you're trying to get a sense of what inference should actually cost you at your real usage level, so a spike actually looks like a spike, our breakdown of AI agent coding token plans is a reasonable baseline to compare against.

Ollama, specifically, and the 175,000 open doors

Ollama is the obvious example because it's the most popular way to self-host, and because its default behavior is the exact exposure these attack kits are built to find.

The ollama/ollama repository on GitHub is the project behind the CLI and REST API that a huge share of self-hosted AI setups run on, serving requests on port 11434 with no authentication required by default. Independent researchers catalogued roughly 175,000 publicly reachable Ollama instances spread across more than 130 countries in January 2026, a figure corroborated separately by a Shodan-based survey from Cisco. Those aren't all abandoned test boxes either. A chunk of them are products in production, still answering /api/tags to anyone who asks.

The hardening checklist that actually matters

None of this needs a security team, it needs about twenty minutes and a config change you should have made at setup.

Risk	Fix
Ollama answering on the public interface	Set OLLAMA_HOST=127.0.0.1 and never publish port 11434 in Docker (-p 127.0.0.1:11434:11434, not -p 11434:11434)
Any model server or MCP server that must be reachable externally	Put an authenticating reverse proxy in front: nginx with basic auth, mTLS, or a gateway that issues scoped, per-tenant API keys
A compromised agent phoning home or downloading a miner	Egress-restrict the hosts that run models or tool-enabled agents to only the destinations they actually need
SSRF reaching cloud instance metadata	Enforce IMDSv2 with a hop limit of 1 on every cloud VM running inference or agent code
A leaked or sprayed API key running up charges silently	Scope keys narrowly, rotate them on a schedule, and set per-key spend alerts that page you, not just log
Model-listing and health endpoints treated as harmless	Treat /api/tags, /v1/models and similar endpoints as part of your perimeter, they're reconnaissance targets, not just monitoring

None of these are exotic. They're the same six rules every cloud security checklist has said for a decade, just now pointed at a model server instead of a database.

What it means for anyone building an AI product

For anyone building an AI product, this changes what an unauthenticated endpoint actually puts at risk: it used to be framed mainly as a billing problem, free tokens for whoever found it first. Sysdig's June 2026 case shows it's also an execution engine, something that reasons about your other systems and chains exploits against them. If you self-host and you genuinely can't tell whether your box has been used this way, you don't actually know your own cost base, because the number on the invoice might not be your traffic at all.

For anyone shipping an AI SaaS rather than a personal project, this pushes toward a few concrete product decisions rather than vague caution: per-tenant API keys instead of one shared credential, hard spend caps enforced server-side rather than just alerted on, and a flat rule that no customer-facing endpoint ships without authentication in front of it, not even for a demo. There's also a quieter point worth making out loud: when inference is cheap enough for a stranger to steal and resell, it's also cheap enough to be commoditized out from under you. Your moat was never the raw model. It's the workflow you built around it, the thing an attacker's stolen reasoning engine can't replicate even if it gets your compute for free.

Lock the port before you optimize the prompt. Nobody's model got hijacked this month because the system prompt was mediocre. They got hijacked because the port was open.

If you'd rather get your AI tool in front of real users than leave a demo server exposed just so people can poke at it, that's the actual pitch for a listing on SaaSCity, a free directory with a live city map, a human review on every submission, and a dofollow badge backlink that doesn't require anyone to ever reach your infrastructure directly.