Exposed AI Infrastructure: 1 Million Services and the CVE-2026-31431 Risk
Just read the analysis on Hacker News regarding the scan of 1 million exposed AI services. It’s a stark reminder that the rush to deploy LLMs is recreating the early 2000s security nightmare, but with much higher stakes.
The research highlights that self-hosted infrastructures—specifically tools like Ray, vLLM, and Oobabooga—are frequently left exposed with default configurations. While the prompt injection risks get the headlines, the real immediate danger is basic exposure. If these services are reachable, they often serve as an easy entry point. Even worse, many of these Linux hosts are running unpatched kernels, making them trivial to escalate from a simple AI dashboard leak to full root compromise using CVE-2026-31431.
We've started scanning our own cloud ranges for these signatures. A quick Masscan on the common AI ports reveals how prevalent this is:
masscan 0.0.0.0/0 -p8000,8265,11434,5000 --rate 10000 -oL exposed_ai.txt
Detection in the SIEM is also critical. We are currently hunting for successful 200 OK responses on endpoints that should be internal:
DeviceNetworkEvents
| where RemotePort in (8000, 8265, 11434)
| where InitiatingProcessFileName !in ("python", "ollama", "python3")
| summarize count() by SourceIP, DestinationIP
How is everyone else handling the "Shadow AI" problem in their environments? Are you blocking these at the perimeter or trying to inventory them?
We treat this exactly like we treated MongoDB exposures a few years ago. Our firewall rules automatically drop traffic destined for ports 8265 (Ray) and 11434 (Ollama) from untrusted IPs.
However, the biggest issue we face is developers spinning up GPU instances in cloud subnets that inherit overly permissive security groups. We had an incident where a single Ray dashboard was exposed, and because the host was vulnerable to CVE-2026-31431, the attacker got root in minutes. Automated enforcement is the only way to stay ahead.
From a pentester's perspective, these are low-hanging fruit. During the last engagement, I found an exposed vLLM instance. The API allowed unrestricted file read access via the model loading parameters (simple path traversal), which let me dump the user's SSH keys.
You don't even need the kernel exploit if the AI interface itself is poorly coded. I'd recommend checking your logs for any POST requests to /v1/files/upload or similar endpoints originating from outside your VPN.
Inventory is a nightmare. Teams are spinning up containers with docker run -p 0.0.0.0:11434:11434 ... without thinking.
We implemented a policy using Falco to detect containers binding to 0.0.0.0 on non-standard ports and kill the pod immediately in dev environments. It's aggressive, but it stopped the bleeding. You have to assume that if it's exposed, it's already owned, especially with CVE-2026-31431 being actively exploited in the wild.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access