{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/oauth/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["n8n"],"_cs_severities":["high"],"_cs_tags":["xss","oauth","n8n","CVE-2026-42235"],"_cs_type":"advisory","_cs_vendors":["npm"],"content_html":"\u003cp\u003en8n, a workflow automation platform, is susceptible to a cross-site scripting (XSS) vulnerability (CVE-2026-42235) related to the registration of malicious MCP OAuth clients. An unauthenticated attacker can register an OAuth client with a crafted \u003ccode\u003eclient_name\u003c/code\u003e containing malicious JavaScript. This vulnerability exists in versions prior to 2.14.2 and also affects versions 2.17.0 to 2.17.3 and 2.18.0. A successful exploit allows the attacker to execute arbitrary JavaScript within a victim\u0026rsquo;s authenticated n8n session, potentially leading to credential theft, session token theft, workflow manipulation, or privilege escalation. Defenders should prioritize patching to version 2.14.2 or later to mitigate the risk.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn unauthenticated attacker registers a malicious MCP OAuth client with a crafted \u003ccode\u003eclient_name\u003c/code\u003e containing XSS payload.\u003c/li\u003e\n\u003cli\u003eA victim user navigates to the n8n instance and is presented with the malicious OAuth consent dialog.\u003c/li\u003e\n\u003cli\u003eThe victim user authorizes the malicious OAuth client, unknowingly injecting the attacker\u0026rsquo;s script into their session.\u003c/li\u003e\n\u003cli\u003eA second user, possibly an administrator, revokes the OAuth access granted to the malicious client.\u003c/li\u003e\n\u003cli\u003eThis revocation triggers a toast notification to the original victim user.\u003c/li\u003e\n\u003cli\u003eThe toast notification renders the attacker\u0026rsquo;s injected script from the crafted \u003ccode\u003eclient_name\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe victim user clicks on the link within the toast notification.\u003c/li\u003e\n\u003cli\u003eThe injected JavaScript executes within the victim\u0026rsquo;s authenticated n8n browser session, enabling the attacker to perform malicious actions such as stealing credentials, manipulating workflows, or escalating privileges.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this XSS vulnerability can lead to significant compromise of an n8n instance. Attackers can steal user credentials and session tokens, allowing them to impersonate legitimate users. Malicious actors could also modify or create workflows, leading to data breaches, system disruption, or unauthorized access. Privilege escalation is also possible, potentially granting attackers administrative control over the n8n platform. The number of potential victims depends on the exposure and user base of the vulnerable n8n instances.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade n8n to version 2.14.2 or later to patch CVE-2026-42235, as recommended in the advisory.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u003ccode\u003eDetect Suspicious n8n MCP OAuth Client Registration\u003c/code\u003e to identify attempts to register OAuth clients with suspicious names.\u003c/li\u003e\n\u003cli\u003eIf immediate patching is not feasible, restrict access to the n8n instance and the MCP OAuth registration endpoint to trusted users only, as suggested in the advisory\u0026rsquo;s workaround.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-29T21:25:44Z","date_published":"2026-04-29T21:25:44Z","id":"/briefs/2026-05-n8n-xss-oauth/","summary":"n8n is vulnerable to cross-site scripting (XSS) via a malicious MCP OAuth client, allowing an unauthenticated attacker to inject arbitrary JavaScript into an authenticated user's session.","title":"n8n MCP OAuth Client XSS Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-05-n8n-xss-oauth/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Azure Active Directory"],"_cs_severities":["high"],"_cs_tags":["oauth","device-code","phishing","initial-access"],"_cs_type":"advisory","_cs_vendors":["Microsoft"],"content_html":"\u003cp\u003eIn early April 2026, Arctic Wolf observed a widespread phishing campaign that abused the OAuth device code flow. This campaign targeted organizations across multiple regions and sectors, mirroring the \u0026ldquo;Riding the Rails\u0026rdquo; campaign observed by Huntress in late March. The attackers exploited the device code grant type in the OAuth 2.0 authorization framework to obtain access tokens. By tricking users into entering a code on a legitimate Microsoft login page, attackers bypassed traditional MFA controls. Defenders should be aware of this evolving technique and implement detection strategies focused on anomalous application registrations and device code flow activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a phishing email to the victim, impersonating a legitimate service.\u003c/li\u003e\n\u003cli\u003eThe email contains a link that redirects the victim to a fake application authorization page.\u003c/li\u003e\n\u003cli\u003eThe fake page prompts the victim to enter a device code.\u003c/li\u003e\n\u003cli\u003eUnbeknownst to the victim, the device code is associated with a malicious OAuth application controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eThe victim is redirected to a legitimate Microsoft login page, where they enter the provided code and authenticate.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the malicious application receives an access token.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the access token to access the victim\u0026rsquo;s account and sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker may then perform actions such as reading emails, accessing files, or initiating further malicious activity within the compromised account.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis OAuth device code phishing campaign affected numerous organizations across multiple sectors and regions in early April 2026. Successful attacks grant threat actors unauthorized access to user accounts, potentially leading to data exfiltration, financial fraud, and further compromise of internal systems. Due to the nature of OAuth, attackers can maintain persistent access even after password changes, posing a significant long-term risk.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor Azure AD sign-in logs for device code flow usage to identify suspicious authentications (logsource: azuread, category: authentication).\u003c/li\u003e\n\u003cli\u003eImplement the Sigma rule provided below to detect suspicious application registrations in Azure AD (logsource: o365, category: configuration).\u003c/li\u003e\n\u003cli\u003eEducate users on the risks of device code phishing and how to identify malicious authorization requests.\u003c/li\u003e\n\u003cli\u003eRegularly audit OAuth applications authorized within your environment and revoke access for any suspicious or unused applications.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts related to anomalous OAuth application activity promptly.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-24T19:52:35Z","date_published":"2026-04-24T19:52:35Z","id":"/briefs/2026-05-oauth-device-code-phishing/","summary":"In early April 2026, Arctic Wolf tracked a large-scale device code phishing campaign across multiple regions and sectors where threat actors abused OAuth device code flow to trick victims into providing authentication codes.","title":"Large-Scale OAuth Device Code Phishing Campaign Observed in April 2026","url":"https://feed.craftedsignal.io/briefs/2026-05-oauth-device-code-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["oauth","authorization","bypass","privilege-escalation","defense-evasion"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAn authorization bypass vulnerability affects the OAuth provider component of Better Auth, specifically versions 1.4.8-beta.7 through 1.6.4 and 1.7.0-beta.0 through 1.7.0-beta.1. This flaw allows any authenticated, low-privilege user to create OAuth clients, bypassing the intended restrictions set by the \u003ccode\u003eclientPrivileges\u003c/code\u003e configuration. The vulnerability stems from the client creation endpoints (\u003ccode\u003eadminCreateOAuthClient\u003c/code\u003e and \u003ccode\u003ecreateOAuthClient\u003c/code\u003e) not enforcing the \u003ccode\u003eclientPrivileges\u003c/code\u003e check before creating new OAuth clients. This bypass allows attackers to register OAuth clients with attacker-controlled redirect URIs and metadata, potentially leading to phishing attacks and abuse of trust assumptions in OAuth/OIDC flows. Defenders should implement detections to identify unauthorized OAuth client creation attempts.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker authenticates to the Better Auth application with a low-privilege account.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a POST request to either \u003ccode\u003e/api/auth/oauth2/create-client\u003c/code\u003e or a custom endpoint that routes to \u003ccode\u003eadminCreateOAuthClient\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker includes parameters for \u003ccode\u003eclient_name\u003c/code\u003e, \u003ccode\u003eredirect_uris\u003c/code\u003e, and other client metadata within the POST request body.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ecreateOAuthClientEndpoint\u003c/code\u003e function is called without first performing a \u003ccode\u003eclientPrivileges\u003c/code\u003e authorization check.\u003c/li\u003e\n\u003cli\u003eA new OAuth client is created and persisted in the system.\u003c/li\u003e\n\u003cli\u003eThe attacker now controls a registered OAuth client with attacker-defined redirect URIs.\u003c/li\u003e\n\u003cli\u003eThe attacker can potentially use this client for phishing attacks or to bypass consent flows if \u003ccode\u003eskip_consent\u003c/code\u003e is enabled (if \u003ccode\u003eadminCreateOAuthClient\u003c/code\u003e is exposed).\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the newly created OAuth client to gain unauthorized access to resources or user data.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability allows unauthorized users to create OAuth clients, potentially leading to several negative consequences. Attackers can register clients with malicious redirect URIs, which can be used in phishing campaigns to steal user credentials or OAuth tokens. In scenarios where the \u003ccode\u003eadminCreateOAuthClient\u003c/code\u003e endpoint is exposed, attackers can create clients that bypass user consent, further increasing the risk of successful attacks. The impact is significant because it breaks the intended access control mechanism of the \u003ccode\u003eclientPrivileges\u003c/code\u003e configuration, affecting applications that rely on it to restrict client registration. Successful exploitation can lead to unauthorized access to user data, compromised accounts, and damaged trust in the application.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor web server logs for POST requests to the \u003ccode\u003e/api/auth/oauth2/create-client\u003c/code\u003e endpoint, especially from users who should not have client creation privileges. Implement the \u0026ldquo;Detect Unauthorized OAuth Client Creation Attempt\u0026rdquo; Sigma rule below, using webserver logs (category: \u0026ldquo;webserver\u0026rdquo;, product: \u0026ldquo;linux\u0026rdquo;).\u003c/li\u003e\n\u003cli\u003eApply the necessary patches to upgrade \u003ccode\u003e@better-auth/oauth-provider\u003c/code\u003e to a version that addresses this vulnerability (\u0026gt;= 1.6.5 or \u0026gt;= 1.7.0-beta.2).\u003c/li\u003e\n\u003cli\u003eAudit your application\u0026rsquo;s OAuth client registration process to ensure that the \u003ccode\u003eclientPrivileges\u003c/code\u003e check is enforced correctly.\u003c/li\u003e\n\u003cli\u003eIf using \u003ccode\u003eadminCreateOAuthClient\u003c/code\u003e, ensure it is not exposed to low-privilege authenticated users to prevent the \u003ccode\u003eskip_consent\u003c/code\u003e bypass.\u003c/li\u003e\n\u003cli\u003eDeploy the \u0026ldquo;Detect OAuth Client Creation with Skip Consent\u0026rdquo; Sigma rule if your deployment exposes the admin client creation endpoint.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T12:00:00Z","date_published":"2026-04-17T12:00:00Z","id":"/briefs/2026-04-better-auth-oauth-bypass/","summary":"An authorization bypass vulnerability exists in Better Auth's OAuth provider, allowing low-privilege users to create OAuth clients despite configured clientPrivileges, potentially leading to unauthorized client registration and increased phishing risks.","title":"Better Auth OAuth Provider Authorization Bypass Vulnerability","url":"https://feed.craftedsignal.io/briefs/2026-04-better-auth-oauth-bypass/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["azure","entra_id","persistence","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection identifies potentially malicious activity within Microsoft Entra ID (Azure AD) involving the Microsoft Authentication Broker (MAB). Specifically, it focuses on OAuth 2.0 token requests where MAB (application ID 29d9ed98-a469-4536-ade2-f981bc1d605e) requests access to the Device Registration Service (DRS) (resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9) on behalf of a user. The presence of the \u003ccode\u003eadrs_access\u003c/code\u003e scope within the authentication processing details signals an attempt to interact with the ADRS (Azure Device Registration Service), an action not typically associated with standard user sign-ins. This behavior could indicate an attacker attempting to abuse device registration mechanisms to achieve persistence, such as acquiring a Primary Refresh Token (PRT) or establishing a trusted session. The Volexity report from April 2025 highlights similar OAuth workflow targeting.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker compromises user credentials through phishing or other means.\u003c/li\u003e\n\u003cli\u003eAttacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.\u003c/li\u003e\n\u003cli\u003eThe Microsoft Authentication Broker is used to request an access token.\u003c/li\u003e\n\u003cli\u003eThe request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.\u003c/li\u003e\n\u003cli\u003eThe OAuth scope includes \u003ccode\u003eadrs_access\u003c/code\u003e, indicating an attempt to access ADRS functionalities.\u003c/li\u003e\n\u003cli\u003eThe request is made using a refresh token, suggesting an attempt to establish persistent access.\u003c/li\u003e\n\u003cli\u003eSuccessful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).\u003c/li\u003e\n\u003cli\u003eThe attacker uses the PRT or device registration to maintain unauthorized access to resources.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation could allow an attacker to maintain persistent access to an organization\u0026rsquo;s cloud resources, even after a user changes their password or is removed from the organization. This can lead to data exfiltration, lateral movement, and further compromise of sensitive information. The number of potentially affected users depends on the scope of the initial compromise and the effectiveness of the attacker\u0026rsquo;s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Entra ID ADRS Token Request by Microsoft Authentication Broker\u0026rdquo; to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.\u003c/li\u003e\n\u003cli\u003eReview Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.\u003c/li\u003e\n\u003cli\u003eMonitor Entra ID audit logs for device registrations or changes to user\u0026rsquo;s device registration status as suggested in the rule\u0026rsquo;s triage steps.\u003c/li\u003e\n\u003cli\u003eCorrelate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule\u0026rsquo;s triage.\u003c/li\u003e\n\u003cli\u003eConsider adjusting the rule or adding exceptions for specific applications or user accounts that legitimately require access to the Device Registration Service, based on false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-10T17:57:29Z","date_published":"2026-04-10T17:57:29Z","id":"/briefs/2026-06-adrs-token-request/","summary":"Detects suspicious OAuth 2.0 token requests where the Microsoft Authentication Broker requests access to the Device Registration Service on behalf of a user principal, potentially indicating an attempt to abuse device registration for unauthorized persistence.","title":"Entra ID ADRS Token Request by Microsoft Authentication Broker","url":"https://feed.craftedsignal.io/briefs/2026-06-adrs-token-request/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["credential-access","initial-access","phishing","oauth"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eAn active phishing campaign is leveraging Microsoft\u0026rsquo;s Device Code OAuth flow to target users of cloud-based file storage and document workflow platforms. Unlike traditional phishing attacks that aim to steal usernames and passwords directly, this campaign exploits a legitimate authentication mechanism to gain unauthorized access. The campaign impersonates popular cloud services, enticing users to enter a provided device code on a Microsoft login page. By doing so, victims inadvertently grant the attacker access to their accounts on the targeted platforms. This campaign highlights the evolving tactics of phishing actors and the need for robust detection mechanisms beyond simple credential harvesting alerts. The scope and scale of the campaign are currently unknown.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.\u003c/li\u003e\n\u003cli\u003eThe email contains a message prompting the user to \u0026ldquo;activate\u0026rdquo; or \u0026ldquo;authenticate\u0026rdquo; their account.\u003c/li\u003e\n\u003cli\u003eThe email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).\u003c/li\u003e\n\u003cli\u003eThe user, believing the request is legitimate, enters the provided device code on the Microsoft login page.\u003c/li\u003e\n\u003cli\u003eThe Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.\u003c/li\u003e\n\u003cli\u003eIf the user approves the permissions, the attacker gains OAuth tokens that allow access to the user\u0026rsquo;s account on the targeted cloud platform.\u003c/li\u003e\n\u003cli\u003eThe attacker can then access, modify, or exfiltrate data stored on the compromised account.\u003c/li\u003e\n\u003cli\u003eThe attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful attacks can lead to unauthorized access to sensitive data stored in cloud-based file storage and document workflow platforms. This can result in data breaches, financial loss, and reputational damage for affected organizations. The use of a legitimate Microsoft authentication flow makes this campaign difficult to detect with traditional phishing detection methods. The lack of credential harvesting may also bypass security controls focused on monitoring password theft. The specific number of victims and sectors targeted remains unknown, but the potential impact is significant given the widespread use of cloud services.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImplement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.\u003c/li\u003e\n\u003cli\u003eMonitor Microsoft Entra ID (Azure AD) logs for unusual device code authentication patterns, focusing on applications requesting broad permissions (reference: Attack Chain steps 5 and 6). Deploy the \u0026ldquo;Detect Suspicious Device Code Authentication\u0026rdquo; Sigma rule to identify anomalous activity.\u003c/li\u003e\n\u003cli\u003eImplement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.\u003c/li\u003e\n\u003cli\u003eInvestigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-03-25T12:00:00Z","date_published":"2026-03-25T12:00:00Z","id":"/briefs/2026-03-device-code-phishing/","summary":"A phishing campaign abuses Microsoft's Device Code OAuth flow to gain access to cloud-based file storage and document workflow platforms, bypassing traditional credential harvesting.","title":"Device Code Phishing Campaign Targeting Cloud Platforms","url":"https://feed.craftedsignal.io/briefs/2026-03-device-code-phishing/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["auth","auth/v2"],"_cs_severities":["critical"],"_cs_tags":["authentication","oauth","id_collision","vulnerability"],"_cs_type":"advisory","_cs_vendors":["GitHub"],"content_html":"\u003cp\u003eA critical vulnerability exists in the Patreon OAuth provider within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e libraries. Specifically, the \u003ccode\u003emapUser\u003c/code\u003e function incorrectly maps all authenticated Patreon accounts to the same local \u003ccode\u003euser.ID\u003c/code\u003e, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of \u003ccode\u003ego-pkgz/auth\u003c/code\u003e and 2.0.0 through 2.1.1 of \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e, arises because the code hashes an uninitialized field instead of the Patreon user ID. This means that all Patreon users are effectively treated as a single identity within applications using these libraries. The vulnerability poses a significant risk to applications relying on \u003ccode\u003etoken.User.ID\u003c/code\u003e for authentication and authorization decisions.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eA user attempts to authenticate with an application using the affected \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library and the Patreon OAuth provider.\u003c/li\u003e\n\u003cli\u003eThe application redirects the user to Patreon for authentication.\u003c/li\u003e\n\u003cli\u003eThe user authenticates with Patreon and is redirected back to the application with an authorization code.\u003c/li\u003e\n\u003cli\u003eThe application exchanges the authorization code for an access token.\u003c/li\u003e\n\u003cli\u003eThe application uses the access token to retrieve the user\u0026rsquo;s Patreon profile data.\u003c/li\u003e\n\u003cli\u003eThe application calls the vulnerable \u003ccode\u003emapUser\u003c/code\u003e function within the \u003ccode\u003ego-pkgz/auth\u003c/code\u003e library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe application stores the mapped user object in JWT claims.\u003c/li\u003e\n\u003cli\u003eSubsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThis vulnerability can lead to severe consequences for applications using the affected libraries. If successful, all Patreon-authenticated users may be collapsed into a single local account. This can result in data associated with one Patreon user being exposed to or overwritten by another. Additionally, Patreon-specific attributes like subscription status can leak across unrelated users. If the application grants elevated privileges to the local account associated with the shared Patreon ID, those privileges can effectively apply to every Patreon login.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade \u003ccode\u003ego-pkgz/auth\u003c/code\u003e to a version higher than 1.25.1 or \u003ccode\u003ego-pkgz/auth/v2\u003c/code\u003e to a version higher than 2.1.1 to patch CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eReview and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.\u003c/li\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;Patreon Auth ID Collision Attempt\u0026rdquo; to detect potential exploitation by monitoring for the specific user ID pattern \u003ccode\u003epatreon_da39a3ee5e6b4b0d3255bfef95601890afd80709\u003c/code\u003e in authentication logs.\u003c/li\u003e\n\u003cli\u003eImplement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-01-03T12:00:00Z","date_published":"2024-01-03T12:00:00Z","id":"/briefs/2024-01-patreon-auth-id-collision/","summary":"The Patreon OAuth provider in go-pkgz/auth and go-pkgz/auth/v2 maps every authenticated Patreon account to the same local user ID, leading to cross-account access, privilege confusion, and subscription-state leakage.","title":"Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth","url":"https://feed.craftedsignal.io/briefs/2024-01-patreon-auth-id-collision/"}],"language":"en","title":"CraftedSignal Threat Feed — Oauth","version":"https://jsonfeed.org/version/1.1"}