Insecure Plugin Design
LLM plugins that accept unvalidated free-text inputs and lack access control — enabling exploits up to and including remote code execution.
What it is
LLM plugins are extensions that, when enabled, are called automatically by the model during user interactions. They are driven by the model-integration platform, and the application may have no control over execution — especially when the model is hosted by another party.
Plugins often implement free-text inputs from the model with no validation or type-checking (to deal with context-size limits). This lets an attacker construct a malicious request to the plugin, resulting in undesired behavior up to and including remote code execution.
The harm often depends on insufficient access controls and the failure to track authorization across plugins: inadequate access control lets a plugin blindly trust other plugins and assume the end user provided the inputs. This item focuses on creating LLM plugins; third-party plugins are covered by LLM05.
Common examples
- A plugin accepts all parameters in a single text field instead of distinct input parameters.
- A plugin accepts configuration strings that can override entire configuration settings.
- A plugin accepts raw SQL or programming statements instead of parameters.
- Authentication is performed without explicit authorization to a particular plugin.
- A plugin treats all LLM content as being created by the user and performs requested actions without requiring additional authorization.
Prevention & mitigation
- Enforce strict parameterized input with type and range checks. Where freeform input is unavoidable, add a second layer of typed calls with validation and sanitization, and inspect carefully for harmful methods.
- Apply OWASP ASVS input validation and sanitization, and test thoroughly with SAST, DAST, and IAST in development pipelines.
- Follow OWASP ASVS access-control guidelines — least-privilege access and exposing as little functionality as possible.
- Use appropriate authentication identities such as OAuth2 for effective authorization; use API keys to provide context for custom authorization decisions reflecting the plugin route rather than the default interactive user.
- Require manual user authorization and confirmation of any action taken by sensitive plugins.
- Treat plugins as REST APIs and apply the OWASP Top 10 API Security Risks – 2023 recommendations.
Example attack scenarios
- A plugin accepts a base URL and combines it with a query to obtain data; a malicious user points the URL to a domain they control, injecting their own content into the LLM system.
- A plugin accepts unvalidated free-form input; an attacker performs reconnaissance from error messages, then exploits known third-party vulnerabilities to execute code and exfiltrate data or escalate privilege.
- A plugin retrieving embeddings accepts a connection string without validation; an attacker changes host parameters to access other vector stores and exfiltrate embeddings.
- A plugin accepts SQL WHERE clauses as advanced filters, allowing an attacker to stage a SQL attack.
- An attacker uses indirect prompt injection to exploit an insecure code-management plugin (no input validation, weak access control) to transfer repository ownership and lock the user out.
References
- OpenAI ChatGPT Plugins – Plugin Flow & Authentication: OpenAI Documentation
- Plugin Vulnerabilities: Visit a Website and Have Your Source Code Stolen: Embrace The Red
- ChatGPT Plugin Exploit Explained: Embrace The Red
- OWASP ASVS – Validation, Sanitization and Encoding: OWASP
- OWASP Top 10 API Security Risks – 2023: OWASP
How Neural Industries helps. We test, exploit, and remediate Insecure Plugin Design as part of a full OWASP LLM Top 10 assessment — then hand you the evidence to prove it.
Request an assessment →