CVE-2026-42183
Argo Workflows RBAC Authorization Denial of Service
Publication date: 2026-05-09
Last updated on: 2026-05-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| argoproj | argo_workflows | From 4.0.0 (inc) to 4.0.5 (exc) |
| argoproj | argo_workflows | From 4.0.1 (inc) to 4.0.4 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-476 | The product dereferences a pointer that it expects to be valid but is NULL. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-42183 is a vulnerability in Argo Workflows versions 4.0.0 to before 4.0.5 involving a nil pointer dereference in the gatekeeper.go file. This occurs when Single Sign-On (SSO) users have claims that match a namespace-level RBAC rule but not an SSO-namespace rule, and the configuration SSO_DELEGATE_RBAC_TO_NAMESPACE is set to true.
Under these conditions, the variable loginAccount becomes nil after getServiceAccount() returns nil. The code then calls the precedence() function on loginAccount without checking if it is nil, causing a panic (denial of service) because precedence() accesses serviceAccount.Annotations unconditionally.
This results in affected SSO users receiving HTTP 500 errors on every subsequent request, effectively causing a denial of service. The issue was patched in version 4.0.5 by adding a nil check before calling precedence(loginAccount).
How can this vulnerability impact me? :
This vulnerability can cause a denial of service (DoS) for SSO users in Argo Workflows under specific RBAC configurations. Affected users will experience HTTP 500 errors on every request, preventing them from successfully using the system.
The impact is limited to users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule when SSO_DELEGATE_RBAC_TO_NAMESPACE is enabled. The vulnerability requires network access, low attack complexity, and low privileges.
Overall, this could disrupt workflow orchestration for affected users, potentially impacting operational continuity until the system is updated to version 4.0.5 or later.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability causes a panic (denial of service) resulting in HTTP 500 errors for affected SSO users when certain RBAC conditions are met and the environment variable SSO_DELEGATE_RBAC_TO_NAMESPACE is set to true.
To detect this vulnerability on your system, monitor your Argo Workflows server logs for repeated HTTP 500 errors related to SSO user requests, especially if those users have claims matching namespace-level RBAC rules but not SSO-namespace rules.
You can also check the version of Argo Workflows running on your system to see if it is between 4.0.0 and before 4.0.5, which are the vulnerable versions.
- Check Argo Workflows version: `argo version` or check the deployment manifest for the image tag.
- Inspect logs for HTTP 500 errors related to SSO user requests: `kubectl logs <argo-workflows-pod> | grep 'HTTP 500'`
- Verify if the environment variable `SSO_DELEGATE_RBAC_TO_NAMESPACE` is set to true in your deployment configuration.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade Argo Workflows to version 4.0.5 or later, where the vulnerability has been patched by adding a nil check to prevent the panic.
If upgrading immediately is not possible, consider temporarily disabling the environment variable `SSO_DELEGATE_RBAC_TO_NAMESPACE` or adjusting RBAC rules to avoid the specific condition that triggers the panic.
Monitor your system for HTTP 500 errors related to SSO users and be prepared to restart the Argo Workflows server if it becomes unresponsive due to this denial of service.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.