CVE-2026-25564: Wekan Auth Bypass Vulnerability

CVE-2026-25564 Overview

CVE-2026-25564 is an Insecure Direct Object Reference (IDOR) vulnerability affecting WeKan, an open-source kanban board application. Versions prior to 8.19 contain a flaw in checklist creation and related checklist routes where the implementation does not verify that the supplied cardId belongs to the supplied boardId. This oversight allows authenticated attackers to perform cross-board ID tampering by manipulating identifiers in API requests.

Critical Impact
Authenticated users can manipulate checklist operations across different boards by exploiting the missing relationship validation between cards and boards, potentially leading to unauthorized data modification or deletion.

Affected Products

WeKan versions prior to 8.19
wekan_project wekan (cpe:2.3:a:wekan_project:wekan:*:*:*:*:*:*:*:*)

Discovery Timeline

2026-02-07 - CVE CVE-2026-25564 published to NVD
2026-02-10 - Last updated in NVD database

Technical Details for CVE-2026-25564

Vulnerability Analysis

This vulnerability is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), a specific type of Insecure Direct Object Reference (IDOR). The flaw exists in the WeKan checklist API routes, where the application accepts user-supplied boardId, cardId, and checklistId parameters but fails to validate the relationships between these entities before performing operations.

When an authenticated user makes API requests to checklist endpoints such as /api/boards/:boardId/cards/:cardId/checklists/:checklistId, the application checks board access permissions but does not verify whether the specified card actually belongs to the specified board. This creates a logical gap where an attacker with access to one board can manipulate checklists on cards belonging to entirely different boards by simply substituting the cardId parameter with an identifier from another board.

Root Cause

The root cause of this vulnerability is the absence of proper relationship validation in the checklist route handlers. The original implementation performed board-level access control using Authentication.checkBoardAccess() but neglected to verify the hierarchical relationship between the board, card, and checklist entities. This is a common pattern in applications with nested resources where developers assume that having access to a parent resource (board) implicitly validates operations on child resources (cards/checklists).

Attack Vector

The attack is network-accessible and requires low-privileged authenticated access to the WeKan application. An attacker would need:

Valid authentication credentials for the WeKan instance
Access to at least one board (to pass initial authorization)
Knowledge or enumeration of valid cardId and checklistId values from other boards

The attacker can then craft API requests that specify their authorized boardId but substitute cardId and checklistId values from boards they should not have access to, bypassing authorization controls and potentially deleting or modifying checklists across board boundaries.

javascript

     '/api/boards/:boardId/cards/:cardId/checklists/:checklistId',
     function(req, res) {
       const paramBoardId = req.params.boardId;
+      const paramCardId = req.params.cardId;
       const paramChecklistId = req.params.checklistId;
       Authentication.checkBoardAccess(req.userId, paramBoardId);
+
+      // Verify the card belongs to the board
+      const card = ReactiveCache.getCard({
+        _id: paramCardId,
+        boardId: paramBoardId,
+      });
+      if (!card) {
+        JsonRoutes.sendResult(res, {
+          code: 404,
+          data: { error: 'Card not found or does not belong to the specified board' },
+        });
+        return;
+      }
+
+      // Verify the checklist exists and belongs to the card
+      const checklist = ReactiveCache.getChecklist({
+        _id: paramChecklistId,
+        cardId: paramCardId,
+      });
+      if (!checklist) {
+        JsonRoutes.sendResult(res, {
+          code: 404,
+          data: { error: 'Checklist not found or does not belong to the specified card' },
+        });

Source: GitHub Wekan Commit Update

Detection Methods for CVE-2026-25564

Indicators of Compromise

API requests to checklist endpoints where the cardId parameter references cards not belonging to the specified boardId
Unusual patterns of API calls with mismatched board and card identifiers from the same user session
Checklist modifications or deletions appearing in audit logs for boards the requesting user does not have explicit access to

Detection Strategies

Implement API request logging that captures the relationship between boardId, cardId, and checklistId parameters for correlation analysis
Deploy application-level anomaly detection to identify users making requests with cross-board identifier patterns
Review WeKan access logs for DELETE or PUT operations on /api/boards/*/cards/*/checklists/* endpoints with unusual parameter combinations

Monitoring Recommendations

Enable verbose logging on WeKan API endpoints, particularly those handling checklist operations
Monitor for 404 responses from checklist endpoints that may indicate attempted exploitation after patching
Implement alerting for high-frequency API requests to checklist routes from individual user sessions

How to Mitigate CVE-2026-25564

Immediate Actions Required

Upgrade WeKan to version 8.19 or later immediately to address this vulnerability
Audit checklist activity logs for any suspicious cross-board operations that may indicate prior exploitation
Review user access permissions and ensure board-level access controls are properly configured
Consider temporarily restricting API access if upgrade cannot be performed immediately

Patch Information

The vulnerability has been addressed in WeKan version 8.19. The fix adds proper relationship validation between boards, cards, and checklists before allowing operations to proceed. The patch verifies that:

The specified card exists and belongs to the specified board
The specified checklist exists and belongs to the specified card

If either validation fails, the API returns a 404 error with an appropriate message, preventing cross-board tampering. For detailed patch information, refer to the GitHub Wekan Commit Update.

Workarounds

Implement a reverse proxy or Web Application Firewall (WAF) rule to validate that API requests contain consistent board-card relationships
Temporarily disable checklist API endpoints if they are not critical to operations while awaiting upgrade
Restrict network access to the WeKan instance to trusted users only until patching is complete

bash

# Example: Upgrade WeKan to patched version
# Using Snap (common WeKan installation method)
sudo snap refresh wekan --channel=latest/stable

# Verify the installed version is 8.19 or later
snap info wekan | grep installed