CVE-2026-50143

The Apify MCP server enables AI agents to extract data from websites using ready-made scrapers, crawlers, and automation tools available on the Apify Store. Prior to 0.10.11, getActorMCPServerURL in src/mcp/actors.ts concatenates the trusted Actor standby URL with the attacker-controlled webServerMcpPath from an Actor definition without verifying the resulting origin, allowing a malicious Actor publisher to use a userinfo-style authority value to redirect connectMCPClient to a third-party host. The call-actor, fetch-actor-details, and actor-mcp tool-loading paths pass this URL to transports in src/mcp/client.ts that attach the victim Authorization bearer token, exposing the Apify API token and enabling access to Actors, stored data, and billable compute. A victim must invoke or inspect the attacker-controlled Actor. This issue is fixed in version 0.10.11.

The Apify MCP server enables AI agents to extract data from websites using ready-made scrapers, crawlers, and automation tools available on the Apify Store. Prior to 0.10.11, getActorMCPServerURL in src/mcp/actors.ts concatenates the trusted Actor standby URL with the attacker-controlled webServerMcpPath from an Actor definition without verifying the resulting origin, allowing a malicious Actor publisher to use a userinfo-style authority value to redirect connectMCPClient to a third-party host. The call-actor, fetch-actor-details, and actor-mcp tool-loading paths pass this URL to transports in src/mcp/client.ts that attach the victim Authorization bearer token, exposing the Apify API token and enabling access to Actors, stored data, and billable compute. A victim must invoke or inspect the attacker-controlled Actor. This issue is fixed in version 0.10.11.

Actor MCP path authority injection leaks Apify token

Summary

@apify/actors-mcp-server version 0.10.7 builds Actor standby URLs by directly concatenating a trusted base URL with an attacker-controlled webServerMcpPath value taken from an Actor definition returned by the Apify API. An attacker who publishes a malicious Actor with a crafted webServerMcpPath (e.g., @attacker.example/mcp) can cause the MCP client to resolve the final URL to an entirely different host. Because the MCP client unconditionally attaches the victim's Authorization: Bearer <APIFY_TOKEN> header to every outbound connection, the victim's Apify API token is exfiltrated to the attacker's server. CVSS Base Score: 8.1 (High).

Details

getActorMCPServerURL() in src/mcp/actors.ts:44 constructs the Actor standby MCP URL by naive string concatenation:

// src/mcp/actors.ts:44
return `${standbyUrl}${mcpServerPath}`;

mcpServerPath originates from the webServerMcpPath field of an Actor definition fetched from the Apify API (src/utils/actor.ts:24-28). The field is trimmed and comma-split in getActorMCPServerPath() (src/mcp/actors.ts:14-20) but is never validated to:

• begin with a / (relative path),
• avoid an @ character (userinfo/authority injection), or
• resolve to the same origin as standbyUrl.

When webServerMcpPath is set to @attacker.example/mcp, the concatenated result becomes:

https://[email protected]/mcp

Node.js's WHATWG URL parser treats everything before @ as userinfo and extracts attacker.example as the hostname. This is not an edge-case browser behavior — it is specified by RFC 3986 and the WHATWG URL standard.

The constructed URL is forwarded to connectMCPClient() through three independent code paths:

| Call site | Trigger | |---|---| | src/tools/core/call_actor_common.ts:317 | call-actor MCP tool | | src/utils/actor_details.ts:155 | fetch-actor-details MCP tool | | src/mcp/server.ts:1047 | actor-mcp type tool loading |

connectMCPClient() (src/mcp/client.ts) attaches the victim's Apify token as a bearer credential to every transport type:

// src/mcp/client.ts:94  — SSEClientTransport requestInit
authorization: `Bearer ${token}`,

// src/mcp/client.ts:103 — SSE fetch callback
headers.set('authorization', `Bearer ${token}`);

// src/mcp/client.ts:124 — StreamableHTTPClientTransport requestInit
authorization: `Bearer ${token}`,

There is no origin check anywhere between URL construction and the outbound HTTP request.

Full data-flow chain:

1. src/mcp/server.ts:811 — MCP tools/call request parameters are read.
2. src/mcp/server.ts:816 — apifyToken is resolved from _meta.apifyToken, server options, or process.env.APIFY_TOKEN.
3. src/tools/core/call_actor_common.ts:489-497 — attacker-controlled actor identifier is resolved via getActorMcpUrlCached().
4. src/utils/actor.ts:24-28 — Actor definition is fetched from the Apify API; webServerMcpPath is passed to getActorMCPServerURL().
5. src/mcp/actors.ts:14-20 — webServerMcpPath is trimmed and split; first element is returned without path validation.
6. src/mcp/actors.ts:44 — standbyUrl + mcpServerPath produces an authority-injected URL.
7. connectMCPClient() is called with the injected URL and the victim's token.
8. src/mcp/client.ts:94/103/124 — Authorization: Bearer <APIFY_TOKEN> is sent to the attacker's host.

PoC

Environment requirements:

• Docker (network-isolated container; no external network access needed)
• The repository at commit 4e2b185 checked out under the build context

Build and run:

# Build the exploit image (from the mcp_38_apify__actors-mcp-server/ context directory)
docker build -t vuln-001-poc \
  -f vuln-001/Dockerfile \
  /path/to/mcp_38_apify__actors-mcp-server

# Run the exploit (--network none: fully air-gapped)
docker run --rm --network none vuln-001-poc

