CVE-2026-100169

7.6High

Published 14 Oct 2026 · NVD status: Deferred · AI triage by gemini-3.8-flash

7.6High

Attack vector: Network
Complexity: Low
Privileges needed: None
User interaction: Passive
Impact: High impact on confidentiality, integrity
Weakness: CWE-287

Impact

Remote unauthenticated attackers can pre-hijack accounts and retain persistent access to a victim's cloud credentials, scan findings, and tenant memberships. To exploit this, the attacker must register the target's email before the legitimate user logs in with Google or GitHub.

Root cause

The API automatically links OAuth logins to existing unverified local accounts with matching emails without resetting the existing password or validating email ownership.

Affected systems

Prowler 5.4.0 before 5.35.0

CVSS v4.0 · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Fix & remediation

Upgrade Prowler to version 5.35.0 or later. If patching immediately is not possible, disable automatic social account linking by setting SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT to False or enforce strict email verification.

shell

$ pip install --upgrade 'prowler>=5.35.0'

AI-suggested. Run it in staging first and check it against the vendor advisory. Why?

Ad · In-content banner

NVD description

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.

References

Source: nvd.nist.gov/vuln/detail/CVE-2026-100169