CVE-2026-57176: Multi-Tenant Account Takeover via Identity Binding Collision in python-social-auth Vend Backend

The python-social-auth library (specifically via the social-core package) provides a federated identity mapping framework for Python web applications. One of its integrated modules is the VendOAuth2 backend, which handles authentication via Vend, a cloud-based point-of-sale (POS) platform.

In standard deployments, the backend authenticates users from external identity providers and associates their unique federated identifier (UID) with a local database record. This lookup acts as the primary access token validation step to establish active user sessions. The attack surface exists on any deployed Python web application using this backend that is configured as a multi-tenant OAuth application.

This vulnerability is classified as an Identity Binding Collision under CWE-289 (Authentication Bypass by Alternate Name). In multi-tenant environments, the unpatched library allows an attacker with a valid account on a specific tenant shop to authenticate and hijack a victim's account registered on a separate tenant shop, provided both accounts share the same numeric ID sequence.

The root cause of this vulnerability lies in a mismatch between the tenant isolation architecture of the Vend platform and the identity mapping design of the social-core library. Vend operates on a multi-tenant infrastructure where each merchant or shop operates inside its own isolated subdomain (e.g., shop-a.vendhq.com and shop-b.vendhq.com).

Inside individual shops, user records are indexed using auto-incrementing integers (e.g., id = 7). Because these integer sequences restart or increment independently per tenant, user ID values collide across different shops. User ID 7 exists in shop-a, and an unrelated User ID 7 exists in shop-b.

Prior to version 5.0.0, the VendOAuth2 backend class did not override the default unique identifier generation logic. It relied strictly on the shop-local numeric user ID (id) returned by the Vend API as the database-level social-auth UID. Consequently, when a multi-tenant application performed a lookup for a user with ID 7, the database could return the mapping for User ID 7 from a completely different tenant shop, enabling immediate identity theft.

The security patch was introduced in Pull Request #1795 and resolved via Commit dee7ad1785877afd355dd6860598823d2631b76e. The key fix is the transition from a flat numeric ID to a composite string-based key that scopes the identifier to the specific tenant.

Below is the logic modification in social_core/backends/vend.py showing the addition of prefix validation and the composite scoping function:

# File: social_core/backends/vend.py
 
DOMAIN_PREFIX_RE = re.compile(
    r"(?=.{1,63}\Z)[A-Za-z0-9](?:[A-Za-z0-9-]*[A-Za-z0-9])?\Z"
)
 
def domain_prefix(self, response=None) -> str:
    prefix = (response or {}).get("domain_prefix") or self.data.get("domain_prefix")
    if not prefix:
        raise AuthMissingParameter(self, "domain_prefix")
    if isinstance(prefix, (list, tuple)):
        prefix = prefix[0] if prefix else ""
    prefix = str(prefix).lower()
    if not self.DOMAIN_PREFIX_RE.match(prefix):
        raise AuthInvalidParameter(self, "domain_prefix")
    return prefix
 
def scoped_uid(self, response) -> str:
    user_id = response.get("id")
    if user_id in (None, ""):
        raise AuthMissingParameter(self, "id")
    return f"{self.domain_prefix(response)}:{user_id}"

The logic implements a domain verification step using a regular expression to validate the prefix structure. This blocks directory-traversal or delimiter injection attacks. The new scoped_uid method constructs a scoped identity format: domain_prefix:user_id (e.g., shop-a:7).

Additionally, the patch implements a secure migration flow in get_user_id to upgrade legacy integer UIDs to the new scoped structure. It verifies that the domain_prefix associated with the legacy session matches the active login context before modifying the mapping. This prevents attackers from claiming an existing un-scoped database entry.

To successfully exploit CVE-2026-57176, the attacker must satisfy several preconditions. First, the target system must use social-core version < 5.0.0 with the Vend backend. Second, the target system must allow logins across multiple independent Vend subdomains. Third, the attacker must have administrative or user-level access on their own independent Vend store, and their account's internal numeric ID must match the internal numeric ID of the victim's account in the target store.

The attack flow is executed as follows:

1. The attacker determines their own numeric ID inside their shop (e.g., 7) and initiates the OAuth login on the target application using their own shop subdomain (shop-b).
2. The target application redirects the attacker to Vend for authentication.
3. Upon successful login, Vend redirects back to the application with an access token.
4. The application queries the Vend API and receives user data where the ID is 7.
5. The application searches the local UserSocialAuth database for a record matching provider="vend" and uid="7".
6. Since the victim (from shop-a) previously registered and has the same numeric ID, the application retrieves the victim's local account and establishes an active session for the attacker.

The security impact of this vulnerability is severe. Successful exploitation grants complete, unauthenticated access to the victim's account on the target web application. This allows attackers to perform any actions privileged to the hijacked user, including extracting personal information, modifying transaction data, or altering configurations.

The CVSS v3.1 base score is evaluated at 6.8 (Medium). The score reflects high confidentiality and integrity impact, but complexity is rated as High (AC:H) because exploitation depends on the target application running a multi-tenant setup and the coincidental overlap of auto-incremented integer keys between independent tenants.

While this CVE is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog and no public active exploits are observed, multi-tenant POS integration dashboards represent high-value targets, and the simplicity of triggering the collision makes remediation urgent.

The definitive remediation path is upgrading the social-core package to version 5.0.0 or higher, which implements the scoped identification scheme natively.

pip install --upgrade social-auth-core>=5.0.0

Because the fix changes the structure of database lookups from integer values to composite string representations, database schemas must be checked. The underlying storage layer methods (get_social_auth and create_social_auth) have updated their type signatures from int to str. Administrators must ensure that the uid column of the UserSocialAuth database table (often social_auth_usersocialauth depending on the framework integration) has been migrated to support string structures like VARCHAR or equivalent.

If upgrading is not immediately possible, a temporary mitigation is to enforce strict subdomain validation. Developers should implement application-level filters that explicitly reject authentication requests if the supplied domain_prefix parameter does not match the organization's single, trusted tenant.