Answer in brief
CVE-2026-42183 records a Unknown severity vulnerability in Argo Affected by SSO RBAC Delegation Nil Pointer Dereference DoS (gatekeeper.go). The current sources do not mark it as known exploited. The current feed maps github.com/argoproj/argo-workflows/v4 (go). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps github.com/argoproj/argo-workflows/v4 (go). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/argoproj/argo-workflows/v4go | >=4.0.0 <4.0.5 | 4.0.5 |
Published upstream
May 4, 2026
Evidence: source:osv:source_dates:source-dates:recordSource modified
Sep 10, 2026
Evidence: source:osv:source_dates:source-dates:recordFirst seen by HOL
Sep 10, 2026
### 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):** ```go // 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. 1. Deploy Argo Workflows with `--auth-mode=sso --auth-mode=client`, SSO pointing to Dex, RBAC enabled. 2. Set `SSO_DELEGATE_RBAC_TO_NAMESPACE=true` on the argo-server deployment. 3. Create an RBAC ServiceAccount with `workflows.argoproj.io/rbac-rule: "true"` annotation in a target namespace (e.g., `target-ns`). 4. Do **not** create a matching RBAC rule in the SSO namespace (`argo`). 5. Authenticate via the Dex SSO flow. 6. Request `GET /api/v1/workflows/target-ns` with the SSO session cookie. 7. Server returns HTTP 500: `{"code":13,"message":"runtime error: invalid memory address or nil pointer dereference"}` 8. Server logs: `Recovered from panic` with stack trace at `gatekeeper.go:233` (`precedence()`) called from `gatekeeper.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).
Quoted source text, attributed separately from HOL analysis.