CVE-2026-68561

Executive Summary

CVE-2026-68561 is a privilege escalation vulnerability in Wekan, an open-source kanban board application built on the Meteor framework. The flaw resides in the Boards.allow({ update }) permission rule, which improperly grants board members with comment-only or read-only privileges the ability to modify critical board properties — including member lists, permissions, and board visibility — by exploiting the OR semantics of Meteor's allow rules combined with a flawed validation function.

Successful exploitation allows any authenticated low-privileged board member to elevate themselves to sole board administrator, expose private boards publicly, and evict legitimate owners, leading to complete compromise of board data confidentiality, integrity, and availability. The vulnerability is rated CVSS 8.8 (High) and affects all Wekan deployments prior to version 9.89. No public exploit code has been identified, and Wekan has not yet been added to CISA's Known Exploited Vulnerabilities catalog.

Technical Analysis

Vulnerability Mechanism

The vulnerability is rooted in Meteor's server-side collection security model. Wekan defines Boards.allow({ update }) rules in server/permissions/boards.js, which specify the conditions under which a Boards.update() operation is permitted. Two distinct allow rules exist, and Meteor uses OR semantics — meaning that if any single allow rule passes, the update is permitted, regardless of what other rules may have rejected.

The first allow rule contains validation logic that invokes canUpdateBoardSort from server/lib/utils.js. This helper function is responsible for determining whether a board member is authorized to reorder board items. Critically, the function allows any board member — regardless of role — to perform updates whenever the fieldNames array includes the string "sort". This is a dangerously broad authorization predicate, as it does not check the user's administrative status or board-specific role.

The Privilege Escalation Chain

The vulnerability exploitation relies on the fact that Meteor applies the complete modifier to the document when an update is permitted. This means that when a user sends a Boards.update call, Meteor does not isolate the allowed fields — it takes the entire modifier object and applies it to the target document.

An attacker can therefore craft a single Boards.update operation that includes:

1. $set for sort — This triggers the permissive allow rule path, which grants authorization because fieldNames contains "sort".
2. $set for members — Replaces the entire members array with a new array where the attacker is the only (or sole administrator) entry.
3. $set for permission — Alters the board visibility from private to public, exposing sensitive project data.
4. $set for title — Changes board metadata as needed.

Because the allow rule passes (due to the sort field being present), the entire modifier is applied. The attacker effectively bypasses role-based restrictions because the validation function never checks that the other fields (members, permission, title) are permitted for a comment-only or read-only user.

The Protector That Failed

Wekan implements a "last administrator" deny rule — a defensive guard intended to prevent removal of the final active administrator from a board. However, the NVD description clarifies that this deny rule inspects only $pull operations. The $pull operator removes specific values from an array. The deny rule correctly blocks attempts to $pull the last admin from the members array.

The attacker circumvents this by using the $set operator instead, which replaces the entire array wholesale. Since the deny rule does not examine $set operations on the members field, it fails to detect or block the eviction of the legitimate owner.

Affected Scope

The attack surface is any authenticated user who is a member of a board with comment-only or read-only permissions. The attacker does not need special privileges — only valid board membership credentials. The attacker can be an external collaborator, a disgruntled contractor, or a lower-tier employee with minimal access.

Fix in Version 9.89

The remediation in version 9.89 applies two specific restrictions:

1. sort must be the only modified field — Any update that includes sort alongside other fields (like members or permission) is rejected.
2. $set of member arrays that remove the last active administrator is rejected — Closing the $set bypass path that circumvents the last-admin protection.

This dual fix ensures that the broad authorization granted for sort updates cannot be abused to modify unrelated sensitive fields.

Exploitation Scenarios

The following attack chain is based strictly on the vulnerability description. Since no public exploit code is known, the chain is inferred from the vulnerability class and mechanism.

Step 1: Reconnaissance and Target Identification

An attacker with valid credentials for a Wekan instance identifies a target board where they have been added as a comment-only or read-only member. This status often applies to external contractors, clients, or junior staff. The attacker identifies the target board's ID (MongoDB ObjectId) and confirms their member role via the Wekan API or UI interactions.

