Argo CD: When GitOps Becomes a Data-Breach Bridge

01 · A deployment controller is delegated authority

Argo CD continuously compares Kubernetes state with desired configuration in Git and reconciles approved changes. It is not merely a dashboard: its controllers and repository integrations act with authority that may exceed the authority of the person viewing an application. Argo CD security model.

Git and rendering

Repository credentials, manifests, Helm dependencies and configuration-management plugins determine what reaches reconciliation. Git write permission can become deployment influence.

Argo CD API and RBAC

SSO groups, project roles and API tokens govern application operations. “Read-only” describes permitted API operations, not a guarantee that every response is harmless.

Kubernetes execution

The destination credential and controller permissions determine which namespaces and resources can change. Application RBAC does not replace Kubernetes authorization.

Evidence and containment

Join the caller, application revision, controller identity, API decision and runtime image digest. A Synced status proves reconciliation, not trustworthy intent.

Threat model: assess a compromised developer identity, stolen project token or untrusted repository contribution. The origin is the application/control-plane layer. Impact can cross into cluster identities and deployed workloads, but host or cloud compromise requires further permissions or vulnerabilities. This is a conditional assessment model, not a report of a named breach.

02 · Critical CVEs—and the limitations of the evidence

Advisory	Prerequisites and impact	Patch evidence
CVE-2025-55190 Critical · 9.9	A project token or identity with applicable project permissions can obtain repository credentials through the detailed project response.	Introduced from 2.2.0-rc1; fixed in 2.13.9, 2.14.16, 3.0.14 and 3.1.2. These are historical patch floors, not current upgrade targets.
CVE-2026-42880 Critical · 9.6	Application read permission, accessible ServerSideDiff and IncludeMutationWebhook=true; a second SSA field manager can preserve Secret values in dry-run responses.	Maintainer range: 3.2.0–3.3.8; original fixes 3.2.11 and 3.3.9. Account for the follow-up below.
Follow-up annotation disclosure Moderate · 6.3	Secret values retained inside last-applied-configuration can survive masking in diffs.	Maintainer range: 3.2.0–3.2.11, 3.3.9 and 3.4.1; fixed 3.2.12, 3.3.10 and 3.4.2.
Application-link stored XSS High · 7.3	Application write access plus a privileged user clicking a crafted link can cross into that user's authenticated browser context.	Listed fixes: 3.2.12, 3.3.10, 3.4.2. The advisory's affected-version field conflicts with its tested 3.3.8 example; do not treat that field alone as a safe-version test.

Technical identity cards: vendor-reported CVSS vectors

55190: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
42880: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Follow-up: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N
Stored XSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N. Consult the linked advisory and supported release line before deciding exposure.

Do not manufacture a three-CVE chain. The repository-disclosure and ServerSideDiff flaws have different release windows. Demonstrate compatible versions and permissions before claiming they coexist. A missing prerequisite can break one route without making the entire installation safe.

03 · Interactive attack-path reconstruction

Caller → Argo CD authority → destination identity → workload or data

Credential route

What does the token authorize?

Record issuer, intended project, role, expiry and revocation status without copying the token. Compare allowed API operations with the effective response. A leaked repository credential is useful only where it is accepted.

Can the repository change production?

Check credential write scope, protected branches, independent review and the application's revision. Read-only repository credentials do not automatically permit malicious commits. Controls: narrowly scoped credentials and independent promotion approval.

Diff route

What crosses the dry-run boundary?

Diff computation can return data even when it persists no Kubernetes changes. Inspect application compare options and the published masking fixes. Keep actual Secret values out of browser recordings and assessment reports.

What proves the exposure?

Use a synthetic, disposable Secret only in an authorized test environment. Record whether the known marker is masked before and after remediation. A canary result establishes that route, not access to every Secret in the cluster.

Execution route

Which identity applies the change?

Trace the revision and sync operation to the destination identity. Evaluate namespace scope, resource allowlists, admission and workload ServiceAccount separately. Stop the path at the first denied boundary.

Does pod access become cluster authority?

Only if a usable credential, network route and authorization grant exist. Token audience, lifetime and binding matter. An accepted Kubernetes API action is evidence; possession of a token-shaped string is not.

1 · Initial authorityCompromised identity or exposed credential. Block with patched APIs and narrow roles.
2 · Trusted changeRepository write plus accepted revision. Block with protected review and promotion.
3 · ReconciliationDestination identity applies resources. Block with scoped RBAC and admission.
4 · Downstream accessWorkload credential and network reach. Block with workload identity and egress limits.

Conditional GitOps supply-chain scenario. Each arrow requires its own evidence; no arrow is guaranteed by a CVE identifier.

04 · Misconfiguration review checklist

Select only controls you have verified. This browser-only checklist is not a vulnerability scanner and sends nothing to a lab or cluster.

The default-role floor and project restrictions must be evaluated using the RBAC documentation. A deny elsewhere does not erase permissions granted by the default policy.

05 · RBAC and token-abuse review: collect authority, not secrets

Run these read-only checks only with an approved assessment identity. The examples assume the usual argocd namespace; replace it if your installation differs. A permission denial is an evidence gap, not a pass.

1 · Inventory what is actually deployed

Capture image tags and runtime imageIDs. The CLI version alone cannot establish the server's version.

bashkubectl -n argocd get pods -o json | jq '.items[] | {pod:.metadata.name, images:[.spec.containers[].image], imageIDs:[.status.containerStatuses[]?.imageID]}'

