wekan-notificationusers-leak-bcrypt-session-tokens

Wekan notificationUsers publication leaked bcrypt password hashes and active session tokens — critical data breach for self-hosted kanban

What happened

The weirdest detail is the name: notificationUsers. It’s a Meteor publication in Wekan that, in versions 8.31.0 through 8.33, returned whole user documents with no field filtering.

In plain terms, any authenticated user who triggers that publication could receive bcrypt password hashes, active session login tokens, email verification tokens, full email addresses and stored OAuth tokens. The advisory lists this as fixed in version 8.34 and rates the issue 9.3, critical.

Who was affected: any Wekan deployment running versions 8.31.0, 8.32 or 8.33. When and who discovered the flaw are not provided in the supplied advisory, so those points have not been disclosed.

Why this matters to businesses

If you run Wekan for internal project tracking, boards often contain commercially sensitive notes, links, and integrations. Exposed credentials give an attacker direct routes into user accounts, and exposed session tokens let them skip passwords entirely.

That matters to customers, partners and suppliers who trust you with private information, and it matters to the board because account takeover becomes a regulatory and contractual risk as well as an operational one. Costs can include incident response, forced password resets, forensic work and potential contractual penalties.

And yes, patch later thinking bites you here; treating MFA as optional or reusing service accounts just hands the attacker a shorter path.

If you’ve got the same weakness, here’s what happens next

First, attackers with harvested bcrypt hashes will attempt offline cracking. Given enough weak passwords, some accounts will fall. Second, session tokens and OAuth tokens can be replayed or used to impersonate users until they are revoked.

Following that, an attacker can quietly enumerate boards, exfiltrate attachments or settings, and pivot to other systems that accept the same credentials or OAuth tokens. Recovery drags on because you must invalidate tokens, force resets, and rebuild trust with stakeholders.

Think of it like a keyring leak rather than one locked door being opened; multiple doors across services can open if the keys are on the same ring.

What to do on Monday morning

• Patch Wekan to 8.34 immediately, or apply vendor-supplied mitigations if you cannot upgrade right away.

• Identify all Wekan instances and inventory versions, including any forks or hosted copies your suppliers run.

• Force session invalidation and rotate OAuth tokens and API keys used by Wekan integrations, then require password resets for high-privilege accounts.

• Audit subscription and publication usage, specifically any calls that subscribe to notificationUsers or other custom publications, and restrict them to admin-only where possible.

• Search logs for unusual subscription activity or fast downloads of user objects, and preserve logs for forensic review.

• Rotate any credentials that may have been stored in Wekan boards or attachments, and notify affected users with clear steps for password hygiene and MFA enrolment.

• Run an incident tabletop with the app owners and your identity team to rehearse token revocation and communication plans.

Where ISO standards fit, without the sales pitch

An ISO 27001-aligned information security management system helps here because it forces you to treat publication controls, access rules and code review as part of change control—see how ISO 27001 frames information security governance. That reduces the chance a publication ships without field filtering.

For smaller organisations, baseline assurance like IASME certification helps make sure basic controls are present, such as least privilege and secure default configuration, see IASME guidance. If you need to rebuild availability and trust after compromise, a BCMS aligned to ISO 22301 supports recovery planning, see ISO 22301.

Finally, while this is primarily a code-level flaw, user training still matters because stolen credentials feed social engineering and account recovery attacks. Practical training and simulated exercises can reduce follow-on abuse, for example Usecure-style security awareness.

All three threads—code hygiene, access control, and people—work together to shrink the blast radius when a publication mistakenly spills secrets.

Take a breath, patch, and assume any exposed token is already used; treat it like a contaminated keypad and start replacing codes now.