Patreon OAuth Provider Identity Collapse: Cryptographic Hash Collision Enabling Cross-User Impersonation

Vulnerability Description

This is a pre-population logic error in OAuth identity mapping. The Patreon provider initializes an empty token.User{} struct, then attempts to derive a stable account identifier via SHA1 hashing before populating the source field (userInfo.ID). Consequently, every Patreon-authenticated user receives the same derived ID: patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 (SHA1 hash of empty string). This violates the fundamental security property that OAuth user IDs must be globally unique per provider. Applications relying on token.User.ID as a session key, account identifier, or privilege anchor will incorrectly merge distinct Patreon accounts, resulting in session hijacking, privilege escalation, and subscription-state leakage between unrelated users.

Proof-of-Concept Significance

The PoC is deterministic and 100% reliable: all Patreon authentication flows produce identical user IDs regardless of actual Patreon account identity. No preconditions beyond normal OAuth flow execution are required. The vulnerability manifests on first authentication and persists across all subsequent logins. This makes it trivially exploitable at scale—an attacker need only authenticate once to gain access to any other affected user's session or data, provided the application uses this library and trusts token.User.ID as an account differentiator.

Detection Guidance

Source Code Audit: Search repositories for patterns where token.User is populated before field assignment (reverse temporal logic). Look for calls to token.HashID() or similar functions operating on uninitialized or empty fields.
Runtime Detection: Monitor for repeated authentication events mapping to the identical user.ID value across different Patreon accounts—anomalous clustering of distinct OAuth subjects to a single local identity.
YARA Signature (code pattern): Search Go binaries for sequences containing json.Unmarshal followed by HashID operations where the input variable is assigned post-hash (or initialized empty).
Log Indicators: Observe authentication logs showing multiple distinct Patreon user attributes (names, profile pictures, emails) associated with the same internal user.ID.

Mitigation Steps

1. Immediate Patch: Update both provider/providers.go:257 and v2/provider/providers.go:257 to populate userInfo fields (especially userInfo.ID from uinfoJSON.Data.ID) before computing the hash.
2. Workaround (Short-term): Implement a secondary account linkage layer that derives user identity from the raw Patreon API response object directly, bypassing the collapsed token.User.ID.
3. Validation: Add unit tests asserting that distinct Patreon accounts produce distinct SHA1 hashes. Enforce test coverage on identity-mapping code paths.
4. Dependency Update: Ensure all applications consuming this provider library apply patched versions immediately.
5. Account Audit: For deployed applications, audit session and account databases for evidence of cross-user access patterns or privilege mixing correlated with this vulnerability's timeline.

Risk Assessment

Likelihood of Exploitation: Very High. The vulnerability is trivially discoverable through basic testing of OAuth flows and requires no special privileges or social engineering. Any attacker with knowledge of the library's usage can impersonate arbitrary Patreon users.
Threat Actor Interest: Critical. Identity collapse vulnerabilities are high-value targets for account takeovers, financial fraud (especially relevant for Patreon's creator-monetization model), and privilege escalation. This is likely to attract opportunistic attackers and organized fraud rings targeting creator subscriptions and payment processing.
In-the-Wild Exploitation: Probable. The deterministic nature and ease of discovery suggest active exploitation is likely if affected applications are publicly deployed. Monitoring threat intelligence for reports of Patreon account takeovers or cross-user session hijacking is advised.