…

The Apify MCP server enables AI agents to extract data from websites using ready-made scrapers, crawlers, and automation tools available on the Apify Store. Prior to 0.10.11, getActorMCPServerURL in src/mcp/actors.ts concatenates the trusted Actor standby URL with the attacker-controlled webServerMcpPath from an Actor definition without verifying the resulting origin, allowing a malicious Actor publisher to use a userinfo-style authority value to redirect connectMCPClient to a third-party host. The call-actor, fetch-actor-details, and actor-mcp tool-loading paths pass this URL to transports in src/mcp/client.ts that attach the victim Authorization bearer token, exposing the Apify API token and enabling access to Actors, stored data, and billable compute. A victim must invoke or inspect the attacker-controlled Actor. This issue is fixed in version 0.10.11.

The Apify MCP server enables AI agents to extract data from websites using ready-made scrapers, crawlers, and automation tools available on the Apify Store. Prior to 0.10.11, getActorMCPServerURL in src/mcp/actors.ts concatenates the trusted Actor standby URL with the attacker-controlled webServerMcpPath from an Actor definition without verifying the resulting origin, allowing a malicious Actor publisher to use a userinfo-style authority value to redirect connectMCPClient to a third-party host. The call-actor, fetch-actor-details, and actor-mcp tool-loading paths pass this URL to transports in src/mcp/client.ts that attach the victim Authorization bearer token, exposing the Apify API token and enabling access to Actors, stored data, and billable compute. A victim must invoke or inspect the attacker-controlled Actor. This issue is fixed in version 0.10.11.

Actor MCP path authority injection leaks Apify token

Summary

@apify/actors-mcp-server version 0.10.7 builds Actor standby URLs by directly concatenating a trusted base URL with an attacker-controlled webServerMcpPath value taken from an Actor definition returned by the Apify API. An attacker who publishes a malicious Actor with a crafted webServerMcpPath (e.g., @attacker.example/mcp) can cause the MCP client to resolve the final URL to an entirely different host. Because the MCP client unconditionally attaches the victim's Authorization: Bearer <APIFY_TOKEN> header to every outbound connection, the victim's Apify API token is exfiltrated to the attacker's server. CVSS Base Score: 8.1 (High).

Details

getActorMCPServerURL() in src/mcp/actors.ts:44 constructs the Actor standby MCP URL by naive string concatenation:

// src/mcp/actors.ts:44
return `${standbyUrl}${mcpServerPath}`;

mcpServerPath originates from the webServerMcpPath field of an Actor definition fetched from the Apify API (src/utils/actor.ts:24-28). The field is trimmed and comma-split in getActorMCPServerPath() (src/mcp/actors.ts:14-20) but is never validated to:

• begin with a / (relative path),
• avoid an @ character (userinfo/authority injection), or
• resolve to the same origin as standbyUrl.

When webServerMcpPath is set to @attacker.example/mcp, the concatenated result becomes:

https://[email protected]/mcp

Node.js's WHATWG URL parser treats everything before @ as userinfo and extracts attacker.example as the hostname. This is not an edge-case browser behavior — it is specified by RFC 3986 and the WHATWG URL standard.

The constructed URL is forwarded to connectMCPClient() through three independent code paths:

| Call site | Trigger | |---|---| | src/tools/core/call_actor_common.ts:317 | call-actor MCP tool | | src/utils/actor_details.ts:155 | fetch-actor-details MCP tool | | src/mcp/server.ts:1047 | actor-mcp type tool loading |

connectMCPClient() (src/mcp/client.ts) attaches the victim's Apify token as a bearer credential to every transport type:

// src/mcp/client.ts:94  — SSEClientTransport requestInit
authorization: `Bearer ${token}`,

// src/mcp/client.ts:103 — SSE fetch callback
headers.set('authorization', `Bearer ${token}`);

// src/mcp/client.ts:124 — StreamableHTTPClientTransport requestInit
authorization: `Bearer ${token}`,

There is no origin check anywhere between URL construction and the outbound HTTP request.

Full data-flow chain:

1. src/mcp/server.ts:811 — MCP tools/call request parameters are read.
2. src/mcp/server.ts:816 — apifyToken is resolved from _meta.apifyToken, server options, or process.env.APIFY_TOKEN.
3. src/tools/core/call_actor_common.ts:489-497 — attacker-controlled actor identifier is resolved via getActorMcpUrlCached().
4. src/utils/actor.ts:24-28 — Actor definition is fetched from the Apify API; webServerMcpPath is passed to getActorMCPServerURL().
5. src/mcp/actors.ts:14-20 — webServerMcpPath is trimmed and split; first element is returned without path validation.
6. src/mcp/actors.ts:44 — standbyUrl + mcpServerPath produces an authority-injected URL.
7. connectMCPClient() is called with the injected URL and the victim's token.
8. src/mcp/client.ts:94/103/124 — Authorization: Bearer <APIFY_TOKEN> is sent to the attacker's host.

PoC

Environment requirements:

• Docker (network-isolated container; no external network access needed)
• The repository at commit 4e2b185 checked out under the build context

Build and run:

# Build the exploit image (from the mcp_38_apify__actors-mcp-server/ context directory)
docker build -t vuln-001-poc \
  -f vuln-001/Dockerfile \
  /path/to/mcp_38_apify__actors-mcp-server

# Run the exploit (--network none: fully air-gapped)
docker run --rm --network none vuln-001-poc

…