CVE-2026-30843: Wekan Auth Bypass Vulnerability

CVE-2026-30843 Overview

CVE-2026-30843 is a critical Insecure Direct Object Reference (IDOR) vulnerability affecting Wekan, the open source kanban tool built with Meteor. This flaw allows unauthorized users to modify custom fields across boards through improperly secured custom fields update endpoints, potentially leading to unauthorized data manipulation across the entire Wekan instance.

The vulnerability stems from an authorization check being performed against the wrong resource. While the application validates that an authenticated user has access to a specified board, the subsequent database update operations use only the custom field's _id as a filter without confirming the field actually belongs to that board. This architectural flaw enables cross-board custom field manipulation by any authenticated user.

Critical Impact

Authenticated attackers can modify, create, or delete custom fields on any board in the Wekan instance by supplying a foreign custom field ID, completely bypassing intended access controls.

Affected Products

• Wekan version 8.32
• Wekan version 8.33

Discovery Timeline

• 2026-03-06 - CVE-2026-30843 published to NVD
• 2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-30843

Vulnerability Analysis

This Insecure Direct Object Reference vulnerability exists in multiple API endpoints within Wekan's custom fields functionality. The PUT /api/boards/:boardId/custom-fields/:customFieldId endpoint performs an authorization check to verify the authenticated user has access to the specified boardId. However, the critical flaw lies in the subsequent database update operation, which filters only by the custom field's _id without verifying that the custom field belongs to the board the user was authorized to access.

The same vulnerability pattern exists across multiple endpoint types including POST, PUT, and DELETE operations for dropdown items under custom fields. An attacker can obtain the required custom field IDs by exporting any board they have read access to, since the exported JSON includes the IDs of all board components including custom fields.

Root Cause

The root cause is a missing authorization verification step in the database query filter. The application correctly validates board access at the API level but fails to enforce that relationship at the data layer. When performing database updates, the code uses only { _id: paramFieldId } as the query filter, allowing modification of any custom field in the database regardless of which board it belongs to.

Attack Vector

The attack can be executed remotely over the network by any authenticated user with access to at least one board. The attacker workflow involves:

1. Creating or accessing any board in the Wekan instance
2. Exporting a target board (requires only read access) to obtain custom field IDs
3. Sending API requests to their own board's endpoint while specifying a target custom field ID from another board
4. The vulnerable endpoint processes the request and modifies the foreign board's custom field

The following patch demonstrates the security fix implemented in version 8.34:

       const paramFieldId = req.params.customFieldId;
       Authentication.checkBoardAccess(req.userId, paramBoardId);
 
+      const boardScopedField = {
+        _id: paramFieldId,
+        boardIds: { $in: [paramBoardId] },
+      };
+
       if (req.body.hasOwnProperty('name')) {
         CustomFields.direct.update(
-          { _id: paramFieldId },
+          boardScopedField,
           { $set: { name: req.body.name } },
         );
       }
       if (req.body.hasOwnProperty('type')) {
         CustomFields.direct.update(
-          { _id: paramFieldId },
+          boardScopedField,
           { $set: { type: req.body.type } },
         );
       }
       if (req.body.hasOwnProperty('settings')) {
         CustomFields.direct.update(
-          { _id: paramFieldId },
+          boardScopedField,
           { $set: { settings: req.body.settings } },
         );
       }
       if (req.body.hasOwnProperty('showOnCard')) {

Source: GitHub Commit

The fix adds boardIds: { $in: [paramBoardId] } to the query filter, ensuring that custom field modifications can only succeed when the custom field actually belongs to the board the user has been authorized to access.

Detection Methods for CVE-2026-30843

Indicators of Compromise

• API requests to /api/boards/:boardId/custom-fields/:customFieldId where the custom field ID does not belong to the specified board
• Unusual patterns of board export operations followed by custom field modification requests
• Audit log entries showing custom field changes by users who should not have write access to those boards
• Cross-board custom field manipulation patterns in application logs

Detection Strategies

• Monitor API access logs for PUT, POST, and DELETE requests to custom field endpoints with mismatched board and field relationships
• Implement correlation rules to detect users exporting boards they don't own followed by custom field modification attempts
• Review application logs for failed or unexpected custom field operations across board boundaries
• Deploy web application firewall rules to detect IDOR attack patterns targeting the affected endpoints

Monitoring Recommendations

• Enable detailed API logging for all custom field operations including the board context and field IDs
• Configure alerting for any custom field modifications on boards where the requesting user has read-only access
• Implement anomaly detection for users making bulk changes across multiple boards in short time windows
• Regularly audit custom field configurations across boards for unauthorized modifications

How to Mitigate CVE-2026-30843

Immediate Actions Required

• Upgrade Wekan to version 8.34 or later immediately to address this critical vulnerability
• Review audit logs for any suspicious custom field modifications prior to the upgrade
• Verify the integrity of custom field configurations across all boards after upgrading
• Consider temporarily restricting API access or board export functionality until the patch is applied

Patch Information

The vulnerability has been fixed in Wekan version 8.34. The patch modifies the models/customFields.js file to include board scope verification in all database queries, ensuring custom fields can only be modified through their associated board's endpoints. The fix adds a boardScopedField filter that validates both the custom field ID and board membership before allowing modifications.

For detailed information about the fix, refer to:

• GitHub Commit 73eb98c
• Wekan Release v8.34
• GitHub Security Advisory GHSL-2026-044

Workarounds

• Disable or restrict access to the board export API endpoint until the upgrade is complete
• Implement network-level access controls to limit who can reach the Wekan API endpoints
• Configure reverse proxy rules to block direct API access to custom field modification endpoints
• Consider placing Wekan behind authentication that requires additional verification for sensitive operations

# Example: Restricting API access via nginx until patched
# Add to nginx location block for Wekan
location /api/boards/ {
    # Temporarily restrict custom-fields endpoints
    if ($request_uri ~* "custom-fields") {
        return 403;
    }
    proxy_pass http://wekan_backend;
}