CVE-2026-42183 — v4
Fix: argoproj/argo-workflows@c4cc17dCVE-2026-42183 is a NULL Pointer Dereference vulnerability in github.com/argoproj/argo-workflows/v4. A fix is available for github.com/argoproj/argo-workflows/v4 — see the affected versions and patch details below.
Argo Workflows: SSO RBAC Delegation Nil Pointer Dereference DoS (gatekeeper.go)
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42183.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/argoproj/argo-workflows/v4Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/argoproj/argo-workflows/v4 | ≥ 4.0.0&&< 4.0.5 | 4.0.5go get github.com/argoproj/argo-workflows/v4@v4.0.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-workflows/v4, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/argoproj/argo-workflows/v4 to 4.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42183 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-42183 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-42183. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-42183 in your dependencies?
O3 Security finds CVE-2026-42183 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.