CVE-2026-25562: Wekan Information Disclosure Vulnerability

CVE-2026-25562 Overview

CVE-2026-25562 is an information disclosure vulnerability affecting WeKan versions prior to 8.19. The vulnerability exists in the attachments publication functionality, where attachment metadata can be returned without properly scoping results to boards and cards accessible to the requesting user. This flaw potentially exposes sensitive attachment metadata to unauthorized users who have authenticated access to the WeKan application.

Critical Impact
Authenticated users can access attachment metadata from boards and cards they are not authorized to view, potentially exposing sensitive file information, upload timestamps, and associated card/board identifiers across the entire WeKan instance.

Affected Products

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

Discovery Timeline

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

Technical Details for CVE-2026-25562

Vulnerability Analysis

This vulnerability is classified as CWE-203 (Observable Discrepancy), which falls under the broader category of information disclosure vulnerabilities. The root issue lies in the attachmentsList Meteor publication endpoint, which fails to enforce proper authorization checks before returning attachment metadata to requesting users.

In vulnerable versions, the publication returns attachment data without verifying whether the requesting user has legitimate access to the associated boards and cards. This means any authenticated user can potentially enumerate and retrieve metadata for attachments across the entire WeKan instance, regardless of their actual permissions.

The attack requires network access and low-privilege authentication (any valid WeKan user account). While the vulnerability does not directly expose the attachment file contents, the leaked metadata can reveal sensitive information including filenames, upload dates, file sizes, and the board/card structure of the organization's project management data.

Root Cause

The root cause is insufficient authorization validation in the attachmentsList publication within server/publications/attachments.js. The original implementation failed to filter attachment results based on the requesting user's board and card access permissions, returning all attachment metadata without proper scoping.

Attack Vector

The attack vector is network-based, requiring an authenticated user to subscribe to the attachmentsList publication. An attacker with a low-privilege WeKan account can exploit this vulnerability by:

Authenticating to the WeKan application with any valid user credentials
Subscribing to the attachmentsList Meteor publication
Receiving attachment metadata from boards and cards they should not have access to
Using the leaked metadata to gather intelligence about projects, files, and organizational structure

javascript

 import { ObjectID } from 'bson';
 
 Meteor.publish('attachmentsList', function(limit) {
+  const userId = this.userId;
+
+  // Get boards the user has access to
+  const userBoards = ReactiveCache.getBoards({
+    $or: [
+      { permission: 'public' },
+      { members: { $elemMatch: { userId, isActive: true } } }
+    ]
+  }).map(board => board._id);
+
+  if (userBoards.length === 0) {
+    // User has no access to any boards, return empty cursor
+    return this.ready();
+  }
+
+  // Get cards from those boards
+  const userCards = ReactiveCache.getCards({
+    boardId: { $in: userBoards },
+    archived: false
+  }).map(card => card._id);
+
+  if (userCards.length === 0) {
+    // No cards found, return empty cursor
+    return this.ready();
+  }
+
+  // Only return attachments for cards the user has access to

Source: GitHub Commit

Detection Methods for CVE-2026-25562

Indicators of Compromise

Unusual subscription patterns to the attachmentsList publication from user accounts that typically don't access attachments
High-volume metadata queries from single authenticated sessions
Access patterns showing users retrieving attachment information for boards they are not members of
Abnormal spikes in Meteor DDP (Distributed Data Protocol) traffic related to attachment publications

Detection Strategies

Monitor Meteor publication subscriptions for the attachmentsList endpoint and correlate with user board membership
Implement logging at the application layer to track attachment metadata access attempts
Review server-side logs for patterns indicating systematic enumeration of attachment resources
Deploy application-level monitoring to detect users accessing data outside their authorized scope

Monitoring Recommendations

Enable verbose logging for Meteor publications in WeKan to capture subscription requests with user context
Set up alerts for users subscribing to attachmentsList who have access to fewer than expected boards
Regularly audit attachment access logs against user permission matrices
Consider implementing rate limiting on publication subscriptions to slow enumeration attempts

How to Mitigate CVE-2026-25562

Immediate Actions Required

Upgrade WeKan to version 8.19 or later immediately
Review application logs to identify any potential exploitation attempts prior to patching
Audit sensitive boards and cards to assess exposure of attachment metadata
Consider temporarily restricting user registration and access for highly sensitive deployments until patching is complete

Patch Information

The vulnerability has been addressed in WeKan version 8.19. The security fix implements proper authorization checks in the attachmentsList publication by:

Retrieving the user's ID from the current session
Querying for boards the user has legitimate access to (public boards or boards where user is an active member)
Filtering cards based on accessible boards
Returning only attachments associated with cards the user can access

Apply the patch by updating to WeKan 8.19 or later. The specific fix can be reviewed in the GitHub Commit.

Workarounds

If immediate upgrade is not possible, consider restricting network access to the WeKan instance to trusted users only
Disable or limit user registration to prevent new accounts from being created for exploitation purposes
Implement network-level controls to limit access to the WeKan application while awaiting patching
Review and minimize the number of active user accounts with access to the system

bash

# Update WeKan to patched version using snap
sudo snap refresh wekan --channel=latest/stable

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