CVE-2026-54547

Meta Ads MCP is a Model Context Protocol (MCP) server that lets AI assistants run Meta Ads. Prior to version 1.0.115, AuthInjectionMiddleware in meta_ads_mcp/core/http_auth_integration.py rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent, while extract_token_from_headers() does not recognize X-Pipeboard-Token as a primary credential. A network caller using the streamable-http transport can therefore send any X-Pipeboard-Token value, pass the guard without establishing authentication context, and cause get_auth_token() to fall back to the server operator's META_ACCESS_TOKEN. Subsequent MCP tools execute with the operator's Meta credentials and can read or modify the operator's Meta Ads data. Deployments using the default stdio transport or without META_ACCESS_TOKEN are not affected. This issue is fixed in version 1.0.115.

Meta Ads MCP is a Model Context Protocol (MCP) server that lets AI assistants run Meta Ads. Prior to version 1.0.115, AuthInjectionMiddleware in meta_ads_mcp/core/http_auth_integration.py rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent, while extract_token_from_headers() does not recognize X-Pipeboard-Token as a primary credential. A network caller using the streamable-http transport can therefore send any X-Pipeboard-Token value, pass the guard without establishing authentication context, and cause get_auth_token() to fall back to the server operator's META_ACCESS_TOKEN. Subsequent MCP tools execute with the operator's Meta credentials and can read or modify the operator's Meta Ads data. Deployments using the default stdio transport or without META_ACCESS_TOKEN are not affected. This issue is fixed in version 1.0.115.

X-Pipeboard-Token Header Auth Bypass Reuses Operator Meta Token

Summary

AuthInjectionMiddleware in meta-ads-mcp rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent. Because extract_token_from_headers() does not recognise the X-Pipeboard-Token header, an attacker who sends that header with any arbitrary value produces auth_token = None and pipeboard_token = <attacker value>, making the guard condition evaluate to False and passing the request through. No authentication context is set; the token getter falls back to the server operator's META_ACCESS_TOKEN environment variable. Every subsequent MCP tool call executes with the operator's Meta credentials, allowing an unauthenticated network caller to read and write the operator's Meta Ads data.

Details

The vulnerable condition is at meta_ads_mcp/core/http_auth_integration.py:259:

# http_auth_integration.py:255-260
auth_token = FastMCPAuthIntegration.extract_token_from_headers(dict(request.headers))
pipeboard_token = FastMCPAuthIntegration.extract_pipeboard_token_from_headers(dict(request.headers))

if not auth_token and not pipeboard_token:      # ← bypass condition
    return Response(..., status_code=401)

extract_token_from_headers() (lines 77–95) recognises only Authorization: Bearer, X-META-ACCESS-TOKEN, and X-PIPEBOARD-API-TOKEN. It does not recognise X-Pipeboard-Token, so that header never populates auth_token.

extract_pipeboard_token_from_headers() (line 108) does recognise X-Pipeboard-Token, so sending that header alone produces:

auth_token      = None          # not set → guard reads False for left operand
pipeboard_token = "<anything>"  # truthy  → guard reads False for right operand
→ (not None) and (not "<anything>") = True and False = False → 401 never returned

After the bypass, set_auth_token() is never called (lines 283–291 only run when auth_token is truthy). The patched token getter at lines 163–168 resolves get_auth_token() = None, then delegates to original_get_current_access_token(). The fallback chain in auth.py:446–453 returns META_ACCESS_TOKEN from the server environment:

# auth.py:443-453
env_token = os.environ.get("META_ACCESS_TOKEN")
if env_token:
    return env_token

@meta_api_tool at api.py:390–396 injects this operator token into every tool's access_token kwarg. The sink at api.py:225–235 forwards it to the Meta Graph API via httpx.AsyncClient. Verified with accounts.py:42–62 (get_ad_accounts): the operator's ad account data is returned for valid tokens; for invalid tokens the Meta Graph API responds with an OAuthException, confirming the token traversed the full path.

Full data flow:

| Step | Location | Description | |------|----------|-------------| | 1 | http_auth_integration.py:255–257 | Middleware extracts attacker-controlled headers | | 2 | http_auth_integration.py:259 | Bypass: X-Pipeboard-Token alone satisfies guard | | 3 | http_auth_integration.py:288–291 | auth_token is None; auth context never set | | 4 | http_auth_integration.py:163–168 | Token getter falls back to original accessor | | 5 | auth.py:446–453 | META_ACCESS_TOKEN env var returned as access token | | 6 | api.py:390–396 | Operator token injected into tool kwargs | | 7 | accounts.py:42–62 | Tool invokes Meta Graph API with operator token | | 8 | api.py:225–235 | httpx.AsyncClient sends privileged HTTP request |

