WhereBleed - GHSA-phm4-4v26-j2vq, Moderate, CWE-943, CVSS 5.8. The people, org, team and translation publications and their companion count/page methods take a query selector from the client and validate only its TYPE - check(query, Match.OneOf(Object, null)) - which is not validation, because a MongoDB selector is executable data. $where makes the database run the caller’s JavaScript once per document scanned, so Meteor.subscribe('team', { $where: 'while(true){}' }, 25, 0) pins a database worker for as long as the caller likes, repeatably: denial of service for every tenant on the instance from one narrowly-scoped account.

The reporter demonstrated both halves on v10.81 against a real MongoDB 7: $where: 'sleep(2000) || true' made the subscription take 2.03s and return the document, $where: 'false' returned nothing in 0.00s - the caller deciding, in JavaScript, which documents come back.

It needs an authenticated admin session, so no board member or visitor can reach it. It matters at this severity because the people and org surfaces are open to a per-tenant Global Admin, a role meant to be confined to one Organization, and those two wrap the caller’s selector as { $and: [query, restriction] } rather than stripping execution operators out of it - so merging the tenant restriction never removed the $where, and a role scoped to one tenant reached instance-wide impact.

What makes this one particular is that the defence was already in the codebase. classifySelector and hasWhere were written for exactly this class, are unit-tested, and were wired into the card-window publication. Eight sibling handlers taking the identical shape of selector simply never called them. So the fix adds no new detection logic: that publication’s own helper moves unchanged into a shared module and all nine call sites use the one copy - a second copy would be the same bug set up to happen again.

Each handler refuses with the “match nothing” selector the card window already uses in production, { _id: { $in: [] } }, so a refused request returns an empty result instead of throwing at an admin mid-page. Ordinary behaviour is untouched: none of the searches, filters, regexes, $or/$and/$in/$elemMatch or date ranges those panes send carries an execution operator.

FerretDB, WeKan’s default database, rejects $where itself, so this degrades to a rejected query there; the supported MongoDB path is where it was reproduced. MongoDB 7 also happens to reject $where inside the aggregation pipeline the count methods use - but that is an engine accident for one operator on one call path, so those methods are guarded like the rest rather than left to it.

Asked for in 2018: “It would be great to have collapsable checklists on cards”, and again this week - “Long checklists can make a card pretty cluttered, so being able to collapse them and expand only when needed would keep the board much cleaner.”

WeKan had something adjacent and it was not this. A checklist carries hideAllChecklistItems, reachable through a toggle switch inside the checklist actions popup - but that is a field ON THE CHECKLIST, so flipping it changes what everyone on the board sees, and it is an edit to the card rather than a view preference. It is untouched; it has its own uses.

Collapsing is per-user, which WeKan already says twice in its own models for lists and swimlanes, so this follows them: one map in the user profile keyed by card. A feature group uses its own section name, an individual checklist uses a key of its own - which is why folding a checklist on the opened card folds it on the minicard too.

The control is a caret on the title rather than another entry in a menu, since the point is to fold at a glance while reading the card. It carries aria-expanded and answers Enter and Space. For the sixteen feature groups on the opened card it is done once, with a delegated handler and CSS: they all open with a title but only three wrap what follows in a content element, so folding hides every sibling after the title, which works whatever a section puts there.

A checklist’s progress bar stays visible when folded - it is the summary of what was folded away - and the fold survives reopening the card.

Reported against 10.81: “I still have the exact same issue, MongoDB cannot start. The web interface is still unreachable, and I do not see the messages you added in the last commits.” The messages were missing because the code that prints them never ran.

Two markers in $SNAP_COMMON stop the snap doing work, and both were PERMANENT. .mongodb-data-too-old is written when no reader in the snap could open the data, after which mongod is not started at all; .mongod-start-failures is a counter that, past three, stops the migration being re-run so a migration/mongod restart loop cannot form. Both are right, and both record a conclusion about what THAT snap could do.

An instance that had already failed on 10.79 or 10.80 - before mongod 4.2 was bundled - carried a marker saying “no reader can open this” and a counter far past three. So 10.81 never started mongod, never attempted the migration, and printed nothing new. Upgrading to the version with the fix changed nothing, which is exactly what their log shows: the database-selection line, then “Waiting for MongoDB replica set primary…” forever.

Each marker now records the revision that wrote it, and one from a different revision is ignored and cleared - a marker with no revision recorded at all is stale by definition, which is precisely what the affected instances carry. Within one revision nothing changes, so the loop protection still holds; and not knowing the revision is never taken as evidence that it changed.

An instance reports FerretDB at 737% CPU, logins over a minute, boards not appearing, and logs full of database is locked (5) (SQLITE_BUSY). The stack names the same write every time: addNotification.

That is an $addToSet on profile.notifications, an array inside the user document - so adding one entry reads the whole document, scans the array and writes the document back, at a cost proportional to the array. FerretDB on SQLite has a single writer, so those rewrites queue and start failing, and login, which also writes to the user document, queues behind them.

It grows without limit because the existing cleanup only removes notifications that have been READ. A user who never clears their tray accumulates entries forever. The same pass now also keeps the newest NOTIFICATION_TRAY_MAX_PER_USER (default 1000) and drops the rest. It is applied to what is left after the expiry pull, a user needing no change is not written to at all, and it stays one write per user. This bounds the array; it does not make SQLite a multi-writer engine, and a busy instance still wants the PostgreSQL backend.

Closing a card by clicking it again was not a missing feature - it was an unreachable one. The handler already ended with a branch that closed the open card, but the TITLE branch above it returned first, and a minicard’s title covers most of the minicard. So the second click almost always re-opened the card that was already open, and the toggle worked only if you managed to miss the title. The title branch now makes the same decision, and on a phone, where the card is a popup, the second click closes that.

The Problems page glitch in the screenshot is the focus ring. The Admin Panel draws its checkboxes as a square that morphs into a tick, and the tick IS a 40-degree rotation of the element - so a browser draws its focus ring around a rotated box, and a checkbox that is both checked and focused (which is what one you just clicked is) comes out as a blue diamond. The ring moves to the row that contains it, which is not rotated; keyboard focus stays visible.

From email feedback: “If i write the expiration date with the keyboard it turns red, if i choose it with the date picker it is yellow. Can you please tell me the difference?” The colour was never the difference - the YEAR was.

<input type="date"> reports its value as YYYY-MM-DD, but a browser lets the year sub-field be typed as two digits and reports exactly that: entering 31-12-26 gives “0026-12-31”, the year 26 AD. That is a valid Date, so nothing refused it, and the card was saved with a due date two thousand years in the past. Red is what an overdue date looks like. The attached screenshot shows it: the yellow badges read “31-12-2026” and the red ones “31-12-26”.

Saving now refuses a year outside 1000-9999 and says which digits are missing. It refuses rather than silently correcting 0026 to 2026, because that would be a guess about a date other people’s reminders hang off.

From email feedback: FerretDB at 190-350% CPU on an instance with 14490 boards, of which 13404 are template containers, for 9264 accounts of which 478 have ever logged in.

