v9.90 2026-07-15 WeKan ® release

This release fixes the following CRITICAL SECURITY ISSUE of MimeBleed:

• MimeBleed:
  file-upload MIME-type validation bypass → stored XSS on deployments without the
  file binary
  (GHSA-jhph-whx8-wq6p,
  CWE-434 Unrestricted Upload of File with Dangerous Type). WeKan's upload validation
  (models/fileValidation.js) detects a file's real MIME type by running the Unix
  file command. On minimal Docker/Alpine images where file is not installed,
  detectMimeFromFile() silently returned undefined and the code fell back to the
  client-supplied fileObj.type. An authenticated board member (with WITH_API=true)
  could therefore upload an HTML file containing JavaScript while setting
  fileType: "image/png": the spoofed type is not on the dangerous-MIME deny-list, so
  the dangerous-content scan was skipped and the file was stored, yielding stored XSS
  served under the WeKan origin (session theft / actions as the victim, including admin).
  • Fixed so the client-supplied type can never gate the safety scan: when
    content-based detection via file is unavailable, WeKan now falls back to a
    dependency-free JS content sniff (looksLikeDangerousMarkup()) that inspects the
    real bytes for HTML/SVG/XML/<script> signatures and forces the dangerous-content
    scan regardless of the claimed MIME — so a spoofed image/png that is actually
    HTML+JS is caught and rejected. The sniff only matches definitive markup signatures,
    so genuine binary uploads (real PNG/JPEG/PDF, including large ones) are unaffected.
    WeKan also now logs a one-time warning when the file command is missing (previously
    the failure was silent). A regression test
    (server/lib/tests/fileValidationBypass.security.tests.js) covers both the spoofed
    dangerous uploads and safe binaries. CVSS:3.1 8.3 High
    (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N).
  • Affected container deployments without the file binary and WITH_API=true;
    fixed at the upcoming WeKan release. Reported by HNUfwj. Also install the file
    package for full content-based MIME detection (WeKan's official images already do).
    Thanks to HNUfwj and xet7.

and adds the following new features:

• Admin Panel / Features / Security: import/export privacy controls. Six new
  optional toggles govern how boards and user data cross the WeKan boundary:

  • Disable all import / Disable all export — master switches that turn off
    every import / export feature (WeKan JSON, Trello, CSV/Excel, Jira, Kanboard,
    NextCloud Deck, OpenProject, GitHub/GitLab/Gitea/Forgejo, board clone, and the
    single-attachment export). The server rejects any such request, and the import /
    export menu options are hidden in the UI.
  • Disable import avatars / Disable export avatars — never carry avatars
    (profile pictures) into / out of WeKan. Import covers WeKan JSON import, Trello
    import and external identity-provider avatar sync on login (LDAP, OIDC/OAuth2),
    gated at the single localizeAvatarFromBuffer choke point; export covers WeKan
    JSON and CSV export.
  • Anonymize import users / Anonymize export users — replace every user's
    username, full name and initials with counter placeholders (user1, user2, ...),
    drop their avatar, and rewrite @username mentions plus the requested-by /
    assigned-by fields inside card and comment content, so the imported board /
    exported file carries no real user identity. The placeholder word "user" follows
    the language of the person importing/exporting (e.g. "käyttäjä1" in Finnish). Both
    export paths are covered — the in-memory build() and the streaming
    buildStream() (which does a lightweight id-only pre-scan so mentions streamed
    before the users array still resolve to matching labels).

  All six default to off (current behaviour). Enforcement lives server-side in the
  Exporter, the WekanCreator import path and the avatar localizer, so it cannot be
  bypassed from the client. Thanks to xet7.

• Admin Panel / Features / Security: new optional "Always show all code as plain
  text" toggle. When enabled, rich text is never rendered as markdown or HTML —
  the entire source is shown as escaped plain text in every rich text field (board
  and card titles, descriptions, comments, checklists, etc.), so hidden content is
  always revealed: HTML comments (<!-- -->), the target URL inside a markdown
  link, JavaScript and any other code. All code is always visible, not clickable,
  and not running. This extends the existing invisiblebleed protection (which
  already showed raw source for description-less markdown links) to all content.
  The wekan-markdown package cannot import app code, so the setting is bridged to
  the markdown renderer through a reactive flag on the exported Markdown object,
  kept in sync by the rich text viewer. Stored as the global alwaysShowCodeAsText
  setting; default off, so markdown renders normally. Thanks to xet7.

• Admin Panel / Features: new optional "Render links as plain text" security
  toggle. When enabled, all links — both markdown links like [label](url) and
  raw HTML <a href> tags — are always shown as plain, non-clickable text in every
  rich text field (board and card titles, descriptions, comments, checklists,
  etc.), so a link can never be clicked and cannot present misleading anchor text.
  This is a hardening option on top of the existing XSS sanitization (which already
  strips javascript:/data: schemes, event-handler attributes and dangerous
  tags): it addresses #6453, where a
  board title could render as a clickable link. The toggle lives under Admin Panel /
  Features / Security, is stored as the global renderLinksAsPlainText setting, and
  defaults to off (links stay clickable). Implemented by forbidding the <a> tag
  (while keeping its visible text) in the shared DOMPurify sanitizer used by the
  rich text viewer, gated on the setting so toggling it re-renders reactively.
  Thanks to bcook-konza and xet7.

and adds the following updates:

• Outgoing webhooks / notifications: include the card description
  (#5143). A card's description was
  saved to the activity log (a a-changedDescription activity, #5482) but was never
  put into the outgoing-webhook / notification payload, so integrations received an
  event with no description text. The payload now carries description (the card's
  current description, added only when non-empty) for every card event, and — for a
  description change — the before/after text as oldValue / value (previously
  only timeValue/timeOldValue were forwarded). New fields are additive, so
  existing webhook consumers are unaffected. Thanks to xet7.
• Update Sandstorm Docs about how to install newest test version.
  Thanks to xet7.

and fixes the following tests:

• Test infrastructure: fix meteor test (Mocha, server-side) crashing at boot
  with 0 tests run (scripts/patch-yargs-dirname.cjs). The whole yargs package
  is dragged into the Meteor test server bundle as a transitive devDependency,
  and Meteor 3 wraps every module in a CommonJS function
  function(require, exports, module, __filename, __dirname){…}. yargs (and its ESM
  dependencies) ship native-ESM constructs that are illegal inside that wrapper and
  crash the bundle before a single test runs:

  • import.meta.url / import.meta.resolve(…) → "Cannot use 'import.meta' outside a module"
  • const __dirname = … → "Identifier '__dirname' has already been declared"
  • const require = createRequire(import.meta.url) (and the guarded bundler variant
    const require = createRequire ? createRequire(import.meta.url) : undefined) →
    "Identifier 'require' has already been declared"

  A postinstall patch (patch-yargs-dirname.cjs) rewrites those constructs to the
  wrapper's own __filename / __dirname / require (yargs is never executed here —
  it only needs to parse as CommonJS). Getting the patch right took several iterations,
  each of which failed in a way that looked like an unrelated source-level syntax error:

  1. The patch expanded import.meta.url before stripping
     const require = createRequire(…). The expansion injected a require('url')…
     call whose ) then terminated the paren-naive createRequire\([^)]*\) match early,
     leaving a dangling .pathToFileURL(__filename).href)) — reify then died with
     SyntaxError: Unexpected token (19:33) on the generated yargs esm.mjs, not on
     any repo file. Diagnosing it required instrumenting reify's Babel parser in the
     Meteor dev_bundle copy to dump the exact source string it was choking on, because
     every scan of the repo's own *.js came back clean (the broken file was in
     node_modules, was .mjs, and was produced by the patch itself). Fixed by
     removing the createRequire line before expanding import.meta.url, plus a
     repair rule that collapses any already-corrupted …href)) leftover back to a marker.
  2. With parsing fixed, a second ESM shim surfaced at boot — this time in a yargs
     dependency, node_modules/yargs-parser/build/lib/index.js (not under
     node_modules/yargs, so import.meta.url there was still unexpanded, a tell that
     the old yargs-only scan had never touched it). Its line 30 used the guarded ternary
     const require = createRequire ? createRequire(import.meta.url) : undefined;, whose
     createRequire ? (space, not () slipped past the direct createRequire\( matcher
     → the leftover const require collided with the wrapper parameter and the server
     bundle crashed at boot with "Identifier 'require' has already been declared".
     Two changes fixed it: (a) generalize the removal (and its trigger) from
     const require = createRequire\(…\) to a line-wise const require = …createRequire…;
     so it matches both the direct call and the guarded-ternary form, running it before
     the import.meta.url expansion so the injected require('url')… parens can never
     confuse it; and (b) broaden the scan from just node_modules/yargs to yargs and
     its ESM dependency packages (yargs-parser is the actual offender; cliui, escalade,
     string-width, y18n, get-caller-file, require-directory are scanned too and are
     harmless to include).

  The patch is idempotent, best-effort (never fails an install), and re-runnable by hand
  (node scripts/patch-yargs-dirname.cjs) to repair a node_modules tree left broken by
  an older version. This is a pre-existing test-only build breakage (the yargs bundling
  predates these fixes); production runtime bundles were never affected. Separately, three
  server test files were present on disk but missing from the curated loader
  server/lib/tests/index.js (which the meteor test entry imports explicitly rather than
  by *.tests.js convention), so they had silently never run — the MimeBleed file-validation
  bypass regression, the import/export privacy settings, and the impersonation report query
  are now registered. With all of the above, the server suite boots and runs clean:
  450 passing, 0 failing (411 before the three files were wired in). Thanks to xet7.

• Test infrastructure: rebuild-wekan.sh and rebuild-wekan.bat now show live
  progress in every test path. Several places used to sit silent for minutes, which
  looked like a hang. Audited both scripts and closed every gap:

  • Server-start wait (both "Run ALL tests" modes). While the :3000 server came
    up, the readiness wait printed only dots. .sh now shows live progress (see the
    .build/bundle item below, where it streams the boot log scrolling); .bat prints a
    check counter now and then and points at the live server log to type in another
    window (on cmd, echoing arbitrary log lines is unsafe as they can contain > < | &).
  • Fixed the readiness poll hanging so nothing showed for minutes (the progress
    line froze at [0s]). The wait polled curl http://127.0.0.1:3000/sign-in with no
    timeout; Meteor binds the :3000 proxy early and accepts the TCP connection while the
    app is still building but sends no HTTP response until it finishes, so curl blocked
    on that first connection for the whole build and the loop never advanced. Added
    --connect-timeout 2 --max-time 4 so each poll returns quickly, and the wait is now
    bounded by wall-clock time (.sh 1200s / .bat ~240 polls) rather than a fixed count
    (also applied to the Playwright-ALL precheck).
  • Sequential per-job (menu option 2). Each job used to block/redirect to a log
    with nothing on screen while it built and ran. Because only one suite runs at a
    time in this mode, .sh now streams each suite's reporter output straight to the
    console via tee (also saving the log), so you see every test tick by one-by-one
    as Mocha / Playwright / the E2E harness prints it, then a final PASS/FAIL + count
    line; .bat runs each job in its own minimized window (reusing the proven parallel
    start-commands + .done-<key> flags) and polls a live pass counter, one at a time.
  • Playwright "ALL browsers" single menu item (.sh option 10 /
    run_playwright_parallel). It redirected each browser to a log and only dumped the
    output after all finished. It now streams each browser's Playwright list reporter
    live via tee (progress visible per test) while still saving the log;
    PIPESTATUS[0] keeps the per-browser pass/fail accurate through the pipe.
  • The single-suite menu items (Mocha, import regression, Node E2E, single Playwright
    browser) already stream straight to the terminal, and the parallel-mode combined
    progress table is unchanged. Thanks to xet7.

• Test infrastructure: "Run ALL tests" reuses the precompiled .build/bundle for the
  :3000 server instead of recompiling with meteor run (both rebuild-wekan.sh and
  rebuild-wekan.bat). Node E2E
  and Playwright drive a live WeKan over HTTP; that server is now started from the
  production bundle you already built with meteor build .build --directory — node main.js boots in seconds with no recompile, using Meteor's bundled node and mongod
  (mongod on :3001, or an already-running MongoDB there is reused). Its one-time
  programs/server npm install and its boot log now stream live (scrolling) so you can
  see exactly what is happening. Two caveats that are inherent to Meteor and are called
  out in the script: (1) the bundle is run as-is, so after changing source you must
  rebuild it or the tests run old code; (2) the server-side Mocha suite still uses
  meteor test (its own .meteor/local-test build) — the in-process unit/security tests
  cannot run from a production bundle, so copying the bundle would not help them. In
  sequential mode the suites run strictly one at a time, each streaming its own output,
  and the parallel-only combined table is skipped (only the live WeKan server + MongoDB run
  alongside — they are the system under test, not parallel test jobs). Before starting, the
  run checks for the .build/bundle directory specifically (not just .build) and
  builds it once with meteor build .build --directory if it is missing or incomplete, so
  a first run with no bundle still works. The bundle server talks to the meteor
  database on :3001 — the DB name Meteor's built-in mongo used under meteor run and the
  one the Playwright / Node E2E tests seed into (tests/playwright/helpers/db.js,
  tests/e2e/list-regressions.js); an earlier /wekan name made the app read an empty
  database while the tests seeded a different one, so every seeded test failed until the
  names were aligned. Both the Bash and the Windows batch runners now use this
  bundle-based :3000 server (the .bat resolves Meteor's bundled node / mongod from
  the dev_bundle, starts mongod in a minimized window, and stops it on exit only when it
  started it). Thanks to xet7.

and fixes the following bugs:

• Sandstorm: the WeKan Admin Panel is now always available in a migrated grain,
  not just a freshly created one. On Sandstorm the grain owner (Sandstorm
  configure permission) is mapped to a WeKan admin, which gates the Admin Panel
  (and Admin Panel / Attachments / Sandstorm, used to delete leftover files after
  a migration). A brand-new grain worked because Users.after.insert derives the
  role for the new user, but a grain migrated from an older WeKan already contains
  the user, so that insert hook never runs. Sandstorm auto-login uses
  connection.setUserId() (bypassing accounts-base, so Accounts.onLogin never
  fires), and the only remaining hook — an observeChanges on services.sandstorm
  — fires solely when that field actually changes on login. When the migrated
  user's stored permissions already equal the grain's current permissions, the
  login $set is a no-op with no oplog entry, so the role was never derived and
  the owner had no Admin Panel. WeKan now reconciles this at grain startup (a
  migrated grain reboots once migration completes): every Sandstorm user whose
  stored permissions include configure is granted WeKan admin. It only promotes,
  never revokes, so a stale/empty stored permission set can never lock the owner
  out. Thanks to xet7.
• Admin Panel / Version: show the MongoDB storage engine even with
  per-database credentials (no more "unknown"). The storage engine was read
  only from the serverStatus command, which requires the cluster-level
  clusterMonitor role. A per-database WeKan user (readWrite on the wekan
  database only, as in the docs/Platforms/FOSS/Docker/Meteor3/ setup) is not
  authorized to run it, so the command was rejected and the field stayed
  unknown. WeKan now falls back to a $collStats aggregation (which needs only
  the collStats action that read/readWrite already grant) and reads the
  real engine — wiredTiger (or inMemory) — from storageStats. The MongoDB
  compatible version and Database commit were already correct: they come from
  buildInfo, which needs no special privileges. Thanks to xet7.

Thanks to above GitHub users for their contributions and translators for their translations.