CVE-2026-25566: WeKan Authorization Bypass Vulnerability

CVE-2026-25566 Overview

CVE-2026-25566 is an authorization bypass vulnerability affecting WeKan versions prior to 8.19. The vulnerability exists in the card move logic, where users can specify a destination board, list, or swimlane without adequate authorization checks. Additionally, the application fails to validate that destination objects actually belong to the specified destination board, potentially enabling unauthorized cross-board card moves that could expose sensitive project data.

Critical Impact

Authenticated users can move cards to boards they don't have access to, potentially exposing confidential project information or disrupting workflows across organizational boundaries.

Affected Products

• WeKan versions prior to 8.19
• WeKan Open Source Kanban Board installations with card move functionality enabled
• Self-hosted WeKan deployments without updated authorization controls

Discovery Timeline

• 2026-02-07 - CVE-2026-25566 published to NVD
• 2026-02-09 - Last updated in NVD database

Technical Details for CVE-2026-25566

Vulnerability Analysis

This vulnerability is classified under CWE-863 (Incorrect Authorization). The flaw resides in the card move API endpoint within WeKan's models/cards.js file. When a user initiates a card move operation specifying a new board ID, swimlane ID, and list ID, the application processes the request without verifying whether the authenticated user has appropriate access rights to the destination board.

Furthermore, the vulnerable code path lacks validation to confirm that the specified destination list and swimlane actually belong to the target board. This creates a scenario where an attacker could craft API requests that reference arbitrary board IDs combined with mismatched list or swimlane identifiers, bypassing the intended access control model.

Root Cause

The root cause is the absence of authorization checks before processing cross-board card move operations. The original implementation trusted user-supplied destination parameters without verifying:

1. Whether the requesting user has board-level access to the destination board
2. Whether the specified destination list exists within and belongs to the destination board
3. Whether the specified destination swimlane exists within and belongs to the destination board

Attack Vector

An authenticated attacker with access to at least one board can exploit this vulnerability via network-based API requests. The attack requires low privileges (valid user account) and no user interaction. By manipulating the newBoardId, newListId, and newSwimlaneId parameters in card move API calls, an attacker can move cards containing potentially sensitive information to boards outside their authorized scope, or conversely, inject unauthorized cards into restricted boards.

// Security patch from models/cards.js showing added authorization checks
// Source: https://github.com/wekan/wekan/commit/198509e7600981400353aec6259247b3c04e043e

       );\n       }\n       if (newBoardId && newSwimlaneId && newListId) {
        // Validate destination board access
        Authentication.checkBoardAccess(req.userId, newBoardId);

        // Validate that the destination list exists and belongs to the destination board
        const destList = ReactiveCache.getList({
          _id: newListId,
          boardId: newBoardId,
          archived: false,
        });
        if (!destList) {
          JsonRoutes.sendResult(res, {
            code: 404,
            data: { error: 'Destination list not found or does not belong to destination board' },
          });
          return;
        }

        // Validate that the destination swimlane exists and belongs to the destination board
        const destSwimlane = ReactiveCache.getSwimlane({
          _id: newSwimlaneId,
          boardId: newBoardId,
          archived: false,
        });
        if (!destSwimlane) {
          JsonRoutes.sendResult(res, {
            code: 404,
            data: { error: 'Destination swimlane not found or does not belong to destination board' },

Source: GitHub Wekan Commit Update

Detection Methods for CVE-2026-25566

Indicators of Compromise

• Unusual card move activity patterns showing cards being transferred to boards where the user lacks explicit membership
• API request logs containing card move operations with destination board IDs that differ from the source board
• Audit trail entries showing cards appearing in boards without corresponding user access grants

Detection Strategies

• Monitor WeKan API logs for card move operations (PUT or POST requests to card endpoints) with cross-board destination parameters
• Implement alerting for card move operations where the requesting user's board membership doesn't include the destination board
• Review application logs for 404 errors related to destination list or swimlane validation failures, which may indicate exploitation attempts against patched systems

Monitoring Recommendations

• Enable detailed API request logging for all card manipulation endpoints in WeKan
• Configure SIEM rules to correlate card move events with user board membership records
• Establish baseline metrics for cross-board card movements to detect anomalous spikes in activity

How to Mitigate CVE-2026-25566

Immediate Actions Required

• Upgrade WeKan installations to version 8.19 or later immediately
• Audit recent card move activity logs to identify any potentially unauthorized cross-board transfers
• Review board membership and access control configurations to ensure principle of least privilege
• Consider temporarily restricting card move functionality to administrators while patching is in progress

Patch Information

The vulnerability has been addressed in WeKan version 8.19. The patch introduces proper authorization checks via Authentication.checkBoardAccess() and validates that destination lists and swimlanes belong to the specified destination board before allowing card moves. The fix is available in commit 198509e7.

For detailed patch information, see the VulnCheck Advisory on Wekan and the official Wekan website.

Workarounds

• Implement network-level access controls to restrict WeKan API access to trusted internal networks only
• Use a reverse proxy or web application firewall to filter and log card move API requests containing cross-board parameters
• Temporarily disable cross-board card move functionality at the application level if the feature is not business-critical

# Example: Update WeKan using Docker
docker pull wekanteam/wekan:v8.19
docker stop wekan-app
docker rm wekan-app
docker run -d --name wekan-app --restart=always \
  -e MONGO_URL=mongodb://wekandb:27017/wekan \
  -e ROOT_URL=https://your-wekan-domain.com \
  wekanteam/wekan:v8.19