CVE-2026-100169
HighCVSS 7.6Exploitation Probability (EPSS)
Elevated risk57th percentile - higher than 57% of all known CVEs
Summary
A vulnerability in Prowler (versions 5.4.0 through 5.35.0) allows an unauthenticated attacker to take over the account of a user who has not yet completed registration. This occurs because Google or GitHub login is automatically linked to an existing local account with the same email address, without verifying that the address belongs to the same person. An attacker can register an account with the victim's email address and gain persistent access to their data, including cloud credentials, scan findings, and tenant memberships.
Risk Assessment
The risk is critical because an attacker can hijack accounts of users who have not finished registration, gaining access to sensitive security data and cloud credentials. This could lead to a breach of confidentiality, integrity, and availability of organizational resources.
Recommendation
Immediately upgrade Prowler to version 5.35.0 or later, which contains the fix. Additionally, as a temporary measure, disable automatic social account linking (SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT) and enforce email verification before account activation.
Other vulnerabilities in Prowler
See all- CVE-2026-73263Critical
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.
- CVE-2026-59151Critical
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.
- CVE-2026-73264High
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.
- CVE-2026-73262Medium
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.
Original NVD description (English source)
Improper Authentication in the social account linking path of the Prowler API in Prowler from 5.4.0 before 5.35.0 allows a remote unauthenticated attacker to obtain persistent access to the account of a user who has not yet registered, because ProwlerSocialAccountAdapter.pre_social_login() in api/src/backend/api/adapters.py links a Google or GitHub login to any existing local account that has the same email address as the one returned by the provider, without requiring that the address has been verified by the provider or on the existing account, and without any other check that both accounts belong to the same person. Self registration is open and the new account is usable at once, because UserViewSet.get_permissions() in api/src/backend/api/v1/views.py grants AllowAny to the create action, ACCOUNT_EMAIL_VERIFICATION is set to none in api/src/backend/config/settings/social_login.py, and the Django ModelBackend checks only the password and is_active, not the django-allauth EmailAddress record. An attacker who registers an email address before its owner keeps the password set at registration after the link is made, because sociallogin.connect() does not reset the password and does not disable the existing account, and the owner who later signs in with Google or GitHub is logged into the attacker's account. django-allauth makes the same email based link on its own, because SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT are both set to True in the same settings module. This gives the attacker the cloud provider credentials, scan findings and tenant memberships held in the account.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS