Wekan vulnerabilities

Wekan before version 9.46 has a vulnerability in the header-login mechanism where getRequestIp() trusts the client-supplied X-Forwarded-For header before the real socket address. This allows an unauthenticated attacker to impersonate any user, including admin, by sending a HEADER_LOGIN_ID header and obtaining a meteor_login_token session.

In Wekan prior to version 9.32, the Accounts.onCreateUser hook in server/models/users.js merges OIDC logins into existing accounts when the OIDC email or username matches an existing Wekan user, without verifying ownership or checking email_verified. An attacker using an OIDC provider account with a victim's email or username can cause Wekan to merge the attacker's OIDC credentials into the victim account and then log in as that account.

Wekan before version 9.07 has a command injection vulnerability in the avatar upload functionality. User-supplied filenames are passed to child_process.exec() without sanitization, allowing shell metacharacters like backticks and $() to execute arbitrary commands on the server.

WeKan versions prior to 8.19 contain an LDAP filter injection vulnerability in LDAP authentication. User-supplied username input is incorporated into LDAP search filters and DN-related values without adequate escaping, allowing an attacker to manipulate LDAP queries during authentication.

Wekan, an open source kanban built with Meteor, prior to 11.11 passes authenticated user-controlled searchTerm and query values to new RegExp() without escaping regular-expression metacharacters. In MongoDB-backed deployments the resulting patterns are evaluated with PCRE2, allowing a logged-in user to submit catastrophic-backtracking expressions that consume database CPU and degrade or deny service to other users. The searchUsers method additionally requires board membership or site-admin status.

Wekan prior to 10.38 contains a vulnerability in several export endpoints where the authToken query parameter is used without checking if the user exists. A request for a private board with an unknown token throws a TypeError, producing an unhandled rejection that could terminate the Wekan process and deny service to all users. Version 10.38 adds a 401 guard and wraps export handlers with safeRoute().

Wekan is open source kanban built with Meteor. From 8.72 until 10.23, addBoardHTMLToZip() in client/lib/exportHTML.js read a card title and body through textContent, which decoded entity-encoded markup, and then interpolated titleText and allText into content.innerHTML in the exported index.html. A board member could store an entity-encoded event-handler payload in a card title that remained inert on the live board but was reparsed and executed when a recipient clicked the card in the downloaded HTML export, allowing the script to read and transmit all board data contained in that export, including content added after the attacker's membership was removed. Version 10.23 builds the modal with DOM nodes and assigns untrusted values through textContent. This issue is fixed in version 10.23.

Wekan is open source kanban built with Meteor. Prior to 9.90, isFileValid() in models/fileValidation.js used the Unix file command for content-based MIME detection, but detectMimeFromFile() silently returned undefined when that binary was unavailable and the validation fell back to the attacker-controlled fileObj.type supplied through server/routes/attachmentApi.js. On deployments with WITH_API=true and no file binary, an authenticated board member could label HTML containing JavaScript as image/png, bypass the dangerous MIME check, and store active content under the Wekan origin for execution when another user opened it. Version 9.90 adds looksLikeDangerousMarkup() to inspect file bytes and force dangerous-content scanning when MIME detection is unavailable. This issue is fixed in version 9.90.

Wekan is open source kanban built with Meteor. Prior to 9.89, the second Boards.allow({ update }) rule in server/permissions/boards.js called canUpdateBoardSort in server/lib/utils.js, which authorized any board member whenever fieldNames included sort. Because Meteor combines allow rules with OR semantics and applies the complete modifier, a comment-only or read-only member could send one Boards.update with $set values for sort, members, permission, and title, make themselves the sole board administrator, expose a private board, and evict the legitimate owner; the last-admin deny rule inspected only $pull and did not block a wholesale $set of members. Version 9.89 requires sort to be the only modified field and rejects $set member arrays that remove the last active administrator. This issue is fixed in version 9.89.

Wekan is open source kanban built with Meteor. Prior to 9.75, models/fileValidation.js interpolated the uploaded fileObj.path into the administrator-configured externalCommandLine at its {file} placeholder and executed the result through asyncExec, which is promisify(exec) and invokes `/bin/sh -c`. On deployments with an external scanner configured, an authenticated user able to upload an attachment could place shell metacharacters such as command substitutions in the filename and execute commands as the Wekan server process. Version 9.75 adds shellQuote() and passes the file path as a POSIX single-quoted argument so shell metacharacters cannot escape the placeholder. This issue is fixed in version 9.75.

Wekan from 9.57 until 9.74 contains a vulnerability in the /api/boards/:boardId/exportExcel route where the authorization guard exporterExcel.canExport(user) is not awaited. The returned Promise is always truthy, so exporterExcel.build(res) runs even when board.isVisibleBy(user) would deny access, allowing any authenticated non-member to download private board data. Fixed in version 9.74.

