CVE-2026-42297
Authorization Bypass in Argo Workflows ConfigMap Provider
Publication date: 2026-05-09
Last updated on: 2026-05-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| argoproj | argo_workflows | From 4.0.0 (inc) to 4.0.5 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-862 | The product does not perform an authorization check when an actor attempts to access a resource or perform an action. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows any authenticated user, including those with fake Bearer tokens, to create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits without proper authorization checks.
This unauthorized access can lead to disclosure of sensitive information, disruption of workflows, and denial of service, which may impact the confidentiality, integrity, and availability of data.
Such impacts could potentially affect compliance with common standards and regulations like GDPR and HIPAA, which require strict controls over data access and integrity to protect sensitive information.
Can you explain this vulnerability to me?
CVE-2026-42297 is a security vulnerability in Argo Workflows affecting the Sync Service's ConfigMap-backed provider. From versions 4.0.0 to before 4.0.5, this component performed no authorization checks on create, read, update, or delete operations on Kubernetes ConfigMaps that contain synchronization limits.
This means that any authenticated user, even those using fake Bearer tokens, could perform these operations without proper permission checks. The root cause was that in Server or SSO authentication modes, the server's privileged client bypassed authorization entirely, relying only on the Kubernetes client's identity for RBAC checks, which was insufficient.
The vulnerability was fixed in version 4.0.5 by introducing explicit authorization checks (SelfSubjectAccessReview) before each ConfigMap operation, ensuring proper permission enforcement regardless of authentication mode.
How can this vulnerability impact me? :
This vulnerability allows any authenticated user with network access to the Argo Server to create, read, update, or delete Kubernetes ConfigMaps that control synchronization limits.
- An attacker can cause denial of service by disrupting workflows.
- Sensitive information stored in ConfigMaps can be disclosed.
- Attackers can manipulate ConfigMaps in any namespace accessible to the server's service account, potentially affecting system integrity and availability.
Overall, the vulnerability has a high severity score (CVSS 8.5) due to its impact on integrity and availability of the system.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the Sync Service's ConfigMap-backed provider in Argo Workflows performing zero authorization checks on CRUD operations for ConfigMaps. Detection involves verifying if your Argo Workflows version is between 4.0.0 and before 4.0.5 and checking if unauthorized users can perform create, read, update, or delete operations on ConfigMaps related to synchronization limits.
You can attempt to detect exploitation by testing access to ConfigMaps via the Argo Server API or Kubernetes API using bearer tokens, including fake ones, to see if unauthorized CRUD operations are permitted.
Suggested commands to test this include:
- Using kubectl with a bearer token to attempt to get or modify ConfigMaps in namespaces accessible to the Argo Server service account.
- Example: kubectl --token=<fake-or-unauthorized-token> get configmap -n <namespace>
- Attempt to create or delete ConfigMaps similarly with kubectl and an unauthorized token.
Monitoring logs of the Argo Server for unauthorized ConfigMap CRUD requests or unusual activity may also help detect exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade Argo Workflows to version 4.0.5 or later, where the vulnerability has been patched by introducing explicit authorization checks (SelfSubjectAccessReview) for ConfigMap operations.
Until the upgrade can be applied, restrict network access to the Argo Server to trusted users only, minimizing exposure to potential attackers.
Review and tighten Kubernetes RBAC policies to limit which users and service accounts can access or modify ConfigMaps related to Argo Workflows synchronization.
Monitor Argo Server logs for suspicious ConfigMap CRUD operations and investigate any unauthorized access attempts.