CVE-2026-86237 in openagents
Summary
by MITRE • 09/07/2026
A vulnerability was found in openagents-org openagents up to 0.8.19/0.9.3.post20. Impacted is the function test_default_model of the file sdk/src/openagents/sdk/transports/http.py. Performing a manipulation of the argument base_url results in server-side request forgery. The attack may be initiated remotely. The exploit has been made public and could be used. Endpoint and both sinks unchanged since filing; only the file moved (e277dd1a). Maintainer closed as inapplicable yet the identical unguarded code still ships in 0.9.3.post20. Sibling admin endpoints do call the shipped-but-unused-by-this-handler _require_admin().
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability identified within openagents-org openagents, affecting versions up to 0.8.19 and 0.9.3.post20, represents a critical server-side request forgery flaw located in the sdk/src/openagents/sdk/transports/http.py file. Specifically, this issue resides within the test_default_model function, where user-supplied input is processed without adequate validation or sanitization before being utilized to construct outbound network requests. The core technical failure involves the manipulation of the base_url argument, which serves as a primary component in determining the destination of HTTP calls initiated by the application. Because the framework fails to enforce strict allowlisting or validate that the provided URL points only to expected internal resources, an attacker can inject arbitrary hostnames and ports into this parameter. This lack of input validation allows the server to be coerced into making requests to endpoints controlled by the adversary, effectively bypassing network-level security controls that might otherwise restrict outbound traffic from sensitive infrastructure components.
From a technical perspective, this vulnerability is classified under CWE-918, which addresses Server-Side Request Forgery (SSRF). The flaw exploits the trust relationship between the application and its underlying server environment. By manipulating the base_url parameter, an attacker can direct the vulnerable function to access internal services that are not exposed to the public internet, such as cloud metadata endpoints, internal databases, or administrative interfaces of other microservices within the same network segment. This capability is particularly dangerous because it leverages the application's own identity and permissions to interact with backend systems. The persistence of this vulnerability in version 0.9.3.post20 indicates a significant gap in the maintenance lifecycle, as the maintainer had previously closed similar reports as inapplicable despite evidence that the unguarded code remained present in subsequent releases. This discrepancy highlights potential issues in the project's security review process and regression testing protocols.
The operational impact of this vulnerability is severe due to its remote exploitability. Since the attack can be initiated remotely, an adversary does not need prior access or authentication to leverage this flaw, provided they have a pathway to trigger the test_default_model function through exposed APIs or endpoints. The fact that sibling admin endpoints correctly call _require_admin() suggests that while some parts of the application adhere to proper security practices regarding authorization, other components like the HTTP transport layer lack equivalent safeguards for input validation. This inconsistency creates an attack vector where authentication controls are bypassed not by breaking encryption or stealing credentials, but by exploiting logical flaws in how external inputs are handled during network operations. Successful exploitation could lead to unauthorized access to internal resources, data exfiltration from backend systems, and potentially further lateral movement within the target environment if combined with other vulnerabilities such as insecure direct object references or weak authentication mechanisms on the accessed internal services.
In alignment with industry frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1571, which covers Non-Standard Ports for C2 Servers, and more broadly to T1090, Proxy Communication, if used to route traffic through compromised hosts. It also relates to T1434, Internal Spearphishing, in scenarios where the SSRF is used to access internal mail servers or collaboration tools. The public availability of exploits underscores the urgency for remediation, as automated scanning and exploitation attempts are likely occurring against known vulnerable instances. Organizations relying on openagents must treat this issue with high priority due to its remote nature and the potential for significant data breach consequences.
Mitigation strategies should focus primarily on implementing strict input validation for all URL-related parameters within the application codebase. Developers must enforce allowlisting of permitted hostnames, IP addresses, or CIDR ranges that the server is authorized to contact, rejecting any requests that do not match these predefined criteria. Additionally, employing a dedicated library or framework feature designed specifically for SSRF prevention can provide robust protection against such manipulations. Network-level controls should also be reviewed; implementing egress filtering rules on firewalls and proxy servers to restrict outbound connections from application servers to only those destinations strictly necessary for business operations adds a critical layer of defense in depth. For immediate risk reduction, organizations using affected versions should upgrade to the latest patched release once available or apply manual code patches that sanitize the base_url argument before it is passed to HTTP client libraries. Continuous monitoring and logging of outbound network connections from application servers can also aid in detecting attempted exploitation activities in real time.