The AI tools on your servers are a new attack surface

October 14, 2026

Agent frameworks, model gateways and inference servers are some of the fastest-growing sources of vulnerabilities. Why they're risky, and how to run them safely.

A new kind of software on the server

In a short time, a whole new category of software has landed on Linux servers: tools for running language models, gateways that route requests between models, frameworks for building AI agents, and servers that give those agents access to files, databases and other tools. They're often installed in an afternoon to try something out - and then left running.

This software is young, changes quickly, and is being looked at closely by security researchers. The result is a fast-growing number of vulnerabilities.

What the numbers show

Trend Micro's State of AI Security Report counted 2,130 vulnerabilities affecting AI systems in 2025, up 34.6% from 2024 and 4.42% of all CVEs that year - the highest share yet. The growth has continued: Google Threat Intelligence Group tracked more than 1,500 AI-related vulnerabilities between January and August 2026 alone.

Google's breakdown shows where they are:

• Agent and orchestration frameworks - tools like LangChain, Langflow, Flowise and Dify, and MCP servers - account for about half of all AI-related vulnerabilities, with disclosures up 347% in 2026.
• Inference and serving software - tools like Ollama, vLLM and LiteLLM that run or route requests to models - had 212 vulnerabilities in 2026. Nearly a quarter came from API endpoints that require no authentication, or let an attacker make the server send requests on their behalf.

Some are already being exploited

Google notes that only a handful of AI-related vulnerabilities have been confirmed as exploited so far, and none as zero-days. But the ones that have been are serious. Two examples from its report:

• Langflow, a visual tool for building AI workflows, had a flaw that let anyone run their own Python code on the server without logging in.
• LiteLLM, a gateway in front of many model providers, had a command injection flaw that allowed attackers to take over the host and steal the API credentials stored on it.

Both are the kind of tool that often runs on an ordinary Linux server, next to everything else.

Why AI tools are a risky combination

• Built for a laptop, deployed on a server. Many tools start out as something to run locally, where open ports and missing passwords don't matter. Moved to a server, the same defaults are exposed. Trend Micro found 285 exposed AI agents using the agent-to-agent (A2A) protocol, and not one of them required authentication.
• They hold the keys. An AI gateway or agent typically stores API keys for model providers, and often credentials for the databases and services it's allowed to use. Taking over the tool means getting those too.
• They're designed to act. Agent frameworks exist to run code, read files and call other systems. A flaw in something built to execute actions tends to be a flaw that executes the attacker's actions.
• They're installed outside the distribution. These tools almost always come from pip, npm, a container image or an install script - not from the distribution's repositories. No security team backports fixes or tracks vulnerabilities for them, and they don't update with the rest of the system. See Who keeps your packages secure?

What to do

• Know where they run. Keep track of which machines have AI tools installed, including the ones someone set up to try something.
• Don't expose them directly. Bind them to localhost or a private network, and put authentication in front of anything that has to be reachable. The listening-ports.sh plugin shows which ports each machine has open to the network.
• Update them like an exposed service. These projects release often, and security fixes arrive as new versions. Check them regularly instead of waiting for something to break.
• Limit what they can reach. Run them as their own user, give agents access to only what they need, and use API keys you can revoke.
• Remove what you don't use. A forgotten experiment is the easiest target of all.

OS Checker tracks a machine's system packages against its distribution's security data. Tools installed outside the distribution can be brought into the same overview with plugins: pip-audit.sh and npm-audit.sh flag known vulnerabilities in Python and Node.js projects, and python-uv-updates.sh lists outdated packages in a Python project managed by uv.