Recommended fix:

--- a/meta_ads_mcp/core/http_auth_integration.py
+++ b/meta_ads_mcp/core/http_auth_integration.py
-        if not auth_token and not pipeboard_token:
+        if not auth_token:

X-Pipeboard-Token should be treated as a supplementary service token only; it must not serve as a standalone authentication credential for MCP tool calls.

PoC

Prerequisites

• Docker installed and the meta-ads-mcp…

Meta Ads MCP is a Model Context Protocol (MCP) server that lets AI assistants run Meta Ads. Prior to version 1.0.115, AuthInjectionMiddleware in meta_ads_mcp/core/http_auth_integration.py rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent, while extract_token_from_headers() does not recognize X-Pipeboard-Token as a primary credential. A network caller using the streamable-http transport can therefore send any X-Pipeboard-Token value, pass the guard without establishing authentication context, and cause get_auth_token() to fall back to the server operator's META_ACCESS_TOKEN. Subsequent MCP tools execute with the operator's Meta credentials and can read or modify the operator's Meta Ads data. Deployments using the default stdio transport or without META_ACCESS_TOKEN are not affected. This issue is fixed in version 1.0.115.

Meta Ads MCP is a Model Context Protocol (MCP) server that lets AI assistants run Meta Ads. Prior to version 1.0.115, AuthInjectionMiddleware in meta_ads_mcp/core/http_auth_integration.py rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent, while extract_token_from_headers() does not recognize X-Pipeboard-Token as a primary credential. A network caller using the streamable-http transport can therefore send any X-Pipeboard-Token value, pass the guard without establishing authentication context, and cause get_auth_token() to fall back to the server operator's META_ACCESS_TOKEN. Subsequent MCP tools execute with the operator's Meta credentials and can read or modify the operator's Meta Ads data. Deployments using the default stdio transport or without META_ACCESS_TOKEN are not affected. This issue is fixed in version 1.0.115.

X-Pipeboard-Token Header Auth Bypass Reuses Operator Meta Token

Summary

AuthInjectionMiddleware in meta-ads-mcp rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent. Because extract_token_from_headers() does not recognise the X-Pipeboard-Token header, an attacker who sends that header with any arbitrary value produces auth_token = None and pipeboard_token = <attacker value>, making the guard condition evaluate to False and passing the request through. No authentication context is set; the token getter falls back to the server operator's META_ACCESS_TOKEN environment variable. Every subsequent MCP tool call executes with the operator's Meta credentials, allowing an unauthenticated network caller to read and write the operator's Meta Ads data.

Details

The vulnerable condition is at meta_ads_mcp/core/http_auth_integration.py:259:

# http_auth_integration.py:255-260
auth_token = FastMCPAuthIntegration.extract_token_from_headers(dict(request.headers))
pipeboard_token = FastMCPAuthIntegration.extract_pipeboard_token_from_headers(dict(request.headers))

if not auth_token and not pipeboard_token:      # ← bypass condition
    return Response(..., status_code=401)

extract_token_from_headers() (lines 77–95) recognises only Authorization: Bearer, X-META-ACCESS-TOKEN, and X-PIPEBOARD-API-TOKEN. It does not recognise X-Pipeboard-Token, so that header never populates auth_token.

extract_pipeboard_token_from_headers() (line 108) does recognise X-Pipeboard-Token, so sending that header alone produces:

auth_token      = None          # not set → guard reads False for left operand
pipeboard_token = "<anything>"  # truthy  → guard reads False for right operand
→ (not None) and (not "<anything>") = True and False = False → 401 never returned

After the bypass, set_auth_token() is never called (lines 283–291 only run when auth_token is truthy). The patched token getter at lines 163–168 resolves get_auth_token() = None, then delegates to original_get_current_access_token(). The fallback chain in auth.py:446–453 returns META_ACCESS_TOKEN from the server environment:

# auth.py:443-453
env_token = os.environ.get("META_ACCESS_TOKEN")
if env_token:
    return env_token

@meta_api_tool at api.py:390–396 injects this operator token into every tool's access_token kwarg. The sink at api.py:225–235 forwards it to the Meta Graph API via httpx.AsyncClient. Verified with accounts.py:42–62 (get_ad_accounts): the operator's ad account data is returned for valid tokens; for invalid tokens the Meta Graph API responds with an OAuthException, confirming the token traversed the full path.

Full data flow:

