Wekan CVE-2025-65780

Requires an authenticated Wekan account (PR:L) that can issue client-side updates to the Meteor user collection; exploitation is most dangerous on instances permitting open self-registration, where any attacker can create the needed account. The specific prerequisite is the absence of server-side authorization on the Users.allow update rule in versions ≤18.15, letting the owner write sensitive fields (isAdmin, orgs, teams, roles, loginDisabled, authenticationMethod) that should be server-only. Limiting factors: a valid login is mandatory (not remote-unauthenticated), and instances that restrict registration or run 18.16+ (which whitelists only username and profile.* for client writes) are not exploitable.

This is a genuine high-priority issue for any organization running a self-hosted Wekan instance, though its real-world risk is bounded by two factors. The CVSS vector (AV:N/AC:L/PR:L/UI:N) confirms network-reachable, low-complexity exploitation requiring only low-level authentication - i.e. any registered user account, no admin rights and no victim interaction. The impact triad C:H/I:H/A:H is justified because the missing authorization check lets a user rewrite forbidden fields of their own user document (isAdmin, orgs, teams, roles, loginDisabled), enabling direct privilege escalation to administrator and lateral access into other teams/orgs. The source-code evidence (commit f26d582 adding USER_UPDATE_FORBIDDEN_PREFIXES and tightening the Users.allow update rule) independently confirms both the root cause and the fix, raising confidence well above a description-only assessment. However, no EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active or at-scale exploitation - this is a high-CVSS flaw whose current threat is latent rather than demonstrated. The requirement for a pre-existing authenticated account (PR:L) is the key mitigating signal: instances with closed/trusted registration face materially lower exposure than those allowing open self-registration, where any attacker-created account becomes an admin. No signals are directly conflicting; the main gap is the absence of exploitation-probability data.

An attacker registers or already holds a low-privilege Wekan account, then issues a client-side update to their own user document setting isAdmin:true (or injecting themselves into additional orgs/teams), which the vulnerable server accepts because it never authorizes these sensitive fields. With administrator rights they can read and modify every board, team, and user across the instance. No public exploit was provided, but the trivial Meteor allow-rule abuse requires no special tooling.