rpm

This article is based on joint research with Eran Segal, researcher at Kodem Security. The most capable commercial AI models are now useful enough to attackers that they have become an integral part of their kill chain, in multiple steps. The Cybench benchmark tests models on offensive cyber tasks. Its current top performers (Claude Opus 4.6, Claude Sonnet 4.5, Grok 4) can write functional exploit code, reason through credential chains, and sustain complex reconnaissance workflows: multi-step offensive work that previously required human expertise. Malware families are already using this. Instead of generating a payload offline and shipping it, they wire a live LLM API into the malware itself so it can adapt its behavior at runtime on the infected host. Commercial providers run abuse detection and terminate accounts linked to malicious activity. A payment method creates a paper trail that investigators can follow. So attackers solve the access problem the same way they solve any resource problem: they steal it, find it free, or find it unguarded. This post covers five routes threat actors use to reach LLM inference without paying for it: buying offensive models on underground forums, using front-end models using 3rd party LLM service that allows paying in bitcoin, using free-tier or keyless public APIs, hunting for leaked API keys in developer artifacts, and exploiting self-hosted LLM servers left open on the internet. Method 1: Offensive LLMs and Anonymous Payment Cyber-oriented LLMs sold on underground forums are the most visible route. WormGPT, GhostGPT, KawaiiGPT, and Xanthorox are the most cited examples, covered in depth by Unit 42. These are returned open-weight models or jailbroken wrappers over commercial APIs, marketed specifically as having no content filter. They solve the moderation problem but not the cost problem: access is sold on a subscription basis, and the capability ceiling sits well below that of frontier commercial models. So they are useful for generating phishing content or simple malware stubs, but less so for the kind of autonomous multi-step offensive work that the frontier models in the Cybench ranking are capable of. Method 2: Using Frontier Models Through a Third-Party Service If a threat actor would like to use the frontier models to achieve top performance, they can still use these models using 3rd party services such as PayWithMoon and AIMLAPI. These services sit between the attacker and a commercial LLM provider, accepting cryptocurrency without identity verification and then funding a legitimate provider account on the attacker's behalf. The account itself reaches frontier models, but the funding trail stops at the middleman. The account will still get burned once abuse detection triggers, but replacing it is cheap. The upstream provider has no usable identity to pursue. This is how attackers buy frontier-model access while skipping the paper trail a normal commercial account would leave behind. Method 3: Free-Tier and Keyless Public Inference APIs A cheaper alternative to underground subscriptions exists in plain sight. Most major inference providers publish permanent free tiers that require nothing more than a disposable email address, and a handful of services accept requests with no credentials at all. An attacker who registers for a pool of free-tier accounts gets as meny tokens as he wishes without paying a dime. The scale of the free-tier ecosystem is easy to measure because the community has cataloged it. Public curated lists such as cheahjs/free-llm-api-resources and mnfst/awesome-free-llm-apis explicitly filter for providers that offer a permanent (not trial-credit) free tier with no credit card. Representative entries, with numbers pulled from each provider's own rate-limit documentation: Groq: 30 requests/minute (RPM) on all free-tier models, with requests/day (RPD) caps ranging from 1,000 (for the 70B llama) to 14,400 (for the 8B llama). Cerebras: 30 RPM, 14,400 RPD, and roughly 1M tokens/day on three of the four free-tier models (gpt-oss-120b, llama3.1-8b, qwen-3-235b). Cohere: 20 RPM on the Chat API and a hard cap of 1,000 total API calls/month on a trial key. Mistral La Plateforme: 1B tokens/month on the Experiment plan. No credit card is required, but a verified phone number is required, which is the highest sign-up friction in this group. HuggingFace: Free accounts are rate-limited on both the Hub API and the Inference API per 5-minute window. Anonymous per-IP access exists but is stricter than the free-account path. OpenRouter: 50 free model RPD with no deposit at all, and 1,000 RPD after a one-time $10 top-up that is never spent against model usage. SambaNova: 20 RPM and 20 RPD, with a 200,000 tokens/day cap. The tightest daily request ceiling in this group by a wide margin. These providers differ in rate limits, models, and throughput. What they share is that a usable credential requires nothing more than a disposable email address (a phone number in Mistral's case) and no payment method. Credentials can simply be rotated when limits are reached. The fully keyless end of the spectrum is thinner, but it exists. Pollinations.ai exposes an OpenAI-compatible endpoint that accepts requests with no authentication for basic use. DuckDuckGo's Duck.ai anonymizes browser-based access to Claude 3.5 Haiku, Llama 4 Scout, Mistral Small 3, GPT-5 mini, and GPT-4o mini with no account at all. These services are not designed for bulk programmatic use, but they are reachable from any HTTP client, and the only cost is rate-limit friction. Among the malware families in the intro table, LameHug/PROMPTSTEAL is the cleanest example of this route in the wild: it calls HuggingFace's Inference API for Qwen 2.5-Coder-32B-Instruct to drive reconnaissance and data theft, with no embedded credentials reported by Splunk. Whether the malware carries a token or registers one at runtime is not established, but either way, the enabling property is HuggingFace's no-credit-card free tier. Method 4: Exposed API Keys The fourth route to free model access doesn't require finding an exposed server at all. Developers routinely hardcode credentials directly into apps, config files, and scripts. These credentials can be found in GitHub in open-source projects, while closed-source projects contain the credentials in the app itself. These artifacts are submitted to VirusTotal when apps are submitted for malware analysis. It can be an APK, ELF, EXE, or any type of artifact shipped with the product. To find them systematically, we wrote a YARA rule targeting the key formats of the major AI providers: Google Gemini (AIzaSy…), OpenAI (sk-…), Anthropic (sk-ant-…), HuggingFace (hf_…), Replicate, Mistral, Cohere, Groq, and several others. We ran the rule as a retrohunting query across the VirusTotal corpus, collected the matching sample hashes, then pulled the raw files and ran a regex extraction pass to extract every key-value pair, provider, and surrounding code context. From there, we enriched each sample with VirusTotal metadata to understand detection rates and file types. The final step was validation: a lightweight GET request against each provider's model-list or whoami endpoint. No prompts sent, just a check of whether the key authenticates. The corpus yielded 647 unique keys across all providers. Roughly 62% were Google Gemini (AIzaSy…) keys. That concentration traces back to the Android developer ecosystem, where apps built for translation, search, or chatbot features commonly bundle the key directly in compiled resources or Java code. HuggingFace keys made up about 11%, Replicate about 8%, OpenAI sk- keys about 7%, and the remaining share was split across Voyage (5%), Mistral (3%), and Cohere (3%), with trace amounts of Anthropic, Groq, and OpenAI environment-style keys. The Mistral and Cohere keys concentrated heavily in a single file: a cracked "Collins Italian Dictionary MOD" Android APK that bundled 20 Mistral keys and 15 Cohere keys alongside 2 Gemini keys, with the small remainder scattered across two versions of a Ubisoft game APK. About 65% of the 659 unique samples are confirmed Android by VirusTotal's type classification. Another 18% are ZIP archives that follow the same submission pattern but were not explicitly tagged as Android. The true APK share sits between 65% and 84%. The remainder consisted of Windows PE files (5%), HTML pages, Python scripts, plain-text credential dumps, and a handful of Mach-O and ELF binaries. That Android skew isn't surprising. APKs are frequently submitted to VirusTotal for modding and repackaging, and their keys remain intact after decompilation. We submitted research samples to Intezer Analyze for code-based attribution, and three entries stand out. Four samples whose filenames suggested Akira ransomware are three Mimikatz binaries (1, 2, 3) and one malicious binary without family attribution, all credential-dumping tools that happened to carry API keys. The sample with a HuggingFace key is SolarMarker, an SEO-poisoning backdoor with infostealer capability. A Windows binary named SystemSettings.exe contained OpenAI, Replicate, and Voyage keys; the multi-key combination is more consistent with theft from a developer's machine than with intentional hardcoding. When we ran the validation, almost all the keys were dead. The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples that had been on VirusTotal long enough to be detected, rotated, or simply expired. The small fraction that remained live consisted entirely of Google Gemini keys from Android APKs. All appeared to be genuine developer mistakes rather than exfiltrated credentials: a key embedded in a const in bundled JavaScript, one in a logging module in a compiled Android class, and one in a utility app's APK resources. Those three keys have been reported to Google. The method also illustrates why embedding API keys in client software is a particularly bad idea. Extracting a key from an APK requires a decompiler, and APKs have a reliable path to VirusTotal: users submit them for malware checks, repackaged versions circulate through third-party stores, and cracked builds get flagged automatically. The near-total revocation rate strongly suggests that LLM providers scan VirusTotal for their own key formats and automatically revoke matches. The three keys that were still live were all recent submissions, not yet caught by that sweep. If that pipeline exists, embedding a key in client-side code is not just a security mistake, but a futile one, and the key will likely be dead before it can be abused at scale. The takeaway for an attacker is that hunting VirusTotal for hardcoded keys is low-effort but low-yield. The more durable access method is the exposed LLM server. A server running vLLM (a popular open-source LLM inference framework) or an open Ollama instance requires no authentication, doesn't rotate anything while in use, and the owner usually doesn't know it's happening. Method 5: Hack Public LLM Hosting Servers Self-hosted LLM platforms make it easy to run your own models on your infrastructure, and that same ease extends to anyone who can access the port. Most ships have no authentication by default and expose administrative endpoints that let a stranger list installed models, queue inference jobs, load new models from remote URLs, or, in several cases, execute code on the host. When the server is exposed to the public internet, the attacker does not need a stolen key or a forum subscription. The victim is paying the GPU bill, carrying the API-key spend, or hosting the RCE. We scanned roughly 4,500 hosts across eleven of them. Every service had open instances, and 14 LocalAI hosts showed active compromise based on attacker-loaded model names consistent with a single automated campaign. The sections below cover what each platform is, how exposure gets abused, and what the scan found in the wild. Ollama Ollama runs open-weight LLMs locally. By default, it binds to 127.0.0.1, and the authentication is disabled. But setting OLLAMA_HOST=0.0.0.0 is a common step when accessing it from another machine on the network or from a frontend app running in a separate container. It exposes all interfaces, and anyone reaching it’s port gets full API, model management, and hardware access. SentinelOne Labs and Censys already published the definitive survey, documenting 175,000+ hosts chained into anonymous AI networks for free text, embedding, and bulk content generation on victim hardware. That pattern is now commercialized by Operation Bizarre Bazaar, which sells subscription access to a unified LLM gateway fronted by stolen Ollama endpoints, turning ad-hoc LLMjacking into a growing concern. LocalAI LocalAI is an OpenAI API-compatible model server supporting LLMs, image generation, speech, and transcription. Authentication is disabled by default. It also supports remote model installation, P2P distributed serving, and a built-in agent platform with support for MCP. Of all the services in this research, it has the widest attack surface. Of all the hosts scanned, 55% were confirmed open, the highest absolute count in this group. About 24% are API proxies with live upstream keys for OpenAI, Anthropic, and Google accessible to anyone who can reach the host. The most striking finding is evidence of automated exploitation at scale. About 21% of confirmed hosts carry model names with a consistent signature tied to ProjectDiscovery's nuclei scanner templates, with per-run timestamps mapping to late March and early April 2026. The pattern is consistent with automated scanning for an unauthenticated remote code execution path, in which a malicious URL supplied during model installation triggers server-side code execution. The exploit payload appears to load a small publicly available Italian-language model as a "hello world" confirmation, which recurs on every affected host. The markers not being cleaned up argue against mature attacker tradecraft. Operators running LocalAI can open /v1/models on their own host: any nuclei-rce-* or rce_ identifier is not human-chosen and indicates this campaign hit them. Langflow Langflow is a visual builder for multi-agent AI pipelines, widely used to prototype RAG systems and chatbots. Flows routinely embed hardcoded credentials: OpenAI and Anthropic API keys, database connection strings, Slack tokens, and webhook secrets. Anyone who can reach the host and read a flow config has all of them. Unlike the previous examples, this app does not have a known major misconfiguration, but it does not prevent attackers from being able to hack and gain access to this service. For example, two unauthenticated RCE bugs make reaching the config trivial: CVE-2025-3248:on the CISA KEV list, reliably patched only in 1.6.4+ CVE-2026-33017: fixed in 1.9.0, exploited in the wild within 20 hours of disclosure. Every confirmed host in our scan ran a version vulnerable to CVE-2026-33017; about 72% were also vulnerable to CVE-2025-3248. Several hosts didn’t authenticate at all, with flows, credentials, and both RCE paths openly accessible. Code execution on the Langflow host is the small prize. The keys inside the flows pivot to everything the workflows connect to. n8n n8n is a low-code workflow automation platform with 400+ service connectors and code execution nodes (workflow steps that run arbitrary scripts). It has the strongest default auth posture of any service in this research: User Management is enforced on fresh installs. But it does not prevent attackers from actively gaining access to n8n. Vulnerabilities such as CVE-2026-21858 ("Ni8mare", CVSS 10.0, fixed in 1.121.0), which is a vulnerability in the web hooks request handling that turns exposed endpoints into a full unauthenticated RCE surface via content-type confusion, with a public PoC already out. Prior research estimates the exposed n8n population at tens of thousands of hosts. The post-exploitation story mirrors Langflow. Workflows carry hardcoded API keys, database connection strings, and webhook secrets. RCE on the n8n host effectively gives access to every system the automations touch. vLLM vLLM is a high-throughput LLM serving engine with GPU acceleration, commonly used to self-host open-weight models in production. It exposes an OpenAI-compatible REST API. Authentication requires an explicit --api-key flag; without it, the API is open. The interesting finding from our scan was not vLLM itself but the adjacent deployments surfaced by the same query: OpenAI-compatible HTTP proxies, specifically LiteLLM-style gateways that aggregate multiple paid providers behind a single endpoint. These proxies store live API keys for OpenAI, Anthropic, Google, Groq, and Cohere. None had protection on the model list endpoint. One host exposed 35 models across multiple providers; several listed exclusively Anthropic Claude models. A proxy returns a model list only when the upstream provider authenticates, so every successful response confirms the underlying keys are live and billable. The abuse path is trivial: point any standard OpenAI SDK client at the proxy, enumerate the models, and, on hosts where prompt submission is also unprotected, send requests billed to the operator's accounts. It is the same credential-pivot pattern as Langflow and n8n. ComfyUI ComfyUI is a node-based workflow UI for Stable Diffusion, video generation, and multimodal image models. It runs on high-end GPU hardware with no authentication by default, making it a direct target for attackers looking to steal GPU compute. Our scan found open instances across a wide range of versions (v0.2.2 to 0.19.0), all of which were fully unauthenticated. The hardware exposure is the headline finding. Open hosts reported a combined ~4.3 TB of GPU VRAM, with cards ranging from RTX 4090s and RTX 5090s to datacenter-grade A100S and L40S units, each worth tens of thousands of dollars. An attacker can queue generation jobs against any of them at no cost. Beyond compute theft, 95% of open hosts expose a job history endpoint that leaks previously executed workflows, local file paths, and prior user content. About 12% advertise URL-loading nodes that act as server-side request forgery primitives: usable for internal network reconnaissance or cloud metadata credential theft. llama.cpp server llama-server is the HTTP server shipped with llama.cpp, commonly used to serve a single open-weight model in production. It has no authentication by default, no access controls on the inference endpoint, and a metadata endpoint that advertises exactly what the host is running. Anyone who reaches the port can submit prompts, watch active jobs, and burn the operator's GPU on their own workload. Classic LLMjacking, with the bonus of knowing exactly which model they are running. Of scanned hosts, 59% were confirmed open, more than any other platform in the scan. Everyone exposed its model name and hardware configuration, and about 37% also leaked real-time job state, confirming the host was actively serving users at the time of the scan. The models observed were standard open-weight builds rather than anything exotic, which is the point. An attacker is not looking for a rare model, just an unattended GPU. Jan Jan is an Electron desktop AI app with an optional OpenAI-compatible API server on port 1337. When enabled, it binds to all interfaces with no authentication. Jan is a useful example of how exposure surfaces unexpected content rather than how common it is. Our scan confirmed only two genuine Jan hosts. Both had gone offline by the rescan a week later. While one was live, it exposed a 35-model library that included miqu-70b; a leaked Mistral Medium prototype that was never officially released. When a desktop app binds its API server to the public internet, whatever model (or file path metadata) sits on the operator's disk becomes visible. Gradio Gradio is a Python framework for building ML demo apps: image classifiers, code interpreters, document Q&A, or anything a researcher can wrap in a web UI. Exposure risk depends entirely on what the underlying app does. A sentiment-analysis demo is low-stakes. An app that accepts file uploads, runs user code, or queries a database is a direct path to exploitation. The Gradio queue keeps processing submitted requests whether the operator is watching or not, so abuse can run quietly for days. Three unauthenticated bugs make unpatched instances worse: CVE-2024-47084: CORS validation bypass, fixed in 4.44.0; a malicious website can reach a locally running Gradio server while the victim is still logged in Ranking the Five Routes Each route carries operational trade-offs. The table below scores each on five dimensions, ranging from 0 (least favorable) to 5 (best for attacking): non-resistance (refusal behavior in response to offensive prompts), model capability (coding ability and parameter count), tool and MCP support, and effective token quota. Offensive LLMs score highest on non-resistance. But the underground-forum variants sit well below frontier models in capability and tool support, and subscriptions cap the quota. The crypto-middleman variant reaches frontier models via real provider accounts, but those accounts burn quickly once abuse is detected. Crypto payment for frontier models is for sure the best way to gain access for the most capable models with the ability to connect the model to any interface, such as MCPs, but it comes with some risks that the model might resist the action or the user will be blocked. Free-tier and keyless public APIs score well in capability and tool support, with full-function calling across most providers. The per-account quota is modest, tens of RPM, thousands of RPD, but trivial account rotation pushes the effective quota well above the face value. Stolen or leaked API keys, in principle, offer the best combination of capability and tool support; the retrohunt's 0.5% live rate shows the real-world quota is near zero. Exposed LLM servers score highest on non-resistance and token quota. Non-resistance is unconstrained: the attacker controls model selection, and our scan found at least one LM Studio host actively serving llama3.3-8b-instruct-thinking-heretic-uncensored-claude-4.5-opus-high-reasoning-i1. Token quota is equally unconstrained, bounded only by the victim's hardware rather than a billing cap. Capability and tool support vary by host, but that variance is what makes the route durable at scale. No individual host needs to run a frontier model. The scoring explains why exposed servers are the most durable route, even though they don't top every dimension. They are the only route where non-resistance and token quota both max out. The other three are each compromised on at least one of those two axes. Cases Found in the Wild Threat actors are now wiring malware to live LLM APIs, using them to generate malicious logic at runtime rather than embedding static code in the payload. Instead of scripting separate execution flows for different host conditions, the malware queries an LLM while running, determines whether the target appears to be a personal machine, a server, or an industrial controller, and then generates tailored commands or code accordingly. This shift matters because dynamically generated logic has no fixed signature to detect. Researchers have identified five malware families doing this. MalTerminal and PROMPTFLUX both use a hardcoded API key to connect to a commercial provider when needed. MalTerminal uses OpenAI GPT-4 via the now-retired chat-completions endpoint to create reverse shells or ransomware. PROMPTFLUX connects to Google gemini-1.5-flash-latest to rewrite its own VBScript source code between runs, making it harder to detect. LameHug, also known as PROMPTSTEAL, uses HuggingFace's Inference API to run Qwen 2.5-Coder-32B-Instruct for Windows commands to support reconnaissance and data theft. HuggingFace requires an API token for each request, but free accounts don't need a payment method and allow a few hundred requests per hour per API token. Attackers can easily create and rotate these API tokens, giving them the same access as stolen keys but with less hassle. PROMPTLOCK is a proof-of-concept AI-powered ransomware prototype, often called "Ransomware 3.0," developed by researchers at NYU's Tandon School of Engineering. The Go binary invokes gpt-oss-20b via a local Ollama API running on the infected host to generate Lua scripts that perform file listing, encryption, exfiltration, and (unfinished) wipe logic. This is a bring-your-own-model: no outbound calls, no provider-side billing trail, and no way to scale beyond the victim's own hardware. QUIETVAULT is a credential-theft variant. The JavaScript stealer exfiltrates GitHub and NPM tokens to an attacker-controlled GitHub repo and then hands off the filesystem search for additional secrets to whatever AI CLI is already installed on the victim, so the stolen credentials are an active on-host AI session rather than a bare API key. Looking at the four main routes discussed in this post, LameHug/PROMPTSTEAL is the best example of the free-tier method, since it calls HuggingFace's Inference API directly. MalTerminal and PROMPTFLUX both use hardcoded API keys, but it's unclear where those keys came from, so they could fit into the free-tier, crypto-middleman, or stolen-keys categories. QUIETVAULT is a twist on the stolen-credential method, using an on-host AI session instead of just a key. PROMPTLOCK is different because it uses a local model and only works on one victim at a time, so it doesn't fit into the four main routes and isn't discussed further. Across four routes: offensive LLMs for sale, free-tier and keyless public APIs, hardcoded keys in distributed artifacts, and exposed LLM servers on victim infrastructure, the most durable access is the last one. The precondition for abuse is almost never a sophisticated exploit. It is an unauthenticated port facing the internet. AI is the defining technology of this moment. It extends what a single person or small team can do and accelerates work that used to take weeks. AI is being integrated into more and more areas, from personal agents and email writing to some vulnerability research. The wow factor is real. But an LLM server is still a service running on a host. It listens on a port, speaks a protocol, and has an attack surface. The failure modes in this report; misconfiguration, leaked credentials, unpatched CVEs, open ports, are the same ones that produced years of incidents on Docker, Kubernetes, cloud storage, Redis, Elasticsearch, and bare Linux servers. The tooling is new. The mistakes are not. Two things follow. The operator is still responsible for the basics: authenticate the service, keep it off the public internet unless there is a reason to expose it, patch the known CVEs, and audit what is running. These are not AI-specific requirements. They are the same ones we have been making for every networked service. An exposed Ollama instance serving a stranger's prompts is not a failure of the model or the vendor that shipped it. It is a failure of whoever put it on the internet without a password. You broke it. You pay for it. IOCs Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.

Apiiro CLI turns AI coding assistants into full-stack security engineers The Apiiro CLI brings the Apiiro platform to your terminal and to your AI coding assistants, giving them six native security capabilities: scanning, risk management, remediation, an AI security analyst (via Apiiro Guardian Agent), AI Threat Modeling, and prompt enrichment. It installs in seconds on macOS, Linux, and Windows via brew, direct download, or RPM. Apiiro CLI ships with agent skills, structured capability definitions that AI coding assistants like Claude Code and Cursor can read and invoke autonomously. These install with one simple command, npx skills add apiiro/cli-releases, and, once installed, give your AI assistants a clear understanding of what Apiiro can do, and invoke the right capability with the right software graph context. No memorized commands. No context switching. No dashboard. Just tell your AI assistant what you need: “Scan this repo for secrets before I push” “What security risks does this repo have?” “Threat model the feature I’m about to build” “Fix the critical risks in this service” – and security becomes part of the conversation. The traditional security workflow (find → report → ticket → fix) takes days to weeks. When vulnerabilities get exploited in minutes, that cycle length is unacceptable. But when security is built into the AI coding assistant, the loop becomes: enrich → prevent → verify. Security findings get surfaced within developer workflows, remediation time collapses, and vulnerable patterns are never generated in the first place. This prevention occurs at every commit, across every repo, without adding headcount. Six skills. Zero interruptions. Here are the six security skills that ship with Apiiro CLI: 1. Scan: Catch secrets and vulnerable dependencies Trigger: When the user mentions scanning code, secrets detection, or OSS vulnerabilities. Fast local scanning for leaked secrets and open-source vulnerabilities, with results in seconds. After your AI assistant generates code, it can run a scan on changed files, report any findings, and apply fixes, all before a single line reaches a commit. For CI/CD pipelines, diff-scan compares git references and blocks on critical findings, creating an auditable security gate whether the code was written by a human or an agent. Outcome: Secrets and known CVEs caught at the moment of generation, not weeks later in a ticket queue. 2. Risks: Your security risk inventory, in context Trigger: When the user asks about security risks, vulnerabilities, or findings. Your AI assistant queries Apiiro’s full risk inventory, filtered by severity, category, or finding type, and explains each finding in the context of your codebase. No dashboard. No spreadsheet. No context switch. Risk data reaches developers through the tool they already use, reducing mean time to remediate (MTTR) by transforming vulnerability investigation into part of the coding conversation. Outcome: Developers engage with security findings inside their workflow, not in a backlog they never open. 3. Fix: From finding to remediation in one flow Trigger: When the user wants to fix, remediate, or resolve a security risk. Apiiro’s risk intelligence connects to your AI assistant’s coding ability. It retrieves risk details, pulls remediation instructions tailored to the finding type, and applies the fix directly in your codebase. For secrets, it removes the exposure. For vulnerable dependencies, it upgrades to a patched version. For code-level findings, it rewrites the vulnerable pattern. When automated remediation isn’t available, it falls back to Apiiro Guardian Agent for guided advice, and applies the fix either way. Outcome: Remediation collapses from days to minutes, without requiring a developer to leave their IDE. 4. Guardian Agent: Your continuous AI AppSec engineer, operating 24/7 across the SDLC Trigger: When the user wants AI-powered security analysis or asks questions about codebase security. Guardian is Apiiro’s AI security agent. It knows your codebase, your dependencies, and your risk history. Its answers are specific to your repository, not generic advice. Ask it anything: “Is my auth implementation secure?” “What’s the attack surface of this service?” “How should I handle file uploads safely?” For security leaders, Guardian’s org-wide mode answers natural-language posture questions across all repositories: “What are our top critical risks this week?” No dashboards. No query languages. No waiting for a weekly report. Outcome: Every developer has an AppSec engineer on demand. Every security leader has instant, org-wide visibility. 5. AI Threat Modeling: Proactive security before a single line is written Trigger: When the user wants threat analysis or STRIDE review of a design or feature spec. Give the CLI a feature description, spec, or architectural change, and it returns a STRIDE-based threat analysis before code generation begins. This is prevention at its earliest possible point. The real power is chaining the threat-model with Apiiro Secure Prompt: describe a feature, receive a structured threat analysis, then feed those threats into Secure Prompt to generate security-hardened implementation requirements for each countermeasure. Outcome: Threat modeling shifts from a quarterly exercise to a per-feature habit, with zero additional overhead on the developer. The workflow becomes: describe → threat-model → secure-prompt → build. 6. Secure-Prompt: Write secure code from the first instruction Trigger: When the user wants to add security requirements to a coding task. Give the CLI a development task, and it returns that same task enriched with security requirements specific to your repo’s stack, dependencies, and known risk profile. The business intent is preserved, but security guardrails are added around it, before the AI agent writes a single line. Outcome: Vulnerable patterns are never generated in the first place. The cost to fix drops to zero. Practical outcomes For developers and AppSec practitioners, Apiiro CLI turns secure development into a trusted conversation with your AI coding agents. Once your assistants have access to Apiiro security capabilities, development scenarios can be secured in seconds with a simple secure prompt: AI is rewriting how software is built. Security platforms that weren’t designed for AI agents will become irrelevant because AI agents can’t interact with them. The Apiiro CLI is proof that being AI-native means more than using AI inside your platform. It means building a platform that AI can use. One where the AI agent that writes the code can also scan it, risk-assess it, threat-model it, and fix it, before it ever reaches production. Security should be easily accessible to the developer and visible to the leader. The CLI is how we make that real.

For a hobby project built in my spare time to provide a simple community service, Have I Been Pwned sure has, well, "escalated". Today, we support hundreds of thousands of website visitors each day, tens of millions of API queries, and hundreds of millions of password searches. We're processing billions of compromised records each year provided by breached companies, white hat researchers, hackers and law enforcement agencies. And it's used by every conceivable demographic: infosec pros, "mums and dads", customer support services, and, according to the data, more than half the Fortune 500 who are actively monitoring the exposure of their domains. So yeah, "escalated" seems fair! Amidst all the time spent processing data, we've been trying to figure out where to invest energy in building new stuff. In essence, data breaches are pretty simple: you've got a bunch of exposed email addresses attributed to a source, sitting next to a whole bunch of fields we describe with metadata. Our goal has always been to help people use this data to do good after bad things happen, and today we're launching a bunch of new features to do just that. So, here goes: New Features, New Plans In the beginning (ok, in "recent years"), there was one plan we referred to as "Pwned", and within that, there were various levels. For example, the entry-level plan has been "Pwned 1," and to this day, more than half our subscriptions are on it. That's "a coffee a month" for a simple service that, by the raw numbers, does precisely what most of our subscribers are looking for. These are typically small businesses that make a handful of API queries or monitor a domain or two with a few email addresses. It's simple, effective and... insufficient for larger organisations. So, we added Pwned 2, 3 and 4, and they all added more RPMs for email searches and more capacity for searching larger domains. Then we added Pwned 5, which added stealer log support, and somewhere along the way also added Pwned Ultra tiers for making large numbers of API requests. As a result, that one "plan" added more and more stuff at different levels and ultimately became a bit kludgy. Today, we're launching a bunch of new features to better support the volume and privacy needs of our subscribers, and we're shuffling our existing plans to help do this. Here's what they now look like: Core: The fundamentals, largely being what we already had and designed for entry-level use cases Pro: Contains a bunch of the new features designed for larger orgs and those searching domains on behalf of customers High RPM: The old "Ultra" plan levels, designed solely for making large volumes of requests to the email search API Enterprise: We've had this for many years now, and it's a more tailored offering So, that's the high-level overview. Let's now look at all the new stuff and everything that changes: Supporting MSPs Monitoring on Behalf of Third Parties For most people, this won't sound particularly exciting, but I'm putting it up front because I'll refer to it when describing the more important stuff shortly. In the past, we've had the following carve-out in our terms of use, namely, what you're not permitted to use the service for: the benefit of a third party (including for use by a related entity or for the purpose of reselling or otherwise making the Services available to any third party for commercial benefit) This excluded managed service providers from, for example, monitoring their customers' domains as part of their services. That clause has now been revised with the preceding text: unless you have purchased a Paid Service which expressly allows you to do so Which means we can now welcome MSPs to the Pro and High RPM tiers. They can't just take HIBP and use it to create a competing product (for obvious reasons, that's a pretty standard clause within many online services), but they can absolutely add it to the offerings they provide to their own customers. And we're adding new features to make it easier to do just that, for example: Automating Domain Verification Preserving privacy whilst still providing a practical, effective service has always been a balancing act, one I think we've gotten pretty spot on. But the hoops people have had to jump through for domain verification, in particular, have been cumbersome. An organisation wanting to add a bunch of its domains has had to go through the process one by one via the web interface, then verify control over them one by one. They'd spend a lot of time doing kludgy, repetitive work. Today, we're launching two new ways of adding domains in a much more automated fashion, and the first is the verifying via DNS API: Successfully adding a pre-defined TXT record to DNS is solid proof that whoever is attempting to search that domain genuinely controls it. As well as the old kludgy way of doing it in the browser, waiting for DNS to propagate, then coming back to the browser to complete the verification, we can now fully automate the process via API. Here's how it works: Call the HIBP API to generate the TXT record token Call the API on your DNS provider to add the token to the TXT record Call another HIBP API to validate that the token exists This is easily scripted in your language of choice, and you can enumerate it over as many domains as you like. You can also keep retrying step 3 above as often as needed when DNS takes a little while to do its thing. It's all now fully documented in the latest version of the API, and ready to roll. But what if you don't control the DNS? Perhaps it's a cumbersome process in your org, or you're an MSP monitoring your customers' domains, but you don't have control of DNS. That's where the verifying by email API comes in: We've long had a verification process that involves choosing one of several standard aliases on a domain to email a verification token to. You do this via the dashboard, grab the token sent to the email, paste it back into the dashboard and the domain is now verified. The new API makes that much easier, especially when multiple domains are being verified. Here's how it works: Call the HIBP API and specify one of the pre-defined aliases to send a verification email to Click the link in the email and approve the domain to be added to the requester's account And that's it. We see this being particularly useful for MSPs who can now send a heap of emails on their customers' domains, and so long as someone receives it and clicks the link, that's the verification process done. That API is also now fully documented and ready to roll and is accessible to all Pro plan subscribers. Auto-verifying Subdomains This one was just unnecessarily frustrating for larger customers who spread email addresses over multiple subdomains. Let's say a company owns example.com and they successfully verify control of it, but then they distribute their email addresses by region. They end up with addresses @apac.example.com and @emea.example.com and so on, and in the past, needed to verify each subdomain separately. Turns out we have 154 votes for this feature in User Voice, which is substantially more than I expected. So, in keeping with the theme of the Pro plan making it easier on larger orgs, anyone on that level can now add their apex domain, verify it accordingly, then go to town adding all the subdomains they want without the need for verifying each one. Bringing K-Anonymity Searches to the Masses Until today, every time you took out a subscription via the public website and started searching email addresses, it looked like this: GET https://haveibeenpwned.com/api/v3/breachedaccount/[email protected] Clearly, this involved sending the email address to HIBP's service. Whilst we don't store those addresses, if you're sending data to a service in this fashion, there's always the technical capability for us to see that piece of PII and associate it back to the requester via their API key. This approach is what we'll refer to as "direct email search". Let's now look at k-anonymity searches, and I'll break it down into a few simple steps: Start by creating a SHA-1 hash of the address to be searched, so for [email protected], that's: 567159D622FFBB50B11B0EFD307BE358624A26EE Take the first 6 characters of the hash and pass them to the new API: What's really important here is that those 6 characters are the only identifier sent to HIBP and they're completely useless in identifying which address was actually searched for (that link also explains why SHA-1 is perfectly reasonable for this)GET https://haveibeenpwned.com/api/v3/breachedaccount/range/567159 HIBP then responds with the suffixes of every hash we have that matches that prefix and for each one, the breaches it's appeared against: The prefix presently contains 393 suffixes, and if one of them matches the remaining characters of the hash of the full email address, you know that's the address you're looking for.{ "hashSuffix": "D622FFBB50B11B0EFD307BE358624A26EE", "websites": [ "Adobe", "Stratfor", "Yahoo", ... ] }, ... This is the same methodology we've been using for years with the Pwned Passwords search, and we're currently serving about 18 billion requests a month, so it seems that lots of people have easily gotten to grips with it. It's a pretty simple technical concept with great privacy attributes, and it's fully documented on the API page. K-anonymity searches are now available to all Pro and High RPM subscribers at the same rate limit as the direct searches. That rate limit is shared, so you can either make 100% of them to k-anon or 100% to the direct search or go 50/50. We're really happy with the privacy aspects of this API and we know it ticks a box a lot of orgs have been asking for. Unsmoothing the API Rate Limit Previously, when you took out a 10-request-per-minute API key, we implemented a rate limit of 1 request every 6 seconds. The same logic applied to all the higher-tier products, too, and the reason was simply to distribute the load across each minute more evenly or in other words, "smoothing" the rate at which requests were made. That was important earlier on as the underlying Azure infrastructure had to support that traffic, and sudden bursts could be problematic. But the other thing that was problematic is that people (quite reasonably) assumed that they could make 10 fast requests, wait a minute, then go again. This led to support overhead for us and customer frustration, and neither is good. With these latest updates, 10RPM (and all the other RPMs) is now implemented exactly as it sounds - 10 requests in any one-minute block. Here's our Azure API Management policy: In other words, we've "unsmoothed" it. You can hammer the service 10 times in quick succession, then wait a minute, and you won't see a single HTTP 429 "Too many requests" response. Equally, if you're on a 12,000 RPM plan (and you can actually send that many requests quickly!), you won't see an unexpected 429. We can do this now because of the way we serve a huge amount of content from Cloudflare's edge, unburdening the underlying infrastructure from sudden spikes. It's a little thing, but it'll solve a lot of unnecessary frustration for a bunch of people, including us. That's implemented across every single plan, too, so everyone benefits. We Just Wanna Go (Even) Fast(er) Here's our challenge today: how do we enable millions of people a day to search through billions of records with near instantaneous results... and do it affordably? They're somewhat competing objectives, but every now and then, we find this one neat trick that dramatically improves things. About 18 months ago, I wrote about how we were Hyperscaling HIBP with Cloudflare Workers and Caching. The basic premise is that, as people search the service, we build a cache in Cloudflare's 300+ edge nodes that includes the entire hash range just searched for (see the k-anon section above). We flush that out on every new breach load and as it builds back up to the full 16^6 possible cachable hash ranges, our origin load approaches zero and everything gets served from the edge. Almost, because we have the following problem I described in the post: However, the second two models (the public and enterprise APIs) have the added burden of validating the API key against Azure API Management (APIM), and the only place that exists is in the West US origin service. What this means for those endpoints is that before we can return search results from a location that may be just a short jet ski ride away, we need to go all the way to the other side of the world to validate the key and ensure the request is within the rate limit. Or at least we had that problem, which we've just solved with a simple fix. The quoted problem stemmed from the fact that, to ensure everyone adhered to the rate limit, we performed the APIM check before returning any data. That meant always waiting for packets to make a round trip to America, even when the data was cached nearby. But what we realised is that adhering to the rate limit can be eventually enforced; it really doesn't matter too much if a request or two in excess of the rate limit slips through, then we enforce it. The reason why that epiphany is important is that with that in mind, we can start returning data to the client immediately whilst doing the APIM check asynchronously. If the request exceeds the rate limit, Cloudflare will block subsequent requests until the client starts making requests within their limit. So, the rate limit check is no longer a blocking call; it's a background process that doesn't delay us returning results. What that means is a dramatic reduction in the time til first byte: That's almost a 40% reduction in wait time! It's an awesome example of how continuous investment in the way we run this thing yields tangible results that make a meaningful difference to the value people get from the service. Passkeys! Just one more thing... This is all new, all free and all available to everyone, whether they have a paid subscription or not. Remember when I got phished last year? I sure do, and I vowed to use that experience to maximise the adoption of passkeys wherever possible. So, putting my money (and time) where my mouth is, we've now launched passkeys as an alternate means of signing into your dashboard: This saves you needing a "magic" link via email on every sign-in, and whilst it doesn't constitute 2FA (the passkey becomes a single factor used to sign in), it massively streamlines how you access the dashboard. And because we never used passwords for access in the first place, the only account-takeover risk our customers face is someone gaining access to either their email account or to where they store their passkeys (in either case, they have much bigger problems!). Here's how it works: start by signing into your dashboard, then heading over to the "Passkeys" section on the left of the screen and adding a new one: The name is so you can keep track of which passkey you save where. I save most of mine in 1Password, but you can also save them on a physical U2F key or in your browser, for example. Clicking "Continue" will cause your browser to prompt you for the location where you'd like to store it and again, that's 1Password for me: And that's it - we're done! So, how does it work? Check this out, and don't blink or you'll miss it: Compared to typing in your email address, hitting the "Sign In" button, flicking over to the mailbox, waiting for the mail to arrive, then clicking the link, we're down from let's call it 30 seconds to about 3 seconds. Nice 😎 Even though there isn't much security benefit to doing this on HIBP (you can still sign in via email, too), we wanted to build this as an example of just how easy it is. It took Stefán about an hour to build a first cut of this (with support from Copilot), and, aside from the dev time, building passkey support into your website is totally free. There are no external services you need to pay for, no hardware to buy or special crypto concepts to grasp. Passkeys are dead simple, and web developers with even a passing interest in security and usability should be adding support for them right now. We also wanted to make sure they were freely available to anyone, regardless of whether you have a paid subscription, because security like this should be the baseline, not a paid extra. So, go and give them a go in HIBP now. And just in case you want to really geek out on how passkeys work, Stefán presented this at NDC Security in Oslo earlier this month: All the Plans and Future Changes for Existing Subscribers It's easiest just to see the whole overview all in one image (or jump over to the pricing page on the website), and it largely reflects everything described above: One immediate difference to how we've previously represented the plans is that the annual price is now shown as a monthly figure. It turns out that the vast majority of our subscribers choose annual billing, so leading with the per-month pricing puts the least relevant figures front and centre. As we looked around at other services, that was a pretty consistent trend, especially when one annual subscription is more cost-effective than renewing a monthly one 12 times (annual is roughly 10x a year's worth of month-by-month payments). Another change is that we're going to cap the number of larger domains (those with over 10 breached addresses) that can be searched on each subscription. Let me explain why: Every time we load a data breach, each record in the breach is checked against each domain being monitored. In 2025, we added 2.9 billion breached records, and we have 400k monitored domains. Multiply those out, and we're looking at 1.16 quadrillion checks for our subscribers each year. This is all handled by SQL queries, so it's not like we're getting hit with human overhead at scale, but we're getting hit hard with SQL costs. Across everything we pay to run this service (storage, app hosting, functions, API management, App Insights, bandwidth, etc.), the SQL bill is more than the total for all other services combined. In addition to how we currently calculate plan size based on breached email count, we're adding a cap on the number of domains per plan. Only domains with more than 10 breached addresses are included in the cap. The “10” threshold aligns with the existing requirement for a domain to need a subscription at all, and means this change impacts only a single-digit percentage of subscribers. It also helps filter out noise so the cap reflects domains that actually matter. For those larger domains beyond the cap, all current alerts will continue to work just fine until they run a search. At that time, they'll have the option to upgrade the plan or reduce the number of domains. But none of that affects existing subscribers now: There will be no changes to existing plans until at least August 2 this year. We do an annual price revision each August, and that's already factored into the table above. That applies to any new subscriptions immediately, but it won't touch existing ones until August 2 at the earliest. The revised pricing only kicks in on the next subscription renewal after that date, so it could be as late as August 2027 if you're an existing subscriber. The same goes for the cap on the number of domains being monitored - there's no impact on existing subscribers until at least August. That leaves plenty of time to cancel, downgrade, upgrade, or just do nothing, and the plan will automatically roll over to the new one. We'll be emailing everyone in the coming days with details of precisely what will change. Note: if you had an old Pwned 5 subscription for the sake of stealer log access, we'll be rolling all those folks over to Pro 1 and applying a permanent discount code to ensure there's no change in price by moving to the higher plan (it'll actually drop slightly). That'll be explained in the upcoming email, it just made more sense to keep stealer logs in Pro and move people over, and this'll just give them free access to all the new stuff too. Speaking of which, the thing that (almost) nobody reads but everyone is subject to has been revised to reflect the changes described above - the Terms of Use. For the first time, we've also summarised all the changes and linked through to an archive of the old ones, so if you really love digging through a long document prepared by lawyers, this should make you happy 😊 We're Still Doing Credit Cards via Stripe While I'm here, just a quick comment on our ongoing Stripe dependency and, as a result, the necessity to pay for public services via credit card. I've written before about some of the challenges we've faced with customers' requests to pay by other means and how, push comes to shove, they (almost) always find a way around internal barriers. Let me share a recent empirical anecdote about this: Just the other day, I had a call with a Fortune 500 company that was initially interested in our enterprise services. As the discussion unfolded, it became evident that the public services would more than suffice and that the enterprise route was too burdensome for their particular use case. Be that as it may, the procurement lady on the call was adamant that payment by credit card was impossible, even going to the extent of making a pretty bold statement: No Fortune 500 company is going to pay for services like this via credit card! O RLY? If only I had the data to check that claim... 😊 Based on a list of their domains, 132 unique Fortune 500 companies have paid for our services by credit card. The real number will be higher because many more of their domains are not on that list, or purchases have been made via an email address not on the corporate domain. Let's call it somewhere between a quarter and a third of the Fortune 500 who've puschased direct via the world's most common payment method. In other words, a significantly different number from the "zero" claim. I've dropped the hard facts here out of both frustration from our dealings with unnecessarily artificial barriers and in support of the folks out there who, just like me in my corporate days, had to deal with "Neville" in procurement. Per that linked blog post, push back against "corporate policy" prohibiting payment by card, and statistically, you'll likely find you're not the 1 in 160 who can't make a simple payment. Summary We're continuing to massively invest in expanding HIBP in every way we can find. Nearly 3 billion additional breached records last year, hundreds of billions of free Pwned Passwords queries during that time, a bunch of new tweaks and features everyone gets access to and, of course, all the new stuff we've rolled into the higher plans. These new features are the culmination of a huge volume of work dating back to November, when I took this pic of our little team during our planning meeting together in Oslo. We all hope it helps people use our Have I Been Pwned services to do more good after bad things happen.

Unit 42 stopped monitoring this threat and updating the brief on March 24, 2026. Please refer to Ivanti’s website for the latest information. Two critical zero-day vulnerabilities (CVE-2026-1281 and CVE-2026-1340) affecting Ivanti Endpoint Manager Mobile (EPMM) are being actively exploited in the wild, affecting enterprise mobile fleets and corporate networks. These vulnerabilities allow unauthenticated attackers to remotely execute arbitrary code on target servers, granting them full control over mobile device management (MDM) infrastructure without requiring user interaction or credentials. Unit 42 has observed widespread exploitation of these vulnerabilities, including: Establishing a reverse shell Installing web shells Conducting reconnaissance Downloading malware This campaign also affected the following sectors in the United States, Germany, Australia and Canada: State and local government Healthcare Manufacturing Professional and legal services High technology Due to the severity of the threat, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-1281 to its Known Exploited Vulnerabilities (KEV) Catalog. Threat actors are accelerating operations, moving from initial reconnaissance to deploying dormant backdoors designed to maintain long-term access even after organizations apply patches. Palo Alto Networks Cortex Xpanse has identified the presence of over 4,400 EPMM instances in our telemetry. Palo Alto Networks customers are better protected from CVE-2026-1281 and CVE-2026-1340 through the following products: Advanced URL Filtering and Advanced DNS Security Cortex Xpanse Next-Generation Firewall with the Advanced Threat Prevention security subscription Palo Alto Networks also recommends referring to Ivanti’s security advisory, released in January 2026. Ivanti recommends in their security advisory to apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. The RPMs are version-specific, not vulnerability-specific. No downtime is required to apply the patch, and Ivanti is not aware of any feature functionality impact with this patch. More details can be found in the Interim Guidance section. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk. CVE-2026-1281 (CVSS 9.8) is a critical remote code execution (RCE) vulnerability in Ivanti EPMM. The vulnerability lies in legacy bash scripts used by the Apache web server to handle URL rewriting. The vulnerable component in Ivanti EPMM uses Apache RewriteMap configurations that point to bash scripts located at /mi/bin/map-appstore-url. These scripts are designed to process URLs for the In-House Application Distribution feature. The flaw is a specific type of code injection that uses bash arithmetic expansion. The exploitation process works by tricking the bash script into evaluating a variable that contains a malicious command. This process consists of the following phases: Input manipulation: The attacker sends an HTTP GET request to an endpoint like /mifs/c/appstore/fob/.... Variable pointing: The attacker sets the st parameter to the string theValue (padded with spaces to meet length requirements). The script assigns this input to a variable named gStartTime. Payload injection: The attacker sets the h parameter to include the malicious command wrapped in an array index, such as gPath['sleep 5']. The script assigns this to the variable theValue. Execution: The script attempts to compare gStartTime (which is now the string theValue) against the current time using an arithmetic evaluation (if [[ ${theCurrentTimeSeconds} -gt ${gStartTime} ]]). Expansion: Because gStartTime points to theValue, bash resolves theValue. Inside theValue, the attacker has embedded a command substitution (the array index). Bash executes the command (e.g., sleep 5 or a reverse shell) while resolving the array index. CVE-2026-1340 (CVSS 9.8) impacts the Ivanti Android File Transfer mechanism. Although the root cause (unsafe bash script usage) is the same as CVE-2026-12821, they reside in two distinct scripts (map-appstore-url vs. map-aft-store-url) handling different features. This vulnerability is triggered via HTTP GET requests to endpoints beginning with /mifs/c/aftstore/fob/. Unit 42 has observed widespread and mostly automated exploitation attempts of CVE-2026-1281 and CVE-2026-1340. We have seen the following command to target vulnerable Ivanti EPMM servers via the following URL pattern shown below in Figure 1. In some instances, attackers attempted to bypass authentication on Ivanti's MobileIron platform and immediately download and run a second-stage payload (the /slt script). This second stage typically installs a web shell, a cryptominer or a persistent backdoor to grant the attacker control of the appliance. Figure 2 below shows an example of the URL and subsequent commands seen during an attempt. We observed attackers downloading a Nezha monitoring agent, an open-source server monitoring utility. They downloaded this tool with specific parameters to fetch from Gitee if the victim’s location is China, ensuring the largest possible victim base irrespective of location. Figure 3 below shows the command to download the Nezha agent. In many cases, we observed attempts to execute reverse shells by injecting commands establishing outbound connections to a listening post. Figure 4 below shows examples of these attempts. We also observed attackers issue sleep commands in attempts to determine whether the server targeted was vulnerable to exploitation. This is a simple method of testing if the server will pause for five seconds. If the connection hangs for exactly five seconds before returning an error (e.g., a 404 error), the attacker knows they have achieved RCE and will follow up immediately with malicious payloads. Figure 5 shows examples of commands for the reconnaissance attempts. We observed threat actors attempt to install a lightweight JSP web shell with names like 401.jsp, 403.jsp and 1.jsp at filepath /mi/tomcat/webapps/mifs/ across various intended targets. In these cases, if the web server is running as root or Administrator, the attacker would gain administrative control of the server. Figure 6 below shows an example of these JSP web shells. A January 2026 Ivanti security advisory recommends their customers apply either RPM 12.x.0.x or RPM 12.x.1.x, depending on their version. Customers do not need to apply both RPMs as they are version-specific, not vulnerability-specific. No downtime is required to apply this patch, and the company is not aware of any feature functionality impact with this patch. Ivanti’s recommendation remains the same: Customers who have not yet patched should do so immediately, and then review their appliance for any signs of exploitation that may have occurred prior to patching. Applying the patch is the most effective way to prevent exploitation, regardless of how IOCs change over time, especially once a POC is available. The patch requires no downtime and takes only seconds to apply. Ivanti has provided customers with high‑fidelity indicators of compromise, technical analysis at disclosure, and an Exploitation Detection script developed with NCSC‑NL, and continues to support customers as they respond to this threat. The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation. If Ivanti EPMM logs are being ingested into Cortex XDR or XSIAM, the following query can be used to identify signs of exploitation. To do so, the dataset name will need to be specified within the dataset stage. The rapid weaponization of these vulnerabilities demonstrates that the window between disclosure and mass exploitation has effectively collapsed, with opportunistic attackers integrating new CVEs into automated scanning frameworks within hours. While these types of attacks lack precision, successfully compromising unpatched edge devices at scale makes them high-risk assets unsecured by patching cycles alone. Organizations with internet-facing management interfaces should adopt an assumed breach mentality and treat detection of any indicators as potential compromise with possible deeper persistence and lateral movement. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Palo Alto Networks customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available. Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat. Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks via the following Threat Prevention signature: 96919. Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious. Cortex Xpanse has the ability to identify exposed Ivanti EPMM devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that they’ve enabled the Ivanti Endpoint Manager Mobile (MobileIron Core) Attack Surface Rule. Identified findings can be viewed in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module. While there are no known indications of the exploitation of this vulnerability within cloud infrastructure, Cortex Cloud customers are better protected from, and can detect and remediate, vulnerable cloud infrastructure by using Cortex Cloud’s vulnerability monitoring. Additionally, the proper placement of Cortex Cloud XDR endpoint agent and serverless agents within a cloud environment helps detect and prevent the malicious operations, configuration alterations or exploitations at runtime providing sustained defenses of the cloud environment. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 23[.]227[.]199[.]80 (Port 443) 64[.]7[.]199[.]177 (Ports 10882, 18899) 83[.]138[.]53[.]139 84[.]72[.]235[.]18 (Port 443) 86[.]106[.]143[.]200 (Port 443) 91[.]193[.]19[.]12 (Port 443) 107[.]173[.]231[.]201 (Port 6666) 130[.]94[.]41[.]206 (Ports 8082, 10808) 138[.]226[.]247[.]241 144[.]172[.]106[.]4 146[.]70[.]41[.]193 (Port 443) 152[.]32[.]173[.]138 158[.]247[.]199[.]185 (Port 80) 185[.]173[.]235[.]232 192[.]242[.]184[.]234 193[.]242[.]184[.]234 (Port 443) 194[.]78[.]67[.]253 (Port 443) 198[.]13[.]158[.]58 (Port 8443) 204[.]251[.]198[.]205 (Port 443) [subdomain].gobygo[.]net [subdomain].introo[.]sh [subdomain].ngrok-free[.]app [subdomain].main[.]interacth3[.]io [subdomain].ddns[.]1433[.]eu[.]org [subdomain].oast[.]live [subdomain].oast[.]me [subdomain].oast[.]site [subdomain].eyes[.]sh [subdomain].requestrepo[.]com [subdomain].ceye[.]io interact[.].gateway[.]horizon3ai[.]com hxxp://152[.]32[.]173[.]138/U26d86f1899513347.5b5b0c1b hxxp://64[.]7[.]199[.]177:18899 zeetcckhtudizieudqyck5o4ez16y973h[.]oast[.]fun/ hxxp://152[.]32[.]173[.]138/U5213b63dda61af48.0F3Ab3D3 hxps://e598292a5fbd[.]ngrok-free[.]app/ /mi/tomcat/webapps/mifs/401.jsp /mi/tomcat/webapps/mifs/403.jsp /mi/tomcat/webapps/mifs/1.jsp agent[.]sh /mi/tomcat/webapps/mifs/css/test.css /mi/tomcat/webapps/mifs/css/poc.css /mi/tomcat/webapps/mifs/css/cssaaa.css /mi/tomcat/webapps/mifs/css/login.css Updated Feb. 23, 2026 at 9:45 a.m. PT to update Indicators of Compromise section. Updated Feb. 23, 2026 at 11:56 a.m. PT to update Indicators of Compromise section and update Figure 2. Updated April 1, 2026 at 1:35 p.m. PT to indicate Unit 42 stopped monitoring this threat.

Update: The article initially listed the wrong CVEs. This has now been corrected to list the CVEs: CVE-2026-1286 and CVE-2026-1340 Threat intelligence observations show that a single threat actor is responsible for most of the active exploitation of two critical vulnerabilities in Ivanti Endpoint Manager Mobile (EPMM), tracked as CVE-2026-1281 and CVE-2026-1340. The security issues have been flagged as actively exploited in zero-day attacks in Ivanti's security advisory, where the company also announced hotfixes. Both flaws received a critical severity rating and allow an attacker to inject code without authentication, leading to remote code execution (RCE) on vulnerable systems. A single IP address hosted on bulletproof infrastructure is responsible for over 83% of exploitation activity related to the two vulnerabilities, says threat-focused internet intelligence company GreyNoise. Between February 1st and 9th, the monitoring platform observed 417 exploitation sessions originating from 8 unique source IP addresses, and centered on CVE-2026-1281 and CVE-2026-1340. The highest volume, 83%, comes from 193[.]24[.]123[.]42, hosted by PROSPERO OOO (AS200593), which Censys analysts marked as a bulletproof autonomous system used to target various software products. A sharp spike occurred on February 8, with 269 recorded sessions in a single day. The figure is almost 13 times the daily average of 22 sessions, GreyNoise noted. Of the 417 exploitation sessions, 354 (85%) used OAST-style DNS callbacks to verify command execution capability, pointing to initial access broker activity. Interestingly, several published indicators of compromise (IoCs) include IP addresses for Windscribe VPN (185[.]212[.]171[.]0/24) present in GreyNoise telemetry as scanning Oracle WebLogic instances, but no Ivanti exploitation activity. The researchers note that the PROSPERO OOO IP address they saw "is not on widely published IOC lists, meaning defenders blocking only published indicators are likely missing the dominant exploitation source." This IP is not limited to Ivanti targeting, as it simultaneously exploited three more vulnerabilities: CVE-2026-21962 in Oracle WebLogic, CVE-2026-24061 in GNU Inetutils Telnetd, and CVE-2025-24799 in GLPI. The Oracle WebLogic flaw had the lion’s share in session volumes, dwarfing the rest with 2,902 sessions, followed by the Telnetd issue with 497 sessions. Exploitation activity appears fully automated, rotating between three hundred user agents. Ivanti's fixes for CVE-2026-1281 and CVE-2026-1340 are not permanent. The company promised to release complete patches in the first quarter of this year, with the release of EPMM version 12.8.0.0. Until then, it is recommended to use RPM packages 12.x.0.x for EPMM versions 12.5.0.x, 12.6.0.x, and 12.7.0.x, and RPM 12.x.1.x for EPMM versions 12.5.1.0 and 12.6.1.0. The vendor notes that the most conservative approach is to build a replacement EPMM instance and migrate all data there. Instructions on how to do that are available here. Update [February 15th]: An Ivanti spokesperson told BleepingComputer that the company's recommendations include immediate patching and checking appliances for signs of exploitation. "Applying the patch is the most effective way to prevent exploitation, regardless of how IOCs change over time, especially once a POC is available. The patch requires no downtime and takes only seconds to apply. "Ivanti has provided customers with high fidelity indicators of compromise, technical analysis at disclosure, and an Exploitation Detection script developed with NCSC NL, and continues to support customers as we respond to this threat." Update [February 15th]: Article edited to correct two Ivanti vulnerabilities erroneously listed as exploited in the campaign observed by GreyNoise Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

CVE-2025-8904 - Issue with Amazon EMR Secret Agent component Bulletin ID: AWS-2025-017 Scope: AWS Content Type: Important (requires attention) Publication Date: 2025/08/13 10:00 AM PDT Description: Amazon EMR is a managed cluster platform that simplifies running big data frameworks on AWS to process and analyze vast amounts of data. We identified CVE-2025-8904, an issue in the Amazon EMR Secret Agent component. The Secret Agent component securely stores secrets and distributes secrets to other Amazon EMR components and applications. When using Amazon EMR clusters with one or more Lake Formation, Apache Ranger, runtime role, or Identity Center feature that uses this component, Secret Agent creates a keytab file containing Kerberos credentials. This file is stored in the /tmp/ directory. A user with access to this directory and another account can potentially decrypt the keys and escalate to higher privileges. We implemented a fix that removes /tmp/ as a staging directory for Kerberos credentials, eliminating the possibility of users accessing the keytab file. The fix is available in Amazon EMR release 7.5 and higher. Affected versions: Amazon EMR version 6.10 through 7.4 Resolution: This issue has been addressed in Amazon EMR version 7.5 and higher. We recommend upgrading to the latest version to incorporate the new fixes. For customers on Amazon EMR releases version 6.10 through 7.4, we strongly recommend running the bootstrap script and RPM files with the fix provided in the location. References: Please email [email protected] with any security questions or concerns.

Researchers demonstrated that smart buses, the transportation vehicles that incorporate various systems to improve safety, efficiency, and passenger experience, can be remotely hacked. The findings were described on Friday at the DEF CON hacker convention by Chiao-Lin ‘Steven Meow’ Yu of Trend Micro Taiwan and Kai-Ching ‘Keniver’ Wang of CHT Security, a Taiwan-based MSSP. The researchers started digging into the cybersecurity of smart buses after noticing that free Wi-Fi was available for passengers. An analysis showed that the same machine-to-machine (M2M) router was used both to provide free Wi-Fi to passengers and for in-vehicle systems used for Advanced Public Transportation Services (APTS) and Advanced Driver Assistance Systems (ADAS). The ADAS uses sensors, cameras, radar and LiDAR to assist drivers and prevent accidents. Its capabilities include collision warning, lane departure warning, speed limit indicator, and traffic sign recognition, as well as passenger and driver monitoring for safety purposes. APTS consists of various components meant to increase the efficiency of public transport systems, such as GPS devices that provide an accurate location of the bus, interfaces for passengers and operators, route and schedule services, and panels installed at bus stops — all managed through a central system. The researchers were able to easily bypass the on-board router’s authentication and gained access to its administration interface. Since there was no network segmentation, they were then able to move to APTS and ADAS functionality. The experts discovered several vulnerabilities in these systems, including command injections and an MQTT backdoor that enabled remote access to the bus. Ultimately, Yu and Wang determined that a hacker could find vulnerable buses on the internet and launch remote attacks. “Once an attacker understands the protocol via packet analysis or similar methods, it is possible to perform attacks from the internet without needing to be physically present on the bus,” Yu told SecurityWeek. They demonstrated various scenarios, including how hackers could track the exact location of a bus or access the onboard camera, which is protected by easy-to-guess default passwords. According to the researchers, through these vulnerabilities hackers could manipulate on-board displays, steal passenger and driver information, and even access the transportation company’s servers. “The protocols in use (at least in Taiwan) do not implement any encryption or authentication, even by industry standards,” Yu explained. “This means if an attacker is able to conduct MITM (Man-In-The-Middle) attacks, they can directly modify or forge the content.” The researchers found that an attacker can connect to the bus’s systems and obtain information such as GPS location, engine speed (RPM), and the vehicle’s average speed. This data can be manipulated and the experts described several theoretical real-world attack scenarios. For instance, an attacker could change a vehicle’s GPS location, which would result in emergency response being delayed in case of an accident. A hacker can also falsify the RPM data to hide real mechanical problems or create spurious ones in an effort to cause disruption. Attackers can also falsify driver and vehicle state data to trigger false emergency or accident alerts. They could also set a false ‘out of service’ status to disrupt bus schedules and operations. The research was conducted on buses in Taiwan, but Yu told SecurityWeek that the vulnerable systems may be used in other countries as well, based on the fact that the vendor offers language options for Chinese, English, Japanese and Vietnamese. The researchers said they attempted to responsibly disclose their findings to affected vendors, including the maker of the router, US-based BEC Technologies, and the firm that provides intelligent transportation solutions for buses in Taiwan, Maxwin. However, they received no response and the vulnerabilities appear to remain unpatched. Trend Micro’s Zero Day Initiative (ZDI) has published several advisories to describe the vulnerabilities found in BEC routers. Related: Major Enterprise AI Assistants Can Be Abused for Data Theft, Manipulation