Oauth — CraftedSignal Threat Feed

n8n MCP OAuth Client XSS Vulnerability

hello@craftedsignal.io — Wed, 29 Apr 2026 21:25:44 +0000

n8n, 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 client_name 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’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.

Attack Chain

An unauthenticated attacker registers a malicious MCP OAuth client with a crafted client_name containing XSS payload.
A victim user navigates to the n8n instance and is presented with the malicious OAuth consent dialog.
The victim user authorizes the malicious OAuth client, unknowingly injecting the attacker’s script into their session.
A second user, possibly an administrator, revokes the OAuth access granted to the malicious client.
This revocation triggers a toast notification to the original victim user.
The toast notification renders the attacker’s injected script from the crafted client_name.
The victim user clicks on the link within the toast notification.
The injected JavaScript executes within the victim’s authenticated n8n browser session, enabling the attacker to perform malicious actions such as stealing credentials, manipulating workflows, or escalating privileges.

Impact

Successful 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.

Recommendation

Upgrade n8n to version 2.14.2 or later to patch CVE-2026-42235, as recommended in the advisory.
Deploy the Sigma rule Detect Suspicious n8n MCP OAuth Client Registration to identify attempts to register OAuth clients with suspicious names.
If 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’s workaround.

Large-Scale OAuth Device Code Phishing Campaign Observed in April 2026

hello@craftedsignal.io — Fri, 24 Apr 2026 19:52:35 +0000

In 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 “Riding the Rails” 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.

Attack Chain

The attacker sends a phishing email to the victim, impersonating a legitimate service.
The email contains a link that redirects the victim to a fake application authorization page.
The fake page prompts the victim to enter a device code.
Unbeknownst to the victim, the device code is associated with a malicious OAuth application controlled by the attacker.
The victim is redirected to a legitimate Microsoft login page, where they enter the provided code and authenticate.
Upon successful authentication, the malicious application receives an access token.
The attacker uses the access token to access the victim’s account and sensitive data.
The attacker may then perform actions such as reading emails, accessing files, or initiating further malicious activity within the compromised account.

Impact

This 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.

Recommendation

Monitor Azure AD sign-in logs for device code flow usage to identify suspicious authentications (logsource: azuread, category: authentication).
Implement the Sigma rule provided below to detect suspicious application registrations in Azure AD (logsource: o365, category: configuration).
Educate users on the risks of device code phishing and how to identify malicious authorization requests.
Regularly audit OAuth applications authorized within your environment and revoke access for any suspicious or unused applications.
Investigate any alerts related to anomalous OAuth application activity promptly.

Better Auth OAuth Provider Authorization Bypass Vulnerability

hello@craftedsignal.io — Fri, 17 Apr 2026 12:00:00 +0000

An 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 clientPrivileges configuration. The vulnerability stems from the client creation endpoints (adminCreateOAuthClient and createOAuthClient) not enforcing the clientPrivileges 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.

Attack Chain

An attacker authenticates to the Better Auth application with a low-privilege account.
The attacker crafts a POST request to either /api/auth/oauth2/create-client or a custom endpoint that routes to adminCreateOAuthClient.
The attacker includes parameters for client_name, redirect_uris, and other client metadata within the POST request body.
The createOAuthClientEndpoint function is called without first performing a clientPrivileges authorization check.
A new OAuth client is created and persisted in the system.
The attacker now controls a registered OAuth client with attacker-defined redirect URIs.
The attacker can potentially use this client for phishing attacks or to bypass consent flows if skip_consent is enabled (if adminCreateOAuthClient is exposed).
The attacker exploits the newly created OAuth client to gain unauthorized access to resources or user data.

Impact

This 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 adminCreateOAuthClient 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 clientPrivileges 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.

Recommendation

Monitor web server logs for POST requests to the /api/auth/oauth2/create-client endpoint, especially from users who should not have client creation privileges. Implement the “Detect Unauthorized OAuth Client Creation Attempt” Sigma rule below, using webserver logs (category: “webserver”, product: “linux”).
Apply the necessary patches to upgrade @better-auth/oauth-provider to a version that addresses this vulnerability (>= 1.6.5 or >= 1.7.0-beta.2).
Audit your application’s OAuth client registration process to ensure that the clientPrivileges check is enforced correctly.
If using adminCreateOAuthClient, ensure it is not exposed to low-privilege authenticated users to prevent the skip_consent bypass.
Deploy the “Detect OAuth Client Creation with Skip Consent” Sigma rule if your deployment exposes the admin client creation endpoint.

Entra ID ADRS Token Request by Microsoft Authentication Broker

hello@craftedsignal.io — Fri, 10 Apr 2026 17:57:29 +0000

