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 anyone operating a malicious ID4me Identity Authority could forge authentication tokens and log in as any user on a vulnerable Nextcloud instance, administrators included. The flaw is tracked as CVE-2026-45156 and scored CVSS 8.1. Nextcloud has over 400,000 deployments worldwide, and data sovereignty requirements keep pushing it further into government and enterprise environments. That makes this authentication bypass a meaningful risk for organizations that have enabled the ID4me federated identity feature.

Nextcloud is the most popular open-source, self-hosted content collaboration platform, with file sync and share, real-time document editing, calendar, email, and chat. Its partner ecosystem grew 300% in 2025, adding companies such as IONOS, Redpill Linpro, and Smile. Nextcloud pitches itself as the sovereign alternative to Microsoft 365 and Google Workspace, and it is a fixture in environments where regulatory compliance and data control come first.

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 then sends JWT tokens back to the Login Partner asserting the user's identity. The whole arrangement rests on one rule. The Login Partner must verify the cryptographic signature of each token to confirm that it really came from the trusted Identity Authority.

Root cause: a TODO that never got done

The vulnerability is classified as CWE-287 (Improper Authentication), and the root cause is unusually simple. Inside lib/Controller/Id4meController.php, the original ID4me authentication flow had 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 base64-decoded the token's header and payload, checked expiration, and processed the user identity. At no point did it check that a trusted authority had signed the token.

A rogue ID4me provider could therefore craft an arbitrary JWT claiming to be any user, and Nextcloud would accept it at face value. The attacker could set the sub claim, the email claim, or any other identity assertion to match any existing user account, and the vulnerable code would authenticate the session as that user.

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, which gives a score of 8.1 (High).

User Interaction is the main constraint. An attacker cannot exploit this silently at scale, because users first have to start an ID4me login flow against the malicious authority. That puts social engineering into the attack chain.

Attack flow

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

2. Lure: The attacker gets a Nextcloud user to start an ID4me login flow that routes through the attacker's Identity Authority. Phishing, DNS manipulation, or other social engineering techniques could do this.

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 goes back 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 gets full access to the victim's files, shares, and calendars, plus administrative capabilities if the target was an admin account.

The attack is also quiet. There is no availability impact (CVSS A:N), so the compromise causes no service disruption that might trigger detection.

Patch information

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

The patch replaces the TODO comment with real cryptographic signature verification. It imports the Firebase\JWT\JWT library, which the app already vendors for its standard OIDC flows, and adds this 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 fetches the JWK Set from the ID4me authority's JWKS URI, as declared in its OpenID configuration, and passes it to JWT::decode(), which performs full cryptographic signature verification. A 60-second leeway tolerates minor clock skew. Validation runs in two passes. The first tries the cached JWK keys. If that fails, for example after a key rotation, the code fetches fresh keys with useCache = false and tries again. It returns an HTTP 403 Forbidden response only if both attempts fail.

To support this, the patch adds a new obtainJWK() method to lib/Service/ID4MeService.php. The method fetches the JWKS from the authority endpoint, caches the response in Nextcloud's distributed cache layer, parses the key set with JWK::parseKeySet(), and calls DiscoveryService::fixJwksAlg() to align key algorithms with the token header. It reuses the JWK resolution logic already proven in the standard OIDC provider flow.

The third change is a small but necessary visibility adjustment in lib/Service/DiscoveryService.php. There, fixJwksAlg() changes from private to public so that the ID4MeService can reuse it.

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

Interim workaround

For organizations that cannot upgrade right away, the advisory gives an explicit workaround: disable the ID4me feature in the configuration. That removes the vulnerable code path entirely. The cost is that users who rely on ID4me-based authentication cannot 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 check their User OIDC app version in the Nextcloud Apps management interface or in the appinfo/info.xml file in the user_oidc app directory.

A Nextcloud instance is vulnerable only if the User OIDC app has the ID4me feature enabled. Organizations that do not use ID4me-based login are not affected by this specific vulnerability. Given this app's history of past vulnerabilities, though, they should stay alert for similar issues in other OIDC flows.

Vendor security history

Nextcloud runs a formal Vulnerability Disclosure Program on HackerOne, and researcher @cybertechajju reported CVE-2026-45156 through it (report #3489490). The User OIDC app, however, has been a recurring source of authentication vulnerabilities:

The repeated OIDC-related authentication issues (issuer verification bypass, CSRF in OIDC login, and now missing JWT signature verification) suggest a systemic difficulty in implementing OIDC and federated identity protocols correctly in their full complexity. Nextcloud is responsive about patching, but the pattern indicates that 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 several Nextcloud vulnerabilities. That level of institutional attention reflects how widely Nextcloud is deployed 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