Intelligence
Join the waitlist
AEV-2026-0034

argocd-mcp 0.8.0 let an unestablished network caller act as Argo CD's own configured credential (GHSA-rp45-5x3v-48mr)

argocd-mcp 0.8.0 bound its HTTP and SSE transports to every network interface and completed a tool call whose request carried no caller credential at all, so long as the operator had configured ARGOCD_API_TOKEN, the credential the server itself presents to Argo CD rather than one belonging to the caller. This entry confirmed directly, from the affected and fixed source, that Argo CD's own authentication and RBAC then evaluated that stored token honestly on every such call, while nothing upstream of it had ever evaluated who made the request. Fixed in 0.9.0, published 11 August 2026, which binds to loopback by default and requires a separate, shared inbound bearer credential before widening it.

AESS 8.0 highConfirmedStatus: resolvedEvent: 11 August 2026Execution AuthorityDelegated AuthorityAgent IdentityEnvironment Boundaries

Affected

Organisation
argoproj-labs
Product
argocd-mcp (argoproj-labs/mcp-for-argocd)
Component
The HTTP and SSE transport listener bind address (src/server/transport.ts) and the resolveCredentials check gating session creation, which accepts the operator's own ARGOCD_API_TOKEN environment variable as sufficient even when the request itself supplies no credential
Versions
Through 0.8.0, per GHSA-rp45-5x3v-48mr. Fixed in 0.9.0, confirmed directly against that tag and unchanged on the project's current default branch
Configurations
The operator configures ARGOCD_API_TOKEN so the server can reach Argo CD, the deployment shape the project itself documents as ordinary; The server's HTTP or SSE transport is reachable to a network caller, the default before 0.9.0 since the listener bound every interface with no operator action required

Execution authority facts

Fields the evidence does not establish are shown as unknown rather than guessed.

Intended task
An MCP caller invoking Argo CD tools, reads and, in write mode, application create, update, delete and sync, through argocd-mcp
Agent
argocd-mcp, the Model Context Protocol server for Argo CD
Delegating actor
The operator who deployed and configured argocd-mcp with its own ARGOCD_API_TOKEN
Action
Completed an MCP tool call, this entry traced sync_application end to end through ArgoCDClient and HttpClient, against Argo CD's own API, authenticated with the operator's configured ARGOCD_API_TOKEN, from a request presenting no caller credential of its own
Target resource
Argo CD's own API, specifically the Applications and resource action surface argocd-mcp's write mode tools expose
Environment
Wherever the operator deployed argocd-mcp, reachable to any network principal able to reach the bound listener
Credentials used
None presented by the calling request; the completed action instead carried the operator's own ARGOCD_API_TOKEN, read by the server from its own configured environment
Privileges available
Whatever Argo CD RBAC and project scope the operator's own configured ARGOCD_API_TOKEN carries
Authority presented
None. This entry confirmed directly that the credential check in front of the tool call does not require the request itself to present anything when the operator's own environment variable is configured
Authority required
An applicable, independently established caller identity or grant, distinct from the server's own downstream Argo CD credential, before the tool call is permitted to proceed
Applicable policy
None, before the fix, gating who could reach the listener or invoke a tool once connected; Host and Origin validation and a separate inbound bearer credential were added only in 0.9.0
Approval mechanism
none
Required approver
unknown
Independent approval
no
Action binding
The completed Argo CD API call bound to the operator's own configured token rather than to any credential or identity the calling request itself supplied
Sequence context
unknown

Impact

Consequence
Argo CD Application creation, update, deletion and sync, and resource level actions, executed under the operator's own configured Argo CD credential, reachable to a caller that presented nothing of its own
Reach
organisational
Reversibility
unknown
Detectability
unknown
Propagation
A concrete path exists, a created or synced Argo CD Application can direct further Kubernetes level deployment within whatever scope Argo CD's own project and RBAC configuration for that token permits, but this entry did not independently verify that effect for any specific deployment and does not extend the finding past the Argo CD API calls it confirmed directly
Recovery
Fixed in 0.9.0: loopback bind by default, a separate MCP_AUTH_TOKEN inbound bearer credential required to widen it or an explicit --allow-unauthenticated override, constant time comparison of that token, and Host and Origin validation; no process described for a request that may have already reached Argo CD before a given deployment upgraded

Evidence

Primary sources

Supporting sources

