Hall of Fame image from https://openclipart.org/detail/120343/trophy
Back to Hall of Fame Contents Back to Wekan Website

Contents / OIDCBleed

CVE Vulnerability name Date Responsible Security Disclosure by Vulnerabilities
CVE-2026-53444 GHSA-cv95-8h7c-2ffq, CVE-2026-52893 GHSA-mp7g-hj5q-gxhq

OIDCBleed

2026-05-31 alexwaira (coordinated disclosure) and Claude

Did send detailed report!
  • 1. OIDC method privilege escalation
  • 2. OIDC account takeover via email merge
  • Affected Wekan v9.31 and earlier
  • Fixed at Wekan v9.32 2026-05-31


Details

1. Missing authorization on OIDC Meteor methods allows privilege escalation to admin (CVE-2026-53444 GHSA-cv95-8h7c-2ffq, CWE-269, CWE-862)

Six Meteor methods used internally by the OIDC login flow were registered as globally DDP-callable with no authorization, while their non-OIDC counterparts require admin. setCreateOrgFromOidc and setOrgAllFieldsFromOidc (server/models/org.js), setCreateTeamFromOidc and setTeamAllFieldsFromOidc (server/models/team.js) let any authenticated user create/rename/deactivate/modify arbitrary organizations and teams — including orgAutoAddUsersWithDomainName — bypassing the admin-only restriction.

Most critically, groupRoutineOnLogin (packages/wekan-oidc/oidc_server.js) sets isAdmin from caller-supplied group data, so with PROPAGATE_OIDC_DATA enabled any authenticated user could call it over DDP with {groups:[{isAdmin:true,forceCreate:true}]} and promote themselves to global admin; boardRoutineOnLogin could likewise add the caller to the default board.

Fix: these six methods are only ever invoked server-side (via Meteor.callAsync) during the OIDC handshake. A server-to-server call runs with this.connection === null, whereas a client call has a non-null connection, so each method now throws not-authorized when this.connection !== null. The legitimate OIDC login flow is unaffected.

2. OIDC account takeover via unconditional email-based account merge (CVE-2026-52893 GHSA-mp7g-hj5q-gxhq, CWE-287)

The onCreateUser hook in server/models/users.js unconditionally merged an incoming OIDC login into any existing Wekan account whose email or username matched the (attacker-controlled) OIDC claims — no ownership check, no email-verification check, no notification. An attacker who could present a matching email/username claim (trivial on self-hosted Keycloak/Authentik, where the email/email_verified claims are attacker-settable) inherited the victim's _id, boards, cards, attachments, API tokens and admin status, during the attacker's own first OIDC login with no victim interaction.

Fix: fail closed, mirroring LDAP_MERGE_EXISTING_USERS: matching is now by email only (never username); auto-linking is opt-in via the new OAUTH2_MERGE_EXISTING_USERS setting (OFF by default); even when enabled the OIDC provider must assert email_verified=true; otherwise the OIDC login is rejected with oidc-email-already-in-use instead of merging.



Timeline Details
2026-05 Report received from alexwaira (coordinated disclosure).
2026-05-31 Fixed at Wekan v9.32 2026-05-31


Back to Hall of Fame Contents Back to Wekan Website