Skip to main content
OneCon26: Gain the advantage in the AI era. Oct. 20–22 in Las Vegas.Register Now
Vulnerability Database/CVE-2026-54547

CVE-2026-54547: Meta Ads MCP Auth Bypass Vulnerability

CVE-2026-54547 is an authentication bypass flaw in Meta Ads MCP that allows attackers to execute tools with operator credentials and access Meta Ads data. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-54547 Overview

CVE-2026-54547 is an authentication bypass vulnerability [CWE-287] in Meta Ads MCP, a Model Context Protocol (MCP) server that allows AI assistants to run Meta Ads campaigns. The flaw exists in AuthInjectionMiddleware within meta_ads_mcp/core/http_auth_integration.py in versions prior to 1.0.115. A network-reachable caller using the streamable-http transport can send an arbitrary X-Pipeboard-Token header to bypass the authentication guard. Tool handlers then fall back to the server operator's META_ACCESS_TOKEN environment variable, executing Meta Ads operations under the operator's identity. Deployments using the default stdio transport or without META_ACCESS_TOKEN configured are not affected.

Critical Impact

Unauthenticated network attackers can read and modify the server operator's Meta Ads data by abusing the operator's credentials, and can potentially exfiltrate the META_ACCESS_TOKEN through Graph API error responses.

Affected Products

  • Meta Ads MCP versions prior to 1.0.115
  • Deployments using the streamable-http transport
  • Deployments configured with a META_ACCESS_TOKEN environment variable

Discovery Timeline

  • 2026-09-15 - CVE-2026-54547 published to NVD
  • 2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-54547

Vulnerability Analysis

The Meta Ads MCP server exposes tools that AI assistants use to manage Meta advertising accounts. When deployed with the streamable-http transport, incoming HTTP requests pass through AuthInjectionMiddleware before reaching tool handlers. The middleware was designed to reject requests lacking credentials, but its guard condition incorrectly treated a supplementary token header as sufficient proof of authentication.

Once a request bypasses the guard, downstream tool handlers invoke get_auth_token(), which falls back to the operator-provided META_ACCESS_TOKEN environment variable. Meta Graph API operations then run under the operator's account, allowing unauthorized read and write access to the operator's ad accounts, campaigns, and audience data.

Root Cause

The middleware evaluated if not auth_token and not pipeboard_token before rejecting requests. The pipeboard_token extracted from the X-Pipeboard-Token header is a service token intended only for a duplication callback flow. It does not establish a caller identity. However, its presence satisfied the guard, allowing any request carrying an attacker-controlled X-Pipeboard-Token value to reach tool handlers without an Authorization: Bearer header, X-META-ACCESS-TOKEN, or X-PIPEBOARD-API-TOKEN.

Attack Vector

An attacker with network reachability to the MCP server sends an HTTP request to an MCP tool endpoint. The request includes a header such as X-Pipeboard-Token: anything. The middleware admits the request. Tool handlers execute Meta Ads API calls using the operator's META_ACCESS_TOKEN, and Graph API error responses may echo credential material back to the attacker.

python
# Patch from meta_ads_mcp/core/http_auth_integration.py
        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:
-            # Reject unauthenticated requests. Without this, the request would fall
-            # through to tool handlers which transparently use the META_ACCESS_TOKEN
-            # env var, allowing any network-reachable caller to invoke tools and
-            # exfiltrate the operator's credential via Graph API error responses.
+        if not auth_token:
+            # A request must carry a primary access-token credential: an
+            # Authorization: Bearer header, X-META-ACCESS-TOKEN, or
+            # X-PIPEBOARD-API-TOKEN (all resolved by extract_token_from_headers).
+            # X-Pipeboard-Token is only a supplementary service token for the
+            # duplication callback — on its own it establishes no request auth
+            # context, so it must not admit a request.
            logger.warning(
                "HTTP Auth Middleware: rejecting request to %s — no Authorization "
                "Bearer or X-PIPEBOARD-API-TOKEN header present", request.url.path,

Source: GitHub Commit 95e8527

Detection Methods for CVE-2026-54547

Indicators of Compromise

  • HTTP requests to MCP tool endpoints containing an X-Pipeboard-Token header without an accompanying Authorization: Bearer or X-PIPEBOARD-API-TOKEN header.
  • Meta Graph API activity from the server operator's account originating from unexpected client IPs or user agents.
  • Unusual create, update, or delete operations against ad accounts, campaigns, ad sets, or audiences performed by the MCP server process.

Detection Strategies

  • Inspect reverse proxy and web server access logs for MCP endpoint requests carrying X-Pipeboard-Token headers with unexpected or malformed values.
  • Correlate MCP tool invocations with authenticated caller identity; requests processed without a validated bearer token should be flagged.
  • Review Meta Business Manager audit logs for administrative actions that do not map to authorized user sessions.

Monitoring Recommendations

  • Enable verbose logging in AuthInjectionMiddleware and forward warning events referencing rejected or admitted authentication attempts to a central log store.
  • Alert on outbound Graph API error responses that include credential fragments, as these indicate potential token exfiltration attempts.
  • Track MCP server version inventory and alert when any instance runs a release earlier than 1.0.115.

How to Mitigate CVE-2026-54547

Immediate Actions Required

  • Upgrade Meta Ads MCP to version 1.0.115 or later on all deployments using the streamable-http transport.
  • Rotate the META_ACCESS_TOKEN value on any server that was network-reachable while running a vulnerable version.
  • Review Meta Ads account activity for unauthorized changes to campaigns, budgets, audiences, or billing settings.

Patch Information

The issue is fixed in Meta Ads MCP 1.0.115. The fix modifies the guard in AuthInjectionMiddleware to require a primary access-token credential (Authorization: Bearer, X-META-ACCESS-TOKEN, or X-PIPEBOARD-API-TOKEN) and no longer treats X-Pipeboard-Token as sufficient authentication. See the GitHub Security Advisory GHSA-2v2f-mvfg-ph56, Pull Request #137, and Release 1.0.115.

Workarounds

  • Switch the MCP server to the default stdio transport, which is not affected by this vulnerability.
  • Unset the META_ACCESS_TOKEN environment variable so tool handlers have no operator credential to fall back on.
  • Restrict network access to the MCP HTTP endpoint using firewall rules, a reverse proxy with mandatory bearer authentication, or a private network overlay.
bash
# Upgrade to the patched release
pip install --upgrade 'meta-ads-mcp>=1.0.115'

# Verify installed version
python -c "import meta_ads_mcp; print(meta_ads_mcp.__version__)"

# Temporary mitigation: run over stdio transport instead of streamable-http
unset META_ACCESS_TOKEN
meta-ads-mcp --transport stdio

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.

Try SentinelOne