Nextcloud User OIDC CVE-2026-45156: Authentication Bypass via Missing JWT Signature Verification in ID4me Flow

Introduction

A missing JWT signature verification in Nextcloud's User OIDC app meant that any entity operating a malicious ID4me Identity Authority could forge authentication tokens and log in as any user on a vulnerable Nextcloud instance, including administrators. With over 400,000 Nextcloud deployments worldwide and the platform's growing footprint in government and enterprise environments driven by data sovereignty requirements, this CVSS 8.1 authentication bypass (CVE-2026-45156) carries meaningful risk for organizations that have enabled the ID4me federated identity feature.

Nextcloud is the most popular open source self-hosted content collaboration platform, offering file sync and share, real-time document editing, calendar, email, and chat capabilities. Its partner ecosystem experienced 300% growth in 2025, with companies such as IONOS, Redpill Linpro, and Smile joining. The platform positions itself as the sovereign alternative to Microsoft 365 and Google Workspace, making it a fixture in environments where regulatory compliance and data control are paramount.

Technical Information

The ID4me Protocol and Trust Model

ID4me is a public, open, federated identity management protocol built on OpenID Connect and DNSSEC standards. In the ID4me flow, a Login Partner (the relying party, in this case Nextcloud) authenticates users by redirecting them to their chosen Identity Authority. The Identity Authority issues JWT tokens asserting the user's identity back to the Login Partner. The fundamental security contract is that the Login Partner must verify the cryptographic signature of these tokens to confirm they genuinely originate from the trusted Identity Authority.

Root Cause: A TODO That Never Got Done

The vulnerability is classified under CWE-287 (Improper Authentication) and the root cause is remarkably straightforward. Inside lib/Controller/Id4meController.php, the original ID4me authentication flow contained this placeholder where signature verification should have been:

/** TODO: VALIATE SIGNATURE! */

That single TODO comment was the only thing standing between a received JWT token and the rest of the login logic. The code would base64 decode the token's header and payload, then proceed directly to checking expiration and processing the user identity, never once verifying that the token was actually signed by a trusted authority.

This meant a rogue ID4me provider could craft an arbitrary JWT claiming to be any user, and Nextcloud would accept it at face value. The token's sub claim, email claim, or any other identity assertion could be set to match any existing user account, and the vulnerable code would authenticate the session accordingly.

CVSS Vector Analysis

The CVSS 3.1 vector for this vulnerability is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, yielding a score of 8.1 (High).

The User Interaction requirement is the key constraint. An attacker cannot silently exploit this at scale without inducing users to initiate the ID4me login flow against the malicious authority. This adds a social engineering component to the attack chain.

Attack Flow

1. Setup: The attacker operates or compromises an ID4me Identity Authority. This is the attacker controlled infrastructure that will issue forged tokens.

2. Lure: The attacker induces a Nextcloud user to initiate an ID4me login flow that routes through the attacker's Identity Authority. This could be accomplished through phishing, DNS manipulation, or other social engineering techniques.

3. Token Forgery: When the user's authentication request reaches the attacker's authority, the attacker crafts a JWT token with identity claims matching the target user (for example, an administrator account). The token can be signed with any key or even left unsigned, since the vulnerable code never checks.

4. Authentication Bypass: The forged JWT is returned to the Nextcloud instance. The vulnerable User OIDC app decodes the token's header and payload, checks expiration, and processes the identity claims without verifying the cryptographic signature.

5. Account Takeover: Nextcloud authenticates the session as the impersonated user. The attacker gains full access to the victim's files, shares, calendars, and administrative capabilities if an admin account was targeted.

The silent nature of this attack is notable: there is no availability impact (CVSS A:N), meaning the compromise produces no service disruption that might trigger detection.

Patch Information

The vulnerability was addressed through Pull Request #1285, titled "Validate signature of id4me login tokens," authored by Nextcloud developer Julien Veyssier (julien-nc). The PR was merged into the main branch on January 12, 2026 (merge commit 5797f577), and subsequently backported to multiple stable release branches. The fix spans three PHP files with 52 additions and 2 deletions.

The patch replaces the TODO comment with a proper cryptographic signature verification block. It imports the Firebase\JWT\JWT library (already vendored by the app for its standard OIDC flows) and introduces the following logic:

