Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessPre-register victim's email with chosen password
-
DeliveryWait for victim to sign in via Google/GitHub
-
ExploitAllauth auto-links SSO to attacker's account
-
ExecutionAttacker retains known password, account not reset
-
ImpactAccess victim's cloud credentials, scan findings and tenants
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the Prowler API to be deployed with social login (Google or GitHub) enabled and the vulnerable settings in config/settings/social_login.py active: SOCIALACCOUNT_EMAIL_AUTHENTICATION=True and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT=True, ACCOUNT_EMAIL_VERIFICATION=none, and the AllowAny create permission on UserViewSet. The decisive precondition is a race: the attacker must self-register the victim's exact email address BEFORE the victim has registered or linked SSO (the flaw is account PRE-hijacking of an unregistered user). Limiting factors that reduce realistic risk: the attacker must know and target a specific victim email, the victim must subsequently authenticate via the social provider (passive user interaction), and the window closes once the legitimate owner has already created or linked an account. Affects versions 5.4.0 up to but not including 5.35.0. |
| Impact | The source assigns CVSS 4.0 7.6 (HIGH) with vector AV:N/AC:L/AT:P/PR:N/UI:P, and the signals are internally consistent: PR:N reflects that self-registration is genuinely open (UserViewSet.get_permissions() grants AllowAny to create, ACCOUNT_EMAIL_VERIFICATION=none), so an attacker needs no prior credentials. However, two metrics heavily constrain real-world impact: AT:P encodes a timing/precondition requirement (the attacker must register the victim's email BEFORE the victim ever registers), and UI:P requires the victim to later authenticate via Google or GitHub. Together these make this a targeted pre-account-hijacking flaw rather than a mass-exploitable one - you must know and race a specific victim's email, then wait for them to sign in via SSO. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so there is no evidence of active or automatable exploitation; the only 'source code' supplied is the vendor's remediation commit, not an attack POC. VC:H/VI:H (high confidentiality and integrity impact) is justified because a successful takeover yields cloud-provider credentials, scan findings, and tenant memberships. Net: a real and credible vulnerability warranting prompt patching for anyone running Prowler's self-hosted API with Google/GitHub social login, but its targeted, race-and-wait nature places it below indiscriminate internet-wide threats. Note the input is missing EPSS, KEV, and POC signals - treat the 'no active exploitation' conclusion as inferred from absence, not vendor-confirmed. |
| Exploit ScenarioDerived | An attacker who learns a target's email address (e.g. a corporate address of someone expected to onboard to Prowler) self-registers that email and a password on the open registration endpoint before the real owner signs up. When the legitimate owner later logs in with Google or GitHub, django-allauth silently links the SSO identity to the attacker's pre-existing local account without verifying email ownership, so the victim is logged into the attacker's account while the attacker retains their known password. No public exploit code was identified; the only published code is the vendor fix. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Account pre-hijacking in the Prowler API (5.4.0 up to but not including 5.35.0) lets an unauthenticated remote attacker gain persistent control of a user account that has not yet registered, by self-registering the victim's email address before the real owner ever signs up or links single sign-on. Because social account linking in ProwlerSocialAccountAdapter.pre_social_login() matches a Google or GitHub login to any existing local account with the same email address without requiring the address to be verified by the provider or on the local account, the genuine owner's later social sign-in is silently connected to the attacker's pre-created account, and the attacker's original password remains valid, exposing cloud provider credentials, scan findings and tenant memberships held in that account. No public exploit code or confirmed in-the-wild exploitation was identified at time of analysis, though exploitation requires only open self-registration plus a victim who later authenticates through Google or GitHub (a race condition that closes once the legitimate owner has an account). The source assigns CVSS 4.0 7.6 (HIGH); our independent assessment scores it CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N.
RemediationAI
Vendor-released patch: upgrade Prowler to 5.35.0 (or later), which contains commit 0f31f1a3c2daa05b4d77a78f451e3fbfb3fe3411 and PR #12013; the release is published at https://github.com/prowler-cloud/prowler/releases/tag/5.35.0 and the fix enforces a verified email match on both the identity provider side and the existing local account before any social link is made. If immediate upgrade is not possible, apply compensating controls on the API instance: set ACCOUNT_EMAIL_VERIFICATION to mandatory (or 'optional' plus an enforced verification step) so an attacker cannot register and immediately use a victim's address - trade-off is that legitimate users must complete email verification before login; set SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT to False to stop django-allauth's own automatic email-based linking - trade-off is that users with an existing local account must explicitly connect their social identity after authenticating; restrict the UserViewSet create permission so self-registration is closed or invite-only, or place the API behind SSO/provisioning only - trade-off is loss of self-service onboarding; and as a detection/containment measure, audit existing accounts for social identities whose provider email does not match a verified local EmailAddress and force password resets and re-verification, since the flaw explicitly leaves the attacker's registration password valid after the link (sociallogin.connect() neither resets the password nor disables the pre-existing account). Because exploitation hinges on the attacker registering the victim's address before the victim ever signs in, closing self-registration and enforcing verification both eliminate the race. Enabling two-factor authentication on affected accounts is a useful additional control but does not by itself remediate the mis-link, because the attacker still holds the original password.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in pypi, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a CWE-287 improper authentication defect in Prowler's Django/django-allauth social login pipeline. ProwlerSocialAccountAdapter.pre_social_login() in api/src/backend/api/adapters.py links an incoming Google or GitHub identity to any existing local account sharing the same email address, but performs no check that the provider has verified that address or that the local account's EmailAddress record is verified, and no check that both identities belong to the same person. The weakness is compounded by three configuration choices in api/src/backend/config/settings/social_login.py and api/src/backend/api/v1/views.py: SOCIALACCOUNT_EMAIL_AUTHENTICATION and SOCIALACCOUNT_EMAIL_AUTHENTICATION_AUTO_CONNECT are both True (so django-allauth performs the same email-based link on its own), ACCOUNT_EMAIL_VERIFICATION is set to none, and UserViewSet.get_permissions() grants AllowAny on the create action so self-registration is open and immediately usable. Django's ModelBackend authenticates only on password and is_active, ignoring the django-allauth EmailAddress record, and sociallogin.connect() neither resets the password nor disables the pre-existing account, so the attacker's credentials survive the link. The upstream fix (commit 0f31f1a3c2daa05b4d77a78f451e3fbfb3fe3411, PR #12013) requires a verified matching email at both the identity provider (sociallogin.email_addresses) and the existing local account (EmailAddress.objects.filter(..., verified=True)), returns early if the provider account is already bound, prefers the normalized allauth email over extra_data (relevant because GitHub can return the primary email separately from the profile), and raises HttpResponseForbidden when either side is unverified.
Know when Github gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
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
AC:H for the pre-registration race before the victim onboards; PR:N because self-registration is open and unauthenticated; UI:R since the victim must later sign in via SSO; no availability impact.
Primary rating from Vendor (4daa8cea-433a-44bd-9456-53b127fc289a).
CVSS VectorVendor: 4daa8cea-433a-44bd-9456-53b127fc289a
Lifecycle Timeline
2DescriptionCVE.org
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.
Executive ViewAI
Prowler API versions 5.4.0 through 5.34.x allow an outside party to permanently pre-empt and seize user accounts before their legitimate owners ever register, then retain that access even after the real owner signs in through Google or GitHub. Because compromised accounts carry cloud provider credentials, scan findings and tenant memberships, an intruder could inherit the same privileges as a trusted cloud security engineer across the organization's estate. Any team running a self-hosted or self-registration-enabled Prowler deployment should treat this as a priority remediation item, particularly where Prowler holds credentials for production cloud environments.
No vendor-released patch identified at time of analysis. Interim mitigations: disable open self-registration, disable or block Google/GitHub social account linking, require provider-verified email and local email verification before any account linkage, restrict Prowler API exposure to trusted networks, audit and remediate unverified or pre-existing accounts, and rotate cloud provider credentials and tenant memberships held by potentially hijacked accounts.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Supply chain vulnerability in Eclipse Theia GitHub Actions workflow. The preview.yml workflow uses pull_request_target w
Supply chain attack vector in OpenLIT GitHub Actions workflows. The pull_request_target trigger with checkout enables ma
Eigent multi-agent workflow CI pipeline (ci.yml) uses pull_request_target with checkout of untrusted PR code, enabling a
An unsafe reflection vulnerability was identified in GitHub Enterprise Server that could lead to reflection injection. R
cmark-gfm is GitHub's extended version of the C reference implementation of CommonMark. Rated critical severity (CVSS 9.
An improper verification of cryptographic signature vulnerability was identified in GitHub Enterprise Server that allowe
Unauthenticated infrastructure overwrite in Hoppscotch API development ecosystem before 2026.2.0. Attackers can overwrit
A exposure of sensitive information vulnerability exists in Jenkins GitHub Plugin 1.29.1 and earlier in GitHubTokenCrede
OneUptime versions prior to 10.0.19 allow unauthenticated attackers to hijack GitHub App integrations across projects by
PolarLearn versions 0-PRERELEASE-15 and earlier lack proper state parameter validation in OAuth 2.0 authentication, enab
Path traversal in esm.sh CDN prior to version 0.0.0-20260116051925-c62ab83c589e allows unauthenticated remote attackers
actions/artifact is the GitHub ToolKit for developing GitHub Actions. Rated high severity (CVSS 7.5), this vulnerability
EUVD-2026-101295
GHSA-5qw5-54v9-9g7q
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB