Hackers Exploit AI Deployments: 91,000+ Malicious Sessions Reveal New Weak Links (and How to Fix Them)

If you thought your AI stack was flying under the radar, think again. Security researchers have tracked more than 91,000 malicious sessions hammering AI infrastructure over just three months—peaking during the holidays when many teams were offline. Two coordinated threat campaigns probed everything from model-pull workflows to misconfigured “OpenAI-compatible” endpoints, quietly mapping where defenses were thin. The goal wasn’t flashy data theft. It was something subtler—and, in many ways, more dangerous: turning the rapidly growing AI attack surface into a predictable, profitable target.

Feeling a twinge of curiosity (or concern)? Good. Because the story here isn’t just about the attacks—it’s about where your AI stack might already be exposed, and what you can do about it this week.

The Big Find: 91,000+ Malicious Sessions Targeting AI Infrastructure

According to reporting from Cyber Press, data captured by GreyNoise honeypots shows two distinct threat campaigns between October 2025 and January 2026:

Campaign 1: Attackers exploited server-side request forgery (SSRF) pathways via Ollama’s model pull functionality and Twilio SMS webhook integrations. By injecting malicious registry URLs, they forced AI services to make outbound requests to attacker-controlled infrastructure. Activity spiked over Christmas: 1,688 sessions in 48 hours, originating from 62 IPs across 27 countries.
Campaign 2: Starting December 28, 2025, a more methodical campaign lit up 73+ LLM endpoints with 80,469 sessions over 11 days. Two IPs with extensive CVE exploitation histories drove systematic recon across “OpenAI-compatible” and Gemini-style API formats, covering major model families: GPT-4o, Claude, Llama, DeepSeek, Gemini, Mistral, Qwen, and Grok. The probes used innocuous prompts and fingerprinting—deliberately low-noise—to identify responsive models and weak configurations without tripping obvious alarms.

The pattern is hard to ignore: adversaries (possibly grey-hat operators or bounty hunters at scale) are inventorying AI deployments the way they once did exposed Kubernetes dashboards and unguarded S3 buckets. And they’re doing it fast.

Why This Matters (Even If You “Don’t Expose” AI to the Internet)

AI stacks are uniquely chatty. They reach out to model registries, external APIs, and plugins. That makes SSRF and egress abuse more damaging than in typical web apps.
“OpenAI-compatible” endpoints are exploding. Compatibility is great for developer velocity—and also great for attackers who can script once and probe anywhere.
Misconfigurations are common. Shadow projects, quick-start proxies, and default settings can inadvertently open LLM endpoints to the internet or leak tokens through reverse proxies.
Traditional security tooling lags behind. Many orgs don’t yet collect the right telemetry (model names, token counts, prompt metadata) to spot abuse early.

In short: the window between “we shipped something neat” and “it’s being scanned across the internet” is closing—quickly.

Inside Campaign 1: SSRF Through Model Pulls and Webhooks

SSRF is a classic issue: an attacker gets your server to make a request on their behalf—often to an internal resource it should never expose. AI infrastructure adds accelerant: model pulls, registries, plugin calls, and webhooks are all pathways for outbound requests.

How SSRF Shows Up in AI Pipelines

Model pulls: Tools like local model runtimes often support fetching models or artifacts from registries. If the registry URL or reference isn’t tightly validated and restricted, an attacker can coerce a fetch from a malicious location.
Webhooks: Messaging and notification flows (e.g., Twilio SMS handlers) receive inbound callbacks. If the handler logic fetches remote content or trusts unvalidated input to construct requests, SSRF becomes possible.
Plugin/connectors: “Call external service X when user says Y” can turn into a generalized SSRF primitive if poorly sandboxed.

The GreyNoise honeypots observed attackers injecting registry URLs into Ollama model pull paths and abusing Twilio SMS webhook handlers to force outbound HTTP to attacker infrastructure. That’s textbook SSRF—applied to AI-specific plumbing.

The Potential Blast Radius

Data path traversal: Access to metadata services (e.g., cloud instance metadata), internal dashboards, or private model registries.
Credential exposure: If the environment attaches tokens to egress or allows IMDS access, SSRF can escalate.
Supply chain risk: Malicious model artifacts or manifests fetched from untrusted registries.
Recon springboard: Even when SSRF is “harmless,” it validates that your server can be forced to talk to the internet—intel attackers can use later.

Defensive Moves That Work

Restrict model pulls:
Enforce explicit allowlists of registries and protocols.
Require digest or signature pinning for model artifacts.
Disable ad-hoc “remote URL” parameters in production paths.
Harden webhook handlers:
Verify signatures (e.g., Twilio HMAC validation) and reject unsigned requests. See Twilio’s webhook security guidance.
Avoid server-side fetches based on user-controlled input.
Enforce strict input validation and timeouts; no SSRF-prone URL parsing shortcuts.
Egress control:
Default-deny outbound connections from model hosts; allow only required domains and IPs.
Enforce DNS policies to prevent resolution of arbitrary domains.
Shield cloud metadata endpoints (e.g., require IMDSv2; block link-local IMDS access from app containers).
Secrets hygiene:
Remove long-lived tokens from runtime environments.
Scope credentials to specific hosts/paths and set low TTLs.
Rotate keys if you observed suspicious egress during the timeframe.

For additional context on SSRF risks and mitigations, see the OWASP SSRF Cheat Sheet.

Inside Campaign 2: Silent Recon Across “OpenAI-Compatible” LLM Endpoints

The second campaign is the more strategic—and arguably more worrying—one. Two IPs, each with a noisy history elsewhere, executed quiet, systematic reconnaissance of LLM endpoints over 11 days:

Probing API formats: OpenAI-compatible routes (e.g., chat/completions), Gemini-style formats, and other common schemas.
Fingerprinting models: Testing for GPT-4o, Claude, Llama, DeepSeek, Gemini, Mistral, Qwen, and Grok families.
Staying under the radar: Using harmless prompts and content to avoid tripping keyword-based alerts, while still extracting enough signal to map capabilities and auth gaps.

What Attackers Are Likely Hunting

Misconfigured reverse proxies that inadvertently forward internal API keys.
Endpoints with no auth (or weak bearer tokens baked into the proxy).
Over-permissive CORS enabling cross-origin token theft from admin tools.
Leaky error messages or headers revealing model, provider, or gateway internals.
Pay-per-call monetization opportunities (abusing metered APIs at your expense).

If your team—or a shadow project—spun up an “OpenAI-compatible” gateway to simplify migrations or routing, that gateway may already be in someone’s scan loop.

Early Indicators You Should Check

Billing or quota anomalies across model providers.
Logs showing 401/403/429 surges from unfamiliar IP ranges (especially late December through early January).
Repeated innocuous prompts originating from a small number of IPs.
Unexpected traffic to model endpoints via direct internet routes instead of your standard ingress.

Providers publish security guidance worth reviewing: OpenAI platform best practices, Google AI/Gemini API docs, and Anthropic Claude guidance.

Why AI Stacks Are Attractive Targets Right Now

Compatibility by design: “Drop-in” API compatibility compresses attacker engineering time.
Rapid adoption, inconsistent governance: Labs and teams launch pilots fast; security guardrails trail behind.
High-value secrets in motion: Model keys, data connectors, vector stores, and customer prompts.
Novel telemetry needs: Traditional WAF logs miss telltale LLM abuse signals (e.g., token spikes, model switches, prompt metadata).

The result: a large, uniform, and often under-instrumented attack surface.

A 48-Hour Triage Plan for Security Teams

If you own or influence AI infrastructure, here’s what to do first—this week.

Inventory exposed endpoints:
Discover all “OpenAI-compatible,” Gemini-style, and vendor-specific routes (including vLLM, TGI, Text Generation Web UI, and custom FastAPI wrappers).
Identify internet exposure via DNS, CDN, or any public IPs.
Enforce authentication and access:
Require strong auth (mTLS or OAuth/JWT) at gateways; avoid static bearer tokens in reverse proxies.
Use identity-aware proxies (e.g., SSO-enforced) for admin panels.
Tighten egress:
Default-deny outbound traffic from model hosts; allow only provider endpoints and vetted registries.
Restrict DNS to approved resolvers; block direct IP egress where feasible. See CISA guidance on egress filtering.
Lock down webhooks:
Validate signatures (Twilio, Slack, etc.), enforce strict source IP allowlists, and minimize server-side fetch behaviors.
Add smart rate limits:
Set per-IP and per-identity limits on chat/completions, embeddings, and image/audio routes.
Alert on spikes in token usage, new model names, or atypical parameter combos.
Improve logging and observability:
Capture model name, token counts, user/service identity, and hashed request IDs (with privacy in mind).
Centralize logs; create dashboards for anomalous patterns.
Secrets and keys:
Rotate provider API keys if you suspect exposure.
Scope keys to specific models/regions; use short-lived tokens where supported.
CORS and CSRF:
Restrict CORS to trusted origins; disable wildcards in production.
Protect internal consoles and admin tools against CSRF.
Patch and harden:
Update AI servers, SDKs, and proxies.
Remove debug endpoints and sample routes from production.

