GHSA-fmqp-4wfc-w3v7: Kyverno APICall SSRF Vulnerability Leading to Multi-Tenant Isolation Breach
SummaryKyverno's APICall feature contains a Server-Side Request Forgery (SSRF) vulnerability that allows users with Policy creation permissions to access arbitrary internal resources through Kyverno's high-privilege ServiceAccount. In multi-tenant Kubernetes environments, this constitutes a classic Confused Deputy problem: low-privilege tenants can steal sensitive data from other tenants (such as database passwords and API keys) and cloud platform IAM credentials, completely breaking tenant isolation. This vulnerability does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.DetailsVulnerability MechanismKyverno's APICall feature allows Policies to fetch external data via HTTP requests. This feature does not validate target URLs when executing HTTP requests, leading to an SSRF vulnerability.**Source Point - User-Controlled URL**File: `api/kyverno/v1/common_types.go`, lines 247-250The URL field is completely controlled by users through Policy configuration, with no validation mechanism to restrict target addresses.**Sink Point - HTTP Request Execution**File: `pkg/engine/apicall/executor.go`, lines 65-110Line 80's `client.Do(req)` directly executes the HTTP request without checking if the target URL is an internal IP address (like 169.254.169.254) or resources belonging to other tenants.**Confused Deputy Problem**In multi-tenant environments, Kyverno uses a cluster-wide high-privilege ServiceAccount to execute all APICall requests. When a low-privilege tenant creates a Policy containing malicious APICall directives, Kyverno executes these requests with its own high privileges, leading to privilege escalation.Attack path:PoCEnvironment Setup**Prerequisites**Kubernetes clusterKyverno v1.16.0 installedMock cloud metadata service (optional, for testing cloud credential theft)**Step 1: Install Kyverno**Verify installation:**Step 2: Deploy Mock Metadata Service**Create file `metadata-mock.yaml`:Deploy:**Step 3: Create Multi-Tenant Environment**Create two tenant namespaces:Create sensitive data in tenant-b:Create restricted ServiceAccount for tenant-a:Create file `tenant-a-rbac.yaml`:Apply configuration:**Step 4: Verify Permission Isolation**Create test Pod:Verify tenant-a cannot directly access tenant-b:This confirms that tenant-a's ServiceAccount indeed cannot directly access tenant-b's resources.Exploitation**Step 1: Create Malicious Policy**Create file `confused-deputy-attack.yaml`:Apply Policy:**Step 2: Trigger Policy Execution**Create ConfigMap to trigger Policy:**Step 3: View Stolen Data**After a few seconds, check PolicyReport:Actual output:Attack successful. Tenant-a has stolen through Kyverno:Tenant-b's database credentials (username: admin, password: SuperSecret123!, database: production-db)Cloud platform IAM credentials (AccessKeyId and SecretAccessKey)**Step 4: Verify Kyverno Logs**Check Kyverno admission controller logs:Logs show APICall executed successfully, returning 180 bytes of data (exactly the JSON length of the mock credentials).ImpactThis is a critical security vulnerability with particularly severe impact in multi-tenant Kubernetes environments.**Affected Environments**All multi-tenant Kubernetes clusters using KyvernoEnvironments granting users namespace-level Policy creation permissionsClusters running on cloud platforms (AWS EKS, GCP GKE, Azure AKS)**Vulnerability Impact**Complete Multi-Tenant Isolation BreachTenants can read other tenants' Secrets (database passwords, API keys, etc.)Tenants can access other tenants' ConfigMaps and other resourcesCompletely violates security assumptions of multi-tenant environmentsCloud Platform Credential LeakageCan access cloud metadata service (169.254.169.254)Obtain node IAM role credentialsUse these credentials to access cloud platform resources (S3, RDS, GCS, etc.)Lateral MovementExtend from Kubernetes cluster permissions to cloud platform resource accessPotentially access other tenants' cloud resourcesFurther penetration in cloud environmentsConfused Deputy ProblemLow-privilege users leverage high-privilege proxy (Kyverno) to execute privileged operationsBypass RBAC permission controlsDifficult to trace actual attackers through audit logs**Severity Assessment**CVSS 3.1 Score: 8.5 (Critical)CWE Classification: CWE-918 (Server-Side Request Forgery)In multi-tenant environments, the severity of this vulnerability is much higher than in single-tenant environments because it does not require cluster-admin privileges and can be exploited with only namespace-level Policy creation permissions.**Real-World Scenario Risks**Scenario 1: SaaS Multi-Tenant PlatformEach customer has one namespaceCustomer A can steal Customer B's database passwords and API keysLeads to data breaches, compliance violations, loss of customer trustScenario 2: Enterprise Internal Multi-Team Shared ClusterDifferent business teams share one Kubernetes clusterTeam A can steal Team B's production database credentialsLeads to internal data breaches, production incidentsScenario 3: Cloud Platform Managed KubernetesRunning on AWS EKS, GCP GKE, Azure AKSTenants can obtain node IAM role credentialsAccess cloud platform resources, lateral movement to cloud environment**Remediation Recommendations**Immediate measures:Disable APICall feature in multi-tenant environmentsRestrict Policy creation permissions to cluster-admin onlyUse NetworkPolicy to restrict Kyverno Pod egress trafficLong-term fixes:Add URL validation in executeServiceCall function to block internal IP addressesUse separate low-privilege ServiceAccount for APICallImplement URL whitelist mechanismAudit and monitor all APICall requests
CVSS v3.1: 7.7