CVE-2025-2828 Overview
A Server-Side Request Forgery (SSRF) vulnerability has been identified in the RequestsToolkit component of the langchain-community package. Specifically, the vulnerability exists in langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit in langchain-ai/langchain version 0.0.27. This security flaw occurs because the toolkit does not enforce restrictions on requests to remote internet addresses, allowing it to also access local addresses. As a result, an attacker could exploit this vulnerability to perform port scans, access local services, retrieve instance metadata from cloud environments (e.g., Azure, AWS), and interact with servers on the local network.
Critical Impact
This SSRF vulnerability enables attackers to bypass network segmentation and access internal resources, potentially leading to credential theft from cloud metadata services, internal network reconnaissance, and unauthorized access to sensitive backend systems.
Affected Products
- langchain-community package (langchain_community.agent_toolkits.openapi.toolkit.RequestsToolkit)
- langchain-ai/langchain version 0.0.27
- All deployments using RequestsToolkit without the allow_dangerous_requests parameter
Discovery Timeline
- 2025-06-23 - CVE CVE-2025-2828 published to NVD
- 2025-07-16 - Last updated in NVD database
Technical Details for CVE-2025-2828
Vulnerability Analysis
The SSRF vulnerability in LangChain's RequestsToolkit stems from insufficient validation of target URLs before making HTTP requests. When an AI agent utilizes the RequestsToolkit to interact with OpenAPI endpoints, the toolkit processes URLs without verifying whether they point to external resources or internal/local addresses. This architectural oversight allows malicious actors to craft requests that target internal infrastructure, cloud metadata endpoints (such as http://169.254.169.254/ for AWS or Azure), or localhost services that should not be externally accessible.
The vulnerability is particularly dangerous in AI agent deployments where user input may influence the URLs being requested. Since LangChain agents are often designed to dynamically interact with APIs based on user queries, an attacker could manipulate the agent into making requests to arbitrary endpoints, effectively using the application server as a proxy to access restricted resources.
Root Cause
The root cause of CVE-2025-2828 is the lack of URL validation and request restrictions in the RequestsToolkit class. The toolkit's request methods (RequestsGetTool, RequestsPostTool, RequestsPatchTool, RequestsPutTool, RequestsDeleteTool) did not implement any safeguards to prevent requests to internal network addresses, localhost, or cloud metadata services. This design assumed that all requests would be made to trusted external APIs, without accounting for scenarios where user input could direct requests to malicious destinations.
Attack Vector
The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:
- Crafting input that causes the LangChain agent to make requests to internal IP addresses (e.g., 127.0.0.1, 10.x.x.x, 192.168.x.x)
- Targeting cloud metadata endpoints to steal instance credentials and configuration data
- Performing port scanning on internal networks to discover available services
- Accessing internal APIs or services that are not exposed to the public internet
- Potentially pivoting to other attacks once internal network topology is mapped
# Security patch in libs/community/langchain_community/tools/requests/tool.py
# Source: https://github.com/langchain-ai/langchain/commit/e188d4ecb085d4561a0be3c583d26aa9c2c3283f
requests_wrapper: GenericRequestsWrapper
+ allow_dangerous_requests: bool = False
+
+ def __init__(self, **kwargs: Any):
+ """Initialize the tool."""
+ if not kwargs.get("allow_dangerous_requests", False):
+ raise ValueError(
+ "You must set allow_dangerous_requests to True to use this tool. "
+ "Request scan be dangerous and can lead to security vulnerabilities. "
+ "For example, users can ask a server to make a request to an internal"
+ "server. It's recommended to use requests through a proxy server "
+ "and avoid accepting inputs from untrusted sources without proper "
+ "sandboxing."
+ "Please see: https://python.langchain.com/docs/security for "
+ "further security information."
+ )
+ super().__init__(**kwargs)
class RequestsGetTool(BaseRequestsTool, BaseTool):
"""Tool for making a GET request to an API endpoint."""
Source: LangChain GitHub Commit
Detection Methods for CVE-2025-2828
Indicators of Compromise
- Outbound HTTP/HTTPS requests from application servers to internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
- Requests to cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal
- Unusual patterns of sequential port connections indicating reconnaissance activity
- Application logs showing requests to unexpected localhost services or internal hostnames
Detection Strategies
- Implement network monitoring to detect requests from LangChain application servers to internal IP ranges or metadata services
- Deploy web application firewalls (WAF) with rules to block SSRF patterns in outbound requests
- Enable detailed logging for all RequestsToolkit operations and monitor for anomalous URL patterns
- Use runtime application self-protection (RASP) solutions to detect and block SSRF attempts at the application layer
Monitoring Recommendations
- Configure alerts for any outbound connections from AI agent servers to RFC 1918 private address spaces
- Monitor cloud provider logs (AWS CloudTrail, Azure Activity Logs) for metadata service access from unexpected sources
- Establish baseline network behavior for LangChain applications and alert on deviations
- Implement DNS query logging to detect resolution attempts for internal hostnames from application servers
How to Mitigate CVE-2025-2828
Immediate Actions Required
- Upgrade langchain-community to version 0.0.28 or later immediately
- Audit all deployments using RequestsToolkit to identify vulnerable instances
- Implement network-level controls to restrict outbound requests from application servers to internal addresses
- Review application logs for evidence of SSRF exploitation attempts
Patch Information
The vulnerability has been fixed in langchain-community version 0.0.28. The patch introduces an allow_dangerous_requests parameter that defaults to False, requiring explicit opt-in for potentially dangerous request behavior. When the parameter is not set to True, the toolkit will raise a ValueError with a security warning, preventing inadvertent exposure to SSRF attacks.
The fix was implemented in commit e188d4ecb085d4561a0be3c583d26aa9c2c3283f.
Workarounds
- Deploy a proxy server that filters outbound requests and blocks access to internal addresses and metadata endpoints
- Implement application-level URL validation before passing URLs to RequestsToolkit
- Use network segmentation to isolate LangChain applications from sensitive internal resources
- Configure firewall rules to prevent application servers from making requests to internal IP ranges
# Configuration example - Upgrade to patched version
pip install --upgrade langchain-community>=0.0.28
# Verify installed version
pip show langchain-community | grep Version
# If upgrade is not immediately possible, implement proxy-based filtering
# Example: Configure environment variable for proxy
export HTTP_PROXY="http://security-proxy.internal:8080"
export HTTPS_PROXY="http://security-proxy.internal:8080"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


