Finding and Fixing 24 CVEs in Wekan with AISLE's Analyzer

After spending time on parser bugs in infrastructure software, we turned to a different class of security issue: access control failures in collaborative applications. That led us to Wekan, the open-source kanban platform built around boards, lists, cards, checklists, attachments, rules, and LDAP-backed administration. With over 20,000 GitHub stars, 3,000 forks, and tens of millions of DockerHub downloads, Wekan has substantial adoption, broad language support, and is also utilized by favorite public-sector agencies in Europe.

Using the AISLE analyzer, we identified 24 CVEs covering authorization bypass, IDOR, missing admin checks, publication leaks, object-scoping failures, and LDAP injection, including three "CVSS3 9.8 Critical" vulnerabilities. Taken together, these issues affected a wide range of application behavior, from board visibility and card updates to attachment handling, activity exposure, and privileged maintenance utilities. In a system like Wekan, where boards define access boundaries and many other objects inherit from them, mistakes in authorization logic can have consequences far beyond a single endpoint.

Wekan is especially attractive to organizations that want self-hosting, data control, and operational flexibility, rather than handing planning data to a SaaS provider. This may be for compliance reasons or otherwise. At the same time, these requirements mean vulnerabilities must be remediated manually through proper patch management. When severe authorization flaws land in software chosen for those reasons, it's likely that the affected deployments may be storing exactly the internal operational data the product was selected to protect.

AISLE's mission is to make the software of the world more secure, one software at a time. The CVEs discovered in Wekan are just some of our hundreds of recent findings, but we won't stop here. Our efforts continue, and we'll be sure to document our findings in future posts.

The remainder of this post outlines our Wekan findings at a high level.

Wekan: The Basics

Wekan is an open-source kanban application used to manage shared workspaces, task boards, and team workflows. Boards, lists, cards, checklists, comments, attachments, and automation all sit close together in the data model, and many actions in the product depend on those relationships being enforced correctly. That matters even more in self-hosted deployments, where a Wekan instance may hold internal planning, operational work, and other non-public data.

That structure shaped the vulnerabilities we found and got fixed. Many of the fixes addressed places where the application accepted a board, card, checklist, or attachment reference without fully checking that the objects matched the user's actual scope of access. Others corrected methods that treated simple membership or visibility as enough, even when the action should have required write access, board-admin privileges, or instance-admin privileges. A smaller set involved publications and maintenance paths that exposed more information or capability than they should have.

Three Classes of Vulnerability

Broken object scoping and IDOR

The largest group came from endpoints and publications that trusted object identifiers without proving the referenced objects actually belonged together.

That pattern appeared in checklist creation and deletion, attachment upload handling, cross-board card moves, card publications, activity publications, rules and triggers publications, and position-history methods. In each case, the application accepted identifiers or subscriptions before fully establishing that the caller was entitled to the specific board, card, checklist, or related object involved in the request.

Missing authorization and admin checks

A second large group involved methods that should have required board admin, instance admin, or write access, but did not enforce those requirements correctly.

This affected private-only board settings, board title updates, read-only roles that could still update cards, list WIP limits, board org and team updates, LDAP sync, translation changes, duplicate-list repair methods, and several migration utilities. The common issue was straightforward: checks for visibility or authentication were standing in for checks that needed to enforce a stronger privilege boundary.

Publication leaks and privileged utility exposure

Several fixes focused on publications and helper methods that exposed more than they should.

Attachment metadata could be published without authorization. Linked-board activities could be exposed to the wrong users. Migration and repair utilities could be called by non-admins. These issues matter because operational paths often sit outside the main product flow while still carrying broad visibility or privileged behavior.

One Different Bug: LDAP Injection

One finding stood apart from the access control issues. The LDAP authentication flow accepted unescaped user input in LDAP filter construction. The fix escapes the username before using it in the LDAP query. It is a classic input-handling flaw, but it fits the same broader theme: security-sensitive boundaries should not trust attacker-controlled data.

Talk to Us

Any secure system has to ensure that every object, every API path, every publication, and every maintenance function respects the same authorization model, and that logical security controls are implemented correctly in a whole codebase. AISLE's AI-native AppSec platform solves this problem. Want to find out more? Get in touch.

Our appreciation goes to Lauri Ojansivu and the WeKan team for their collaboration throughout this process. These vulnerabilities were discovered by Joshua Rogers of the AISLE Research Team.