Prowler vulnerabilities

Prowler before version 5.33.1 allows an authenticated user with Lighthouse provider configuration access to supply an unvalidated base_url for the openai_compatible provider through POST /api/v1/lighthouse/providers and POST /api/v1/lighthouse/providers/{id}/connection, causing api/src/backend/tasks/jobs/lighthouse_providers.py to send outbound requests, including the API key in the Authorization header, to attacker-controlled or internal endpoints when client.models.list was called.

Prowler before version 5.36.0 in the Kubernetes provider connection test accepts kubeconfig_content containing a legacy gcp auth-provider with config.cmd-path and config.cmd-args. Checking only exec blocks in kubeconfig_contains_exec_auth and loading via config.load_kube_config_from_dict causes kubernetes-python CommandTokenSource.token to run the attacker-supplied command through subprocess.Popen on the shared worker.

A vulnerability in Prowler before 5.30.3 allows an attacker to take over accounts in another tenant by manipulating the email address in a SAMLResponse. The system trusted the email domain from the SAMLResponse when selecting the tenant, instead of binding the token to the validated SAML configuration.

In Prowler prior to 5.37.0, the HTML output formatter in prowler/lib/outputs/html/html.py inserted finding.resource_tags, assembled by unroll_dict and parse_html_string, into generated reports without HTML escaping, allowing a cloud principal who can modify a scanned resource tag to store HTML or JavaScript that executes when another user opens the report.