Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-7r7x-4c4q-c4qf
No affected components available
Impact
next-auth applications using OAuth provider versions before v4.20.1 are affected.
A bad actor who can spy on the victim's network or able to social engineer the victim to click a manipulated login link could intercept and tamper with the authorization URL to log in as the victim, bypassing the CSRF protection.
As an example, an attack can happen in the following scenario.
TL;DR: The attacker steals the victim's authenticated callback by intercepting and tampering with the authorization URL created by
next-auth.
-
The victim attempts to log in to the
next-authsite. For example https://next-auth-example.vercel.app/ -
<img width="1971" alt="Screen Shot 2023-03-03 at 09 54 26" src="https://user-images.githubusercontent.com/31528554/222619750-a2062bb8-99eb-4985-a75c-d75acd3da67e.png">next-authsets thecheckscookies according to how the OAuth provider is configured. In this case,stateandpkceare set by default for the Google Provider. -
The attacker intercepts the returned authorization URL, strips away the OAuth check (nonce, state, pkce), and returns the URL without the check to the victim's browser. For example: From
https://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?client_id=client_id&scope=openid%20email%20profile&response_type=code&redirect_uri=https%3A%2F%2Fnext-auth-example.vercel.app%2Fapi%2Fauth%2Fcallback%2Fgoogle&state=state&code_challenge=code_challenge&code_challenge_method=S256&service=lso&o2v=2&flowName=GeneralOAuthFlowtohttps://accounts.google.com/o/oauth2/v2/auth/oauthchooseaccount?client_id=client_id&scope=openid%20email%20profile&response_type=code&redirect_uri=https%3A%2F%2Fnext-auth-example.vercel.app%2Fapi%2Fauth%2Fcallback%2Fgoogle&service=lso&o2v=2&flowName=GeneralOAuthFlow. Notice the parametersstate,code_challengeandcode_verifierare removed from the victim's address bar. -
The victim attempts to log in using their OAuth account.
-
The Authorization Server logs the victim in and calls back to the
next-authapi/auth/callback/:providerIdendpoint. 5.1. The attacker intercepts and logs this callback URL for later use. 5.2.next-authchecks the callback call from OAuth Authorization Server (doesn't have checks) and compares the checks with the cookies set (has checks) at step 2. This check will fail, resulting in the victim isn't logged in. However, at this step, the Authorization Server has already accepted the victim's request to log in and generated/sent acodein the URL. -
The attacker now has an authorization URL with the
codethat the AS will exchange for validaccess_token/id_tokenand can log in as the victim automatically. They can open a new browser window and paste in the URL logged at step 5.1 and log in as the victim.
Patches
We patched the vulnerability in next-auth v4.20.1
To upgrade, run one of the following:
npm i next-auth@latest
yarn add next-auth@latest
pnpm add next-auth@latest
Workarounds
Upgrading to latest is the recommended way to fix this issue. However, using Advanced Initialization, developers can manually check the callback request for state, pkce, and nonce against the provider configuration, and abort the sign-in process if there is a mismatch. Check out the source code for help.
References
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. The attacker needs the user to perform some action, like clicking a link. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data.
Exploitation activity has been observed. Apply available patches or mitigations urgently.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard