CVE-2026-93991 in Argo Workflows
Summary
by MITRE • 09/20/2026
Argo Workflows versions 4.1.0 through 4.1.3 contain an authorization bypass vulnerability in ListArchivedWorkflows that fails to apply cluster-scoped access review when the metadata.namespace field selector uses the NotEquals operator. Attackers with namespace-scoped list permissions can use a negated namespace field selector to retrieve archived workflows from all other namespaces, exposing spec arguments, parameter values, and annotations.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/20/2026
The vulnerability identified in Argo Workflows versions 4.1.0 through 4.1.3 represents a critical authorization bypass within the ListArchivedWorkflows API endpoint. This flaw stems from an incorrect implementation of access control logic when handling field selectors that utilize the NotEquals operator on the metadata.namespace field. In standard Kubernetes and Argo workflows, namespace-scoped permissions are designed to restrict user actions to resources within specific namespaces unless explicitly granted broader cluster-wide privileges. However, in this specific scenario, the authorization mechanism fails to perform a comprehensive cluster-scoped access review when such negated selectors are employed. Consequently, users who possess only list permissions for their own or specific designated namespaces can exploit this logic error to bypass those restrictions entirely.
From a technical perspective, the root cause lies in how the API server processes field selector conditions during authorization checks. When a request is made with a namespace filter that excludes certain namespaces using NotEquals, the system incorrectly assumes that if the user has permission for any remaining included namespaces, they should be granted access to all resources matching the query across the entire cluster. This oversight means the security boundary between namespace-scoped and cluster-scoped permissions is effectively dissolved under these specific conditions. The vulnerability allows an authenticated attacker with limited privileges to enumerate archived workflows from every other namespace in the cluster, regardless of their actual assigned role or policy restrictions.
The operational impact of this vulnerability is significant due to the sensitive nature of data contained within workflow archives. Archived workflows often contain historical execution details that include spec arguments, parameter values, and annotations. These elements can expose critical configuration settings, internal API endpoints, database connection strings, authentication tokens, or other secrets embedded in the workflow definitions. An attacker leveraging this flaw could conduct a broad reconnaissance operation to map out the infrastructure's architecture, identify sensitive data stores, or gather information necessary for further exploitation such as privilege escalation attacks. The exposure of annotations may also reveal internal service mesh configurations or deployment strategies that are valuable for targeted attacks against other components in the environment.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where an actor is granted privileges they should not have due to a logic error in access control decisions. Furthermore, it relates to ATT&CK technique T1078, Valid Accounts, as exploitation relies on using legitimate but insufficiently restricted credentials to gain unauthorized access to resources across multiple namespaces. The behavior also reflects aspects of CWE-284, Improper Access Control, where the system fails to enforce intended restrictions based on user roles and resource scope.
To mitigate this risk, organizations running Argo Workflows versions 4.1.0 through 4.1.3 must upgrade immediately to a patched version that corrects the authorization logic for field selectors involving NotEquals operators. Until an upgrade is feasible, administrators should implement strict network-level controls or API gateway policies to restrict access to the ListArchivedWorkflows endpoint based on IP addresses and known service accounts rather than relying solely on internal RBAC rules. Additionally, auditing existing roles and cluster role bindings can help identify users with broad list permissions that could be exploited via this vector. It is also advisable to review workflow templates for hardcoded secrets or sensitive data in annotations and parameters, ensuring that even if such enumeration occurs, the exposed information does not compromise downstream systems. Regular security assessments focusing on RBAC configurations are recommended to prevent similar logic flaws from being introduced during future updates or customizations.