A critical vulnerability has been discovered in the Kyverno policy engine that allows for an authorization boundary bypass. This flaw enables an authenticated user with limited permissions within a specific Kubernetes namespace to execute commands with the high-level privileges of the Kyverno system. This could lead to a complete compromise of the cloud native environment, allowing the attacker to read sensitive data, including secrets, from any namespace and create cluster-wide policies to gain full administrative control.

The vulnerability is a critical authorization bypass within the namespaced Kyverno Policy apiCall function. An attacker with permissions to create or update a Kyverno Policy in any single namespace can craft a malicious apiCall rule. The urlPath parameter within this rule is not properly validated to restrict the API call to the policy's own namespace. By using context variable substitution to control the urlPath, an attacker can force the Kyverno admission controller to execute arbitrary Kubernetes API requests using its own highly-privileged ServiceAccount, effectively breaking the namespace isolation security model. This allows the attacker to perform cross-namespace data theft (e.g., reading Secrets and ConfigMaps) and privilege escalation by creating cluster-scoped resources (e.g., ClusterPolicies) that grant them further access.

This vulnerability is rated as critical with a CVSS score of 9.9, reflecting the highest possible level of risk. Successful exploitation allows a low-privileged user to escalate their privileges to that of a cluster administrator, leading to a complete compromise of the Kubernetes cluster's confidentiality, integrity, and availability. The business impact includes the potential for exfiltration of highly sensitive data such as customer information, intellectual property, and application secrets stored across all namespaces. Furthermore, an attacker could disrupt critical services, deploy malicious workloads like cryptocurrency miners, or use the compromised cluster as a pivot point to attack other parts of the corporate network.

Immediate Action: Update Kyverno is a policy engine designed for cloud native platform engineering Multiple Products to the latest version. Specifically, organizations should upgrade to version 1.16.3, 1.15.3, or a later patched release immediately. After patching, monitor for any signs of exploitation attempts that may have occurred prior to the update and review Kubernetes audit logs for anomalous activity originating from the Kyverno ServiceAccount.

Proactive Monitoring:

• Review Kubernetes audit logs for any unusual or unexpected API requests made by the Kyverno admission controller's ServiceAccount, particularly requests targeting resources outside of its expected operational scope.
• Implement alerting for the creation or modification of Kyverno Policy resources that contain an apiCall definition, and scrutinize their urlPath for suspicious variable substitution patterns.
• Monitor for the unexpected creation of high-privilege resources, such as ClusterPolicies or ClusterRoleBindings, which could indicate a successful privilege escalation attack.

Compensating Controls:

• If immediate patching is not feasible, severely restrict RBAC permissions for creating and modifying namespaced Policy resources to only highly-trusted cluster administrators.
• Consider deploying a secondary admission controller (e.g., OPA/Gatekeeper) to create a rule that denies the creation of any Kyverno Policy that utilizes the apiCall feature until patching can be completed.
• As a last resort, audit and reduce the permissions of the Kyverno admission controller's ServiceAccount itself to the bare minimum required for essential operations, which may limit the blast radius but could also break legitimate policy functionality.

Public Exploit Available: false

Given the critical CVSS score of 9.9 and the potential for a full cluster compromise from a low-privileged position, this vulnerability represents a severe and immediate risk to the organization. We strongly recommend that all affected Kyverno instances be patched to a non-vulnerable version on an emergency basis. Due to the high impact and the simplicity of exploitation once a user has the prerequisite permissions, this vulnerability should be treated as the highest priority for remediation.