CVE-2026-28229: Argo Workflows Information Disclosure Flaw

CVE-2026-28229 Overview

Argo Workflows, an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes, contains a critical authorization bypass vulnerability in its workflow template endpoints. Prior to versions 4.0.2 and 3.7.11, the workflow templates endpoints fail to properly authenticate API requests, allowing any client to retrieve WorkflowTemplates and ClusterWorkflowTemplates. An attacker can exploit this flaw by submitting requests with a malformed Authorization: Bearer nothing token to leak sensitive template content, including embedded Secret manifests.

Critical Impact

Unauthorized access to workflow templates can expose sensitive Kubernetes secrets, credentials, and configuration data embedded within templates, potentially compromising the entire Kubernetes cluster environment.

Affected Products

• Argo Workflows versions prior to 4.0.2
• Argo Workflows versions prior to 3.7.11
• Kubernetes clusters running vulnerable Argo Workflows deployments

Discovery Timeline

• 2026-03-11 - CVE CVE-2026-28229 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-28229

Vulnerability Analysis

This vulnerability is classified as CWE-863 (Incorrect Authorization), indicating a fundamental flaw in the authentication and authorization logic of the Argo Workflows API. The workflow templates endpoints fail to properly validate authentication tokens, accepting arbitrary bearer tokens including the literal string "nothing" as valid authentication credentials.

The root cause lies in improper token validation within the API authentication middleware. When processing requests to WorkflowTemplate and ClusterWorkflowTemplate endpoints, the system does not adequately verify the validity of the provided bearer token before granting access to protected resources. This allows unauthenticated attackers to bypass security controls entirely.

The impact is severe because WorkflowTemplates and ClusterWorkflowTemplates often contain embedded Kubernetes Secret references or inline secret values used for authentication, API keys, database credentials, and other sensitive configuration data required for workflow execution.

Root Cause

The vulnerability stems from improper authorization checks in the Argo Workflows API authentication layer. The endpoints responsible for serving WorkflowTemplate and ClusterWorkflowTemplate resources accept any bearer token without proper validation, effectively treating all requests as authenticated regardless of the token's actual validity. This design flaw allows attackers to bypass authentication entirely by providing arbitrary token values.

Attack Vector

This vulnerability is exploitable over the network without requiring prior authentication or user interaction. An attacker with network access to the Argo Workflows API can craft HTTP requests with a forged Authorization header to retrieve sensitive workflow template content.

The attack proceeds as follows:

1. Attacker identifies an exposed Argo Workflows API endpoint
2. Attacker crafts an HTTP request to the workflow templates endpoint with an arbitrary bearer token (e.g., Authorization: Bearer nothing)
3. The vulnerable API accepts the malformed token and returns WorkflowTemplate or ClusterWorkflowTemplate resources
4. Attacker extracts embedded secrets, credentials, or sensitive configuration data from the returned templates

For detailed technical information about the vulnerability mechanism, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-28229

Indicators of Compromise

• Unusual API requests to /api/v1/workflow-templates or /api/v1/cluster-workflow-templates endpoints
• Authentication logs showing repeated access with invalid or suspicious bearer tokens
• Unexpected API activity from external IP addresses accessing workflow template resources
• Bulk retrieval of WorkflowTemplate resources from a single source

Detection Strategies

• Monitor Argo Workflows API access logs for requests with malformed or suspicious authorization headers
• Implement network segmentation monitoring to detect unauthorized access attempts to the Argo Workflows API
• Deploy SentinelOne Singularity Platform to detect anomalous Kubernetes API activity and unauthorized container access patterns
• Review audit logs for unexpected WorkflowTemplate or ClusterWorkflowTemplate retrievals

Monitoring Recommendations

• Enable detailed access logging for all Argo Workflows API endpoints
• Configure alerting for any API access from non-whitelisted IP ranges or service accounts
• Implement Kubernetes audit logging to track all resource access within the cluster
• Monitor for credential exposure by scanning logs and templates for sensitive data patterns

How to Mitigate CVE-2026-28229

Immediate Actions Required

• Upgrade Argo Workflows to version 4.0.2 or 3.7.11 immediately
• Restrict network access to Argo Workflows API endpoints using Kubernetes NetworkPolicies or firewall rules
• Audit all existing WorkflowTemplates and ClusterWorkflowTemplates for exposed secrets and rotate any compromised credentials
• Review API access logs for signs of prior exploitation

Patch Information

Argo Workflows has released security patches addressing this vulnerability. Organizations should upgrade to version 4.0.2 (for the 4.x branch) or version 3.7.11 (for the 3.x branch). The patches implement proper authentication validation for workflow template endpoints, ensuring that only properly authenticated requests can access sensitive template resources.

Refer to the GitHub Security Advisory for official patch details and upgrade instructions.

Workarounds

• Implement Kubernetes NetworkPolicies to restrict access to Argo Workflows pods from untrusted networks
• Use an ingress controller or API gateway with proper authentication enforcement in front of Argo Workflows
• Remove embedded secrets from WorkflowTemplates and use Kubernetes Secret references with proper RBAC controls instead
• Deploy a service mesh with mTLS to enforce mutual authentication for all API communications

# Example NetworkPolicy to restrict Argo Workflows API access
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-argo-workflows-api
  namespace: argo
spec:
  podSelector:
    matchLabels:
      app: argo-server
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          trusted: "true"
    ports:
    - protocol: TCP
      port: 2746
EOF