CVE-2026-25563 in WeKan
Summary
by MITRE • 02/08/2026
WeKan versions prior to 8.19 contain an insecure direct object reference (IDOR) in checklist creation and related checklist routes. The implementation does not verify that the supplied cardId belongs to the supplied boardId, allowing cross-board ID tampering by manipulating identifiers.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability identified as CVE-2026-25563 represents a critical insecure direct object reference flaw in WeKan versions prior to 8.19 that fundamentally compromises the application's access control mechanisms. This issue specifically affects checklist creation functionality and related checklist routes within the collaborative project management platform. The vulnerability stems from insufficient validation of object relationships within the application's backend logic, where the system fails to properly verify that the card identifier provided during checklist creation actually belongs to the board identifier specified in the request. This oversight creates a scenario where authenticated users can manipulate URL parameters or API calls to reference objects across different boards, effectively bypassing the intended access controls that should prevent cross-board data access and manipulation.
The technical implementation of this vulnerability aligns with CWE-284, which describes insecure direct object references that occur when an application provides direct access to objects based on user-supplied input without proper authorization checks. The flaw manifests when a user attempts to create or modify a checklist by supplying a cardId parameter that references a card belonging to a different board than the one specified in the request. This allows attackers to exploit the lack of proper board-card relationship validation, enabling them to access, modify, or delete checklists associated with boards they should not have access to. The vulnerability operates at the application logic level, where the system assumes that legitimate users will provide valid combinations of board and card identifiers without performing the necessary cross-reference verification that should occur before any object manipulation.
The operational impact of this vulnerability extends beyond simple data access violations and can lead to significant security breaches within collaborative environments. An attacker with access to one board could potentially manipulate checklists across multiple boards within the same WeKan instance, compromising the integrity of project data and potentially exposing sensitive information. This cross-board manipulation capability undermines the fundamental security model of collaborative platforms where boards represent isolated workspaces for different projects or teams. The vulnerability particularly affects environments where multiple teams or projects share the same WeKan instance, as it allows unauthorized access to project data that should remain compartmentalized. The impact is amplified when considering that checklists often contain detailed task information, deadlines, and progress tracking data that may be sensitive or confidential to specific project stakeholders.
Mitigation strategies for this vulnerability must address the root cause through proper input validation and access control implementation. Organizations should immediately upgrade to WeKan version 8.19 or later, which includes the necessary fixes for this insecure direct object reference issue. Additionally, administrators should implement comprehensive access control measures that validate object relationships before processing any requests involving cross-referenced identifiers. The fix typically involves implementing proper authorization checks that verify the relationship between board and card identifiers, ensuring that any cardId parameter corresponds to a valid card within the specified board. Security teams should also consider implementing monitoring and logging mechanisms to detect suspicious access patterns that might indicate attempts to exploit this vulnerability, as recommended by ATT&CK technique T1078 for valid accounts and T1566 for credential access through social engineering. Organizations should conduct thorough security assessments of their WeKan implementations to identify any other potential insecure direct object reference vulnerabilities within the application's API endpoints and ensure that all object access controls are properly enforced through proper relationship validation checks.