Description

Wekan is open source kanban built with Meteor. Prior to 9.89, the second Boards.allow({ update }) rule in server/permissions/boards.js called canUpdateBoardSort in server/lib/utils.js, which authorized any board member whenever fieldNames included sort. Because Meteor combines allow rules with OR semantics and applies the complete modifier, a comment-only or read-only member could send one Boards.update with $set values for sort, members, permission, and title, make themselves the sole board administrator, expose a private board, and evict the legitimate owner; the last-admin deny rule inspected only $pull and did not block a wholesale $set of members. Version 9.89 requires sort to be the only modified field and rejects $set member arrays that remove the last active administrator. This issue is fixed in version 9.89.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-19T20:17:21.400Z",
  "pubdate": "2026-08-19T20:17:21.400Z",
  "executiveSummary": "An authorization bypass and privilege escalation vulnerability exists in Wekan prior to version 9.89. The flaw resides within the server-side permission handling logic for board updates, specifically allowing comment-only or read-only board members to execute unauthorized administrative actions.\nThe vulnerability allows low-privileged users to leverage insecure allow-rule semantics in Meteor to modify restricted board attributes. By submitting a crafted update request containing simultaneous modifications to the sort field alongside sensitive fields such as members, permission, and title, an attacker can elevate their privileges to sole board administrator, expose private boards, and evict legitimate owners.\nThe root cause stems from improper logical combination of allow rules using OR semantics, combined with a failure in deny rules to inspect wholesale $set operations on member arrays, checking only for $pull operations. Successful exploitation requires board membership but bypasses intended role-based restrictions, posing a severe risk to data confidentiality and integrity on affected Wekan instances.",
  "technicalDetails": "The vulnerability is located in Wekan prior to version 9.89, specifically within the second Boards.allow({ update }) rule defined in server/permissions/boards.js, which invokes the canUpdateBoardSort function located in server/lib/utils.js.\nThe root cause of the vulnerability stems from how Meteor evaluates allow and deny rules. Meteor combines allow rules using logical OR semantics and applies the complete modifier in a single transaction. The vulnerable implementation improperly authorized any board member to perform updates whenever the modified fieldNames array included the sort field. Because the validation logic failed to restrict other fields modified within the same operation, an attacker possessing only comment-only or read-only access could append arbitrary update operators alongside sort.\nThe attack flow proceeds as follows: an authenticated user with low privileges (such as a read-only or comment-only member) initiates a malicious Boards.update request. The payload utilizes a wholesale $set modifier to target multiple fields simultaneously. The request includes the sort field to satisfy the flawed canUpdateBoardSort authorization check, while concurrently injecting malicious updates into the members, permission, and title fields.\nDuring evaluation, the server checks the allow rules. Because the sort field is present in the fieldNames list, the update is provisionally permitted due to the permissive OR evaluation logic. Furthermore, the existing last-admin deny rule fails to prevent the attack because it was designed to inspect only $pull operations, entirely failing to block malicious wholesale $set operations targeting the members array.\nPost-exploitation impact includes complete loss of board control for the legitimate owner. The attacker can successfully rewrite the members array to remove the actual owner, assign themselves sole administrative privileges, and alter the board permission settings to expose private data to unauthorized entities.\nAffected versions include all Wekan installations prior to version 9.89. The vulnerability requires existing board membership (either read-only or comment-only) and network exposure to the Wekan application server to transmit the crafted database update payload."
}