{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/argo-workflows/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":6.5,"id":"CVE-2025-62157"}],"_cs_exploited":false,"_cs_products":["argo-workflows"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","credential-access","kubernetes"],"_cs_type":"advisory","_cs_vendors":["Argoproj","Google","Microsoft"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, is vulnerable to credential exposure. Specifically, versions 4.0.0 through 4.0.4 inadvertently log artifact repository credentials in plaintext during artifact operations. This includes sensitive data like S3 Access Keys, Secret Keys, Session Tokens, Server-Side Customer Keys, OSS Access Keys, Secret Keys, Security Tokens, and GCS Service Account Keys. The vulnerability stems from the logging driver passing the entire ArtifactDriver struct to the structured logger. Any user with read access to workflow pod logs can extract these credentials, creating a significant security risk. This is an incomplete fix of CVE-2025-62157.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains read access to Kubernetes pod logs within the Argo Workflows namespace. This could be achieved through compromised credentials, misconfigured RBAC policies, or other Kubernetes vulnerabilities.\u003c/li\u003e\n\u003cli\u003eThe attacker identifies a workflow that utilizes artifact storage, such as S3 or GCS.\u003c/li\u003e\n\u003cli\u003eThe workflow executes an artifact operation (upload or download).\u003c/li\u003e\n\u003cli\u003eArgo Workflows logs the entire ArtifactDriver struct, including the plaintext credentials, into the pod logs.\u003c/li\u003e\n\u003cli\u003eThe attacker queries the pod logs using \u003ccode\u003ekubectl\u003c/code\u003e or other Kubernetes tooling. For example: \u003ccode\u003ekubectl -n argo logs \u0026quot;cred-leak-test\u0026quot; -c wait\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker extracts the plaintext credentials (e.g., S3 Access Key and Secret Key) from the log output.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the extracted credentials to access the artifact repository (e.g., S3 bucket) and potentially steal data or perform other unauthorized actions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows unauthorized access to artifact repositories used by Argo Workflows. This can lead to data breaches, as sensitive data stored in S3 buckets, GCS buckets, or other storage solutions can be exposed. The impact is especially severe if the compromised credentials have broad permissions or if the artifact repository contains highly sensitive data. This affects Argo Workflows versions 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Argo Workflows to version 4.0.5 or later to remediate the vulnerability (CVE-2026-42295).\u003c/li\u003e\n\u003cli\u003eReview and restrict Kubernetes RBAC permissions to limit access to pod logs, following the principle of least privilege.\u003c/li\u003e\n\u003cli\u003eImplement log monitoring and alerting for unusual access patterns to Kubernetes pod logs.\u003c/li\u003e\n\u003cli\u003eRotate any potentially exposed artifact repository credentials (S3 access keys, GCS service account keys, etc.) if Argo Workflows versions 4.0.0-4.0.4 were in use.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:12:01Z","date_published":"2026-05-04T20:12:01Z","id":"/briefs/2024-01-09-argo-cred-leak/","summary":"Argo Workflows versions 4.0.0 to 4.0.4 log artifact repository credentials in plaintext, allowing users with read access to pod logs to extract sensitive information such as S3 access keys and GCS service account keys.","title":"Argo Workflows Credentials Exposed in Pod Logs","url":"https://feed.craftedsignal.io/briefs/2024-01-09-argo-cred-leak/"},{"_cs_actors":[],"_cs_cves":[{"cvss":8.1,"id":"CVE-2026-31892"}],"_cs_exploited":false,"_cs_products":["argo-workflows"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","kubernetes","privilege-escalation","defense-evasion"],"_cs_type":"advisory","_cs_vendors":["Argo"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, contains an incomplete fix for CVE-2026-31892. The initial patch blocked \u003ccode\u003epodSpecPatch\u003c/code\u003e modifications when \u003ccode\u003etemplateReferencing: Strict\u003c/code\u003e was active. However, other fields within the WorkflowSpec that influence pod creation, such as \u003ccode\u003ehostNetwork\u003c/code\u003e, \u003ccode\u003eserviceAccountName\u003c/code\u003e, and \u003ccode\u003esecurityContext\u003c/code\u003e, were not restricted. This allows a malicious user to bypass intended security controls and potentially escalate privileges within the Kubernetes cluster. Versions affected include those supporting the \u003ccode\u003etemplateReferencing\u003c/code\u003e feature, specifically v4.0.2 and v3.7.11, which include the initial fix for CVE-2026-31892 but are still vulnerable to this bypass. This vulnerability exists because the check in \u003ccode\u003esetExecWorkflow\u003c/code\u003e only validates \u003ccode\u003eHasPodSpecPatch()\u003c/code\u003e, while other critical fields are applied directly to the pod specification. The bypass affects both \u003ccode\u003eStrict\u003c/code\u003e and \u003ccode\u003eSecure\u003c/code\u003e modes.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains \u003ccode\u003ecreate Workflow\u003c/code\u003e permission within the Argo Workflows environment.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a Workflow manifest that references a hardened WorkflowTemplate.\u003c/li\u003e\n\u003cli\u003eAttacker sets \u003ccode\u003ehostNetwork: true\u003c/code\u003e (or other vulnerable fields like \u003ccode\u003esecurityContext\u003c/code\u003e, \u003ccode\u003eserviceAccountName\u003c/code\u003e, \u003ccode\u003etolerations\u003c/code\u003e, or \u003ccode\u003eautomountServiceAccountToken\u003c/code\u003e) in the Workflow manifest.\u003c/li\u003e\n\u003cli\u003eThe Workflow is submitted, and the \u003ccode\u003esetExecWorkflow\u003c/code\u003e function in the Argo controller only checks for \u003ccode\u003epodSpecPatch\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eDue to the missing validation, the user-defined \u003ccode\u003ehostNetwork: true\u003c/code\u003e (or other vulnerable fields) is merged with the WorkflowTemplate specification.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecreateWorkflowPod\u003c/code\u003e function reads the merged specification and applies the \u003ccode\u003ehostNetwork: true\u003c/code\u003e setting directly to the pod specification, bypassing the intended restrictions.\u003c/li\u003e\n\u003cli\u003eA pod is created with host networking enabled, granting the container access to the host\u0026rsquo;s network namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker can now access sensitive information or perform actions on the network as if they were running directly on the host.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation allows an attacker to bypass the intended security restrictions imposed by Argo Workflows\u0026rsquo; \u003ccode\u003etemplateReferencing\u003c/code\u003e feature. This can lead to privilege escalation, unauthorized access to network resources, and the potential to compromise other containers or nodes within the Kubernetes cluster. The impact is most significant in clusters that rely on Argo\u0026rsquo;s Strict mode as the primary enforcement layer, as other Kubernetes-level controls like PodSecurity admission or OPA/Gatekeeper may not be in place to mitigate these bypasses.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eArgo Workflow Host Network Bypass\u003c/code\u003e to detect workflows attempting to set \u003ccode\u003ehostNetwork: true\u003c/code\u003e, and tune for your environment.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eArgo Workflow Service Account Override\u003c/code\u003e to detect workflows attempting to override the service account.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Argo Workflows that addresses CVE-2026-42296, ensuring that all WorkflowSpec fields that influence pod security posture are validated.\u003c/li\u003e\n\u003cli\u003eImplement Kubernetes-level controls, such as PodSecurity admission or OPA/Gatekeeper, to provide an additional layer of defense against unauthorized pod specification modifications.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:11:38Z","date_published":"2026-05-04T20:11:38Z","id":"/briefs/2026-05-argo-workflow-bypass/","summary":"Argo Workflows has an incomplete fix for CVE-2026-31892, allowing bypass of templateReferencing restrictions to modify pod specifications, leading to potential privilege escalation and security context overrides.","title":"Argo Workflows Template Referencing Restriction Bypass","url":"https://feed.craftedsignal.io/briefs/2026-05-argo-workflow-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Argo Workflows \u003c 3.7.14","Argo Workflows \u003e= 4.0.0","Argo Workflows \u003c 4.0.5"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","argo-workflows","cloud"],"_cs_type":"advisory","_cs_vendors":["Argoproj"],"content_html":"\u003cp\u003eArgo Workflows is vulnerable to a denial-of-service (DoS) attack (CVE-2026-42294) due to unbounded memory allocation in the Webhook Interceptor. The vulnerability resides in the \u003ccode\u003eserver/auth/webhook/interceptor.go\u003c/code\u003e component, specifically within the \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint. This endpoint, intended for webhook integrations, reads the entire request body into memory without proper size limits, leading to potential memory exhaustion. An attacker can exploit this vulnerability by sending a crafted request with an extremely large body, causing the Argo Server to allocate excessive memory and potentially crash, resulting in a denial of service. Affected versions include Argo Workflows versions prior to 3.7.14 and versions 4.0.0 up to 4.0.5.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker identifies an Argo Workflows instance with a publicly accessible \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts an HTTP POST request targeting the \u003ccode\u003e/api/v1/events/\u003c/code\u003e endpoint.\u003c/li\u003e\n\u003cli\u003eThe attacker sets the \u003ccode\u003eContent-Length\u003c/code\u003e header of the request to a very large value (e.g., 1GB or more).\u003c/li\u003e\n\u003cli\u003eThe attacker sends the malicious request with a large amount of arbitrary data as the request body.\u003c/li\u003e\n\u003cli\u003eThe Argo Server receives the request and, within the \u003ccode\u003eWebhookInterceptor\u003c/code\u003e, calls \u003ccode\u003eio.ReadAll(r.Body)\u003c/code\u003e, allocating memory to store the entire request body.\u003c/li\u003e\n\u003cli\u003eDue to the large request body, the Argo Server\u0026rsquo;s memory consumption increases significantly.\u003c/li\u003e\n\u003cli\u003eIf the attacker sends a sufficiently large request, the Argo Server exhausts its available memory.\u003c/li\u003e\n\u003cli\u003eThe Argo Server process crashes due to an Out-Of-Memory (OOM) error, leading to a denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability results in a denial-of-service condition, disrupting workflow execution and API access for all users of the Argo Workflows instance. The Argo Server crashes, making it unavailable until restarted. This impacts service availability and potentially causes data loss if workflows are interrupted during execution. The number of victims depends on the number of Argo Workflows instances exposed and targeted by attackers.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnforce a strict limit on webhook body size (e.g., 10MB) using \u003ccode\u003ehttp.MaxBytesReader\u003c/code\u003e or similar mechanisms within your ingress controller or reverse proxy to prevent oversized requests from reaching the Argo Server.\u003c/li\u003e\n\u003cli\u003eUpgrade Argo Workflows to version 3.7.14 or 4.0.5 or later to patch CVE-2026-42294 and mitigate the risk of denial-of-service attacks.\u003c/li\u003e\n\u003cli\u003eMonitor memory usage of the Argo Server process and set up alerts for unusually high memory consumption to detect potential exploitation attempts.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-05-04T20:11:01Z","date_published":"2026-05-04T20:11:01Z","id":"/briefs/2026-05-argo-dos/","summary":"Argo Workflows is vulnerable to a denial-of-service (DoS) attack due to unbounded memory allocation in the Webhook Interceptor component.","title":"Argo Workflows Webhook Interceptor Vulnerable to Unauthenticated Memory Exhaustion (CVE-2026-42294)","url":"https://feed.craftedsignal.io/briefs/2026-05-argo-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Argo Workflows"],"_cs_severities":["medium"],"_cs_tags":["argo-workflows","denial-of-service","kubernetes"],"_cs_type":"advisory","_cs_vendors":["Argo Project"],"content_html":"\u003cp\u003eArgo Workflows is vulnerable to a denial-of-service attack where a malformed \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotation within a workflow pod can crash the Argo Workflows controller. This vulnerability stems from an unchecked array index in the \u003ccode\u003epodGCFromPod()\u003c/code\u003e function. When the annotation value lacks a \u0026ldquo;/\u0026rdquo;, the \u003ccode\u003estrings.Split\u003c/code\u003e function returns an array of length 1, leading to an out-of-bounds access when trying to retrieve the second element. The resulting panic occurs outside the controller\u0026rsquo;s recovery scope, causing the entire controller process to terminate. The affected versions include 3.6.5 through 3.6.19, 3.7.0-rc1 through 3.7.12, and 4.0.0-rc1 through 4.0.3. This vulnerability was introduced in commit \u003ca href=\"https://github.com/argoproj/argo-workflows/issues/14129\"\u003e#14129\u003c/a\u003e.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious Argo Workflow YAML file.\u003c/li\u003e\n\u003cli\u003eThe YAML includes a \u003ccode\u003epodMetadata\u003c/code\u003e section defining annotations for the workflow pod.\u003c/li\u003e\n\u003cli\u003eWithin the annotations, the \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e key is set to a value that does not contain a forward slash (\u0026quot;/\u0026quot;), such as \u0026ldquo;NoSlash\u0026rdquo;.\u003c/li\u003e\n\u003cli\u003eThe attacker submits the crafted workflow to the Argo Workflows controller using \u003ccode\u003ekubectl apply -n argo -f malicious-workflow.yaml\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe Argo Workflows controller receives the workflow definition and creates a corresponding pod based on the specification.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003epodGCFromPod()\u003c/code\u003e function in \u003ccode\u003e/workflow/controller/pod/controller.go\u003c/code\u003e attempts to parse the \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotation.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003estrings.Split\u003c/code\u003e function splits the annotation value, resulting in an array with only one element.\u003c/li\u003e\n\u003cli\u003eThe code attempts to access \u003ccode\u003eparts[1]\u003c/code\u003e, causing a panic due to an out-of-bounds array access and crashes the controller, resulting in a denial-of-service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows any user with the ability to submit workflows to crash the Argo Workflows controller. The controller will enter a crash loop, rendering the entire Argo Workflows deployment unavailable. Since the controller is responsible for managing and executing workflows, all workflow processing is halted, leading to a denial-of-service condition. This can severely impact organizations relying on Argo Workflows for their CI/CD pipelines or other automated tasks. The attacker requires only \u003ccode\u003ecreate\u003c/code\u003e permission on Workflow resources to execute this attack.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to a patched version of Argo Workflows (v3.6.4 or earlier, v3.6.20+, v3.7.13+, or v4.0.4+) to remediate the vulnerability as described in \u003ca href=\"https://github.com/advisories/GHSA-5jv8-h7qh-rf5p\"\u003eGHSA-5jv8-h7qh-rf5p\u003c/a\u003e.\u003c/li\u003e\n\u003cli\u003eImplement input validation on workflow submissions to reject workflows with malformed \u003ccode\u003eworkflows.argoproj.io/pod-gc-strategy\u003c/code\u003e annotations. See the PoC workflow example provided in \u003ca href=\"https://github.com/advisories/GHSA-5jv8-h7qh-rf5p\"\u003eGHSA-5jv8-h7qh-rf5p\u003c/a\u003e for examples of vulnerable annotation values.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Argo Workflows Malformed Pod GC Annotation\u003c/code\u003e to detect workflow submissions containing potentially malicious annotations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-23T21:39:21Z","date_published":"2026-04-23T21:39:21Z","id":"/briefs/2024-01-09-argo-workflow-dos/","summary":"A malformed `workflows.argoproj.io/pod-gc-strategy` annotation in an Argo Workflow pod can trigger an unchecked array index in the `podGCFromPod()` function, leading to a controller-wide panic and denial-of-service.","title":"Argo Workflows Controller Denial-of-Service via Malformed Pod Annotation","url":"https://feed.craftedsignal.io/briefs/2024-01-09-argo-workflow-dos/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["argo-workflows/v4"],"_cs_severities":["high"],"_cs_tags":["argo-workflows","kubernetes","configmap","authorization","vulnerability"],"_cs_type":"advisory","_cs_vendors":["Argo"],"content_html":"\u003cp\u003eArgo Workflows, a Kubernetes-native workflow engine, is vulnerable to an authorization bypass in its Sync Service\u0026rsquo;s ConfigMap-backed provider. This vulnerability, present in versions 4.0.0 through 4.0.4, stems from a lack of authorization checks on CRUD operations performed on ConfigMaps. This means that any authenticated user, even with a fake Bearer token, can create, read, update, and delete Kubernetes ConfigMaps used for synchronization limits. This flaw allows attackers to potentially disrupt workflow execution, access sensitive configuration data, or even manipulate ConfigMaps in namespaces accessible to the server\u0026rsquo;s service account. The vulnerability was reported on May 4, 2026, and poses a significant risk to Argo Workflows deployments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains network access to the Argo Server.\u003c/li\u003e\n\u003cli\u003eAttacker authenticates to the Argo Server using any valid or even a \u0026ldquo;fake\u0026rdquo; Bearer token (e.g., \u003ccode\u003efake-token\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAttacker crafts a POST request to the \u003ccode\u003e/api/v1/sync/default\u003c/code\u003e endpoint to create a new Sync Limit ConfigMap with specified parameters like namespace, ConfigMap name, key, and limit.\u003c/li\u003e\n\u003cli\u003eThe Argo Server\u0026rsquo;s \u003ccode\u003econfigMapSyncProvider.createSyncLimit\u003c/code\u003e function executes without performing any authorization checks.\u003c/li\u003e\n\u003cli\u003eThe function uses the Kubernetes client to create a ConfigMap in the specified namespace based on the attacker\u0026rsquo;s input.\u003c/li\u003e\n\u003cli\u003eAttacker can subsequently send GET, PUT, or DELETE requests to \u003ccode\u003e/api/v1/sync/default/{key}\u003c/code\u003e to read, update, or delete existing Sync Limit ConfigMaps without authorization.\u003c/li\u003e\n\u003cli\u003eThe Argo Server processes these requests, modifying the ConfigMaps accordingly, due to the missing \u003ccode\u003eauth.CanI\u003c/code\u003e checks.\u003c/li\u003e\n\u003cli\u003eThe attacker disrupts workflow execution, gains access to sensitive configuration data, or manipulates ConfigMaps, leading to denial of service or other malicious outcomes.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows an attacker with network access to the Argo Server and valid or fake authentication credentials to perform several malicious actions. They can cause a denial of service by setting sync limits to zero or a very low number, effectively blocking parallel workflow execution. Attackers can also disrupt running workflows by modifying existing sync limits. Furthermore, they can gain access to sensitive information by reading ConfigMap data or manipulate ConfigMaps in any namespace accessible to the server\u0026rsquo;s service account. This could lead to complete compromise of the Argo Workflows environment.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Argo Workflows version 4.0.5 or later to patch CVE-2026-42297 and mitigate the missing authorization checks.\u003c/li\u003e\n\u003cli\u003eMonitor access logs on the Argo Server for unexpected API calls to the \u003ccode\u003e/api/v1/sync\u003c/code\u003e endpoints, especially POST, PUT, and DELETE requests, which could indicate unauthorized ConfigMap manipulation. Use the rule \u003ccode\u003eArgo Workflows ConfigMap Sync Service Modification\u003c/code\u003e to detect unauthorized modifications.\u003c/li\u003e\n\u003cli\u003eImplement network segmentation and access controls to limit network access to the Argo Server, reducing the attack surface.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-03T16:23:00Z","date_published":"2024-05-03T16:23:00Z","id":"/briefs/2024-05-argo-configmap-auth-bypass/","summary":"The Sync Service's ConfigMap-backed provider in Argo Workflows performs zero authorization checks on all CRUD operations, allowing any authenticated user to create, read, update, and delete Kubernetes ConfigMaps containing synchronization limits, potentially leading to denial of service, workflow disruption, information disclosure, or arbitrary ConfigMap manipulation in Argo Workflows versions v4.0.0 to v4.0.4.","title":"Argo Workflows ConfigMap Sync Service Missing Authorization Vulnerability","url":"https://feed.craftedsignal.io/briefs/2024-05-argo-configmap-auth-bypass/"}],"language":"en","title":"CraftedSignal Threat Feed — Argo-Workflows","version":"https://jsonfeed.org/version/1.1"}