Indirect Prompt Injection via Third-Party Plugins

Indirect prompt injection is a flaw baked into how large language models work, and third-party chatbot plugins are turning that flaw into a live, exploitable pathway. An attacker doesn't need to trick a user into typing anything malicious. They just need to plant text somewhere an AI agent will read it later (a product review, a GitHub issue, a calendar invite) and wait.

The distinction from direct injection matters. When a user knowingly feeds a model adversarial text, there's at least a human in the loop who could catch it. Indirect injection skips that step. The malicious instruction sits inside a webpage, an email, or a document the agent pulls in during normal operation, and by the time anyone notices, the model has already acted on it.

How third-party plugins create the retrieval pathway attackers exploit

Third-party chatbot plugins exist because most website builders aren't LLM engineers. These plugins sit between a commercial LLM API and a customer's site, letting a small business bolt on a chatbot without writing a line of model integration code. That convenience carries a cost: the same low barrier to entry that makes these plugins popular also means security gets treated as an afterthought.

This isn't new, either. Third-party plugins have a long history of shipping with XSS and SQL injection holes, mostly because the people building them optimize for features over hardening. Prompt injection just rides in through that same loose integration.

Kaya, Landerer, Pletinckx, Zimmermann, Kruegel, and Vigna ran the first large-scale look at this ecosystem, covering 17 plugins deployed across more than 10,000 public websites. The ecosystem grew nearly 50% in 2025 alone, so the attack surface expanded faster than anyone's security practices could keep pace.

Two failure patterns stood out. Eight of the plugins, covering roughly 8,000 websites, send conversation history from the user's browser to the LLM with no integrity checks. That gap lets an attacker forge fake system-role messages, which the study found boosts the impact of direct injection attacks by 3 to 8 times. The second pattern compounds it: 15 of the 17 plugins scrape the web indiscriminately to feed retrieval-augmented generation (RAG) pipelines. A store's own product descriptions and a stranger's customer review land in the same context window with the same apparent authority. Once they're both sitting in that window, neither the plugin nor the model can tell which one to trust.

Most of these plugins also skip low-privilege roles when inserting external data into the LLM's context. That matters because model-level defenses assume role-based isolation is already in place upstream. When the plugin doesn't enforce it, the model never gets the chance to.

The study's manual audit found that about 13% of e-commerce websites had already exposed their chatbots to third-party content at the time of research. That's a live baseline, not a hypothetical sitting in a lab somewhere.

Because a retrieval system pulls in whatever matches the query, legitimate content and injected instructions alike, since it has no mechanism to tell the two apart, RAG is the structural crack here. Attackers have adapted with a technique researchers call "RAG spraying," seeding dozens or hundreds of documents or emails with the same injected instruction and betting that at least one gets pulled into a future retrieval.

The payload delivery techniques attackers use once the retrieval path is open

Once the retrieval path is open, the real question is how attackers smuggle instructions past a human reviewer's eyes. Palo Alto Networks' Unit 42 catalogued 22 distinct payload-delivery techniques observed in live abuse, not lab demonstrations dreamed up by researchers.

Concealment comes first. Zero-sized fonts and text pushed off-screen sit in the page's DOM, invisible to someone scrolling through but fully readable to a model parsing the raw content. White text on a white background does the same job with less code. HTML comments carry instructions that never render. Base64-encoded blocks assemble into readable text only at runtime, long after a human reviewer has signed off on the page.

Then comes social engineering aimed at the model instead of a person. Unit 42 found that 85% of observed attacks used phrasing along the lines of "this is a security update," a framing that nudges the model into treating injected text as a higher-priority instruction than whatever task it was originally given. Separate research from a cloud security research group flagged shared trigger phrases, things like "ignore previous instructions" or "if you are an LLM," appearing across completely unrelated domains. That points to shared toolkits circulating among attackers, not independent invention happening in isolated corners of the internet.

The injection point extends beyond webpages. PDFs, calendar invites, email bodies, GitHub issue titles, even code comments: any content type an agent ingests is a candidate. If a model reads it, an attacker can write to it.

IterInject, described by Chen and colleagues in an arXiv paper from May 2026, closes the loop between attempt and refinement. A rule-based diagnoser labels whether an injection succeeded or failed, and an LLM-based optimizer rewrites the payload based on that outcome. Against undefended models, this pushes success rates into a range of 33% to 90%, depending on the target. Against defended models the rates drop substantially, but the mechanism itself, an attacker that learns from its own failures, should worry people more than any single percentage.

What are attackers actually trying to accomplish once a payload lands? Unit 42's telemetry breaks it down: 28.6% of observed payloads just push irrelevant output, a kind of low-grade sabotage. 14.2% attempt data destruction. 9.5% try to bypass AI-based content moderation specifically. That spread, from nuisance to genuinely destructive, says this isn't a single-purpose exploit class.

None of these payloads leave behind what traditional security tooling knows how to look for. No malware hash, no suspicious file download. Standard EDR and SIEM systems are, for the most part, simply blind to this.

What the documented incidents reveal about real-world impact