Step 2: Triggering the Flaw

The attacker constructs a Boards.update call targeting the victim board's document ID. The modifier includes:

• A $set operation on the sort field (any value — even trivial or unchanged data triggers the fieldNames check).
• A $set operation on the members array — replacing it with an array containing only the attacker, with admin privileges.
• A $set operation on the permission field — changing the value to "public" to expose the board.
• A $set operation on the title field — optionally renaming the board.

The request is made via WebSocket (Meteor's DDP protocol) or the REST API, depending on the attacker's tooling.

Step 3: Exploitation Mechanics

The attack succeeds because:

1. The server-side allow rule for updates delegates authorization to canUpdateBoardSort.
2. canUpdateBoardSort returns true for any board member when fieldNames contains "sort".
3. Meteor's OR-rule semantics mean this passing rule is sufficient to authorize the entire update.
4. The complete modifier is applied because Meteor does not filter individual fields within an allowed update.
5. The last-admin deny rule fails because it only inspects $pull operations, not wholesale $set array replacement.

Step 4: Post-Exploitation Impact

Once the attacker becomes sole board administrator:

• Data Exposure: They can view all cards, comments, attachments, and checklists on the board, even if the board was previously private.
• Persistent Access: As the only admin, the attacker controls all future member additions/removals.
• Data Manipulation: They can edit or delete any card, alter board settings, and tamper with project metadata.
• Lateral Movement Potential: The exposed board may contain credentials, API keys, project planning documents, or other sensitive material that enables further attacks against internal systems.

If the attacker chooses permission: "public", any unauthenticated user on the internet can discover and view the board, expanding the exposure beyond the Wekan instance's user base.

Impact Assessment

The CVSS vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H translates to a High severity rating (8.8/10). Breaking down the vectors:

• Attack Vector (AV:N): The vulnerability is remotely exploitable over the network; no physical or local access required.
• Attack Complexity (AC:L): No special conditions or race conditions needed. The attack is straightforward and reliable.
• Privileges Required (PR:L): The attacker needs only a valid low-privileged account with comment-only or read-only board membership.
• User Interaction (UI:N): No victim interaction required — the attack executes automatically once submitted.
• Scope (S:U): The impact is limited to the Wekan application and its data store; no cross-system scope expansion.
• Confidentiality (C:H): Complete loss of board data confidentiality — private boards become visible, and admin-level read access is gained.
• Integrity (I:H): Full write capability — attacker can modify, delete, or corrupt all board content.
• Availability (A:H): The legitimate owner is evicted; the attacker can lock others out, effectively rendering the board unavailable to the original team.

Business Impact

Blast Radius

Any Wekan deployment running version prior to 9.89 is vulnerable. This includes self-hosted Docker deployments, Kubernetes installations, and Meteor-based cloud instances. Organizations using Wekan for:

• Agile/Scrum project management
• Incident response coordination
• Client-facing project tracking
• Internal knowledge management

are all at risk if low-privileged collaborators (comment-only or read-only) have access to any board.

Detection Guidance

The following detection rules target the server-side audit trail of MongoDB update operations, Wekan application logs, and network traffic patterns consistent with the exploitation mechanism. All rules should be tuned to the organization's environment.

Sigma Rule

title: Wekan Privilege Escalation via Boards.update Sort Bypass (CVE-2026-68561)
id: 8f3e6b1a-5c74-4d6a-b089-1f2a9c73d8e1
status: experimental
description: Detects Wekan Boards.update operations where the sort field is modified alongside members or permission fields, indicating attempted privilege escalation via CVE-2026-68561.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-68561
    - https://github.com/wekan/wekan
author: Valtersit Threat Intelligence
date: 2026/01/20
logsource:
    category: application
    product: wekan
    service: meteor
detection:
    selection_operation:
        event.action: 'boards.update'
    selection_fields:
        update.modifier.$set|has_all:
            - 'sort'
            - 'members'
    condition: selection_operation and selection_fields
falsepositives:
    - Legitimate board administration actions where an admin reorders cards and updates member lists in the same operation
level: high
tags:
    - attack.t1190
    - cve.2026-68561
    - cwe.269

YARA Rule

rule Wekan_Boards_Update_PrivEsc_CVE_2026_68561 {
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects Wekan API or DDP payloads attempting privilege escalation via sort field authorization bypass"
        date = "2026-01-20"
        cve = "CVE-2026-68561"
        severity = "high"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-68561"
    strings:
        $s1 = "Boards.update" ascii wide nocase
        $s2 = "fieldNames" ascii wide nocase
        $s3 = "sort" ascii wide nocase
        $s4 = "$set" ascii wide nocase
        $s5 = "members" ascii wide nocase
        $s6 = "permission" ascii wide nocase
        $s7 = "canUpdateBoardSort" ascii wide nocase
    condition:
        uint16(0) == 0x5B7B and (   // "[{" JSON start
            ($s1 or $s7) and
            ($s3) and
            ($s2) and
            ($s4 and $s5) or
            ($s1 and $s3 and $s4 and $s5 and $s6)
        )
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-68561 Wekan Boards.update Privilege Escalation Attempt"; flow:established,to_server; content:"Boards.update"; http_client_body; nocase; content:"sort"; http_client_body; distance:0; content:"members"; http_client_body; distance:0; content:"$set"; http_client_body; distance:0; reference:cve,2026-68561; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-68561; classtype:attempted-admin; sid:202668561; rev:1;)

alert http any any -> $HOME_NET any (msg:"CVE-2026-68561 Wekan Sort Field Bypass Update Detected"; flow:established,to_server; content:"canUpdateBoardSort"; http_client_body; nocase; content:"fieldNames"; http_client_body; distance:0; content:"sort"; http_client_body; distance:0; reference:cve,2026-68561; classtype:attempted-admin; sid:202668562; rev:1;)

Elastic Detection

// Detection for HTTP requests to Wekan API endpoints containing Boards.update
// with simultaneous sort and members field modifications

sequence by source.ip, user.name with maxspan=5s
  [ network where event.category == "network" and event.outcome == "success" and
    network.protocol == "http" and destination.port in (80, 443) ]
  [ http where event.category == "web" and http.request.method == "POST" and
    http.request.body.content contains "Boards.update" and
    http.request.body.content contains "sort" and
    http.request.body.content contains "members" and
    http.request.body.content contains "$set" ]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=json
| search "Boards.update" AND "sort" AND "members" AND "$set"
| table _time, src_ip, user, uri_path, http_method, status
| rename uri_path AS "API Endpoint", src_ip AS "Source IP"
| sort - _time

For MongoDB audit logs:

index=mongodb sourcetype=mongodb_audit
| search "Boards.update" AND "modifier.$set.sort" AND "modifier.$set.members"
| table _time, user, db, collection, operation
| where isnotnull(modifier.$set.members) AND isnotnull(modifier.$set.sort)

Wazuh OSSEC Rule

<group name="wekan,">
  <rule id="100856" level="15">
    <decoded_as>json</decoded_as>
    <field name="collection">^boards$</field>
    <field name="operation">^update$</field>
    <field name="modifier\.\$set\.sort">.+</field>
    <field name="modifier\.\$set\.members">.+</field>
    <description>CVE-2026-68561: Wekan privilege escalation - Boards.update with sort and members $set modification</description>
    <group>attack.t1190,wekan,cve-2026-68561,</group>
    <cve>CVE-2026-68561</cve>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>

  <rule id="100857" level="12">
    <decoded_as>json</decoded_as>
    <field name="event\.action">^boards\.update$</field>
    <field name="update\.operation">^\$set$</field>
    <field name="update\.fields">.*sort.*</field>
    <field name="update\.fields">.*members.*</field>
    <description>CVE-2026-68561: Wekan application log - Boards.update with sort and members fields</description>
    <group>attack.t1190,wekan,cve-2026-68561,</group>
    <cve>CVE-2026-68561</cve>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED — no patch evidence from any tracked source

The NVD description indicates the fix landed in Wekan version 9.89, but no upstream patch confirmation from vendor release channels, GitHub release tags, or security advisory mailing lists has been identified in our tracked sources. This is a critical discrepancy that must be validated directly with the vendor.

1. Immediate Mitigations (While Waiting for Patch Verification)

Since no confirmed patch is available, implement the following mitigations immediately:

• Restrict board memberships: Remove or downgrade comment-only and read-only members on sensitive boards until the patch is verified. If all board members are administrators, the vulnerability cannot be exploited.
• Network access controls: Restrict access to the Wekan instance to trusted IP ranges only. This reduces the exposure of unauthenticated attackers to the AV:N vector.
• Enable MongoDB audit logging: If using MongoDB's enterprise audit features, enable audit trail for update operations on the boards collection to detect suspicious modification patterns.
• Web application firewall (WAF) rules: Deploy WAF rules that inspect request bodies for the presence of both sort and members fields in Boards.update operations and block or alert.
• Review existing boards: Manually audit all boards for unauthorized member additions or permission changes in recent logs. If any abnormal changes are found, restore from backup.
• Disable remote access for low-privileged accounts: If feasible, require VPN access for all board members with non-admin roles.

2. Patch/Upgrade Steps

• Validate patch authenticity: Contact Wekan maintainers directly or monitor the official GitHub repository (wekan/wekan) release notes to confirm version 9.89 is a legitimate, signed release.
• Upgrade to version 9.89 or later once patch authenticity is confirmed:
  • For Docker: docker pull wekanteam/wekan:latest then restart containers with the new image.
  • For Meteor-based deployments: follow the official upgrade guide for your deployment method (meteor update, npm, systemd service, etc.).
• Pre-upgrade steps:
  1. Back up the MongoDB database (board documents, user data, attachments).
  2. Take a snapshot of the running container/VM.
  3. Document current version and configuration for rollback purposes.
• Post-upgrade verification:
  1. Verify version via the Wekan UI footer or API.
  2. Test the vulnerability by creating a comment-only member account and attempting the exploit on a test board.
  3. Confirm that a $set of members alongside sort is rejected.

3. Long-Term Hardening

• Enable two-factor authentication (2FA) for all Wekan accounts, especially board administrators. This reduces the risk of credential compromise that could be leveraged for this attack.
• Implement the principle of least privilege: Regularly audit board memberships and remove users who no longer require access. Prefer granting view-only over comment-only, and comment-only over editor roles.
• Monitor Wekan security advisories: Subscribe to the Wekan GitHub releases feed and security mailing lists to receive future alerts promptly.
• Application-layer monitoring: Deploy the detection rules provided in this report (Sigma, YARA, Suricata, Elastic, Splunk, Wazuh) to detect exploitation attempts in real time.
• Network segmentation: Place Wekan behind a reverse proxy and restrict direct database access to internal networks only.
• Periodic penetration testing: Schedule regular internal penetration tests that include testing of the Wekan instance's permission model, especially after any upgrade.
• Keep MongoDB hardened: Ensure the MongoDB instance backing Wekan is not exposed externally and uses authentication mechanisms that prevent direct manipulation of the boards collection.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-68561 — Official NVD vulnerability record for CVE-2026-68561.

2. Wekan Official Repository: https://github.com/wekan/wekan — Source repository and release notes; version 9.89 contains the fix. Verify release notes directly here for patch confirmation.

3. Wekan Official Site: https://wekan.github.io/ — Project documentation and deployment guides.

4. CWE-269 Description: https://cwe.mitre.org/data/definitions/269.html — Improper Privilege Management; the weakness class this CVE maps to.

5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog — Check periodically; as of this report, CVE-2026-68561 is not listed (KEV status: NO).

Threat Actor Campaigns

No known threat actor campaigns, exploit-in-the-wild activity, or Proof-of-Concept publications have been identified for CVE-2026-68561 at the time of this writing. The EPSS score has not yet been assigned by FIRST.org. However, given that the attack requires only low-privileged credentials and the mechanism is straightforward (single MongoDB update call), the likelihood of exploitation increases significantly once a PoC circulates in the security community or dark web forums. Organizations running Wekan should treat this as a priority remediation item despite the lack of currently observed exploitation.