Wekan
Open source kanban board application built with Meteor
Alternative to: trello
v12.17
2026-10-03In short
Fixes SamlSubjectBleed by binding SAML accounts to their original identity; legacy accounts missing issuer information require administrator verification before SAML access resumes. Confirms the existing ZipBombBleed fix with browser regression coverage, restores Firefox tests on macOS, and expands translations for archiving, date filters and other UI guidance.
Security
Bind SAML accounts to their original identity. Thanks to alham-rizvi and xet7.
SamlSubjectBleed, GHSA-966m-4qgp-j8w4: a different SAML subject could take over an existing SAML account by claiming its username/email. Login now resolves the issuer and qualified NameID first, persists the binding atomically, and refuses replacement regardless of the merge setting. Email is verified only with an explicit attestation; opt-in local linking also requires a verified matching local email.
Upgrade: legacy accounts without issuer scope require independent owner verification and administrator repair. See the SAML upgrade instructions. Transient NameIDs are rejected. Conflicting subjects appear in Admin Panel → Problems; incomplete legacy bindings are refused without classifying normal upgrade logins as attacks.
Eight SAML/canary suites pass, including actual signed assertions sharing an email but carrying different subjects, negative source checks and concurrent updates. Chromium, Firefox and WebKit each pass the SAML error-display and signed-login browser regressions. External production IdPs were not tested.
Verify the native ZIP decompression report is already fixed. Thanks to alham-rizvi and xet7.
GHSA-rmcq-68x2-3g5j describes the native wekan.json decompression path fixed
by the ZipBombBleed patch,
included in v12.15. Current code counts actual decompressed bytes and stops at
256 MiB. Strengthened real-archive tests confirm a false size declaration cannot
bypass the counter. All three ZIP regression checks pass. Chromium, Firefox and WebKit each
reject a small upload that expands beyond the production limit, leave board
cards unchanged, then accept a valid import in the same session.
Oversized exports can be legitimate, so this refusal intentionally does not classify the user as an attacker in Admin Panel → Problems.
Thanks to above GitHub users for their contributions.