CVE-2026-81093 in Actors MCP Server
Summary
by MITRE • 08/27/2026
The get-html-skeleton tool fetched a URL the caller supplied after checking only its syntax. The handler in src/tools/common/get_html_skeleton.ts validated the url argument with isValidHttpUrl from src/utils/generic.ts, which confirmed the string began with an http or https scheme and parsed as a URL and inspected neither the host name nor the address it resolves to. Loopback, link-local and private ranges therefore passed, including the address cloud providers use to serve instance metadata. The unchecked URL was handed to the web-browser actor and the fetched document was returned in the tool response, so any caller of the MCP server could make it request an endpoint reachable only from the host and read the result, including instance credentials. Version 0.9.12 removes the tool.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified involves a critical flaw in input validation within the get-html-skeleton utility of the Model Context Protocol (MCP) server implementation. The core issue stems from an insufficient check on user-supplied Uniform Resource Locators before they are processed by the underlying web browser actor. Specifically, the handler located at src/tools/common/get_html_skeleton.ts relies exclusively on a function named isValidHttpUrl found in src/utils/generic.ts to validate input. This validation routine performs only syntactic checks, confirming that the provided string begins with either an http or https scheme and can be parsed as a valid URL structure. It fails to perform any semantic analysis of the target host name or inspect the IP address resulting from DNS resolution. Consequently, this oversight allows attackers to bypass security controls by supplying URLs pointing to internal network ranges that are typically inaccessible from external networks but fully reachable from within the hosting environment itself.
This lack of destination validation creates a significant server-side request forgery risk, enabling unauthorized access to sensitive resources hosted on loopback interfaces, link-local addresses, and private IP ranges. Most critically, this flaw exposes cloud instance metadata endpoints which are designed to be accessible only from within the virtual machine or container hosting the application. These metadata services often contain highly sensitive information such as temporary security credentials, IAM roles, and configuration details necessary for the operation of cloud workloads. By exploiting this vulnerability, an attacker who has access to the MCP server can instruct it to fetch content from these internal endpoints. The fetched document is then returned directly in the tool response, effectively allowing the attacker to exfiltrate instance credentials and other confidential data that should remain isolated from external or even lateral network movement attempts.
The operational impact of this vulnerability is severe, particularly for deployments running on cloud infrastructure where metadata services are a primary target for credential theft attacks. An adversary can leverage this flaw to escalate privileges by obtaining temporary access keys associated with the instance role. These credentials can then be used to interact with other cloud APIs, potentially leading to further compromise of the broader environment. This aligns closely with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws where a web server fetches a remote resource without validating the user-supplied URL. Furthermore, in the context of the MITRE ATT&CK framework, this behavior corresponds to techniques involving cloud infrastructure discovery and credential access, specifically leveraging SSRF to reach internal endpoints that are not directly exposed to the internet but are accessible via the compromised host's network stack.
To mitigate this vulnerability, it is essential to implement robust server-side request validation mechanisms that go beyond simple syntax checking. Developers should enforce allowlists for permitted domains or IP ranges and explicitly block requests targeting private address spaces as defined in RFC 1918, loopback addresses such as 127.0.0.0/8, link-local addresses like 169.254.0.0/16, and other reserved ranges including cloud metadata endpoints typically found at specific static IPs or hostnames. Additionally, employing a dedicated HTTP client with strict redirect policies that prevent following redirects to internal destinations can provide an additional layer of defense. In the case of this specific tool, version 0.9.12 addresses the issue by removing the get-html-skeleton functionality entirely from the codebase, thereby eliminating the attack vector until a more secure implementation is developed and deployed. Organizations relying on earlier versions should upgrade immediately or disable the affected tool to prevent potential credential theft and unauthorized access to internal resources.