| Step | Location | Description | |------|----------|-------------| | 1 | http_auth_integration.py:255–257 | Middleware extracts attacker-controlled headers | | 2 | http_auth_integration.py:259 | Bypass: X-Pipeboard-Token alone satisfies guard | | 3 | http_auth_integration.py:288–291 | auth_token is None; auth context never set | | 4 | http_auth_integration.py:163–168 | Token getter falls back to original accessor | | 5 | auth.py:446–453 | META_ACCESS_TOKEN env var returned as access token | | 6 | api.py:390–396 | Operator token injected into tool kwargs | | 7 | accounts.py:42–62 | Tool invokes Meta Graph API with operator token | | 8 | api.py:225–235 | httpx.AsyncClient sends privileged HTTP request |

Recommended fix:

--- a/meta_ads_mcp/core/http_auth_integration.py
+++ b/meta_ads_mcp/core/http_auth_integration.py
-        if not auth_token and not pipeboard_token:
+        if not auth_token:

X-Pipeboard-Token should be treated as a supplementary service token only; it must not serve as a standalone authentication credential for MCP tool calls.

PoC

Prerequisites

• Docker installed and the meta-ads-mcp…

X-Pipeboard-Token Header Auth Bypass Reuses Operator Meta Token

Summary

AuthInjectionMiddleware in meta-ads-mcp rejects HTTP MCP requests only when both auth_token and pipeboard_token are absent. Because extract_token_from_headers() does not recognise the X-Pipeboard-Token header, an attacker who sends that header with any arbitrary value produces auth_token = None and pipeboard_token = <attacker value>, making the guard condition evaluate to False and passing the request through. No authentication context is set; the token getter falls back to the server operator's META_ACCESS_TOKEN environment variable. Every subsequent MCP tool call executes with the operator's Meta credentials, allowing an unauthenticated network caller to read and write the operator's Meta Ads data.

Details

The vulnerable condition is at meta_ads_mcp/core/http_auth_integration.py:259:

# http_auth_integration.py:255-260
auth_token = FastMCPAuthIntegration.extract_token_from_headers(dict(request.headers))
pipeboard_token = FastMCPAuthIntegration.extract_pipeboard_token_from_headers(dict(request.headers))

if not auth_token and not pipeboard_token:      # ← bypass condition
    return Response(..., status_code=401)

extract_token_from_headers() (lines 77–95) recognises only Authorization: Bearer, X-META-ACCESS-TOKEN, and X-PIPEBOARD-API-TOKEN. It does not recognise X-Pipeboard-Token, so that header never populates auth_token.

extract_pipeboard_token_from_headers() (line 108) does recognise X-Pipeboard-Token, so sending that header alone produces:

auth_token      = None          # not set → guard reads False for left operand
pipeboard_token = "<anything>"  # truthy  → guard reads False for right operand
→ (not None) and (not "<anything>") = True and False = False → 401 never returned

After the bypass, set_auth_token() is never called (lines 283–291 only run when auth_token is truthy). The patched token getter at lines 163–168 resolves get_auth_token() = None, then delegates to original_get_current_access_token(). The fallback chain in auth.py:446–453 returns META_ACCESS_TOKEN from the server environment:

# auth.py:443-453
env_token = os.environ.get("META_ACCESS_TOKEN")
if env_token:
    return env_token

@meta_api_tool at api.py:390–396 injects this operator token into every tool's access_token kwarg. The sink at api.py:225–235 forwards it to the Meta Graph API via httpx.AsyncClient. Verified with accounts.py:42–62 (get_ad_accounts): the operator's ad account data is returned for valid tokens; for invalid tokens the Meta Graph API responds with an OAuthException, confirming the token traversed the full path.

Full data flow:

| Step | Location | Description | |------|----------|-------------| | 1 | http_auth_integration.py:255–257 | Middleware extracts attacker-controlled headers | | 2 | http_auth_integration.py:259 | Bypass: X-Pipeboard-Token alone satisfies guard | | 3 | http_auth_integration.py:288–291 | auth_token is None; auth context never set | | 4 | http_auth_integration.py:163–168 | Token getter falls back to original accessor | | 5 | auth.py:446–453 | META_ACCESS_TOKEN env var returned as access token | | 6 | api.py:390–396 | Operator token injected into tool kwargs | | 7 | accounts.py:42–62 | Tool invokes Meta Graph API with operator token | | 8 | api.py:225–235 | httpx.AsyncClient sends privileged HTTP request |

Recommended fix:

--- a/meta_ads_mcp/core/http_auth_integration.py
+++ b/meta_ads_mcp/core/http_auth_integration.py
-        if not auth_token and not pipeboard_token:
+        if not auth_token:

X-Pipeboard-Token should be treated as a supplementary service token only; it must not serve as a standalone authentication credential for MCP tool calls.

PoC

Prerequisites

• Docker installed and the meta-ads-mcp…