Apify actors-mcp-server EUVD-2026-67148

The get-html-skeleton tool must be loaded by the MCP server - it is included in default configurations and requires no special enablement flag. The attacker must be able to send MCP tool-call requests to the server, either by direct network access to the MCP endpoint or by controlling an LLM agent that uses the server. Cloud metadata credential theft specifically requires the server to run on a cloud VM (AWS, GCP, Azure) where 169.254.169.254 is reachable without egress restrictions; SSRF to other RFC 1918 hosts is exploitable in any network-adjacent deployment regardless of cloud provider. No authenticated session or elevated privilege is required per the CVSS 4.0 PR:N rating. The limiting factor is MCP server reachability - deployments restricted to localhost or trusted internal callers face lower practical exposure than publicly accessible endpoints.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N yielding 8.7 accurately reflects a no-authentication, no-complexity network exploit with high confidentiality impact. EPSS data is absent from available intelligence; no KEV listing and no POC code are confirmed. Despite the absence of public exploits, the real-world risk is material for cloud-hosted deployments: a single SSRF request to 169.254.169.254 can yield temporary IAM credentials enabling lateral movement into the cloud account - a high-impact, low-skill outcome. The attack surface is bounded by who can invoke MCP tool calls on the server; deployments fronted by authentication or restricted to trusted LLM agents face lower practical risk than publicly exposed endpoints. The fix is decisive - complete tool removal in 0.9.12 eliminates the surface entirely, so the primary risk signal for defenders is patch adoption on existing deployments.

An attacker with access to an Apify MCP server running a pre-0.9.12 version calls the get-html-skeleton tool with the URL http://169.254.169.254/latest/meta-data/iam/security-credentials/ as the argument. The server's URL validator accepts the link-local address as syntactically valid, passes it to the internal browser actor, and returns the IAM role credential payload in the tool response. The attacker uses the harvested temporary AWS credentials to authenticate to the cloud account and escalate access.