Vulnerabilidades de Wekan

Wekan is open source kanban built with Meteor. Prior to 9.35, the Wekan cloneBoard Meteor method in models/import.js uses caller-supplied sourceBoardId to build a board export through models/exporter.js without invoking canExport() or checking source-board membership. Any authenticated user who knows a private board ID can clone the board into their own account and read its cards, comments, attachments, member information, and activities. This issue is fixed in version 9.35.

Wekan is open source kanban built with Meteor. Prior to 9.32, Wekan webhook integration URLs in models/integrations.js are stored from user input and later fetched by server/notifications/outgoing.js without applying the existing validateAttachmentUrl() private-network checks from models/lib/attachmentUrlValidation.js. A board administrator can configure webhook URLs that cause server-side requests to internal or metadata services. This issue is fixed in version 9.32.

Wekan is open source kanban built with Meteor. Prior to 9.32, Wekan REST handlers in server/models/customFields.js use read-level Authentication.checkBoardAccess instead of write-level Authentication.checkBoardWriteAccess for mutating custom-field routes. A read-only board member can call POST, PUT, and DELETE handlers for /api/boards/:boardId/custom-fields and custom-field dropdown items to create, update, or delete board custom fields. This issue is fixed in version 9.32.

Wekan is open source kanban built with Meteor. Prior to 9.64, Wekan has a cross-board authorization bypass in the direct Meteor collection allow rules for Checklists and ChecklistItems because updates are authorized only against the current source doc.cardId and do not inspect the destination cardId or boardId in the update modifier, allowing a low-privileged authenticated user with write access to one board and knowledge of a target private card id to create checklist data on an accessible card and move it into a private board where they are not a member. This issue is fixed in version 9.64.

Wekan is an open source kanban tool built with Meteor. In versions 8.31.0 through 8.33, the notificationUsers publication in Wekan publishes user documents with no field filtering, causing the ReactiveCache.getUsers() call to return all fields including highly sensitive data such as bcrypt password hashes, active session login tokens, email verification tokens, full email addresses, and any stored OAuth tokens. Unlike Meteor's default auto-publication which strips the services field for security, custom publications return whatever fields the cursor contains, meaning all subscribers receive the complete user documents. Any authenticated user who triggers this publication can harvest credentials and active session tokens for other users, enabling password cracking, session hijacking, and full account takeover. This issue has been fixed in version 8.34.

Wekan is an open source kanban tool built with Meteor. Versions 8.32 and 8.33 have a critical Insecure Direct Object Reference (IDOR) issue which could allow unauthorized users to modify custom fields across boards through its custom fields update endpoints, potentially leading to unauthorized data manipulation. The PUT /api/boards/:boardId/custom-fields/:customFieldId endpoint in Wekan validates that the authenticated user has access to the specified boardId, but the subsequent database update uses only the custom field's _id as a filter without confirming the field actually belongs to that board. This means an attacker who owns any board can modify custom fields on any other board by supplying a foreign custom field ID, and the same flaw exists in the POST, PUT, and DELETE endpoints for dropdown items under custom fields. The required custom field IDs can be obtained by exporting a board (which only needs read access), since the exported JSON includes the IDs of all board components. The authorization check is performed against the wrong resource, allowing cross-board custom field manipulation. This issue has been fixed in version 8.34.

WeKan versions prior to 8.19 contain an authorization logic vulnerability where the instance configuration setting allowPrivateOnly is not sufficiently enforced at board creation time. When allowPrivateOnly is enabled, users can still create public boards due to incomplete server-side enforcement.

WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in the card comment creation API. The endpoint accepts an authorId from the request body, allowing an authenticated user to spoof the recorded comment author by supplying another user's identifier.

WeKan versions prior to 8.19 contain an authorization vulnerability in card move logic. A user can specify a destination board/list/swimlane without adequate authorization checks for the destination and without validating that destination objects belong to the destination board, potentially enabling unauthorized cross-board moves.

WeKan versions prior to 8.19 contain an authorization vulnerability where certain card update API paths validate only board read access rather than requiring write permission. This can allow users with read-only roles to perform card updates that should require write access.