fetcher-mcp CVE-2026-74858

The attacker must have authorization to invoke the fetch_url or fetch_urls MCP tool, which corresponds to PR:L in the CVSS vector - some level of authenticated access to the MCP server session is required (e.g., an authorized AI assistant user). For the highest-impact IMDSv1 credential-theft scenario, the fetcher-mcp instance must be running on AWS EC2 (or compatible cloud compute) that has not enforced IMDSv2 (HttpTokens=required); if IMDSv2 is required, the metadata credential path is blocked, though SSRF to other internal RFC 1918 services remains exploitable. No non-default application configuration, feature flag, or special deployment mode is required - the vulnerable code path is triggered by ordinary use of the fetch functions. Exploitation is limited to resources network-reachable from the fetcher-mcp host process.

The CVSS 4.0 base score of 5.3 (Medium) reflects low privileges and limited direct system impact (VC:L/VI:L/VA:L/SC:N), but this framing materially understates real-world risk in the primary deployment scenario - cloud-hosted AI tooling on EC2 or comparable compute. An SSRF that reaches IMDSv1 returns live, short-lived AWS IAM credentials for the attached instance role, effectively granting the attacker whatever cloud permissions that role holds, which can include S3 access, Lambda invocation, or broader account traversal; this scope-changing confidentiality impact is not reflected in the assigned subsequent-system metrics (SC:N/SI:N/SA:N). No EPSS score was provided in the available intelligence, so exploitation probability cannot be quantified numerically; however, the vulnerability class is well-understood and the attack path against IMDSv1 is trivial for anyone familiar with cloud exploitation techniques. There is no CISA KEV listing and no known public POC beyond the GitHub issue (#37), so mass exploitation has not been observed, but even a mid-sized municipal IT team in sanok running AI assistant infrastructure on cloud compute would face material credential-exposure risk if fetcher-mcp instances operate on EC2 without IMDSv2 enforcement. The absence of any maintainer response removes patch timeline certainty and elevates urgency for compensating controls.

An attacker with low-privilege access to an AI assistant session backed by fetcher-mcp invokes the fetch_url tool with the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/MyRole. The MCP server, lacking URL validation, forwards the request to the EC2 metadata service on the host and returns the JSON response containing AccessKeyId, SecretAccessKey, and SessionToken. The attacker uses these credentials externally to authenticate to AWS APIs under the permissions of the instance role, potentially achieving lateral movement across cloud resources. No public POC exploit code has been identified, but the attack requires only knowledge of the standard metadata URL path.