Skip to content
Secur0
Solutions
View all AI Agent Security New Protect your AI agents Vulnerability Disclosure Secure reporting channel Penetration Testing Expert manual audits Crowdsourced Pentest Thousands of hackers, one goal Bug Bounty Success-based payment Live Hacking Live real-time pentesting For company teams Train your technical team For educational centers Bring hacking to the classroom For hackers Learn and get certified Hackathons / CTFs Tailor-made events
Customer Stories
View all Penetration Testing Manual pentesting VDP Secure reporting channel Pentest In-depth audits Crowdsourced Pentest Thousands of hackers, one goal Bug Bounty Success-based payment
Resources
About Secur0 Get to know us Jobs Join the team Media Kit Brand resources Contact Talk to us Newsletter Industry news Blog Articles and guides Partners Join the partner network We are a CNA We are a CVE Numbering Authority
Are you a hacker?
Request a demo Log in
Español English
Back to list
cve-2026-100169 ·
High · October 14, 2026

Account pre-hijacking in the Prowler API through email based social account linking without verification

S0
Secur0 CNA
cve-2026-100169

Description

Improper Authentication (CWE-287) in ProwlerSocialAccountAdapter.pre_social_login() (api/src/backend/api/adapters.py), the function that links a Google or GitHub login to an existing Prowler account, in Prowler from 5.4.0 before 5.35.0. An unauthenticated attacker can take over the account of a user who has not registered yet. The function links the Google or GitHub login to any existing account with the same email address as the one the provider sends back. It does not require that address to be verified, by the provider or on the existing account, and it does not check in any other way that the two accounts belong to the same person.

Registration is open to anyone and no email confirmation is required. UserViewSet.get_permissions() (api/src/backend/api/v1/views.py) gives AllowAny to the create action, ACCOUNT_EMAIL_VERIFICATION is none in api/src/backend/config/settings/social_login.py, and the Django ModelBackend only checks the password and is_active. An account registered with someone else's address is therefore active immediately and accepts the password set by whoever registered it.

The attacker registers the victim's email address with a password of their own. The victim later logs in with Google or GitHub. The function links that login to the attacker's account, and the victim is placed inside it. sociallogin.connect() does not reset the password and does not disable the account, so the attacker keeps access afterwards. ACCOUNT_EMAIL_NOTIFICATIONS is not set in the affected versions and django-allauth 65 treats it as false, so the user receives no notice that a social login has been connected to their account.

django-allauth also makes the same link on its own, without going through this function, because SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT are both True in the same settings file.

The attacker obtains the victim's Prowler account: the cloud provider credentials connected to it, the scan findings and the tenant memberships.

Vulnerability type (CWE)

  • CWE-287: Improper Authentication

Affected versions

Prowler from 5.4.0 before 5.35.0. The code and the settings involved appear for the first time in 5.4.0, and the Prowler API does not exist in earlier releases. Every release from 5.4.0 to 5.34.0 is affected, and there is no intermediate patch release. Default status: unaffected.

Only installations with Google or GitHub login turned on are affected.

Score (CVSS 4.0)

High (7.6)

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

Privileges required are None because anyone who can reach the API can register. Attack requirements are Present because the attack depends on two conditions the attacker does not control: the server must have Google or GitHub login turned on, and the victim must not have registered yet. User interaction is Passive because the victim only logs in the normal way, and the attack requires no unusual action from them. Confidentiality and integrity on the vulnerable system are High because the attacker has full control of the account. Availability is None because the victim does not lose access to the account.

The subsequent system metrics are None: the cloud credentials held in the account are counted as impact on Prowler.

The first half, registering someone else's address, was tested live against the prowlercloud/prowler-api:stable image: POST /api/v1/users returns 201 for an address the person registering it does not own, and POST /api/v1/tokens then issues a token for it. The second half, the link itself, requires Google or GitHub login to be configured on the server, so it was verified by reading the code and not by running it.

Solution

Upgrade to Prowler 5.35.0 or later.

No setting or environment variable in the affected versions turns off registration or requires email confirmation, so configuration alone does not correct it.

Patch

Commit 0f31f1a3c (pull request #12013), released in 5.35.0. Before linking, the address must be marked verified in two places: on the existing account, in the django-allauth EmailAddress table, and in the list of addresses the provider itself reports as verified. If either is missing it returns 403. It also sets SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT to False, so django-allauth no longer makes the link on its own. It returns immediately if the provider account is already linked, and it reads the address from sociallogin.user.email before falling back to extra_data, because GitHub sometimes sends the primary address outside the profile data.

Credits

  • Nacho García Egea - finder
  • Darío Rivas - analyst
  • Xoán M. Otero Jorge - analyst
  • Secur0 CNA - coordinator
  • Prowler Cloud Security Team - remediation developer Discovery source: External

Official record: CVE-2026-100169

Related records

  • CVE-2026-59151 - the SAML side of the same function, fixed in 5.30.3