In November 2023, researchers at Salt Security disclosed a set of vulnerabilities in OpenAI's ChatGPT plugin framework that could have let an attacker hijack a user's account and silently install malicious plugins capable of intercepting every message that user sent afterward — no suspicious click, no unusual login alert, nothing a security team would normally catch. The flaw wasn't in the language model itself. It was in the plumbing wrapped around it: an OAuth flow that trusted a plugin's own claims about which domain it controlled. That plumbing failure is precisely what OWASP labeled "insecure plugin design" — the pattern where an LLM's ability to call external tools, APIs, and functions gets bolted on without the input validation, authentication, and least-privilege controls that any production API would require. As enterprises hand copilots and agents the ability to query databases, move money, and execute code, the plugin layer, not the model, has become the most exploitable part of the stack.
What Is Insecure Plugin Design in LLM Applications?
Insecure plugin design is when a plugin or tool connected to an LLM accepts and acts on model-generated input without the validation, authentication, or scoping controls a traditional API endpoint would enforce, letting an attacker steer the model into misusing the plugin on their behalf. OWASP formalized this as LLM07 in its original 2023 Top 10 for LLM Applications, describing plugins that take free-text parameters instead of typed, validated inputs; that run with the full privileges of the developer instead of the invoking user; and that treat model output as a trusted instruction rather than untrusted, attacker-influenceable text.
The failure mode is a variant of the confused deputy problem that security engineers have chased since the 1980s, just with a probabilistic, prompt-injectable component in the loop. A plugin built to fetch a URL, run a SQL query, or send an email doesn't know the difference between "the user asked for this" and "a malicious document the model just summarized told it to do this." When OWASP refreshed its list in 2025, insecure plugin design didn't disappear — it was absorbed into "Excessive Agency" (LLM06) and "Improper Output Handling" (LLM05), because the same root cause — unvalidated, over-privileged tool invocation — had spread from a narrow plugin marketplace into every agentic framework on the market.
How Did ChatGPT's Plugin Ecosystem Expose These Flaws at Scale?
ChatGPT's plugin store exposed insecure plugin design at scale because it let hundreds of third-party developers wire arbitrary APIs into a single trusted chat interface within months of launching in May 2023, with no standardized security review of how each plugin handled authentication. Salt Labs' November 2023 research found that ChatGPT's own plugin installation flow could be manipulated to redirect a victim's OAuth approval to an attacker-controlled account, and that PluginLab, an authentication framework used by multiple third-party plugins including the code-review plugin AskTheCode, failed to verify that a returned user identifier actually belonged to the session requesting it — allowing account takeover on any plugin built on top of it.
Neither bug lived in GPT-4's weights. Both lived in the identity and authorization layer that plugin developers assembled in weeks to catch a wave of demand, the same shortcut that produces insecure design in any fast-moving API ecosystem. OpenAI has since retired the original plugin store in favor of GPTs and function calling, but the underlying lesson traveled forward: every framework that has since offered "give the model a tool" has had to relearn the same access-control lessons, usually the hard way.
Why Do LangChain and Agent Frameworks Keep Shipping Plugin CVEs?
LangChain keeps shipping plugin-adjacent CVEs because its tool-calling design encourages exactly the kind of implicit trust OWASP warned about, and its install base — tens of millions of monthly downloads across the Python and JavaScript ecosystems — turns every one of those flaws into a supply chain event. CVE-2023-36258 tracked a PALChain component that passed LLM-generated strings into Python's exec(), giving an attacker who could influence the prompt a path to arbitrary code execution on the host running the agent. CVE-2023-46229 tracked a server-side request forgery flaw in LangChain's web-loading tools, where an attacker-supplied or model-generated URL could bypass SSRF protections and reach internal network resources the developer never intended to expose.
Both issues follow the same shape as the ChatGPT plugin bugs: a tool built to be convenient — run this code, fetch this URL — trusted its input source more than it should have. Because LangChain and comparable agent frameworks are dependencies pulled into thousands of downstream applications via pip and npm, a single insecure default in a tool wrapper doesn't stay contained to one chatbot; it propagates through every application that imported that version, which is why these disclosures read less like isolated app bugs and more like the dependency-confusion and typosquat incidents software supply chain teams already track.
Did Moving to MCP Servers Fix the Insecure Plugin Problem?
Moving to Anthropic's Model Context Protocol, introduced in November 2024 as a standardized way to connect LLMs to external tools, did not fix insecure plugin design — it gave the same failure mode a new transport layer. In April 2025, researchers at Invariant Labs disclosed "tool poisoning" attacks against MCP servers, showing that a tool's description field, text most client applications never surface to the end user but that the model reads in full, could carry hidden instructions telling the model to exfiltrate SSH keys or environment variables while performing an unrelated, legitimate-looking task. The same research described "rug pull" attacks, where a tool behaves safely during review and then silently changes its own description or behavior after users have already approved it, and cross-server "shadowing," where a malicious MCP server rewrites how a client interprets calls to a completely different, trusted server.
MCP standardized the wire format for plugins; it did not mandate signing, provenance verification, or runtime behavior monitoring for the servers speaking that format. Enterprises that treat "we adopted MCP" as a security control are repeating 2023's ChatGPT-plugin mistake with a cleaner spec.
What Does an Insecure Plugin Actually Cost a Business?
An insecure plugin costs a business the same things any exploited API costs it — stolen credentials, exfiltrated data, and fraudulent transactions — except the attack path runs through a chat window instead of a login form, which means it often evades the monitoring built for traditional endpoints. A plugin with an SSRF flaw that can be pointed at a cloud metadata endpoint like 169.254.169.254 hands an attacker the IAM credentials of whatever workload is running the agent, turning a single crafted prompt into full cloud account compromise. A plugin with excessive scope — say, a support-ticket tool that can also query billing records because it shares a service account with other internal tools — turns a routine prompt injection in an incoming customer email into a confused-deputy data leak.
IBM's 2024 Cost of a Data Breach report put the global average breach cost at $4.88 million, and breaches involving unsecured or over-permissioned systems consistently sit above that average because remediation requires tracing every downstream system the compromised credential could touch. Plugin-mediated breaches inherit that same blast radius calculation, compounded by the fact that most organizations still have no inventory of which LLM tools exist, what scopes they hold, or which third-party services they call.
How Safeguard Helps
Safeguard treats LLM plugins and MCP servers the way it treats any other third-party dependency entering the software supply chain: as code and configuration that needs provenance verification, scoped permissions, and continuous monitoring, not a one-time approval. Concretely, that means:
- Plugin and tool inventory — Safeguard discovers every plugin, function definition, and MCP server wired into an application's LLM layer, closing the "we don't actually know what our agents can call" gap that shows up in nearly every incident above.
- Provenance and integrity checks — tool manifests and descriptions are fingerprinted and diffed on every deployment, so a rug-pull change to a tool's behavior or description after approval gets flagged instead of executing silently, the exact gap Invariant Labs' MCP research exposed.
- Least-privilege scope enforcement — Safeguard maps each plugin's declared capabilities against the credentials and network paths it actually holds, surfacing over-broad service accounts before they become the confused-deputy path attackers exploit.
- SSRF and injection-aware policy gating — outbound calls a plugin makes on the model's behalf are checked against allow-listed destinations, blocking the metadata-endpoint and internal-network pivots that turned LangChain's SSRF CVEs into full compromises.
- Dependency-chain visibility — because frameworks like LangChain ship as libraries, Safeguard tracks the CVE history and version drift of the agent frameworks themselves, alerting teams when a patched vulnerability like CVE-2023-36258 or CVE-2023-46229 is still present in a production build.
Insecure plugin design didn't disappear when OWASP folded it into other categories, and it won't disappear as vendors rebrand plugins into tools, functions, and MCP servers. The pattern is stable even as the terminology shifts: an LLM is being trusted to invoke code with real-world side effects, and that invocation needs the same supply chain discipline applied to every other piece of software an organization runs. Safeguard exists to make sure that discipline gets applied before the next Salt Labs-style disclosure has your company's name on it.