Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 0.40% for the current model date.
BlackTreeCVE IntelligenceWekan · Wekan
Critical technical severity; prioritise exposed affected systems while verifying vendor guidance.
Critical technical severity; prioritise exposed affected systems while verifying vendor guidance.
Patch availableWekan 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 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.
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-639: Authorization Bypass Through User-Controlled Key. The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:NCommon Vulnerability Scoring System 4.0: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 6 Mar 2026 · Last source change 9 Mar 2026, 20:34 UTC · CWE-639 · Authorization Bypass Through User-Controlled Key
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.