CVE-2026-100169 in Prowler
Summary
by MITRE • 10/15/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified as Improper Authentication within the Prowler API represents a critical flaw in the social account linking mechanism, specifically affecting versions from 5.4.0 up to but not including 5.35.0. This security defect allows remote unauthenticated attackers to hijack user accounts by exploiting weaknesses in how email addresses are verified and associated with local versus social identities. The core technical issue resides in the ProwlerSocialAccountAdapter.pre_social_login method, which is responsible for handling incoming authentication requests from external providers such as Google or GitHub. When a user attempts to log in using these third-party services, the system checks if an existing local account shares the same email address returned by the provider. If a match is found, the social login is automatically linked to that local account without performing any additional verification steps. Crucially, the implementation fails to verify whether the email address has been confirmed as belonging to the user via the external identity provider or through prior confirmation on the existing local account. Furthermore, there are no checks to ensure that both accounts actually belong to the same individual, creating a straightforward path for account takeover based solely on email address similarity.
The severity of this vulnerability is significantly amplified by the application's registration and authentication configuration settings. Self-registration is open to all users without restriction, meaning anyone can create an account using any valid-looking email address immediately upon submission. The UserViewSet.get_permissions method explicitly grants AllowAny access to the create action, facilitating rapid account creation by attackers. Additionally, the ACCOUNT_EMAIL_VERIFICATION setting in the social login configuration module is set to none, which disables the requirement for users to verify their email addresses before an account becomes fully functional. This design choice means that newly created accounts are usable instantly without any proof of ownership over the associated email address. The Django ModelBackend further contributes to this weakness by relying solely on password and active status checks during authentication, ignoring django-allauth EmailAddress records that might otherwise indicate verification status. Consequently, an attacker can register a target's email address long before the legitimate owner attempts to sign up or log in.
The operational impact of this flaw is severe, resulting in persistent account takeover for victims who have not yet registered on the platform but whose email addresses are known to attackers. When an attacker registers with a victim's email and sets a password, they establish control over that local account profile. Later, when the legitimate user attempts to log in using their Google or GitHub credentials, the system detects the matching email address and links the social login to the pre-existing local account controlled by the attacker. The django-allauth library’s own settings for SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT being set to True exacerbate this issue by automatically connecting accounts based on email matches without further user intervention. A critical aspect of the persistence mechanism is that when sociallogin.connect executes, it does not reset the password associated with the local account nor does it disable the existing account. This ensures that the attacker retains access via their originally chosen password even after the victim links their social identity to the hijacked profile. The victim effectively loses control over their cloud provider credentials, scan findings, and tenant memberships stored within the compromised Prowler instance.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of users during the login process. It also relates closely to CWE-640 Weak Password Recovery Mechanism for Forgotten Password and CWE-384 Session Fixation concepts, although primarily it is an account takeover via email address collision. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1078 Valid Accounts, where attackers exploit valid credentials or accounts to gain access, specifically leveraging the Initial Access tactic by creating a foothold through social engineering or automated registration before the legitimate user can intervene. The exploitation chain involves initial reconnaissance to identify target email addresses followed by rapid account creation and subsequent hijacking upon victim login attempts.
Mitigation strategies must address both the immediate configuration weaknesses and the underlying logic flaws in the authentication flow. First, administrators should enforce strict email verification requirements by setting ACCOUNT_EMAIL_VERIFICATION to mandatory or high within the social_login settings module. This ensures that no account can be fully activated until the user proves ownership of the provided email address through a confirmation link sent to their inbox. Second, the pre_social_login adapter logic must be updated to include additional checks beyond simple email matching. Implementing mechanisms such as requiring users to confirm identity via multi-factor authentication or prompting for explicit consent before linking social accounts to existing local profiles would prevent automatic hijacking. Additionally, reviewing and tightening permissions in UserViewSet.get_permissions is essential; while open registration may be necessary for some use cases, it should ideally require email verification prior to granting full account privileges. Finally, updating the django-allauth configuration to disable auto-connect features or requiring explicit user action during social login linking can further reduce the risk of unintended account associations. Immediate patching to version 5.35.0 or later is recommended as these versions contain fixes for this improper authentication flaw.