Prowler CVE-2026-73263: kubeconfig can execute code on a worker

CVE-2026-73263, published on 12 August 2026, affects the Prowler cloud-security platform. A user able to create or test a Kubernetes provider connection could submit a kubeconfig containing the legacy gcp auth-provider mechanism with cmd-path and cmd-args. The Kubernetes client library executed the named program through subprocess.Popen on a shared Prowler worker. A low-privileged application user could therefore achieve host code execution.

Versions below 5.36.0 are affected, and Prowler 5.36.0 includes the fix. The advisory scores the flaw 9.9 under CVSS 3.1: network access, low complexity, low privileges, no interaction and a scope change from a tenant account to a shared worker. Public sources do not report mass exploitation.

A kubeconfig is not passive data

Kubeconfig is commonly understood as cluster name, API address, certificate and context. The format can also contain credential-provider mechanisms that launch an external program. Current configurations often use an exec block; the older GCP provider had separate command fields. A client runs that program to obtain a token before contacting the API.

This can be a legitimate feature on an administrator’s laptop when they trust their own configuration. It becomes dangerous deserialization in a multi-tenant service where a user uploads YAML and a backend interprets it on a privileged worker. The format’s boundary does not end with YAML syntax: the document’s semantics include process execution, file reads and network connections.

Prowler already rejected exec blocks, but the check did not cover the legacy gcp auth-provider. This is the classic failure of blocking one representation rather than modelling every route to the dangerous capability. The fixing commit expands validation so the old command path is not interpreted either.

Where the flow crossed the boundary

The /api/v1/providers/{id}/connection endpoint accepted configuration for a connection test. After parsing, the Kubernetes client recognised the GCP auth provider and instantiated a command token source. Its logic executed cmd-path before Prowler could safely assess the cluster. The program inherited the worker process’s rights and network position.

Impact therefore depends on the worker environment. It may see application secrets, a database, queue, workload identity, a container socket or internal networks. Not every installation grants the same rights. The CVE establishes RCE; access to a specific cloud account or dataset must be demonstrated from deployment configuration.

The scope change is particularly important in SaaS. A user authorised to manage their own provider should never execute code on a layer shared with other tenants. Correct endpoint authorization is insufficient when the accepted document contains an operating-system instruction.

What to do now

1. Identify every Prowler App/API installation and effective version, including worker images and test environments.
2. Upgrade to 5.36.0 or a later supported release, rebuild images without the old layer and replace every replica.
3. Until completion, restrict Kubernetes provider creation and connection testing to trusted administrators.
4. Search submitted kubeconfigs for auth-provider, gcp, cmd-path, cmd-args or exec. Treat their contents as sensitive and keep them out of ordinary tickets.
5. Review endpoint, worker-process, EDR, container, cloud and network logs for child programs and unusual connections.
6. If a malicious configuration may have been tested, rebuild workers from a trusted image and rotate reachable secrets after removing persistence.
7. Run a post-update negative test proving both command representations are rejected without process execution.

In Kubernetes, deleting a vulnerable pod is not enough if the same old image is pulled again. Pin the fixed digest, remove affected versions from manifests and inspect queues where tasks may remain. An autoscaler can create a new worker from a stale template long after the main deployment ends.

Investigating possible impact

Define the window from first endpoint availability to replacement of the final worker. Map user and provider IDs to job, pod and node. Look for child processes outside the application’s normal toolset. An unexpected interpreter, network utility, /tmp write or attempt to read a service-account token justifies expanded analysis.

Then inventory privileges: environment, Secret mounts, projected service-account token, IAM role, metadata access, Docker socket and egress rules. This defines a plausible blast radius. Do not rotate everything blindly, but do not ignore short-lived credentials: their use may have created a long-lived resource, account or key.

Search cloud logs for worker-identity actions at unusual times, new credentials, policy changes, secret reads and calls from unfamiliar addresses. Inspect Prowler provider changes and access to other tenant data. Where a worker was shared, investigation should consider an isolation breach even without direct proof that every record was read.

Processing kubeconfig safely

The strongest design executes no credential plugins from a user-supplied document. A service can accept only a limited static schema and implement cluster authentication with its own server-side mechanism. A schema allowlist is stronger than a growing denylist because formats and libraries can add another side-effect path.

If full compatibility is mandatory, inspect configuration in a disposable sandbox with no secrets, read-only filesystem, no escalation, constrained CPU and memory, and default-deny egress. Sandboxing is not a replacement for validation, only another layer when new semantics bypass the filter.

Workers should not share a broad cloud identity with the API. Separate accounts, short tokens, minimum roles and segmentation reduce RCE impact. Per-tenant isolation may be justified at high risk, but at minimum jobs accepting active configuration should be separated from processes holding platform secrets.

Test the capability, not one field name

Regression tests should enumerate supported authentication mechanisms in the Kubernetes client’s documentation and prove none can launch a process in the server context. Instrument subprocess, file and network access, failing on any unexpected side effect. Keep legacy configurations in the corpus because an uncommon compatibility path bypassed the original control.

Dependency review should track semantic library changes as well. A Kubernetes client update may add another provider without application code changing. Testing the property “parsing does not execute code” lasts longer than testing “the exec field is blocked.”

The endpoint, legacy provider, subprocess.Popen, fixed version and CVSS details come from the Prowler advisory and fixing commit. Isolation, rotation and testing guidance is Breachroad analysis. Public sources do not establish an active campaign.

This case joins AppSec, Kubernetes and multi-tenant security, making it valuable for a cross-team exercise. Our cybersecurity training for organisations teaches teams to recognise active configuration formats. An independent cloud security assessment can examine worker isolation, IAM and secret handling.