CVE-2026-42560: 
vulnerability analysis and mitigation

CVE-2026-42560 is an improper authentication vulnerability in the go-pkgz/auth Go library, specifically in its Patreon OAuth2 provider, that causes every authenticated Patreon account to be mapped to the same local user identity. This identity collision enables cross-account access, privilege confusion, and subscription-state leakage across all Patreon-authenticated users of any application using the library. Affected versions are github.com/go-pkgz/auth v1.18.0 through v1.25.1 and github.com/go-pkgz/auth/v2 v2.0.0 through v2.1.1. The vulnerability was discovered by researcher Nadav0077, disclosed via GitHub Security Advisory GHSA-f6qq-3m3h-4g42 on April 22, 2026, and published to NVD on May 9, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory).

The root cause (CWE-287: Improper Authentication) is a programming error in the Patreon provider's mapUser function in both provider/providers.go and v2/provider/providers.go. The code creates a fresh empty token.User{} struct and then hashes userInfo.ID — which is still an empty string at that point — instead of hashing uinfoJSON.Data.ID, the actual Patreon account ID returned from the API response. The result is that every Patreon login produces the deterministic, constant local ID patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 (the SHA-1 hash of an empty string). This flaw is exploitable over the network with no privileges and no user interaction required: any attacker with a valid Patreon account can authenticate to an affected application and be treated as the same local identity as every other Patreon user. The bug was also silently encoded into the library's existing test suite, which asserted the constant broken hash value as correct behavior (GitHub Advisory, Fix Commit).

All Patreon-authenticated users of any application built on the affected library versions are collapsed into a single local account identity, meaning any Patreon user can access data, roles, entitlements, and subscription state belonging to other Patreon users. Confidentiality impact is high — sensitive account data and subscription attributes (e.g., is_paid_sub) can leak across unrelated users. Integrity impact is also high — one user's profile or account records can be overwritten by another's login. If the shared local identity holds elevated privileges (e.g., admin or paid-tier access), those privileges are effectively granted to every Patreon login, enabling unauthorized privilege escalation without any additional steps (GitHub Advisory).

A proof-of-concept is included in the GitHub Security Advisory itself, demonstrating that two distinct Patreon account payloads produce identical local user IDs without any network interaction with Patreon. Exploitation requires only a valid Patreon account and access to an application using the vulnerable library — no special privileges or user interaction are needed. There is no public evidence of in-the-wild exploitation or threat actor attribution at this time. The EPSS score is approximately 0.07%, reflecting low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Identify a target application: Find an application that uses github.com/go-pkgz/auth or github.com/go-pkgz/auth/v2 with the Patreon OAuth provider enabled (versions v1.18.0–v1.25.1 or v2.0.0–v2.1.1).
2. Create or use a Patreon account: Register any valid Patreon account — no special tier or relationship with the target application is required.
3. Initiate Patreon OAuth login: Navigate to the target application's Patreon login flow and complete the standard OAuth2 authorization, granting the application access to your Patreon account data.
4. Receive the shared identity: The application's mapUser function hashes an empty string instead of your Patreon account ID, assigning you the constant local ID patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 — the same ID assigned to every other Patreon user.
5. Access merged account data: The JWT token issued by the application encodes this shared identity. Any data, roles, subscription state, or entitlements associated with the shared local account (potentially populated by another Patreon user's prior login) are now accessible to the attacker.
6. Escalate privileges if applicable: If any prior Patreon user's login caused the shared local account to be granted elevated roles (e.g., admin, paid subscriber), the attacker inherits those privileges for the duration of their session (GitHub Advisory).

• Logs: Application authentication logs showing multiple distinct Patreon users (different names, email addresses, or Patreon profile URLs) all resolving to the same local user ID patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709.
• Application Data: Database or session records where the user key patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 is associated with multiple distinct display names, profile pictures, or subscription states across different sessions.
• JWT Tokens: Issued JWT tokens containing "id": "patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709" for any Patreon-authenticated user — this value is the canonical indicator of the vulnerable behavior.
• Session Activity: Unusual account activity patterns where a single local account ID shows logins from geographically or temporally disparate sources consistent with different end users (GitHub Advisory).

Upgrade to github.com/go-pkgz/auth v1.25.2 or github.com/go-pkgz/auth/v2 v2.1.2, which fix the bug by hashing uinfoJSON.Data.ID (the actual Patreon account ID) instead of the uninitialized userInfo.ID field. There is no configuration-based workaround — the flaw is in the library's core user-mapping logic and cannot be mitigated without patching. Maintainers also recommend that application developers review any existing Patreon-linked local accounts created under the broken identifier (patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709) and consider migration guidance to re-associate those records with correct per-user identities (v1.25.2 Release, v2.1.2 Release).

The vulnerability was reported by researcher Nadav0077 and credited in both the v1.25.2 and v2.1.2 release notes. Coverage appeared on The Hacker Wire and was noted on Mastodon (infosec.exchange) and Bluesky shortly after NVD publication. No major vendor statements beyond the maintainer's advisory and patch release have been identified (The Hacker Wire, GitHub Advisory).