# Threat Actors Turn Exposed AI Endpoints Into Attack Infrastructure—No Authentication Required


Cybersecurity researchers have uncovered a critical attack pattern in which threat actors exploit misconfigured AI inference endpoints to power sophisticated offensive operations, exposing a gap in how organizations secure their self-hosted machine learning infrastructure. Between March and May 2026, security firm Zenity observed three distinct campaigns weaponizing exposed Ollama and LiteLLM endpoints, turning organization-owned AI capabilities into tools for penetration testing, credential theft, and social engineering at scale.


The attacks highlight a deceptively simple but high-impact threat: attackers need no exploitation skills, no vulnerability chains, and no special access. They simply need to know an endpoint exists.


## The Threat: Exposed AI Endpoints as a Free Attack Platform


Organizations deploying self-hosted large language models (LLMs) typically expose inference endpoints to enable applications to call the AI models—a standard architectural pattern in modern AI deployments. These endpoints, commonly hosted on ports 11434 (Ollama) or 4000 (LiteLLM), are designed for application-to-application communication and are frequently left accessible with minimal or no authentication.


Threat actors have recognized this as low-hanging fruit. Unlike traditional cloud compromises that require discovering credentials, exploiting vulnerabilities, or gaining initial access through phishing, abusing an exposed AI endpoint requires only two things:


1. Knowledge of the endpoint location (IP address and port)

2. Understanding of the endpoint's API (widely documented in open-source projects)


"The attacker doesn't need any special authentication to reach them; they just need to know where the endpoint is," according to Zenity's analysis. Once connected, an attacker can submit a crafted request containing their own system prompts, instructions, and tool definitions—essentially injecting a malicious AI agent directly into an organization's compute resources.


The implications are severe: organizations are unknowingly providing threat actors with free access to powerful LLM infrastructure, which can process thousands of requests, operate continuously, and carry out complex reasoning-based attacks at scale.


## How the Attack Works: The Injection Method


The attack follows a predictable sequence that requires no sophisticated exploitation:


Step 1: Reconnaissance

Attackers scan for exposed endpoints using port-scanning tools or passive techniques. They may send a small "hello" probe to confirm the endpoint responds to valid API calls.


Step 2: Payload Configuration

The attacker configures a client application (LiteLLM client, CherryStudio desktop app, or custom Codex CLI) to route requests through the exposed endpoint as its model backend.


Step 3: Agent Injection

