CVE-2026-28229: 
Wolfi vulnerability analysis and mitigation

CVE-2026-28229 is an unauthorized access vulnerability in Argo Workflows, an open-source container-native workflow engine for Kubernetes, that allows any unauthenticated client to retrieve WorkflowTemplates and ClusterWorkflowTemplates — including embedded Kubernetes Secret manifests. The vulnerability was published on March 11, 2026, and affects versions >= 3.7.0 and < 3.7.11, as well as versions < 4.0.2 in the 4.0.x branch. It carries a CVSS v3.1 base score of 7.5 (High) per the GitHub Advisory Database, though the security advisory itself rates it 9.1 (Critical) (Github Advisory, Argo Security Advisory).

The root cause is an incorrect authorization check (CWE-863) and missing authentication for a critical function (CWE-306) introduced when informer-based caching was added to the workflow template server. The GetWorkflowTemplate and GetClusterWorkflowTemplate server handlers retrieve template data from an in-memory informer cache populated using the server's own service account credentials, but they fail to perform any auth.CanI() authorization check against the caller's identity before returning data. As a result, any HTTP request bearing even a syntactically invalid bearer token (e.g., Authorization: Bearer nothing) bypasses authentication and receives the full template JSON, including embedded Secret manifests. The fix (commit 34afaf9) adds explicit auth.CanI() checks in both handlers before serving data from the cache (Argo Security Advisory, Fix Commit).

Successful exploitation allows any unauthenticated network attacker to exfiltrate the full content of WorkflowTemplates and ClusterWorkflowTemplates, which may contain Kubernetes Secret manifests (including base64-encoded credentials), artifact storage locations, service account names, environment variables, and resource manifests. This constitutes a high-severity confidentiality breach that could expose credentials enabling lateral movement within the Kubernetes cluster or to connected external systems. Integrity and availability are not directly impacted by this vulnerability (Github Advisory, Argo Security Advisory).

A proof-of-concept exploit is publicly available in the official security advisory, consisting of a simple curl command with a fake bearer token targeting the workflow template API endpoint — no special tooling or privileges are required (Argo Security Advisory). The EPSS score is approximately 0.017% (0.041% per Feedly), indicating a currently low probability of active exploitation in the wild. There is no evidence of in-the-wild exploitation or threat actor attribution at this time, and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible Argo Workflows server instances (default port 2746) running versions >= 3.7.0 and < 3.7.11, or >= 4.0.0 and < 4.0.2, using tools like Shodan, Censys, or internal network scanning.
2. Enumerate template names: If template names are not already known, attempt to list templates via the API (e.g., GET /api/v1/workflow-templates/{namespace}) or infer common names from organizational conventions.
3. Send unauthenticated request with fake token: Issue an HTTP GET request to the target Argo Workflows API with any syntactically present but invalid bearer token:

curl -sk -H "Authorization: Bearer nothing" \
  "https://<argo-server>:2746/api/v1/workflow-templates/argo/leak-workflow-template"

4. Extract sensitive data: Parse the returned JSON response to extract embedded Kubernetes Secret manifests (base64-encoded credentials), artifact storage configurations, service account names, and environment variables.
5. Leverage extracted credentials: Decode base64-encoded secrets and use extracted credentials to authenticate to Kubernetes clusters, cloud storage, CI/CD systems, or other connected infrastructure for lateral movement (Argo Security Advisory).

• Network: Unexpected HTTP GET requests to /api/v1/workflow-templates/{namespace}/{name} or /api/v1/cluster-workflow-templates/{name} on port 2746 from unknown or external IP addresses; requests bearing Authorization: Bearer nothing or other clearly invalid/placeholder tokens.
• Logs: Argo Workflows server access logs showing successful (HTTP 200) responses to workflow template or cluster workflow template GET endpoints from unauthenticated or unrecognized clients; high volume of template retrieval requests from a single source IP.
• Logs: Absence of corresponding user activity in Argo UI or CLI sessions that would explain template access patterns — indicating programmatic/automated scraping.
• File System / Kubernetes: Unexpected use of credentials or service accounts that were embedded in workflow templates, such as new Kubernetes API calls or cloud API calls using those credentials shortly after template access events.

Upgrade Argo Workflows to version 3.7.11 (for the 3.7.x branch) or 4.0.2 (for the 4.0.x branch), which add explicit auth.CanI() authorization checks before serving template data from the informer cache (v3.7.11 Release, v4.0.2 Release). As an interim workaround, implement network-level access controls (firewall rules, Kubernetes NetworkPolicies, or API gateway authentication) to restrict access to the Argo Workflows API (port 2746) to trusted clients only. Additionally, review Argo Workflows server access logs to determine whether template endpoints were accessed by unauthorized clients prior to patching, and rotate any credentials embedded in workflow templates as a precaution (Argo Security Advisory).

The vulnerability was reported by security researcher Masamuneee and published by the Argo Workflows maintainer Joibel on March 11, 2026, the same day patches were released, indicating a coordinated disclosure process (Argo Security Advisory). The issue received coverage from threat intelligence aggregators including The Hacker Wire and Yazoul, and was discussed on Mastodon and Bluesky by security community members. Red Hat also tracked the vulnerability via Bugzilla, reflecting its relevance to OpenShift and related Kubernetes distributions.