Hardening Patterns That Make AI Infrastructure Safer

1) Model Pull Governance

Only allow model/artifact pulls from approved registries.
Pin by digest or signature; verify integrity before load.
Separate build-time pulls (in CI/CD) from runtime pulls; avoid on-demand “pull-from-web” in production.

If you use local runtimes, review documentation (e.g., Ollama) for secure configuration patterns and environment hardening.

2) LLM Gateway With Policy Enforcement

Place a dedicated gateway in front of model providers and local runtimes.
Enforce:
AuthZ: Which identities can call which models.
Quotas and rate limits.
Content policies (prompt/response filtering for PII or secrets).
Output sanitation before downstream use.
Maintain a denylist of disallowed parameters or plugins; require explicit approval for advanced tool use.

3) Default-Deny Egress + DNS Policies

Model servers and plugins should not “browse the internet.”
Allowlist:
Provider API FQDNs and IP ranges (monitor changes).
Internal services strictly needed for function.
Block link-local metadata endpoints from containers unless explicitly required (and then enforce IMDSv2).

4) Secrets Hygiene by Design

Use a secrets manager with envelope encryption and automatic rotation.
Scope credentials to environments and purposes (dev vs. prod).
Never pass provider API keys to the browser; route calls server-side.

5) Observability Built for LLMs

Collect:
Model/endpoint called, token usage, latency, error codes.
Identity (service account or user), tenant/org, region.
High-level prompt/response fingerprints or hashes (respecting privacy).
Alert on:
New models being called unexpectedly.
Token usage outliers.
Traffic from new geographies or ASNs.
Repeated harmless probes from a small set of IPs (a recon tell).

6) Test What You Expect to Break

Include SSRF cases in security testing (fuzz URL parsers, redirect logic, and webhook handlers).
Simulate misconfigurations: public proxy without auth, wildcard CORS, disabled egress filtering.
Map your controls to frameworks like the NIST AI Risk Management Framework and the OWASP Top 10 for LLM Applications.

Telemetry That Separates Noise From Signal

You don’t need every packet. You do need the right breadcrumbs to spot this kind of campaign:

HTTP/API metadata:
Path, method, status, latency, and headers (minus secrets).
Model name/version, token in/out counts.
Caller identity (service user, API key ID), source IP/ASN.
Egress summaries:
Destinations by domain/IP.
DNS queries made by model hosts.
Connection attempts to non-allowlisted destinations.
Auth anomalies:
Repeated failed bearer token attempts.
Tokens used from atypical geos or services.
Provider-side signals:
Quota spikes or error bursts (401/403/429) in vendor dashboards.
New model usage that your apps don’t normally call.

Are These Grey-Hats or Preludes to Something Bigger?

The Cyber Press analysis suggests the operators might be grey-hat researchers or bounty hunters running at scale. Maybe. But intent is notoriously hard to attribute—especially when tactics favor low-noise reconnaissance. Whether “helpful” or not, mass probing builds a map attackers can use later.

Two practical steps for responsible engagement:

Publish a clear vulnerability disclosure policy and security.txt file so researchers know how to contact you responsibly.
Track outreach professionally; reward good faith, but keep your detection tuned for abuse regardless of who knocks.

Learn more about honeypot-driven internet scanning from sources like GreyNoise.

What This Means for 2026: Expect More of It

