{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/kyverno/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":9.9,"id":"CVE-2026-22039"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kyverno","rbac-bypass","kubernetes","privilege-escalation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis brief addresses a critical vulnerability in Kyverno version 1.17.0 (and earlier) related to cross-namespace ConfigMap access, stemming from an incomplete fix for CVE-2026-22039. While the original CVE addressed privilege escalation in Kyverno\u0026rsquo;s \u003ccode\u003eapiCall\u003c/code\u003e context, the ConfigMap context loader (\u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e) still lacks namespace validation. This allows a namespace administrator to craft a Kyverno policy that reads ConfigMaps from any namespace, effectively bypassing RBAC controls. This vulnerability impacts multi-tenant Kubernetes clusters, particularly those running Azure Kubernetes Service (AKS) or other managed Kubernetes services using Kyverno. Exploitation requires a namespace admin to create a Kyverno Policy resource in their namespace.  A successful exploit allows the attacker to exfiltrate sensitive data, such as database credentials and API keys, stored in ConfigMaps across the cluster.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker with namespace admin privileges creates a service account and role binding within their assigned namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker deploys a Kyverno \u003ccode\u003ePolicy\u003c/code\u003e resource within their namespace. This policy is crafted to exploit the vulnerability in the ConfigMap context loader.\u003c/li\u003e\n\u003cli\u003eThe policy specifies \u003ccode\u003econtext.configMap.namespace\u003c/code\u003e to target a ConfigMap in a different, victim namespace.  This step leverages the lack of namespace validation in \u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe policy includes a \u003ccode\u003emutate\u003c/code\u003e rule designed to extract data from the targeted ConfigMap and embed it into annotations of another ConfigMap within the attacker\u0026rsquo;s namespace.\u003c/li\u003e\n\u003cli\u003eThe attacker triggers the policy by creating or modifying a ConfigMap (e.g., \u003ccode\u003etrigger-cm\u003c/code\u003e) in their own namespace. This triggers Kyverno\u0026rsquo;s admission controller.\u003c/li\u003e\n\u003cli\u003eKyverno, running with a privileged service account (cluster-wide \u003ccode\u003eview\u003c/code\u003e role), fetches the ConfigMap from the victim namespace based on the attacker\u0026rsquo;s policy.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003emutate\u003c/code\u003e rule in the policy executes, copying the contents of the stolen ConfigMap data into annotations of the trigger ConfigMap.\u003c/li\u003e\n\u003cli\u003eThe attacker retrieves the modified \u003ccode\u003etrigger-cm\u003c/code\u003e ConfigMap and extracts the exfiltrated secrets from the annotations.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability allows a namespace administrator to bypass Kubernetes RBAC and read ConfigMaps from any namespace within the cluster. This can lead to the exfiltration of sensitive data such as database credentials, API keys, and other secrets stored in ConfigMaps. The impact is most severe in multi-tenant environments where namespace isolation is critical for security.  This vulnerability affects any Kubernetes cluster running Kyverno v1.17.0 (and earlier) with namespace-scoped Policy creation enabled. A successful attack violates the principle of least privilege and breaks multi-tenancy guarantees.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Kyverno Policy Creating Cross-Namespace ConfigMap Context\u003c/code\u003e to identify potentially malicious policies.\u003c/li\u003e\n\u003cli\u003eApply the namespace validation fix suggested in the advisory to \u003ccode\u003econfigmap.NewConfigMapLoader()\u003c/code\u003e.  Specifically, ensure the resolved namespace in the ConfigMap context matches the policy\u0026rsquo;s namespace (\u003ccode\u003epkg/engine/context/loaders/configmap.go\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eAudit other Kyverno context loaders (\u003ccode\u003eglobalReference\u003c/code\u003e, \u003ccode\u003eimageRegistry\u003c/code\u003e, \u003ccode\u003evariable\u003c/code\u003e) for similar missing namespace validation patterns.\u003c/li\u003e\n\u003cli\u003eUpgrade to a patched version of Kyverno as soon as it is released. Refer to the Kyverno release notes for the fix version.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T12:00:00Z","date_published":"2026-04-17T12:00:00Z","id":"/briefs/2026-04-kyverno-configmap-rbac-bypass/","summary":"CVE-2026-22039 incompletely fixed a cross-namespace privilege escalation vulnerability in Kyverno's apiCall context, as the ConfigMap context loader still lacks namespace validation, allowing a namespace admin to read ConfigMaps from any namespace using Kyverno's privileged service account, leading to a complete RBAC bypass in multi-tenant Kubernetes clusters.","title":"Kyverno ConfigMap Cross-Namespace Read RBAC Bypass (CVE-2026-22039 Incomplete Fix)","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-configmap-rbac-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["kyverno","kubernetes","privilege-escalation","data-manipulation"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eKyverno, a Kubernetes policy engine, is susceptible to multiple vulnerabilities that can be exploited by authenticated remote attackers. These flaws allow attackers to disclose sensitive information, circumvent security measures, manipulate data, and ultimately gain elevated privileges within the Kubernetes environment. Successful exploitation of these vulnerabilities could lead to unauthorized access to sensitive resources, disruption of services, and potential compromise of the entire cluster. Given Kyverno\u0026rsquo;s central role in enforcing security policies, these vulnerabilities pose a significant risk to organizations relying on this tool for governance and compliance. Defenders should prioritize identifying and mitigating these vulnerabilities to prevent potential attacks.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker authenticates to the Kyverno API server using valid credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker exploits a vulnerability in the policy evaluation engine to bypass configured security policies.\u003c/li\u003e\n\u003cli\u003eThe attacker leverages an information disclosure vulnerability to gain access to sensitive data, such as service account tokens or configuration details.\u003c/li\u003e\n\u003cli\u003eThe attacker manipulates existing Kyverno policies to grant themselves additional permissions within the cluster.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the elevated permissions to create or modify Kubernetes resources, such as pods or deployments.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies data within the cluster, potentially impacting applications and services.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges to gain cluster-admin access.\u003c/li\u003e\n\u003cli\u003eThe attacker exfiltrates sensitive data from the compromised Kubernetes cluster.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of these vulnerabilities in Kyverno can have severe consequences. It can lead to unauthorized access to sensitive data, manipulation of Kubernetes resources, and ultimately, a complete compromise of the cluster. This can result in data breaches, service disruptions, and significant financial and reputational damage. Organizations relying on Kyverno for security and governance in their Kubernetes environments are particularly vulnerable. The lack of specific victim numbers makes it difficult to quantify the impact precisely, but the criticality of Kyverno in Kubernetes security makes this a high-priority threat.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement strict access controls and monitoring for the Kyverno API server to detect unauthorized authentication attempts.\u003c/li\u003e\n\u003cli\u003eAnalyze Kyverno audit logs for suspicious policy modifications and resource creations to identify potential exploitation attempts. Enable Kubernetes audit logging to detect unusual activity related to resources managed by Kyverno.\u003c/li\u003e\n\u003cli\u003eDevelop and deploy the Sigma rules provided in this brief to detect attempts to bypass security policies.\u003c/li\u003e\n\u003cli\u003eRegularly review and update Kyverno policies to ensure they are effective and do not contain any vulnerabilities.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-16T11:19:02Z","date_published":"2026-04-16T11:19:02Z","id":"/briefs/2026-04-kyverno-vulns/","summary":"An authenticated remote attacker can exploit multiple vulnerabilities in Kyverno to disclose information, bypass security measures, manipulate data, and gain elevated privileges.","title":"Multiple Vulnerabilities in Kyverno Allow Privilege Escalation and Data Manipulation","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-vulns/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-4789"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["SSRF","kyverno","kubernetes","cel","cloud-security"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA Server-Side Request Forgery (SSRF) vulnerability has been identified in Kyverno\u0026rsquo;s CEL HTTP library (\u003ccode\u003epkg/cel/libs/http/\u003c/code\u003e), affecting versions \u0026gt;= 1.16.0. This flaw allows users with permissions to create namespace-scoped policies to bypass intended restrictions and make arbitrary HTTP requests from the Kyverno admission controller. This can lead to unauthorized access to internal Kubernetes services in other namespaces, cloud metadata endpoints such as 169.254.169.254 (allowing credential theft), and the exfiltration of sensitive data by embedding it in policy error messages. The vulnerability stems from a lack of URL validation in the \u003ccode\u003ehttp.Get()\u003c/code\u003e and \u003ccode\u003ehttp.Post()\u003c/code\u003e functions used within CEL policies, contrasting with the namespace enforcement present in the \u003ccode\u003eresource.Lib\u003c/code\u003e. The reported vulnerability was tested and confirmed on Kyverno v1.16.2 deployed via Helm chart 3.6.2.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains the ability to create NamespacedValidatingPolicy resources within a specific Kubernetes namespace. This could be achieved through compromised credentials, misconfigured RBAC, or other privilege escalation methods.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious NamespacedValidatingPolicy that utilizes the \u003ccode\u003ehttp.Get()\u003c/code\u003e or \u003ccode\u003ehttp.Post()\u003c/code\u003e function within a CEL expression. The crafted policy is applied to the target Kubernetes cluster.\u003c/li\u003e\n\u003cli\u003eThe CEL expression within the policy is designed to make an HTTP request to an internal service (e.g., \u003ccode\u003einternal-api.kube-system.svc.cluster.local\u003c/code\u003e) or a cloud metadata endpoint (\u003ccode\u003e169.254.169.254\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe crafted NamespacedValidatingPolicy is triggered by a specific event, such as the creation of a ConfigMap within the attacker\u0026rsquo;s namespace, which matches the \u003ccode\u003ematchConstraints\u003c/code\u003e defined in the policy.\u003c/li\u003e\n\u003cli\u003eThe Kyverno admission controller executes the CEL expression, making the HTTP request to the specified internal service or cloud metadata endpoint.\u003c/li\u003e\n\u003cli\u003eThe HTTP response from the internal service or cloud metadata endpoint is captured by the CEL expression.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a \u003ccode\u003emessageExpression\u003c/code\u003e within the NamespacedValidatingPolicy to include the captured data in a validation error message.\u003c/li\u003e\n\u003cli\u003eThe validation error message, containing the exfiltrated data, is returned to the user, effectively leaking sensitive information.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis SSRF vulnerability allows attackers with limited, namespace-scoped privileges to access sensitive data within a Kubernetes cluster. This includes the ability to access services in other namespaces, potentially compromising sensitive configurations or secrets. Access to cloud metadata endpoints (169.254.169.254) allows the theft of IAM credentials, leading to further escalation of privileges within the cloud environment. Successful exploitation breaks namespace isolation, undermining the security model of Kyverno and Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule to detect suspicious usage of \u003ccode\u003ehttp.Get\u003c/code\u003e or \u003ccode\u003ehttp.Post\u003c/code\u003e function in \u003ccode\u003eNamespacedValidatingPolicy\u003c/code\u003e resources in your SIEM and tune for your environment.\u003c/li\u003e\n\u003cli\u003eMonitor network connections originating from the Kyverno pods, specifically looking for connections to internal Kubernetes services or cloud metadata endpoints (169.254.169.254), using the \u003ccode\u003enetwork_connection\u003c/code\u003e log source.\u003c/li\u003e\n\u003cli\u003eApply the suggested fix by adding namespace and URL restrictions to \u003ccode\u003epkg/cel/libs/http/http.go\u003c/code\u003e in Kyverno, similar to how \u003ccode\u003eresource.Lib\u003c/code\u003e enforces namespace boundaries as per the advisory.\u003c/li\u003e\n\u003cli\u003eUpgrade Kyverno to a patched version \u0026gt;= 1.17 when available, addressing the CVE-2026-4789.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T22:37:20Z","date_published":"2026-04-14T22:37:20Z","id":"/briefs/2024-01-08-kyverno-ssrf/","summary":"A Server-Side Request Forgery (SSRF) vulnerability in Kyverno's CEL HTTP library allows users with namespace-scoped policy creation permissions to make arbitrary HTTP requests, enabling unauthorized access to internal services, cloud metadata endpoints, and data exfiltration.","title":"Kyverno SSRF Vulnerability in CEL HTTP Library","url":"https://feed.craftedsignal.io/briefs/2024-01-08-kyverno-ssrf/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kyverno","token-leak","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in Kyverno versions prior to 1.17.0 where the \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e helpers automatically inject the Kyverno controller\u0026rsquo;s service account token into outgoing requests. This occurs when a Kyverno policy does not explicitly define an \u003ccode\u003eAuthorization\u003c/code\u003e header for the request. Because the destination URL for these API calls is policy-controlled via \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e, a malicious actor could create or modify a \u003ccode\u003eClusterPolicy\u003c/code\u003e or \u003ccode\u003eGlobalContextEntry\u003c/code\u003e to direct these requests—and thus the service account token—to an attacker-controlled endpoint. This vulnerability allows for token exfiltration and subsequent unauthorized actions, depending on the RBAC permissions granted to the Kyverno service account. This issue is limited to \u003ccode\u003eClusterPolicy\u003c/code\u003e and global context usage, as namespaced policies are blocked from \u003ccode\u003eservicecall\u003c/code\u003e usage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains the ability to create or modify \u003ccode\u003eClusterPolicy\u003c/code\u003e objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious \u003ccode\u003eClusterPolicy\u003c/code\u003e that uses the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e feature.\u003c/li\u003e\n\u003cli\u003eThe policy specifies a URL for the \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e that points to an attacker-controlled endpoint designed to capture the incoming request.\u003c/li\u003e\n\u003cli\u003eThe crafted policy does not define an explicit \u003ccode\u003eAuthorization\u003c/code\u003e header for the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen the policy is triggered, Kyverno\u0026rsquo;s \u003ccode\u003eexecutor.addHTTPHeaders\u003c/code\u003e function detects the missing \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eKyverno reads the service account token from \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eKyverno injects the service account token into the request header as \u003ccode\u003eAuthorization: Bearer \u0026lt;token\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this vulnerability results in the exfiltration of the Kyverno controller service account token. The severity of the impact depends on the RBAC roles and permissions assigned to the Kyverno service account within the Kubernetes cluster. With the stolen token, an attacker can perform any action that the Kyverno service account is authorized to perform, potentially leading to cluster-wide compromise, data breaches, or denial-of-service conditions. The number of affected clusters would depend on the number of Kyverno deployments using vulnerable versions.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).\u003c/li\u003e\n\u003cli\u003eImplement monitoring to detect modifications to \u003ccode\u003eClusterPolicy\u003c/code\u003e resources, especially those utilizing \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e to arbitrary URLs, to quickly identify potentially malicious policy changes.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.\u003c/li\u003e\n\u003cli\u003eAs a workaround, set explicit \u003ccode\u003eAuthorization\u003c/code\u003e headers in all \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e policies to prevent the implicit token injection (see workarounds).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T20:09:00Z","date_published":"2026-04-14T20:09:00Z","id":"/briefs/2026-04-kyverno-token-leak/","summary":"Kyverno's apiCall serviceCall helper implicitly injects the Kyverno controller service account token into requests when policies lack an explicit Authorization header, allowing exfiltration to attacker-controlled endpoints and unauthorized actions.","title":"Kyverno Service Account Token Leak via API Call","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-token-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Kyverno"],"_cs_severities":["medium"],"_cs_tags":["kyverno","denial-of-service","kubernetes","policy-engine"],"_cs_type":"advisory","_cs_vendors":["Kyverno"],"content_html":"\u003cp\u003eA denial-of-service vulnerability exists in the \u003ccode\u003eforEach\u003c/code\u003e mutation handler of Kyverno, a Kubernetes policy engine. Specifically, Kyverno versions v1.13.0 through v1.17.1 are susceptible to a flaw where an unchecked type assertion within the \u003ccode\u003eForEach\u003c/code\u003e function in \u003ccode\u003epkg/engine/mutate/mutation.go\u003c/code\u003e can be triggered by a specially crafted \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e. Any user with the ability to create these policy types can exploit this vulnerability. When a \u003ccode\u003epatchesJson6902\u003c/code\u003e field contains a variable substitution (e.g., \u003ccode\u003e{{ element.nonexistent }}\u003c/code\u003e) that resolves to \u003ccode\u003enil\u003c/code\u003e at runtime, the type assertion \u003ccode\u003e.(string)\u003c/code\u003e on a nil \u003ccode\u003einterface{}\u003c/code\u003e triggers an unrecoverable Go panic. This results in the background controller entering a persistent CrashLoopBackOff state, effectively halting background processing. The admission controller will also drop connections and block matching resource operations. CEL-based policies are unaffected.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker crafts a malicious \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e YAML manifest containing a \u003ccode\u003eforEach\u003c/code\u003e rule.\u003c/li\u003e\n\u003cli\u003eThe crafted rule includes a \u003ccode\u003epatchesJson6902\u003c/code\u003e field with a variable substitution, such as \u003ccode\u003e{{ element.nonexistent }}\u003c/code\u003e, designed to resolve to \u003ccode\u003enil\u003c/code\u003e at runtime.\u003c/li\u003e\n\u003cli\u003eThe attacker applies the malicious policy to the Kubernetes cluster. This requires appropriate permissions to create \u003ccode\u003ePolicy\u003c/code\u003e or \u003ccode\u003eClusterPolicy\u003c/code\u003e resources.\u003c/li\u003e\n\u003cli\u003eWhen a resource matching the policy\u0026rsquo;s \u003ccode\u003ematch\u003c/code\u003e criteria is created or updated, the Kyverno admission controller attempts to apply the policy.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003eForEach\u003c/code\u003e function in \u003ccode\u003epkg/engine/mutate/mutation.go\u003c/code\u003e is invoked, processing the \u003ccode\u003epatchesJson6902\u003c/code\u003e field.\u003c/li\u003e\n\u003cli\u003eThe variable substitution resolves to \u003ccode\u003enil\u003c/code\u003e, leading to a bare type assertion failure: \u003ccode\u003efe[\u0026quot;patchesJson6902\u0026quot;].(string)\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThis triggers an unrecoverable Go panic, causing either the background controller (if triggered by \u003ccode\u003emutateExisting\u003c/code\u003e rules) or the admission controller to terminate the connection.\u003c/li\u003e\n\u003cli\u003eThe background controller enters a CrashLoopBackOff state due to the persistent \u003ccode\u003eUpdateRequest\u003c/code\u003e resources that re-trigger the panic on every restart, achieving 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 leads to a denial of service affecting Kyverno\u0026rsquo;s core functionalities within the Kubernetes cluster. An attacker can crash the background controller, halting critical background tasks such as generate rules, mutateExisting rules, and cleanup processes. The admission controller can also be affected, dropping connections and blocking resource operations that match the malicious policy\u0026rsquo;s criteria. If a ClusterPolicy is used, this block extends cluster-wide. This vulnerability allows even users with limited, namespace-scoped permissions (via Policy creation) to impact the entire cluster, thus escalating privileges.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade to Kyverno version v1.17.2 or later to patch the vulnerability (see Overview).\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Kyverno Policy with Suspicious forEach\u003c/code\u003e to identify potentially malicious policies containing \u003ccode\u003eforEach\u003c/code\u003e loops with \u003ccode\u003epatchesJson6902\u003c/code\u003e fields that could trigger the vulnerability.\u003c/li\u003e\n\u003cli\u003eMonitor Kyverno controller logs for \u0026ldquo;panic: interface conversion: interface {} is nil, not string\u0026rdquo; errors, indicating a potential exploitation attempt (see Attack Chain, step 7).\u003c/li\u003e\n\u003cli\u003eImplement strict RBAC policies to limit the ability to create or modify Kyverno \u003ccode\u003ePolicy\u003c/code\u003e and \u003ccode\u003eClusterPolicy\u003c/code\u003e resources (see Impact).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-27T12:00:00Z","date_published":"2024-01-27T12:00:00Z","id":"/briefs/2024-01-kyverno-dos/","summary":"An unchecked type assertion in Kyverno versions v1.13.0 to v1.17.1 allows a user with permission to create a Policy or ClusterPolicy to crash the cluster-wide background controller into a persistent CrashLoopBackOff, leading to a denial of service, by crafting a malicious policy that triggers a nil pointer dereference in the forEach mutation handler.","title":"Kyverno Controller Denial of Service via forEach Mutation Panic","url":"https://feed.craftedsignal.io/briefs/2024-01-kyverno-dos/"}],"language":"en","title":"CraftedSignal Threat Feed — Kyverno","version":"https://jsonfeed.org/version/1.1"}