Many appear to be proxies. I'm familiar with some "serverless" architectures that do things like this https://www.shodan.io/host/34.255.41.58 ... you can see this has a bunch of ollama ports running really really old versions
You can pull down "new" manifests but very few ollamas are new enough for decent modern models like glm-4.7-flash. The free tier for the kimi-k2.5:cloud is going to be far more useful then pasting these into you OLLAMA_HOST variable.
I think the real headline is: "thousands of slow machines running mediocre small models from last year. Totally open..."
Anyways, if codellama:13b is your jam, go wild I guess.
I'm not sure the "journos" from Techradar are too familiar with how networks ... work.
IPv4 requires an inbound NAT these days to work at all globally, unless you actually have a machine with a globally routable IP. There will probably be a default deny firewall rule too. I do remember the days before NAT ...
IPv6 doesn't require NAT (but prefix translation is available and so is ULA) but again a default deny is likely in force.
You do actually have to try quite hard to expose something to the internets. I know this because I do a lot of it.
The entire article is just a load of buzz words and basically bollocks. Yes it is possible to expose a system on the internet but it is unlikely that you do it by accident. If I was Sead, I'd go easy on the AI generated cobblers and get a real job.
I was rigging this up, myself, and conciscious of the fact that basic docker is "all or none" for container port forwarding because it's for presenting network services, had to dig around with iptables so it'd be similar to binding on localhost.
Out of curiosity, why would you need to wrap the call to an Ollama modelfile in docker? Does the dockerized ollama client provide some benefit, when it’s shelling down to local Ollama instance anyway?
(Wrt tax-pal)
It's more of a distribution thing for me really. I'm basically using docker as a package manager since they otherwise distribute through one of those ad-hoc shell scripts that I'd prefer to avoid accidentally breaking Debian with somehow.
I've built ollama before too, but, I like that I can cleanly rip it out of my system or upgrade it without handing root off to some shell script somewhere I guess.
If anyone's gonna bash up my system it oughta be me
I'm using open-webui project to host a Web UI for Ollama, and Ollama itself in Docker containers. It's super-useful, because I don't have to worry about it blowing up stuff on my system with automatic installations.
When you do "tool calling" with an LLM, all you're doing is having the LLM generate output in a particular format you can parse out of the response; it's then your code's responsibility to run the tools (locally) and stick the results back into the conversation.
So that _specific_ part isn't RCE. It's still bad for the nine million other obvious reasons though.
This is a combination problem poor default (listening to all interfaces?) and also IPv6 can be publicly accessible. It's a bit dependent on how this is configured upstream by default, but this is a gotcha compared to IPv4.
The article says no, the default is listening to just localhost. Given the instances in question have been deliberately configured to listen on public ports, calling this misconfiguration seems somewhat unjustified.
In my opinion Ollama has become so far off course with their licensing and user hostile features [1] that the only sane options I've come across is using llama.cpp.
Fun fact! On macOS you can expose privileged ports (<1024) using a regular user account.
But ONLY if you don't bind the listening port to any interface. So you try to create a listening port on localhost (e.g. 127.0.0.1:443) under a non-root account you get a permission error.
Edit: the thing is, you CAN expose "0.0.0.0:443" without root privileges!
I see this happen all the time when people just want their new toys to work right away. They copy and paste commands from the internet to open up the connection but they forget to put a lock on the door. It is dangerous that so many people run these programs without understanding the basics of how networks work.
We have those who are openly admitting that they have never written / read a line of code and have no idea on what it does and using AI to deploy "AI tools" without knowing how to secure them.
Infosec experts are going to have a great time with collecting lots of money out of this.
I tried a few these ... they are pretty slow. If you are looking for free inference you'd have to be pretty desperate.
example:
$ OLLAMA_HOST=http://47.101.61.248:9000/ ollama run gemma3:27b "outline ww2"
Many appear to be proxies. I'm familiar with some "serverless" architectures that do things like this https://www.shodan.io/host/34.255.41.58 ... you can see this has a bunch of ollama ports running really really old versions
You can pull down "new" manifests but very few ollamas are new enough for decent modern models like glm-4.7-flash. The free tier for the kimi-k2.5:cloud is going to be far more useful then pasting these into you OLLAMA_HOST variable.
I think the real headline is: "thousands of slow machines running mediocre small models from last year. Totally open..."
Anyways, if codellama:13b is your jam, go wild I guess.
If someone is that desperate looking for free inference, or just for fun openrouter has many free models
I'm not sure the "journos" from Techradar are too familiar with how networks ... work.
IPv4 requires an inbound NAT these days to work at all globally, unless you actually have a machine with a globally routable IP. There will probably be a default deny firewall rule too. I do remember the days before NAT ...
IPv6 doesn't require NAT (but prefix translation is available and so is ULA) but again a default deny is likely in force.
You do actually have to try quite hard to expose something to the internets. I know this because I do a lot of it.
The entire article is just a load of buzz words and basically bollocks. Yes it is possible to expose a system on the internet but it is unlikely that you do it by accident. If I was Sead, I'd go easy on the AI generated cobblers and get a real job.
Fortunately there’s an easy way to check…
This is a weakness of docker, a bit, I think.
I was rigging this up, myself, and conciscious of the fact that basic docker is "all or none" for container port forwarding because it's for presenting network services, had to dig around with iptables so it'd be similar to binding on localhost.
The use case https://github.com/meltyness/tax-pal
The ollama container is fairly easy to deploy, and supports GPU inference through container toolkit. I'd imagine many of these are docker containers.
e: i stand corrected, apparently -p of `docker run` can have a binding interface stipulated
e2: https://docs.docker.com/engine/containers/run/#exposed-ports which is not in some docs
e3: but it's in the man page ofc
Yes the binding interface can be specified, but the default for -p 11434:11434 is 0.0.0.0.
IMO the default should be 127.0.0.1 and the user should have to explicitly bind to all via -p 0.0.0.0:11434:11434.
Apparently been that way for a while haha
https://github.com/moby/moby/commit/1cbdaebaa1c2326e57945333...
Docker has a lot of lazy hacks to make it work well on MacOS that had to have it running in a VM for any of the linux containers to work.
Out of curiosity, why would you need to wrap the call to an Ollama modelfile in docker? Does the dockerized ollama client provide some benefit, when it’s shelling down to local Ollama instance anyway? (Wrt tax-pal)
It's more of a distribution thing for me really. I'm basically using docker as a package manager since they otherwise distribute through one of those ad-hoc shell scripts that I'd prefer to avoid accidentally breaking Debian with somehow.
I've built ollama before too, but, I like that I can cleanly rip it out of my system or upgrade it without handing root off to some shell script somewhere I guess.
If anyone's gonna bash up my system it oughta be me
I'm using open-webui project to host a Web UI for Ollama, and Ollama itself in Docker containers. It's super-useful, because I don't have to worry about it blowing up stuff on my system with automatic installations.
- you ll be surprised how many OLLAMA API KEYS [you can find here](https://github.com/search?q=%22OLLAMA_API_KEY%22&type=code&p...) its 2026 and this technique still works. I wonder if github supports regex search
> I wonder if github supports regex search
/it does like this/
I just looked through 2 pages and didn't see any keys, just empty config vars and placeholder values. How many real keys are you actually finding?
well i did not use regex earlier but found some AWS keys https://github.com/search?q=%2F%22AWS_(%5Cw%2B)%22%3D%22(%5C...
these are the same guys that later complain about a 100k$ bill on AWS
also this conversation never happened
GitHub sends those keys to Amazon which automatically quarantines them
The tool-calling thing here is overblown.
When you do "tool calling" with an LLM, all you're doing is having the LLM generate output in a particular format you can parse out of the response; it's then your code's responsibility to run the tools (locally) and stick the results back into the conversation.
So that _specific_ part isn't RCE. It's still bad for the nine million other obvious reasons though.
This is a combination problem poor default (listening to all interfaces?) and also IPv6 can be publicly accessible. It's a bit dependent on how this is configured upstream by default, but this is a gotcha compared to IPv4.
The article says no, the default is listening to just localhost. Given the instances in question have been deliberately configured to listen on public ports, calling this misconfiguration seems somewhat unjustified.
Not true for their docker instructions which specify -p 11434:11434 instead of -p 127.0.0.1:11434:11434. [1]
Combine that with rootful docker's famous bypass of ufw and you have a publicly exposed ollama, even with a firewall. [2]
[1] https://docs.ollama.com/docker
[2] https://github.com/moby/moby/issues/4737
Ouch. Thanks.
https://www.shodan.io/
I ironically found out about this website from Mr Robot tv show.
In my opinion Ollama has become so far off course with their licensing and user hostile features [1] that the only sane options I've come across is using llama.cpp.
[1] https://www.glukhov.org/post/2025/09/ollama-enshittification...
To not even be able to disable data being exfiltrated with their automatic updates is terrible behavior.
Nevermind. [0] Nothing to see here.
[0] https://news.ycombinator.com/item?id=45116322
Pay for Shodan, folks!
Fun fact! On macOS you can expose privileged ports (<1024) using a regular user account.
But ONLY if you don't bind the listening port to any interface. So you try to create a listening port on localhost (e.g. 127.0.0.1:443) under a non-root account you get a permission error.
Edit: the thing is, you CAN expose "0.0.0.0:443" without root privileges!
it's called a privileged port and it's been like this for decades, on every system, ever.
Here's a reference to this "macos feature" from 1995: https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....
https://news.ycombinator.com/item?id=18302380
A feature! Not a bug! Bugs can be undisovered features.
How exactly are the ports "exposed" if they can't be bound to an interface?
Binding to 0.0.0.0 means binding to every interface.
I see this happen all the time when people just want their new toys to work right away. They copy and paste commands from the internet to open up the connection but they forget to put a lock on the door. It is dangerous that so many people run these programs without understanding the basics of how networks work.
Even better.
We have those who are openly admitting that they have never written / read a line of code and have no idea on what it does and using AI to deploy "AI tools" without knowing how to secure them.
Infosec experts are going to have a great time with collecting lots of money out of this.