How do attackers use cross-plugin request forgery?

How cross-plugin request forgery works in practice

Cross-plugin request forgery is an abuse of trust between tools, not a traditional browser-only forgery. A hostile prompt, poisoned plugin output, or malformed tool response can cause one plugin to submit an authenticated request to another plugin or backend service that it is allowed to reach. The attacker is exploiting delegated authority and the fact that the call looks legitimate to the receiving component.

This becomes especially dangerous when the plugin environment lets tools chain freely. The forged request can inherit the user’s session, the agent’s context, or a stored token, so the receiving plugin sees an authorised action rather than an attack. In agentic systems, that means the attack path is often indirect: the malicious content does not need direct network access, only a way to influence a tool that already does.

Because the request is routed through a trusted plugin path, defenders often miss the real boundary being crossed. The security question is not just whether a plugin is authenticated, but whether it should be allowed to invoke another tool, access another plugin’s endpoints, or relay a request on the user’s behalf without a fresh authorisation decision.

Why this attack path is attractive to attackers

Attackers prefer this technique because it turns a minor foothold, such as a prompt injection or untrusted plugin output, into a second-stage action that uses existing trust. They do not need to break the receiving service directly if they can coerce another plugin into doing the work for them.

That makes cross-plugin request forgery a useful escalation path for data access, workflow abuse, and unwanted state changes. A request can be crafted to look routine, yet still trigger sensitive actions such as reading records, exporting content, changing configuration, or reaching internal endpoints that were never meant to be callable in that sequence.

The most fragile environments are those that assume plugins are benign once installed. When an integration can call broad endpoints, reuse credentials, or pass arbitrary parameters downstream, the attacker gains a way to move from content influence to operational impact without ever needing the user to approve the exact action being taken.

What breaks if plugin boundaries are too loose

Loose plugin boundaries create confusion between who initiated the action, which tool is authorised to perform it, and whether the callee should trust the caller. The result is a delegated-action problem: one plugin becomes a proxy for another, and the proxy inherits capabilities that were never intended to be chained together.

LLM Security Guide discusses endpoint limits and output handling because the same failure mode appears whenever model or plugin output is allowed to drive privileged actions without sufficient checks. A well-designed system limits which tools can call which endpoints, separates read and write paths, and treats inter-tool requests as security-sensitive events.

Web Application Attacks Guide is relevant here because the control failure resembles CSRF and related request abuse patterns: an action is accepted because the application trusts the source of the request too much. The plugin layer adds another trust boundary, so the same principle applies, but across tools rather than only across web pages.

Risk and Threat Considerations

Cross-plugin request forgery can expose data, trigger unauthorised actions, or widen blast radius across otherwise separate integrations. The core risk is not only malicious content, but also overbroad inter-plugin trust that allows one compromised or manipulated tool to act as a bridge into another.

Failure mechanism: A plugin or agent accepts a crafted request from another plugin and forwards it with valid credentials, shared context, or implicit trust, so the receiving service processes an action that was never independently authorised.

Impact: Attackers can exfiltrate data, modify settings, invoke sensitive functions, or pivot into connected services, especially when tools can chain actions without per-call approval or endpoint restrictions.

Practitioner Guidance

What to prioritise: Treat tool-to-tool invocation as a privileged capability, not a convenience feature. The highest-value control is to constrain which plugins can call which endpoints, because the attack succeeds when trust is transferred automatically between components that should not share authority.

What to verify: Check whether every cross-plugin action has an explicit authorisation point, a narrow allowlist of callable endpoints, and a clear audit trail that identifies the originating tool as well as the final action. If the receiving plugin cannot distinguish a direct user action from a relayed one, the boundary is too weak.

Common mistake: Relying on “authenticated plugin” status alone. Authentication proves the caller has a session or token; it does not prove the caller should be allowed to exercise that privilege for this specific downstream action.

Practitioner takeaway: The practical defence is to make delegated tool use explicit, scoped, and revocable, so a compromised prompt or plugin output cannot freely transform one trusted plugin into an unchecked action broker.

Related resources from NHI Mgmt Group

• Cross-Plugin Request Forgery
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?