// validate the JWT signature
$idTokenRaw = $data['id_token'];
$jwkUri = $openIdConfig->getJwksUri();
JWT::$leeway = 60;
try {
    $jwks = $this->id4MeService->obtainJWK($jwkUri, $data['id_token'], true);
    $idTokenPayload = JWT::decode($idTokenRaw, $jwks);
} catch (\Exception|\Throwable $e) {
    $this->logger->debug('Failed to decode the JWT token, retrying with fresh JWK');
    try {
        $jwks = $this->id4MeService->obtainJWK($jwkUri, $idTokenRaw, false);
        $idTokenPayload = JWT::decode($idTokenRaw, $jwks);
    } catch (\Exception|\Throwable $e) {
        $this->logger->debug('Failed to decode the JWT token with fresh JWK');
        $message = $this->l10n->t('Failed to authenticate');
        return $this->build403TemplateResponse($message, Http::STATUS_FORBIDDEN, ['reason' => 'token signature check failed']);
    }
}

The flow now retrieves the JWK Set from the ID4me authority's JWKS URI (as declared in its OpenID configuration), then calls JWT::decode() which performs full cryptographic signature verification. A 60 second leeway is set to tolerate minor clock skew. The patch implements a two pass retry strategy: it first attempts validation against cached JWK keys, and if that fails (for example, due to key rotation), it fetches fresh keys with useCache = false before retrying. Only if both attempts fail does it return an HTTP 403 Forbidden response.

To support this, a new obtainJWK() method was added to lib/Service/ID4MeService.php. This method handles fetching the JWKS from the authority endpoint, caching the response using Nextcloud's distributed cache layer, parsing the key set via JWK::parseKeySet(), and invoking DiscoveryService::fixJwksAlg() to align key algorithms with the token header. This reuses the same JWK resolution logic already proven in the standard OIDC provider flow.

The third change was a minimal but necessary visibility adjustment in lib/Service/DiscoveryService.php, where fixJwksAlg() was changed from private to public so that the ID4MeService could reuse it.

The fix was released across five patched versions: 3.1.0, 4.1.0, 5.1.0, 6.4.0, and 8.3.0. The advisory was publicly disclosed on May 12, 2026 via GHSA-qqgv-fqwp-mjpp.

Interim Workaround

For organizations that cannot immediately upgrade, the advisory provides an explicit workaround: disable the ID4me feature in the configuration. This removes the vulnerable code path entirely. However, any users relying on ID4me based authentication will be unable to log in until the feature is re-enabled after patching.

Affected Systems and Versions

The vulnerability affects the following version ranges of the Nextcloud User OIDC app:

Organizations can verify their User OIDC app version via the Nextcloud Apps management interface or by checking the appinfo/info.xml file in the user_oidc app directory.

Only Nextcloud instances with the ID4me feature enabled in the User OIDC app are vulnerable. Organizations that do not use ID4me based login are not affected by this specific vulnerability, though they should remain alert for similar issues in other OIDC flows given the pattern of past vulnerabilities in this app.

Vendor Security History

Nextcloud maintains a formal Vulnerability Disclosure Program through HackerOne, and CVE-2026-45156 was reported through this program (report #3489490) by researcher @cybertechajju. However, the User OIDC app has been a recurring source of authentication vulnerabilities:

The recurrence of OIDC related authentication issues (issuer verification bypass, CSRF in OIDC login, and now missing JWT signature verification) suggests a systemic challenge in correctly implementing the full complexity of OIDC and federated identity protocols. While Nextcloud is responsive in patching, the pattern indicates the User OIDC app's development process may benefit from more rigorous security review against the complete OIDC and ID4me specifications before release.

The French government CERT (CERT-FR) published advisory CERTFR-2026-AVI-0569 on May 12, 2026, covering multiple Nextcloud vulnerabilities. This level of institutional attention reflects Nextcloud's significant deployment base in government and enterprise environments.

References

• CVE-2026-45156 on NVD
• GHSA-qqgv-fqwp-mjpp: GitHub Security Advisory
• Pull Request #1285: Validate signature of id4me login tokens
• Merge Commit 5797f577
• HackerOne Report #3489490
• Nextcloud HackerOne Bounty Program
• HackerOne Report #2021684: Issuer not verified in user_oidc
• HackerOne Report #1878381: CSRF protection on OIDC login is broken
• CERT-FR Advisory CERTFR-2026-AVI-0569
• CVE-2026-45156 on Vulners/CIRCL
• Nextcloud User OIDC GitHub Repository
• Nextcloud Content Collaboration Platform
• ID4me Login Partner Developer Zone
• ID4me: A Global Open Standard for Digital Identity