Description

Prowler is a cloud security platform. Prior to 5.36.0, the Kubernetes provider connection test accepted kubeconfig_content containing a legacy gcp auth-provider with config.cmd-path and config.cmd-args because kubeconfig_contains_exec_auth in api/src/backend/api/v1/serializers.py checked only exec blocks, and POST /api/v1/providers/{id}/connection loaded it through config.load_kube_config_from_dict in prowler/providers/kubernetes/kubernetes_provider.py, causing kubernetes-python CommandTokenSource.token to run the attacker-supplied command through subprocess.Popen on the shared worker. This issue is fixed in version 5.36.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-12T15:18:30.943Z",
  "pubdate": "2026-08-12T15:18:30.943Z",
  "executiveSummary": "A remote code execution vulnerability exists in Prowler prior to version 5.36.0 within the Kubernetes provider connection testing functionality.\nThe flaw stems from insufficient validation of kubeconfig inputs, specifically allowing legacy Google Cloud Platform authentication provider configurations containing arbitrary command execution parameters.\nAn authenticated attacker capable of supplying a crafted kubeconfig_content payload can trigger arbitrary command execution on the shared worker node hosting the Prowler API backend.\nSuccessful exploitation compromises the integrity and confidentiality of the underlying host environment and potentially exposes shared infrastructure secrets.\nThe risk is mitigated by updating Prowler to version 5.36.0 or later, where input validation restrictions are enforced on kubeconfig parsing mechanisms.",
  "technicalDetails": "The vulnerability resides in the Kubernetes provider connection test mechanism of Prowler prior to version 5.36.0.\nThe vulnerable components include api/src/backend/api/v1/serializers.py and prowler/providers/kubernetes/kubernetes_provider.py.\nThe root cause is that the validation function kubeconfig_contains_exec_auth in api/src/backend/api/v1/serializers.py exclusively inspected exec blocks within the submitted kubeconfig data.\nConsequently, the validation logic failed to intercept legacy GCP auth-provider configurations that incorporated config.cmd-path and config.cmd-args parameters.\nDuring the processing of the POST /api/v1/providers/{id}/connection endpoint, the unvalidated payload is ingested via config.load_kube_config_from_dict in prowler/providers/kubernetes/kubernetes_provider.py.\nThis triggers the kubernetes-python CommandTokenSource.token mechanism, which subsequently executes the attacker-supplied command via subprocess.Popen directly on the shared worker executing the backend process.\nThe attack flow proceeds as follows: 1) An authenticated user submits a malicious kubeconfig payload containing legacy gcp auth-provider command arguments; 2) The serializer fails to block the legacy auth configuration due to narrow validation checks; 3) The backend loads the configuration dictionary to test the provider connection; 4) The underlying python Kubernetes client resolves the token source by invoking subprocess.Popen on the specified cmd-path with cmd-args; 5) Arbitrary commands execute with the privilege level of the Prowler worker process.\nAffected versions include all Prowler builds prior to 5.36.0."
}