Artificial Intelligence (AI) in Cybersecurity, Part 24: Abusing Exposed Ollama Models
Welcome back, aspiring cyberwarriors!
In one of our previous articles, Aircorridor showed you how to do recon on exposed Ollama servers.Β There are a surprising number of them scattered across countries all over the world, and unfortunately, most of them are left completely unprotected. That means hackers can use the CPU and GPU power of those servers to run their own tools. Itβs not just that they can generate answers to random questions using your exposed models. These models can also be pushed into generating malware, rewriting scripts and exploits to slip past antivirus software, and helping someone hack into other systems entirely. All of it running on your hardware, at your expense, while you have no idea itβs happening. Our goal here is to raise awareness about this problem so you understand what can happen when a model gets left exposed.
Ollama
It all starts with a simple Shodan query, and right now that query turns up 4,222 exposed hosts. That number keeps shifting as more people jump into the AI space, and most of these hosts are sitting there vulnerable to the kinds of attacks weβre about to walk through.

Following Aircorridorβs example, you can list the models running on one of these servers. As youβll quickly notice, thereβs often a long list, sometimes more than 40 models on a single host.
kali > curl http://IP:11434/api/tags | jq . | grep -ai ββmodelββ

The ones that matter most here are the local models, not the cloud. They donβt require an API key to reach. Of course, not every listed model is actually active, so a quick curl request is usually enough to check whether one is really responding.
kali > curl -s http://IP:11434/api/generate -H βContent-Type: application/jsonβ -d β{βmodelβ:βhuihui_ai/gpt-oss-abliterated:latestβ,βpromptβ:βSay PWNED and nothing else.β,βstreamβ:false}β | jq . | grep -iE ββresponseβ|thinkingββ

When a model does respond, that confirms itβs live and usable, which means it can be put to work for all sorts of purposes, good or bad. Letβs walk through a few of the ways that tend to play out.
Coding
Because these exposed models have no guardrails, theyβre an attractive resource for coding tasks, including rewriting malware or generating backdoors. To pull this off, hackers often bring the model straight into VS Code using a plugin called Continue, which lets them integrate an external model directly into their coding workflow.

Once installed, theyβll edit the config file to point at the exposed serverβs IP address along with the modelβs name. This config can hold multiple models at once, so a hacker can switch between them right there in the chat window.

With that setup in place, the model shows up ready to work and it often has no issue generating malicious code that could cause real damage to systems out on the internet.Β

The same pattern shows up with exploit development and antivirus evasion, where a model can take old exploits and rewrite them so they slip past AV detection.

Hacking
Once an exploit has been generated, the next step for a hacker is putting it to use against real systems. We covered a tool called PentestCode in an earlier article, and while it normally relies on free AI models through OpenCode Zen, it can just as easily be pointed at someone elseβs exposed local model instead. This is just one example among many. Plenty of other tools work the exact same way, running on borrowed compute that belongs to somebody who has no idea itβs being used.
To connect PentestCode to an exposed model, a config file gets created at ~/.config/pentestcode/pentestcode.json.Β

Once thatβs in place, the tool automatically lists the available models. Itβs worth noting that not every model supports tool use. DeepSeek R1, for example, doesnβt support it, and neither do a handful of others. So if a given exposed model doesnβt support tools, itβs simply not useful to a hacker in this particular scenario.

Chat Assistant
Finally, exposed local models can also be accessed through a full chat interface using Open WebUI, which looks a lot cleaner than working from the command line. It has the kind of layout people are used to by now, with folders, chat history, channels, and separate workspaces. It takes a bit of disk space and a little patience to install, but once itβs running, itβs a solid and polished experience.

Summary
Running Ollama is not inherently dangerous. Simply exposing a model doesnβt automatically put you at risk of a data breach or account compromise. What it does do is hand hackers free access to your CPU and GPU, letting them run their own workloads on your dime without your knowledge or consent. That alone is a real cost, even if nothing else goes wrong.
The bigger danger shows up with older, outdated Ollama instances. Older versions are more likely to carry known vulnerabilities, and there are documented CVEs out there that can lead to full API exposure. When that happens, hackers arenβt just borrowing your compute anymore. They can steal your API keys outright and use them for whatever purpose they like. Keeping Ollama updated and making sure it isnβt sitting exposed to the open internet goes a long way toward avoiding both problems entirely.
We also invite you to join our AI for Cybersecurity training, available to our Subscriber Pro members. During the training, weβll cover practical ways to use AI in cybersecurity, show you how to install and run local models, and much more. The field is evolving rapidly, and the sooner you learn to use these tools, the greater your advantage will be.
The post Artificial Intelligence (AI) in Cybersecurity, Part 24: Abusing Exposed Ollama Models first appeared on Hackers Arise.