CVE-2026-45690
Description
Nextcloud Server versions 32.0.0-32.0.9 and 33.0.0-33.0.3 allow 2FA bypass using a temporary session token replay.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Nextcloud Server versions 32.0.0-32.0.9 and 33.0.0-33.0.3 allow 2FA bypass using a temporary session token replay.
Vulnerability
Nextcloud Server versions from 32.0.0 to before 32.0.9, and 33.0.0 to before 33.0.3, contain an authentication bypass vulnerability. This vulnerability allows attackers who know a user's password to bypass two-factor authentication (2FA) protections [2].
Exploitation
An attacker with knowledge of a user's password can exploit this by initiating a login with valid credentials on a 2FA-enabled account. The system creates a temporary session token before the second factor challenge is enforced. The attacker can then extract and replay this token using HTTP Basic Authentication to gain unauthorized access to authenticated endpoints [2].
Impact
Successful exploitation allows an attacker to bypass two-factor authentication and gain unauthorized access to authenticated endpoints. This effectively compromises the user's account and any data accessible through it, with the privilege level of the targeted user [2].
Mitigation
It is recommended to upgrade Nextcloud Server to version 33.0.3 or 32.0.9. For Nextcloud Enterprise Server, upgrade to 33.0.3, 32.0.9, 31.0.14.5, 30.0.17.9, or 29.0.16.16. No workaround is available [2]. The pull request that addresses this issue was merged on April 21, 2026 [1].
AI Insight generated on Jun 1, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2- Range: 33.0.3, 32.0.9, 31.0.14.5, 30.0.17.9, 29.0.16.16
Patches
1836546414ecdMerge pull request #59758 from nextcloud/fix/improve-session-token-handling
1 file changed · +20 −7
lib/private/User/Session.php+20 −7 modified@@ -394,6 +394,12 @@ public function logClientIn($user, try { $dbToken = $this->getTokenFromPassword($password); $isTokenPassword = $dbToken !== null; + if (($dbToken instanceof PublicKeyToken) + && !in_array($dbToken->getType(), [IToken::PERMANENT_TOKEN,IToken::ONETIME_TOKEN]) + ) { + // Refuse session tokens here, only app tokens and onetime tokens are handled + return false; + } } catch (ExpiredTokenException) { // Just return on an expired token no need to check further or record a failed login return false; @@ -817,32 +823,39 @@ private function validateTokenLoginName(?string $loginName, IToken $token): bool */ public function tryTokenLogin(IRequest $request) { $authHeader = $request->getHeader('Authorization'); + $tokenFromCookie = false; if (str_starts_with($authHeader, 'Bearer ')) { $token = substr($authHeader, 7); } elseif ($request->getCookie($this->config->getSystemValueString('instanceid')) !== null) { // No auth header, let's try session id, but only if this is an existing // session and the request has a session cookie try { $token = $this->session->getId(); + $tokenFromCookie = true; } catch (SessionNotAvailableException $ex) { return false; } } else { return false; } - if (!$this->loginWithToken($token)) { + try { + $dbToken = $this->tokenProvider->getToken($token); + } catch (InvalidTokenException $e) { + // Can't really happen but better safe than sorry return false; } - if (!$this->validateToken($token)) { + + if ($dbToken instanceof PublicKeyToken && $dbToken->getType() === IToken::TEMPORARY_TOKEN && !$tokenFromCookie) { + // Session token but from Bearer header, not allowed return false; } - try { - $dbToken = $this->tokenProvider->getToken($token); - } catch (InvalidTokenException $e) { - // Can't really happen but better save than sorry - return true; + if (!$this->loginWithToken($token)) { + return false; + } + if (!$this->validateToken($token)) { + return false; } // Set the session variable so we know this is an app password
Vulnerability mechanics
No source-code context for this CVE — mechanics is only generated when we can read the actual fix diff. Without that, the four sections (root cause, attack vector, affected code, fix) would be speculation rather than analysis.
References
3News mentions
0No linked articles in our index yet.