EchoLeak, tracked as CVE-2025-32711 and affecting Microsoft 365 Copilot, is the clearest illustration of what this looks like in production. Aim Security disclosed it in June 2025, and It was assigned a CVSS score of 9.3. The attack was zero-click: a single crafted email, no user interaction required.

The attack chain strung together several bypasses at once. It evaded Microsoft's XPIA classifier, built specifically to catch cross-prompt injection attempts, got around link redaction using reference-style Markdown formatting, exploited auto-fetched images, and abused a Teams proxy the content security policy happened to allow. The classifier failed to flag the injected instructions, leaving the attack chain intact.

What was at risk? Anything sitting in Copilot's context window: emails, Teams messages, OneDrive files, SharePoint content, Office documents. EchoLeak stands as the first documented case of prompt injection weaponized for actual data exfiltration in a production AI system, and it exposes a structural risk present in any RAG-based enterprise assistant, not just this one product. Microsoft pushed a server-side patch in May 2025, publicly disclosed through the June 2025 Patch Tuesday cycle. No customer action was needed, and no in-the-wild exploitation has been confirmed.

A second incident, disclosed in February 2026 by researcher Adnan Khan and nicknamed Clinejection, shows the same mechanic reaching into software supply chains. A single malicious GitHub issue title served as the entry point, with no repository access needed. The attack chained indirect prompt injection with GitHub Actions cache poisoning and weaknesses in credential handling, and the payoff was exfiltrated publishing credentials for npm, the VS Code Marketplace, and OpenVSX.

On February 17, 2026, those stolen credentials were used to publish a tampered Cline CLI package to npm. A covert postinstall script quietly installed an unauthorized AI agent, called openclaw, on roughly 4,000 developer machines before the package got pulled. Khan filed a GitHub Security Advisory on January 1, 2026, and heard nothing back for five weeks before going public on February 9. Once public, Cline patched the issue in about 30 minutes. That gap between filing and fix says the disclosure pipeline, not the fix itself, is where the real delay lives.

A third case, disclosed June 1, 2026 by researcher RyotaK at GMO Flatt Security, hit the Claude Code GitHub Action. A function called checkWritePermissions trusted any GitHub App actor without question, and combined with access to /proc/self/environ, that let an attacker steal OIDC tokens and compromise the full repository supply chain. It was fixed in claude-code-action v1.0.94, carried a CVSS v4.0 score of 7.8, and earned a $3,800 bounty plus a $1,000 bonus, $4,800 total. Separate research from Aikido Security, published under the name "PromptPwnd," identified at least five Fortune 500 companies running misconfigured AI agent workflows consistent with this same vulnerability class.

Unit 42's report adds the web-based angle. Researchers observed real payloads triggering actual Stripe and PayPal payments, deleting database records, leaking system prompts, and approving scam advertisements. In one case, an attacker planted 24 separate injection attempts inside a single webpage to get an AI-based ad reviewer to approve a scam product, the first confirmed instance of an in-the-wild ad-review bypass. Elsewhere, LLM-powered scrapers got tricked into emailing internal data straight to attackers through hidden footer text, and recruitment systems got nudged toward attacker-preferred candidates through off-screen text buried in resumes.

Zooming out across incidents reveals a pattern that stands out: of eight major AI incidents documented by an industry security group between January and April 2026, only one received a CVE. The rest came from misconfiguration, excessive agency granted to the AI, supply-chain failures, or prompt injection itself. The standard vulnerability-tracking system misses most of what's actually happening in this space. Anyone relying on CVE counts to gauge exposure is working from a number that undercounts reality by a wide margin.

Scale and trajectory of the threat: from theoretical to operational

Google's security researchers crawl somewhere around 2 to 3 billion web pages a month, and their data shows malicious indirect-injection content grew 32% in relative terms between November 2025 and February 2026. Attackers gravitate toward parts of the web that are cheap to post on and rarely moderated.

Neither Google's team nor other researchers scanning public web infrastructure found evidence of one big, centralized campaign running the show. What they found instead were shared injection templates on completely unrelated domains, which points to cheap, reusable tooling rather than a single coordinated actor. That's arguably the worse finding: persistent background pressure spread across the whole web is harder to defend against than one campaign with a fingerprint security teams can track and block.

Multi-hop indirect attacks, the kind that move through agents and chained tool calls rather than hitting a model directly, grew more than 70% year-over-year across 2025 and 2026 according to compiled statistics. Attack success rates, depending on model configuration, are between 50% and 84%, and adaptive techniques push past 85%. Those aren't edge-case numbers, and they shouldn't get treated as one.

The InjecAgent benchmark found that even GPT-4 running inside a ReAct agent framework was vulnerable somewhere between 24% and 47% of the time. Anthropic's own Claude Opus 4.5 system card showed indirect prompt injection success climbing with persistence: 4.7% at a single attempt, 33.6% at 10 attempts, 63.0% at 100 attempts, in agentic coding environments specifically. Attackers who can afford to keep trying, and most can, get better odds the longer they stay at it. A defense that holds at one attempt tells you almost nothing about what happens at attempt fifty.