Monetization will move beyond key theft: meter fraud, compute theft on GPU nodes, and abuse of model-to-plugin chains.
Supply chain pressure will grow: malicious model manifests, poisoned weights, and trojaned loaders are real risks.
Cross-domain attacks will converge: prompt injection meets SSRF meets data exfiltration, stitched together through AI-aware middlewares.
Compliance will catch up: you’ll be asked for LLM-specific logging and access controls—not just app-level ones.

The teams that do best will treat AI infrastructure as first-class, high-risk software—not a sidecar to the main app.

Quick-Reference: AI Security Checklist

Restrict model pulls to approved registries; pin by digest/signature.
Default-deny egress from model hosts and gateways; allowlist provider endpoints.
Validate and sign all webhooks; avoid server-side fetches based on user input.
Enforce strong auth at LLM gateways; kill unauthenticated “compatibility” routes.
Lock down CORS; protect consoles with SSO and CSRF defenses.
Collect LLM-aware telemetry (model, tokens, identity); alert on anomalies.
Scope and rotate provider keys; never expose them client-side.
Patch AI frameworks/proxies; remove debug/demo routes in prod.
Publish a disclosure policy; monitor reconnaissance without assumptions about intent.

FAQ

Q: Are my LLM endpoints safe if they’re behind a VPN or private network?
A: Better—but not automatically safe. SSRF can pivot from internal services, and misconfigured reverse proxies can still leak. Treat private endpoints with the same rigor: strong auth, default-deny egress, and careful webhook handling.

Q: What’s SSRF in simple terms?
A: It’s when an attacker convinces your server to fetch a URL they choose. If your server can reach internal networks, metadata services, or trusted registries, that “one fetch” can expose secrets or download malicious content. See the OWASP guide.

Q: How do I know if I accidentally exposed an “OpenAI-compatible” API?
A: Scan your own perimeter: look for routes like /v1/chat/completions, /v1/completions, /v1/embeddings, or Gemini-style endpoints. Check ingress rules, CDN configs, and any test proxies created for migrations. If it’s reachable without auth, assume it’s already been probed.

Q: Will rate limiting alone stop these reconnaissance campaigns?
A: Rate limiting helps, but it’s not enough. The observed probes were low-and-slow, designed to slip under simple limits. Combine limits with auth, egress controls, and anomaly detection.

Q: Should I block all outbound traffic from model servers?
A: In production, yes—default-deny and allow only what’s needed (provider domains, licensed registries). For development, use a controlled egress proxy so you can observe and adjust without going wide-open.

Q: How can I safely support model pulls (e.g., with local runtimes)?
A: Treat model pulls like dependency management: – Only from approved registries. – Pin by digest or signature. – Pull during CI/CD, not dynamically at runtime. – Scan artifacts before deployment and store in an internal cache/registry.

Q: Are open-source LLMs safer than closed-source APIs?
A: “Safer” depends on configuration. Open-source models eliminate third-party API exposure but increase your responsibility for patching, egress, and artifact integrity. Closed-source APIs centralize security to the provider but put a premium on key management and gateway hardening.

Q: What logs help detect this kind of activity?
A: Record endpoint, model name, token counts, request latency, identity (user/service), source IP/ASN, and high-level prompt fingerprints. On the network side, track DNS queries and egress destinations from model hosts.

Q: Could these have been grey-hat scans? Should I ignore them?
A: Intent is unclear and changeable. Don’t ignore them. Use them as signals to harden now, publish a disclosure policy, and stay ready for follow-up campaigns that may be less benign.

The Takeaway

AI systems aren’t niche anymore—they’re part of your core attack surface. The 91,000+ malicious sessions observed this winter show that adversaries (curious, commercial, or criminal) are already mapping where AI deployments bend and break. You don’t need to panic. You do need to act:

Kill unauthenticated “compatibility” endpoints.
Default-deny egress from anything that can run a model or fetch one.
Validate webhooks and lock down model pulls.
Log what matters for LLMs, not just web apps.

Do those four things and you’ll blunt the exact techniques powering the campaigns researchers just documented—before they’re used for something more than reconnaissance.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

Hackers Exploit AI Deployments: 91,000+ Malicious Sessions Reveal New Weak Links (and How to Fix Them)

The Big Find: 91,000+ Malicious Sessions Targeting AI Infrastructure

Why This Matters (Even If You “Don’t Expose” AI to the Internet)