Live › vulnerability › CVE-2026-119300
Wekan's user-search feature passes user-supplied text straight into regular expressions without escaping, so a crafted search pattern can make MongoDB spend heavy CPU on it. A logged-in user can use this to slow or deny service to other users of the same deployment.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-30 17:31 UTC. All times on this page are UTC.
Self-hosted Wekan instances running before 11.11 on MongoDB are exposed, because any logged-in user can trigger the expensive search. Deployments on FerretDB v1 (RE2 regex engine) are not practically affected by catastrophic backtracking, according to the sources. Exploitation of the searchUsers path additionally needs board membership or site-admin status.
No product ranges from the sources yet.
11.11.11.11Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Wekan is open source kanban built with Meteor. Prior to 11.11, the user-search publication in server/publications/users.js and the searchUsers method in server/models/users.js pass authenticated user-controlled searchTerm and query values to new RegExp() without escaping regular-expression metacharacters. MongoDB-backed deployments evaluate the resulting patterns with PCRE2, allowing a logged-in user to submit catastrophic-backtracking expressions that consume database CPU and degrade or deny service to other users; searchUsers additionally requires board membership or site-admin status. The FerretDB v1 / RE2 unaffected configuration is not practically affected by catastrophic backtracking. This issue is fixed in version 11.11.
This page as .md · .json · in your agent: get_signal("CVE-2026-119300")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.