Reproduction status
Independently confirmed by Moona Intelligence reading the real, affected and fixed source directly, at the v0.8.0 and v0.9.0 tags and the fixing commit, rather than by running an exploit against a live deployment
Evidence state
Confirmed

Known unknowns

  • Whether this has been exploited against a real argocd-mcp deployment; no source available to this entry states that it was.
  • Whether the specific CVE identifier CVE-2026-82456 and GHSA identifier GHSA-p2x5-x87w-v2xj named in the brief that commissioned this entry refer to a real, separate record this entry could not locate, or do not exist at all; both returned not found in this session, and the affected repository's own advisories listing shows exactly one advisory for this vulnerability, under the identifier this entry uses instead.
  • What Argo CD project scoping and RBAC any specific affected deployment's own ARGOCD_API_TOKEN carried, and so what a created or synced Application could actually deploy into a cluster in that deployment.

Limitations

  • This entry could not independently confirm a CVE assignment for this vulnerability through any CVE numbering authority reachable in this session; the advisory this entry cites states plainly that no CVE is currently known.
  • This entry verifies the mechanism from the affected and fixed source directly rather than from an independently run reproduction against a live deployment.

Claim provenance

  • verified
    argoproj-labs's own advisory, fetched directly, rates the vulnerability CVSS 3.1 base 10.0 Critical, vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, under CWE-306, CWE-346 and CWE-1327, affecting argocd-mcp through 0.8.0 and fixed in 0.9.0, and states plainly that no CVE is currently known for it.
    Argo CD Knew Who the Server Was. It Still Did Not Know Who Asked the Server to Act.
  • verified
    This entry's own reading of src/server/transport.ts, src/server/server.ts, src/argocd/client.ts and src/argocd/http.ts at the v0.8.0 tag confirms the all interfaces bind, the resolveCredentials check's own indifference to whether the request itself supplied a credential once ARGOCD_API_TOKEN is configured, the write mode mutating tool set, and the outbound Authorization header built from that same operator configured token.
    Argo CD Knew Who the Server Was. It Still Did Not Know Who Asked the Server to Act.
  • verified
    This entry's own reading of the new src/server/security.ts module at this commit, the v0.9.0 tag target, confirms the loopback default bind address, the refusal to widen it without MCP_AUTH_TOKEN or an explicit override, the constant time comparison of that token, and the added Host and Origin validation, with GET /healthz confirmed exempt from all of it.
    Argo CD Knew Who the Server Was. It Still Did Not Know Who Asked the Server to Act.

Protocol evidence

Published authority architectures whose artifacts bear on the requirement this vulnerability exposes: which satisfy it, which expose a way past it, and which leave it unanswered.

  • Implementation evidence

    Agent Action Decision Protocol (AADP)

    Shamik Saha, individual submission to the IETF

    Requirement A Policy Decision Point owns authorization state and evidence; PEPs enforce it

    AADP requires a Policy Enforcement Point to hold a permit from a Policy Decision Point before performing a governed action. argocd-mcp 0.9.0's own MCP_AUTH_TOKEN check, confirmed directly against the fixed source, sits ahead of every tool call once a bind is widened beyond loopback, and the server refuses to start against a widened bind at all without that token configured or an explicit override. This is real, shipped enforcement evidence for a permit gating governed action, distinct from the pre fix state this vulnerability describes, in which no such enforcement point existed at all and the operator's own downstream Argo CD credential stood in for one.

    View protocol evidence

  • Contradicts requirement

    Agent Identity and Agent Identity Auth Manager

    Google

    Requirement With Agent Gateway and Gemini Enterprise, end user credentials are encrypted by Auth Manager and decrypted only at the gateway, so the agent never sees the raw credential

    Google's own stronger architecture keeps a raw third party credential from ever reaching the calling agent at all, decrypting it only at a mediating gateway. argocd-mcp 0.8.0 is the direct opposite of that property: the server's own ArgoCDClient attaches its configured ARGOCD_API_TOKEN to every outbound Argo CD request on behalf of any caller whose request the credential check accepted, which this entry confirmed included a caller who presented nothing at all. This entry does not read Google's property as a claim about MCP servers specifically; it reads argocd-mcp's own pre fix design as evidence contradicting the requirement wherever an intermediary attaches its own standing credential to a caller's request with no mediation narrower than the caller reaching the intermediary at all.

    View protocol evidence