This 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 adrs_access 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.

Attack Chain

Attacker compromises user credentials through phishing or other means.
Attacker leverages the compromised credentials to initiate an OAuth 2.0 authentication flow.
The Microsoft Authentication Broker is used to request an access token.
The request targets the Device Registration Service (DRS) with resource ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9.
The OAuth scope includes adrs_access, indicating an attempt to access ADRS functionalities.
The request is made using a refresh token, suggesting an attempt to establish persistent access.
Successful token acquisition allows the attacker to manipulate device registration or acquire a Primary Refresh Token (PRT).
The attacker uses the PRT or device registration to maintain unauthorized access to resources.

Impact

Successful exploitation could allow an attacker to maintain persistent access to an organization’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’s persistence mechanisms. This attack targets any organization using Microsoft Entra ID.

Recommendation

Deploy the Sigma rule “Entra ID ADRS Token Request by Microsoft Authentication Broker” to your SIEM and tune it for your environment to detect suspicious ADRS access attempts.
Investigate any alerts generated by the Sigma rule, focusing on the user principal and the origin of the request.
Review Conditional Access policies to ensure they are sufficient to prevent unauthorized access to sensitive resources.
Monitor Entra ID audit logs for device registrations or changes to user’s device registration status as suggested in the rule’s triage steps.
Correlate with primary refresh token (PRTs) usage for the same user and/or session ID to identify any potential abuse, as mentioned in the rule’s triage.
Consider 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.

Device Code Phishing Campaign Targeting Cloud Platforms

hello@craftedsignal.io — Wed, 25 Mar 2026 12:00:00 +0000

An active phishing campaign is leveraging Microsoft’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.

Attack Chain

The attacker sends a phishing email impersonating a cloud-based file storage or document workflow service.
The email contains a message prompting the user to “activate” or “authenticate” their account.
The email includes a device code and instructs the user to visit a Microsoft login page (e.g., microsoft.com/devicelogin).
The user, believing the request is legitimate, enters the provided device code on the Microsoft login page.
The Microsoft login page prompts the user to grant permissions to an application controlled by the attacker.
If the user approves the permissions, the attacker gains OAuth tokens that allow access to the user’s account on the targeted cloud platform.
The attacker can then access, modify, or exfiltrate data stored on the compromised account.
The attacker may use the compromised account to further propagate the phishing campaign to other users within the organization.

Impact

Successful 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.

Recommendation

Implement user awareness training to educate employees about device code phishing and the risks of entering unknown codes on login pages.
Monitor 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 “Detect Suspicious Device Code Authentication” Sigma rule to identify anomalous activity.
Implement Conditional Access policies in Microsoft Entra ID to restrict device code authentication to trusted devices and locations.
Investigate any successful device code authentications where the application requesting permissions is not recognized or approved by the organization.

Patreon OAuth Provider ID Collision Vulnerability in go-pkgz/auth

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

A critical vulnerability exists in the Patreon OAuth provider within the go-pkgz/auth and go-pkgz/auth/v2 libraries. Specifically, the mapUser function incorrectly maps all authenticated Patreon accounts to the same local user.ID, instead of generating unique IDs based on the Patreon account data. This flaw, present in versions 1.18.0 through 1.25.1 of go-pkgz/auth and 2.0.0 through 2.1.1 of go-pkgz/auth/v2, 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 token.User.ID for authentication and authorization decisions.

Attack Chain

A user attempts to authenticate with an application using the affected go-pkgz/auth library and the Patreon OAuth provider.
The application redirects the user to Patreon for authentication.
The user authenticates with Patreon and is redirected back to the application with an authorization code.
The application exchanges the authorization code for an access token.
The application uses the access token to retrieve the user’s Patreon profile data.
The application calls the vulnerable mapUser function within the go-pkgz/auth library to map the Patreon user to a local user. Due to the vulnerability, all users are mapped to the same local user ID: patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709.
The application stores the mapped user object in JWT claims.
Subsequent requests from different Patreon users are treated as coming from the same user, potentially leading to data leakage, privilege escalation, or account takeover.

Impact

This 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.

Recommendation

Upgrade go-pkgz/auth to a version higher than 1.25.1 or go-pkgz/auth/v2 to a version higher than 2.1.1 to patch CVE-2026-42560.
Review and update any existing applications using the vulnerable Patreon provider to ensure proper user ID mapping after patching CVE-2026-42560.
Deploy the Sigma rule “Patreon Auth ID Collision Attempt” to detect potential exploitation by monitoring for the specific user ID pattern patreon_da39a3ee5e6b4b0d3255bfef95601890afd80709 in authentication logs.
Implement additional logging and monitoring to track user authentication events and identify any anomalies in user ID assignments.