CVE-2026-103957 in Loom
Summary
by MITRE • 10/02/2026
Server-side request forgery in the OAuth2 discovery handling in Loom for AWS before 1.7.0 might allow an authenticated remote user to obtain the access token of another user of the deployment and to cause the application to issue requests to arbitrary internal network locations, via a crafted discovery document address supplied when registering a tool server or remote agent configured for delegated authentication.
To remediate this issue, users should upgrade to version 1.7.0 or later.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Loom for AWS prior to version 1.7.0 represents a critical Server-Side Request Forgery (SSRF) flaw embedded within the OAuth2 discovery handling mechanism. This security defect allows an authenticated remote user, who possesses valid credentials for the deployment, to manipulate the application into performing HTTP requests on their behalf to arbitrary destinations. The attack vector specifically targets the process of registering a tool server or configuring a remote agent that utilizes delegated authentication. By supplying a crafted URL pointing to a malicious discovery document address during this registration phase, an attacker can exploit the lack of strict validation and sanitization in the OAuth2 metadata retrieval logic. This flaw fundamentally undermines the trust boundary between the application and its internal infrastructure, as well as external identity providers, by allowing the server-side component to act as a proxy for unauthorized network access.
From a technical perspective, the core issue lies in how the application processes the discovery document URL provided during the OAuth2 configuration phase. When an administrator or authorized user registers a new tool server or remote agent, they must specify the endpoint where the OpenID Connect (OIDC) or OAuth 2.0 metadata is hosted. The vulnerable versions of Loom for AWS fail to adequately restrict the protocols allowed in this URL, such as permitting file:// or gopher:// schemes, and critically, fail to enforce strict allow-lists on destination IP addresses or domains that are not explicitly trusted identity providers. Consequently, an attacker can direct the server to fetch metadata from a controlled endpoint within the internal network topology. This capability enables the application to expose sensitive configuration data or interact with internal services that should remain inaccessible from external-facing interfaces. The exploitation of this flaw does not require privilege escalation beyond standard authenticated user status, making it particularly dangerous in multi-tenant environments where lateral movement is a primary concern for adversaries seeking deeper access into an organization's infrastructure.
The operational impact of this vulnerability extends significantly beyond simple data exfiltration. By leveraging the SSRF to obtain the OAuth2 discovery document from internal services or by manipulating the redirect URIs and token endpoints defined within that document, an attacker can potentially intercept or forge authentication flows. This may lead to the acquisition of access tokens belonging to other users within the same deployment if the application improperly handles session states or token validation based on the fetched metadata. Furthermore, the ability to issue requests to arbitrary internal network locations facilitates reconnaissance and further exploitation against backend services such as databases, message queues, or microservices that are not directly exposed to the internet but rely on implicit trust from the web tier. This effectively bypasses perimeter security controls like firewalls and intrusion detection systems, which typically do inspect traffic originating from trusted application servers. The scenario aligns closely with CWE-918, Server-Side Request Forgery (SSRF), where a server makes requests to internal resources based on user-supplied input without sufficient validation. Additionally, the technique of using forged discovery documents to manipulate authentication flows relates to ATT&CK tactic T1556, specifically sub-techniques involving modification of authentication processes or abuse of OAuth2 protocols for credential access and lateral movement.
To mitigate this risk, organizations running Loom for AWS must immediately upgrade to version 1.7.0 or any subsequent release where the vulnerability has been patched. The remediation likely involves implementing strict input validation on URLs provided during tool server registration, enforcing allow-lists for permitted domains in OAuth2 discovery endpoints, and disabling dangerous URL schemes such as file:// or gopher:// at the application level. In addition to upgrading, administrators should review existing configurations of registered tools and remote agents to ensure that no malicious entries were introduced prior to patching. Implementing network-level controls, such as egress filtering for the Loom server instances, can also provide a defense-in-depth layer by restricting outbound connections to only known and necessary external identity providers and internal service endpoints. Regular auditing of OAuth2 configurations and monitoring for anomalous outbound traffic patterns from application servers are recommended practices to detect potential exploitation attempts in environments where immediate patching may be delayed due to operational constraints.