Roughly 40% of AI agent frameworks carry exploitable prompt injection flaws in the logic that handles tool execution, and autonomous agents calling APIs on their own show substantially higher risk exposure than standalone chat models. Enterprise AI copilots wired into productivity tools showed data-exfiltration vulnerabilities in 60% of real-world red-team tests. In multi-agent systems, where several agents run together and hand off tasks, a single successful injection propagates to 48% of co-running agents. Lateral movement inside an agent mesh is a current, demonstrated risk. Testing has already recorded it.

OWASP's own documentation tells the same story from a different angle. OWASP's own documentation tracks the shift from emerging concern to active operational risk, reflecting what's actually happening on the ground.

Why existing defenses fall short

The main defense at the model layer is instruction hierarchy, a training-time mechanism that tells the model to trust system-role messages more than tool outputs or retrieved content. It works reasonably well when the plugin layer respects role boundaries. The UC Santa Barbara study found that 15 of the 17 plugins examined didn't respect those boundaries at all, which means the model's defense gets undermined before the model ever sees the malicious content. A lock on the front door doesn't do much good when the back door was never installed.

Classifier-based filtering runs into a related wall, and EchoLeak shows how it breaks. Microsoft's XPIA classifier got bypassed simply by phrasing instructions the way a human would write to another human: no mention of AI, no telltale injection syntax. A classifier trained to spot known attack patterns has nothing to grab onto when the attack doesn't look like an attack.

Application-layer controls fare no better once an attacker takes the time to study them. EchoLeak got around link redaction using reference-style Markdown, and it slipped past the content security policy through a Teams proxy the policy happened to allow. Layered controls help, but anyone patient enough to probe them can usually find the gap between layers.

Even done well, layered defenses reduce attack success rates from 73.2% down to 8.7% in testing, a real improvement worth taking seriously. But 8.7% residual success against a determined, high-volume attacker still isn't zero, and at scale that residual rate adds up to real incidents. IterInject's May 2026 results underline the point: its adaptive payloads achieved full success against 5 of 9 Claude Code targets even when those targets ran layered defenses. Static defenses built to catch known patterns lose to an attacker that adjusts its payload based on what failed last time.

There's also no forensic trail, which compounds every other weakness on this list. No malware hash, no suspicious download, nothing for EDR or SIEM tooling to flag. Incident response teams built around traditional malware indicators have no standard way to even confirm an attack happened, let alone trace how far it spread.

Then there's the disclosure gap, and it should bother security teams the most. According to the Cloud Security Alliance's review, Anthropic, GitHub, and Google all paid bounties for prompt-injection flaws found in Claude Code, Copilot Agent, and Gemini CLI Action, without issuing a CVE or a public advisory for any of them. That leaves downstream users with no standard artifact to check against, no way to look up whether they're exposed the way they'd check a CVE database for a traditional software flaw.

The numbers on unauthorized action are the ones that should really change how a security team thinks about monitoring. Tool misuse through prompt injection triggers unauthorized actions in 31% of evaluated agent scenarios, and more than 25% of vulnerable third-party integrations will execute unauthorized API calls when fed a malicious prompt. At that rate, watching for anomalies after the fact is a hope, not a plan.

Mitigation strategies that reduce exposure without waiting for a model-layer fix

None of this waits on a fix from the model providers, and treating it that way is itself a risk. The UC Santa Barbara study's clearest recommendation lands at the architecture level: enforce privilege separation at the plugin layer. Retrieved external content, scraped reviews, ingested documents, anything pulled from an untrusted source, should get inserted into the model's context at a low-privilege role, something like "tool," never at the system or user role. That's exactly the gap the study found in 15 of the 17 plugins it examined, and it's a gap a plugin's own developers can close without waiting for anyone upstream to move first.

Beyond that architectural fix, a handful of operational habits reduce exposure meaningfully. Segregating trusted from untrusted content changes how a plugin weighs sources: a product description written in-house and a customer review submitted anonymously should not sit in the same context window with equal weight. If a plugin can't tell them apart, replace it or wrap it with a filter that can.

RAG ingestion pipelines deserve their own security review. Given how RAG spraying works (seeding many documents and betting on retrieval odds), an organization scraping third-party content at volume should assume some fraction of what it pulls in is hostile, and build retrieval logic around that assumption rather than around good faith.

Watching for behavioral signatures matters too. Unit 42's catalog flags unexpected payment triggers, unusual database write attempts, and content that tries to reframe itself as a "system update" or authority instruction. None of that appears in a malware scanner, so it has to be visible somewhere else, in application logs, in anomaly detection tuned to agent behavior rather than file signatures.

None of these steps make the underlying problem disappear. One national cybersecurity agency said in December 2025 that prompt injection "may be a problem that is never fully fixed," because it grows out of how language models interpret language in the first place, not out of a discrete bug sitting in one function. That's a sober way to set expectations, and it's the right one. The mitigations above don't close the gap. They shrink the window an attacker has to work with, and given the trajectory of the numbers here, shrinking that window is the realistic goal for now.