The attacker crafts a request containing:

  • A malicious system prompt designed to override the model's safety guidelines
  • Tool definitions that grant the AI agent specific capabilities (web browsing, credential harvesting, code generation)
  • Instructions for autonomous operation without human oversight

    • Step 4: Execution

    The request is submitted to the endpoint. The AI model processes the injected instructions and carries out the attacker's objectives using the organization's compute infrastructure.


    This approach is remarkable in its simplicity. Unlike traditional cloud account takeovers or container escape vulnerabilities, there are no exploits to deploy, no credentials to crack, and no suspicious lateral movement to detect. The attacker's malicious agent rides entirely in the request body.


    ## Three Campaigns Exploiting AI Infrastructure


    Zenity's honeypot sensors captured evidence of three distinct operations abusing exposed AI endpoints:


    ### Autonomous Penetration Testing Frameworks


    Two campaigns deployed autonomous penetration testing toolkits—Strix and HexStrike AI—against unidentified targets. These frameworks are designed to automate security testing and reconnaissance tasks, but in this context were being weaponized for unauthorized network assessment.


    In one documented incident, a single IP source used a LiteLLM client to send a 140,000-character prompt to attack a French auction house. The prompt included explicit instructions to:

  • Never request permission before proceeding with actions
  • Run continuously without pausing or waiting for user input
  • Conceal the identity of the Strix framework in all activity logs and outputs
  • "GO SUPER HARD on all targets"—language suggesting maximum intensity reconnaissance and exploitation attempts

    • ### Custom Codex Agents with Suppressed Safety Controls


    The third campaign deployed a custom OpenAI Codex-based agent explicitly configured to suppress safety refusals. This agent was built to assist in reverse-engineering web applications and APIs, suggesting a campaign focused on understanding target infrastructure before launching deeper attacks.


    By suppressing safety mechanisms, the attacker attempted to bypass the model's built-in guardrails that would normally refuse certain request types or flag potentially harmful instructions.


    ## Why This Matters: Scale, Persistence, and Attribution Challenges


    Traditional attack infrastructure—rented servers, compromised hosts, command-and-control networks—leaves forensic traces, incurs operational costs, and can be traced back to attackers. Abusing an exposed AI endpoint sidesteps all of these constraints:


    | Factor | Traditional Infrastructure | Exposed AI Endpoint |

    |--------|---------------------------|---------------------|

    | Cost to attacker | Monthly hosting fees, proxy subscriptions | Zero; uses victim's resources |

    | Attribution | Logs tied to attack infrastructure | Traffic originates from victim's IP |

    | Detection | Unusual outbound connections, rare ports | Legitimate internal API traffic |

    | Persistence | Requires maintaining access | Endpoint remains perpetually available |

    | Scalability | Limited by attacker's resources | Unlimited, bounded only by victim's compute |


    An attacker leveraging an exposed LLM endpoint can process tens of thousands of requests, maintain multiple parallel agents, and scale reconnaissance or credential-stuffing campaigns without acquiring additional infrastructure.


    From the victim's perspective, detecting such abuse is challenging. The traffic appears as normal API calls from localhost or internal networks. Without specific monitoring for malicious prompts, exfiltration of data through model outputs, or anomalous reasoning chains, these attacks may go undetected for extended periods.


    ## Defensive Recommendations


    Organizations deploying self-hosted AI infrastructure must take immediate action:


    ### Network Isolation

  • Restrict access to inference endpoints at the network level. Use firewall rules, network segmentation, or VPN requirements to ensure only authorized applications can reach these services.
  • Deploy endpoints on private networks, not on internet-facing IP addresses.
  • Use service-to-service authentication (mutual TLS, API keys) between applications and endpoints.

    • ### Authentication and Authorization

  • Implement API key authentication on all inference endpoints. Require clients to present valid credentials.
  • Rotate API keys regularly and monitor for suspicious key usage patterns.
  • Log all requests with metadata about the source IP, credentials used, and request content.

    • ### Monitoring and Anomaly Detection

  • Monitor for unusually long prompts or suspicious system prompt injection attempts.
  • Alert on requests attempting to override safety guidelines or disable model guardrails.
  • Track the number of requests per client or IP; sudden spikes may indicate abuse.
  • Analyze model outputs for signs of data exfiltration or credential harvesting.

    • ### Incident Response

  • Audit logs for evidence of past abuse. Look for requests with high character counts or suspicious patterns.
  • If compromise is suspected, isolate the endpoint immediately and review all outputs generated during the suspicious period.
  • Assume any data processed by the model (including proprietary code, customer data, or system prompts) may have been accessed by attackers.

    • ### Supply Chain Vigilance

  • Keep Ollama, LiteLLM, and related frameworks updated to patch security issues.
  • Review the deployment documentation for these tools and ensure default configurations are hardened.
  • Consider running inference endpoints on air-gapped or highly restricted networks where possible.

    • ## HackWire Analysis


    This attack pattern represents a critical blindspot in how organizations think about AI security. Most discussions focus on model poisoning, prompt injection, or data privacy—but this threat is different and simpler: it's an infrastructure access problem masquerading as an AI problem.


    The attacks observed by Zenity don't require sophisticated AI knowledge or deep understanding of LLM behavior. An attacker with basic API familiarity and a Shodan query can compromise organizations at scale. The fact that three distinct campaigns were observed in just three months suggests this technique is already in the attacker playbook, likely spreading through underground forums and threat actor communities.


    What makes this particularly dangerous is the misdirection. Organizations deploying AI endpoints are likely focused on safety, bias, and hallucination controls—legitimate concerns—but they're overlooking the most basic requirement: controlling who gets to call your model at all. An AI endpoint with world-class safety controls but no authentication is still a publicly available supercomputer at an attacker's disposal.


    The scale multiplier is also underestimated. Traditional penetration testing frameworks require significant overhead to operate at scale. An attacker renting servers, managing proxies, and handling tool deployment might scale to dozens of concurrent operations before costs spiral. But an attacker leveraging a victim's LLM infrastructure can run hundreds of autonomous agents in parallel, process millions of prompts, and maintain persistence indefinitely—all at the victim's cost.


    Organizations should assume their exposed AI endpoints have already been discovered and probed. The urgent priority is network isolation and authentication, not configuration optimization. If your inference endpoint is currently reachable without a credential, treat it as a critical incident.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Cloud Security](https://www.hackwire.news/category/cloud-security) coverage
  • Cross-reference with [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) and [Threat Intelligence](https://www.hackwire.news/category/threat-intelligence)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)