2 · Inspect the authorization policy and project boundaries

Review policy inheritance and the resource/destination scope. These ConfigMaps and project specifications may reveal internal names; preserve them as restricted evidence.

bashkubectl -n argocd get configmap argocd-rbac-cm -o json | jq '.data'
kubectl -n argocd get appprojects -o json | jq '.items[] | {name:.metadata.name, sourceRepos:.spec.sourceRepos, destinations:.spec.destinations, clusterResourceWhitelist:.spec.clusterResourceWhitelist, namespaceResourceWhitelist:.spec.namespaceResourceWhitelist}'
kubectl -n argocd get applications -o json | jq '.items[] | {name:.metadata.name, project:.spec.project, compareOptions:.metadata.annotations["argocd.argoproj.io/compare-options"]}'

3 · Ask authorization questions without exercising the action

The following checks assess the current identity. A cluster administrator may separately use approved impersonation to review the actual controller or workload identity; never confuse these results with another account's rights.

bashkubectl auth can-i create pods -n argocd
kubectl auth can-i create pods/exec -n argocd
kubectl auth can-i get secrets -n argocd
kubectl auth can-i bind clusterroles.rbac.authorization.k8s.io
kubectl auth can-i escalate clusterroles.rbac.authorization.k8s.io

Expert tip: a ServiceAccount able to create pods may obtain indirect access to data mounted by those pods. Review admission and allowed ServiceAccounts, not just get secrets. Do not extract or replay production bearer tokens as a shortcut.

06 · Evidence that survives a skeptical review

Unexpected project-detail reads

Argo API logs: unusual calls to detailed project endpoints by automation identities. Medium-confidence lead; ordinary administrative reads are a false-positive source.

Diff behavior changes

Application audit changes to compare options followed by unusual diff activity. Medium-confidence lead; inspect the approved change history before escalation.

Identity discontinuity

A token or controller begins accessing namespaces outside its baseline. Correlated Git, Argo and API events raise confidence; a single unusual event does not prove compromise.

Browser trust abuse

New application-link annotations, followed by privileged browser actions. Preserve sanitized metadata, not malicious-link execution or captured user credentials.

Retain Argo API/security events, Git reviews, identity-provider sessions and Kubernetes audit metadata. Avoid request/response body logging for Secrets. The following is an illustrative complete metadata-only audit policy; managed clusters may require provider-side logging configuration. Merge these rules into your existing audit policy rather than replacing unrelated coverage; the final None rule drops unmatched events. Integrate retention and volume limits before enabling it. Kubernetes audit policy.

yamlapiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  # Metadata captures actor, resource and decision without Secret bodies.
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "pods", "pods/exec"]
      - group: "rbac.authorization.k8s.io"
        resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
      - group: "argoproj.io"
        resources: ["applications", "appprojects", "applicationsets"]
  - level: None

For a preserved JSON-lines audit export, this query emits only metadata for ServiceAccount activity. It is a triage filter, not a CVE signature:

bashjq -c 'select((.user.username // "") | startswith("system:serviceaccount:")) | select(.objectRef.resource == "secrets" or .objectRef.subresource == "exec" or .objectRef.apiGroup == "rbac.authorization.k8s.io") | {time:.requestReceivedTimestamp,actor:.user.username,verb,resource:.objectRef.resource,namespace:.objectRef.namespace,code:.responseStatus.code}' audit.jsonl

MITRE ATT&CK mapping: use T1552.001 — Credentials In Files only when the evidence includes such credential access; use T1609 — Container Administration Command when an administrative container action is demonstrated. These labels describe behavior, not automatic CVE outcomes.

07 · Break the route, then prove the fix

Contain

Preserve evidence and restrict the affected API, identity or reconciliation scope through an approved incident process. Record each temporary rule and owner; avoid an unplanned fleet-wide sync interruption.

Patch and recover

Upgrade to a currently supported release containing every applicable fix. Test against your manifests and plugins first. Rotate established exposures from a trusted administration path; patching does not revoke stolen tokens.

Reduce standing authority

Use tenant-specific projects, constrained destination identities, reviewed Git changes and enforced admission. Separate rendering, reconciliation and application workload identities.

Validate and roll back safely

Re-run the same canary and deny tests after remediation. Retain the previous policy revision for approved rollback. Do not roll software back into a known vulnerable version; follow supported recovery or roll-forward guidance.

Configuration-review standard: every exception needs an owner, reason, expiry and negative test. Review the rendered configuration and effective policy—not only the intended Helm values. Record unresolved visibility gaps explicitly.

08 · Final word

I treat GitOps as an authority pipeline. My review is not finished when the dashboard says Synced; it is finished when I can explain who proposed the change, who authorized it, which identity applied it, and which control rejects an unauthorized alternative.

Protect the controller's authority as carefully as the cluster it controls.

Riad DAHMANI — K8SEC Security Research

Connect the control plane to infrastructure evidence

K8SEC Agent maps Kubernetes relationships read-only. It does not collect Secret values, execute in pods, mutate resources or autonomously exploit these routes. Correlate its graph with separately authorized Argo and Git evidence.

Explore KAOS Kubernetes audit-log guide

Reviewed September 12, 2026. Source and version claims link to maintainer advisories above. Scenarios, checklists and investigation guidance are K8SEC analysis. Commands are reviewed and syntax-checked, not validated against a live vulnerable installation. Offensive validation belongs only in authorized isolated environments.