Before v10.00 every new account got a “Templates” container board at signup whether or not the person ever saved a template. v10.00 made that lazy (#2339, #5850), so no new account creates one - but nothing removed the ones already made, and they are not visible enough for anybody to delete by hand. On that instance they are 13x the boards collection, and every query that touches boards carries it.

Because this deletes boards, the rule for what may go is narrow: only a container nobody ever used. A template saved into it, a list, swimlane or card, a second member, a rename, a star or a manual archive all keep it, and every board that is kept reports why. A rename is judged only against the titles the app itself used, so a container whose default name is in another language is not deleted for it. The default is a dry run showing what WOULD go; deleting takes a second, explicit request.

After upgrading from v6 the reporter saw “the state of the data from days ago” and suspected a snap revert done four weeks earlier. They were right about the cause, and nothing was lost.

The MongoDB to FerretDB migration copies MongoDB into SQLite once and writes .migration-to-ferretdb-done. That copy is a snapshot; nothing keeps it in step. Revert the snap to a revision that runs mongod and WeKan carries on writing to MongoDB - for four weeks here - while the finished SQLite sits frozen at the date it was made. Refresh forward again and the snap saw a marker plus a non-empty SQLite, called that a completed migration and switched onto it. Every board and card written during the revert was still on disk and simply not being served.

The data was never in danger: it lives in $SNAP_COMMON, which is shared across revisions and is not rolled back by a revert (unlike $SNAP_DATA, which is per-revision). What was wrong was which of the two copies got served, and nothing compared their ages.

A new check answers exactly that: mongod rewrites its WiredTiger files on every commit, so the newest mtime among them is when MongoDB was last written to, and later than the marker means the copy is behind. It counts data files only - a newer mongodb.log means the snap was started, not that the database changed - and allows a margin, because the migration stops its own temporary source mongod moments after writing the marker. Anything it cannot tell is reported as NOT stale, since the callers act on a yes.

Where mongod runs, the snap now stays on MongoDB, which has the newest data. Where mongod cannot start at all - the case that forces the migration in the first place - it migrates again from scratch rather than serve the old copy; the migration reads with its own temporary mongod and the 4.2/3.2 readers, so it still reaches everything written since. And wekan-control gains the second half of a guard it already had: it refused to start an empty FerretDB while MongoDB had data, and a full but out-of-date one looks worse, because WeKan comes up with everything present except the last weeks.

“Upwards is no problem, the Line scrolls automaticly up, but this does not work downwards. The whole Page/Site scrolls down and not ne Line”.

The card drag auto-scrolls at the edges. Horizontally it picks the lane under the pointer (#443); vertically it picked nothing, and always scrolled .board-canvas - which holds the swimlanes - rather than the .list-body under the pointer, which is overflow-y: scroll and holds the cards. Scrolling the canvas moves the whole board.

The asymmetry is what makes it reproducible. Dragging up, the canvas is usually already at the top, so the handler did nothing and jQuery UI’s own scroll option - which acts on the placeholder’s scroll parent, the list body - scrolled the list, which is why up always worked. Dragging down, the canvas nearly always has room left, so the handler fired first and scrolled the board instead.

The list under the pointer is scrolled first now, and the board only once that list cannot go further - so a drag down a long list scrolls the list, and a drag past the end of it moves on to the board, which is what dragging a card into another swimlane needs.

Backfilling the index taught this within the hour: Artifact Hub scans every entry and mailed a list of errors.

error scanning image ghcr.io/wekan/wekan:v9.62: image not found error scanning
image docker.io/bitnami/mongodb:7.0.14-debian-12-r3: image not found

That was this side’s doing. The rebuild listed every package on gh-pages, and a chart is a POINTER TO CONTAINER IMAGES - one whose images have been deleted installs and then fails at the pull, so listing it says the repository is broken when the repository is fine and the images are gone. 135 of the 360 packages are in that state, from two unrelated causes: six WeKan images were never pushed (v8.30, v9.12, v9.14, v9.38, v9.39, v9.62 - releases whose own docker job failed, and exactly the six Artifact Hub named), and 129 older charts vendor the Bitnami mongodb subchart and pin tags Bitnami has since deleted. Charts from 8.41 on vendor groundhog2k’s mongodb, which uses the official mongo image and is unaffected.

The index now holds 225 entries: every one of the 216 that were listed before - none dropped - plus the 9 backfilled packages whose images all resolve. The exclusions are recorded in unindexed.txt beside the packages, not decided per run, so a rebuild during a release cannot depend on reaching two registries, and an image that comes back is one deleted line away from being listed again. The .tgz files stay, so direct URLs keep working.

Two things this shook out. --check-images asks each registry with ITS OWN 401 challenge instead of a hard-coded token URL per host - the first attempt reported every quay.io image as missing, including quay.io/wekan/wekan:latest, which plainly exists. And an image that cannot be checked is never treated as missing, only a definite 404, so a registry hiccup cannot silently unpublish charts. release-charts.sh now refuses to publish a chart at all when ghcr.io/wekan/wekan:v<version> does not exist, which is what created these six in the first place.

Every backend of the conformance stage failed before a single query was compared: “Failed to create debug handler … listen tcp 127.0.0.1:8088: bind: address already in use”, then “FerretDB did not start on this backend” for each of them.

FerretDB opens a debug handler for metrics and profiling at 127.0.0.1:8088 by default and EXITS when that address is taken, so an unrelated FerretDB running on the machine made the whole stage report a database problem that was nothing of the sort - as it would for anyone with anything on that port.

The script already takes this seriously for the two ports it knows about: it picks a free wire port, makes both overridable, and says in its own comment that they are chosen so it can run while something else is running. The debug port was simply never passed. Nothing in the run queries it, so it is not opened at all - which is also what FerretDB’s own integration tests effectively do, choosing a random debug port rather than the default.

The earlier fix for this covered one of the three ways the mongo42 part gives up

• the unsupported-architecture exit. The other two removed the whole staged directory and exited 0, which leaves stage: mongo42 naming a path that is not there, and snapcraft ends the build on that rather than skipping it.

Those two are reached on amd64 and arm64, where the binary IS downloaded: OpenSSL 1.1 unavailable for the architecture, or the staged mongod 4.2 failing the check that it actually runs. Either would have ended the snap build for the two architectures that matter most, the same way it ended all four Launchpad ones. Both now clear the CONTENTS and keep the directory; an empty one still means “no 4.2 reader”, because every use is guarded on the binary rather than the directory.