CVE-2026-68561

The version 9.89 patch fixes a specific privilege escalation vector in Wekan, but the remediation is narrower than the underlying problem. The core issue isn't that comment-only members could modify the sort field — it's that Meteor's allow rules use OR semantics while applying the complete modifier atomically. One allow rule authorized sorting; a second authorized other field changes. When an attacker bundles a legitimate sort $set with malicious $set operations on members, permission, and title, Meteor evaluates each allow rule independently: the sort rule returns true, and OR semantics mean the entire operation proceeds with all modifiers applied. The deny rule should have stopped this, but it checked only $pull operations (removing members) while ignoring $set operations that accomplish the same end through a different MongoDB operator. The patch adds two conditions: sort must be the sole modified field, and $set cannot remove the last admin. These close the documented exploit, but they don't fix the architectural flaw. The underlying authorization model — allow rules evaluated independently under OR semantics, complete modifier applied atomically — remains unchanged. Any other field with a permissive allow rule paired with an incomplete deny rule is still a potential vector. The boards.js schema contains other fields (description, color, archived, slug, tags) that almost certainly have similar allow/deny pairs that weren't chained into a full privilege escalation and therefore weren't patched. The maintenance pressure here is significant. Requiring sort as the sole modified field is a brittle constraint. When a future developer needs to update sort atomically with another field for performance reasons, they'll encounter this guard, find no architectural documentation explaining it, and face pressure to remove the constraint or add a bypass — reopening the vector. The check for "removing the last admin" also creates edge cases: what about demoting rather than removing? What defines "last" when multiple conditions exist? This pattern isn't unique to Wekan. The boards.js permission model is a template that Meteor developers copy. Other Wekan instances, forks, or derivative applications using similar allow/deny patterns likely carry the same structural flaw. The CVE patches one node in a graph of potentially unpatched systems. If you're defending this system, prioritize auditing other allow/deny pairs in the permission model for the same OR-semantics-plus-incomplete-deny pattern. Consider whether a deny rule should inspect the complete modifier object rather than individual operator types. The fix in 9.89 is necessary, but without addressing the underlying authorization design, the next similar vulnerability is a matter of when, not if.

Reviewed through automated stages and approved by a human before publication.