CVE-2025-46059: indirect prompt injection to RCE

CISO Take

Any LangChain agent with GmailToolkit enabled can be hijacked by a single crafted inbound email — no user interaction required beyond the agent checking the inbox. While LangChain disputes the root cause (blaming insecure user-written glue code), the practical risk is the same: untrusted email content flows directly into LLM context where it can trigger arbitrary tool invocations. Audit all agentic email workflows immediately, enforce input sanitization, and restrict tool permissions to least-privilege until a hardened implementation is verified.

What is the risk?

CVSS 9.8 reflects worst-case: network-reachable, zero privileges, no user click required once the agent is running. The supplier dispute introduces ambiguity — exploitability depends on how the GmailToolkit is wired in each deployment — but that does not reduce operational risk for organizations that shipped agents without explicit input sandboxing. LangChain's broad adoption in enterprise agentic workflows (RAG pipelines, email triage bots, AI assistants) makes the blast radius significant. Email is a universally accessible attack surface, lowering attacker cost to near zero.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 47% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

5 steps

IMMEDIATE

Audit all LangChain deployments using GmailToolkit or any email-reading tool. Disable or restrict auto-processing of inbound emails in production agents.
SHORT-TERM: Implement input sanitization/escaping of email content before passing to LLM context. Follow LangChain's official security guide (python.langchain.com/docs/security/).
ARCHITECTURE

Run agents with least-privilege tool scopes — Gmail read-only if write is not needed. Isolate code execution tools from email-processing agents. Add a human-in-the-loop step before any write/execute action triggered by external email content.
DETECTION

Monitor for anomalous tool invocations correlated with inbound email processing — unusual send_email, file_write, or shell_execute calls following email reads are red flags.
UPGRADE

Review langchain-community changelog for any hardening patches post-v0.3.51 and test against your implementation.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Prompt Injection Code Execution Data Extraction Framework Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0051.001 - Indirect AML.T0053 - AI Agent Tool Invocation AML.T0080.001 - Thread AML.T0086 - Exfiltration via AI Agent Tool Invocation AML.T0093 - Prompt Infiltration via Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

8.4 - AI system operation and monitoring

NIST AI RMF

GOVERN-1.1 - Policies and processes for AI risk management MANAGE-2.2 - Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM01 - Prompt Injection LLM07 - System Prompt Leakage

Frequently Asked Questions

What is CVE-2025-46059?

Any LangChain agent with GmailToolkit enabled can be hijacked by a single crafted inbound email — no user interaction required beyond the agent checking the inbox. While LangChain disputes the root cause (blaming insecure user-written glue code), the practical risk is the same: untrusted email content flows directly into LLM context where it can trigger arbitrary tool invocations. Audit all agentic email workflows immediately, enforce input sanitization, and restrict tool permissions to least-privilege until a hardened implementation is verified.

Is CVE-2025-46059 actively exploited?

No confirmed active exploitation of CVE-2025-46059 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-46059?

1. IMMEDIATE: Audit all LangChain deployments using GmailToolkit or any email-reading tool. Disable or restrict auto-processing of inbound emails in production agents. 2. SHORT-TERM: Implement input sanitization/escaping of email content before passing to LLM context. Follow LangChain's official security guide (python.langchain.com/docs/security/). 3. ARCHITECTURE: Run agents with least-privilege tool scopes — Gmail read-only if write is not needed. Isolate code execution tools from email-processing agents. Add a human-in-the-loop step before any write/execute action triggered by external email content. 4. DETECTION: Monitor for anomalous tool invocations correlated with inbound email processing — unusual send_email, file_write, or shell_execute calls following email reads are red flags. 5. UPGRADE: Review langchain-community changelog for any hardening patches post-v0.3.51 and test against your implementation.

What systems are affected by CVE-2025-46059?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, email automation pipelines, RAG pipelines with email ingestion, AI-powered email assistants, agentic workflow orchestration.

What is the CVSS score for CVE-2025-46059?

CVE-2025-46059 has a CVSS v3.1 base score of 9.8 (CRITICAL). The EPSS exploitation probability is 0.67%.

What is the AI security impact?

Affected AI Architectures

agent frameworksemail automation pipelinesRAG pipelines with email ingestionAI-powered email assistantsagentic workflow orchestration

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0051.001 Indirect

AML.T0053 AI Agent Tool Invocation

AML.T0080.001 Thread

AML.T0086 Exfiltration via AI Agent Tool Invocation

AML.T0093 Prompt Infiltration via Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: 8.4

NIST AI RMF: GOVERN-1.1, MANAGE-2.2

OWASP LLM Top 10: LLM01, LLM07

What are the technical details?

Original Advisory

langchain-ai v0.3.51 was discovered to contain an indirect prompt injection vulnerability in the GmailToolkit component. This vulnerability allows attackers to execute arbitrary code and compromise the application via a crafted email message. NOTE: this is disputed by the Supplier because the code-execution issue was introduced by user-written code that does not adhere to the LangChain security practices.

Exploitation Scenario

An attacker sends an email to a corporate inbox monitored by a LangChain AI assistant. The email body contains a prompt injection payload disguised as normal text, e.g., hidden instructions at the end of a marketing email. When the agent's GmailToolkit fetches and passes the email to the LLM for summarization or triage, the injected instructions override the agent's system prompt. The LLM then calls available tools — executing shell commands, exfiltrating credentials from the context window, forwarding emails, or downloading and running remote payloads — entirely within the agent's normal permission scope, leaving minimal forensic trace since all actions appear as legitimate tool use.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.