Wekan is open source kanban built with Meteor. From 8.36 until 9.74, the outgoing webhook Integration URL validator in models/integrations.js checked only the literal URL.hostname against regular expressions, so DNS names such as 169-254-169-254.nip.io passed that first-line check. The delivery path's fetchSafe guard already blocked the reported IPv4 destination, but its separate IPv4-only resolver and duplicated blocklist created inconsistent all-address-family enforcement and drift risk between input-time and connection-time validation. Version 9.74 makes server/lib/ssrfGuard.js resolve all addresses with `dns.lookup({ all: true })`, validate every result through the shared isIpBlocked logic, pin the connection, and block redirects. This issue is fixed in version 9.74.

In Wekan prior to version 9.37, DDP update rules in cards.js, lists.js, and swimlanes.js authorize against the stored source boardId and do not validate a new boardId in the update modifier. An authenticated user with write access to their own board can move cards, lists, or swimlanes into a private board they are not a member of.

Wekan before version 9.34 has a vulnerability in the cloneBoard method that allows an authenticated user to clone any board (knowing its ID) without permission checks. This enables reading cards, comments, attachments, member information, and activities from private boards.

In Wekan prior to version 9.32, webhook URLs stored from user input are not validated against internal network connections. A board administrator can configure webhooks that cause server-side requests to internal or metadata services.

In Wekan prior to version 9.32, the copyBoard Meteor DDP method in server/publications/boards.js copies a board by caller-supplied board ID without checking this.userId, membership, or admin access. Any authenticated user can copy a private board they are not a member of, including its cards, checklists, custom fields, labels, and rules.

In Wekan prior to version 9.32, OIDC-related Meteor methods are globally callable without admin authorization checks. Authenticated users can create or modify organizations and teams, and grant global admin privileges when PROPAGATE_OIDC_DATA is enabled.

In Wekan prior to version 9.32, 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.

Wekan before version 9.31 has a vulnerability allowing arbitrary file read and DoS. A logged-in board member can insert an attachment with a controlled file path, and the server reads it without checking if it is within the allowed storage directory.

In Wekan prior to version 9.64, a cross-board authorization bypass vulnerability exists in the direct Meteor collection allow rules for Checklists and ChecklistItems. An authenticated low-privileged user with write access to one board and knowledge of a target private card ID can create checklist data on an accessible card and move it into a private board where they are not a member.

WeKan before version 8.35 contains a server-side request forgery (SSRF) vulnerability in webhook URL handling. The URL scheme field accepts any string without protocol restrictions or destination validation.

WeKan before version 8.35 has a missing authorization vulnerability in the Integration REST API endpoints, allowing authenticated board members to perform administrative actions without proper privilege verification. Attackers can enumerate integrations including webhook URLs, create new integrations, modify or delete existing ones, and manage integration activities by exploiting insufficient authorization checks in the JsonRoutes REST handlers.

In Wekan prior to version 8.20, non-administrative users can access migration functionality due to insufficient permission checks, potentially resulting in unauthorized migration operations.

In WeKan versions prior to 8.19, there is 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.

An IDOR vulnerability in the card comment creation API of WeKan versions prior to 8.19 allows an authenticated user to spoof the comment author by supplying another user's identifier in the request. This compromises data integrity.

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.

An authorization vulnerability in WeKan versions prior to 8.19 allows certain card update API paths to validate only board read access instead of requiring write permission.

An IDOR vulnerability in WeKan before version 8.19 allows cross-board ID tampering during checklist creation. The implementation does not verify that the supplied cardId belongs to the supplied boardId, enabling unauthorized access to checklists in other boards.

An IDOR vulnerability in WeKan before version 8.19 allows cross-board ID tampering during checklist creation. The implementation does not verify that the supplied cardId belongs to the supplied boardId, enabling unauthorized access to checklists from other boards.

WeKan versions prior to 8.19 have an information disclosure vulnerability in attachments publication. Attachment metadata can be returned without properly scoping results to boards and cards accessible to the requesting user, potentially exposing metadata to unauthorized users.

WeKan versions prior to 8.19 have an authorization weakness in the attachment upload API due to insufficient validation of identifiers (boardId, cardId, swimlaneId, listId). This allows an attacker to upload attachments with mismatched object relationships.

An issue was discovered in Wekan (open source kanban board system) up to version 18.15, fixed in 18.16. Authorization flaw in card update handling allows board members (and potentially other authenticated users) to add/remove arbitrary user IDs in vote.positive / vote.negative arrays, enabling vote forgery and unauthorized voting.

In Wekan kanban board system up to version 18.15 (fixed in 18.16), the attachment upload API treats the Authorization bearer value as a userId and enters a non-terminating body-handling branch for any non-empty bearer token, enabling trivial application-layer DoS and latent identity-spoofing.

In Wekan up to version 18.15 (fixed in 18.16), authenticated users can update their entire user document (beyond profile fields), including orgs/teams and loginDisabled, due to missing server-side authorization checks; this enables privilege escalation and unauthorized access to other teams/orgs.

In Wekan up to version 18.15 (fixed in 18.16), unauthenticated attackers can update a board's "sort" value (Boards.allow returns true without verifying userId), allowing arbitrary reordering of boards.

In Wekan (open source kanban board system) up to version 18.15, fixed in 18.16, uploaded attachments can be served with attacker-controlled Content-Type (text/html), allowing execution of attacker-supplied HTML/JS in the application's origin and enabling session/token theft and CSRF actions.