Argo Workflows CVE-2026-42183
LOWSeverity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionGitHub Advisory
Summary
A nil pointer dereference in server/auth/gatekeeper.go rbacAuthorization() causes a panic (denial of service) for SSO users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule, when SSO_DELEGATE_RBAC_TO_NAMESPACE=true.
Details
When getServiceAccount(claims, ssoNamespace) returns nil (no matching rule), the error is suppressed and loginAccount remains nil. If RBAC delegation finds a matching namespaceAccount, line 304 calls precedence(loginAccount) which unconditionally accesses serviceAccount.Annotations - nil pointer dereference.
Affected code (v4.0.4):
// gatekeeper.go:304
} else if precedence(namespaceAccount) > precedence(loginAccount) {
// loginAccount is nil here -> precedence(nil) -> PANIC
// gatekeeper.go:232-234
func precedence(serviceAccount *corev1.ServiceAccount) int {
i, _ := strconv.Atoi(serviceAccount.Annotations[common.AnnotationKeyRBACRulePrecedence])
return i
}PoC
Live-tested 2026-04-17: kind cluster, Argo Workflows v4.0.4, Dex v2.43.1 OIDC provider.
- Deploy Argo Workflows with
--auth-mode=sso --auth-mode=client, SSO pointing to Dex, RBAC enabled. - Set
SSO_DELEGATE_RBAC_TO_NAMESPACE=trueon the argo-server deployment. - Create an RBAC ServiceAccount with
workflows.argoproj.io/rbac-rule: "true"annotation in a target namespace (e.g.,target-ns). - Do not create a matching RBAC rule in the SSO namespace (
argo). - Authenticate via the Dex SSO flow.
- Request
GET /api/v1/workflows/target-nswith the SSO session cookie. - Server returns HTTP 500:
{"code":13,"message":"runtime error: invalid memory address or nil pointer dereference"} - Server logs:
Recovered from panicwith stack trace atgatekeeper.go:233(precedence()) called fromgatekeeper.go:304.
Every subsequent API request from affected SSO users triggers the same panic.
Impact
Permanent denial of service for any SSO user whose claims don't match SSO-namespace RBAC but do match a target namespace rule. Realistic in multi-tenant deployments with per-namespace RBAC. The gRPC recovery interceptor catches the panic so the server process survives, but the affected user gets HTTP 500 on every request.
Suggested Fix
Add nil check: if loginAccount == nil || precedence(namespaceAccount) > precedence(loginAccount)
AI Disclosure
This advisory was prepared with AI assistance (Claude Code, Anthropic).
AnalysisAI
Denial of service via nil pointer dereference in Argo Workflows 4.0.0-4.0.4 affects SSO users with RBAC namespace delegation enabled when their identity claims match a namespace-level RBAC rule but not an SSO-namespace rule. The gatekeeper.go rbacAuthorization() function unconditionally dereferences a nil serviceAccount pointer when comparing rule precedence, causing an HTTP 500 panic on every API request from the affected user. Live-tested exploit confirmed on v4.0.4 with Dex OIDC provider; vendor patch released as v4.0.5.
Technical ContextAI
Argo Workflows is a Kubernetes-native workflow orchestration engine that supports SSO authentication via OIDC (OpenID Connect) providers like Dex and implements role-based access control (RBAC) via ServiceAccount annotations. When the SSO_DELEGATE_RBAC_TO_NAMESPACE environment variable is enabled, the authorization logic attempts to match user identity claims against both SSO-namespace RBAC rules and delegated namespace-level rules. The vulnerability resides in server/auth/gatekeeper.go at the rbacAuthorization() function, specifically in the precedence comparison logic at lines 232-304. The precedence() helper function (line 232) accesses serviceAccount.Annotations without null checking, and the conditional at line 304 calls precedence(loginAccount) where loginAccount may be nil if getServiceAccount(claims, ssoNamespace) returns nil for a user whose claims do match a namespace-delegated rule. This is a classic null pointer dereference (CWE-476) in Go, where a nil interface{} pointer is dereferenced, triggering a runtime panic caught by the gRPC recovery interceptor, resulting in HTTP 500 errors. CPE: pkg:go/github.com/argoproj/argo-workflows/v4.
RemediationAI
Upgrade to Argo Workflows v4.0.5 or later, which includes the nil pointer check in the precedence comparison logic (commit c4cc17d0c034fa9a9cc01ef1af6c8016c93071d4). The patched code adds a guard condition if loginAccount == nil || precedence(namespaceAccount) > precedence(loginAccount) and ensures the logging code handles nil loginAccount gracefully. If immediate upgrade is not possible, disable SSO_DELEGATE_RBAC_TO_NAMESPACE (set to false or leave unset) to revert to SSO-namespace-only RBAC rules, though this reduces per-namespace RBAC flexibility. Alternatively, ensure all SSO user claims have matching RBAC ServiceAccount entries in the SSO namespace (argo by default) to prevent the nil loginAccount condition; however, this is a configuration workaround and does not address the underlying code defect. The patch is minimal and low-risk; upgrading is strongly recommended. See https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5.
Same weakness CWE-476 – NULL Pointer Dereference
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-p4gq-3vxj-f4jq