PassBleed - GHSA-6p5m-f9p2-wqm5, Moderate, CWE-639, CVSS 6.5. GET /api/boards/:boardId/lists/:listId/cards/:cardId/exportExcel checked whether the caller could see the board in :boardId, then resolved the card by :cardId alone. Nothing confirmed that the card was on that board, so the two identifiers came apart: one decided the authorisation, the other decided the data.

The pass is self-service. POST /api/boards takes permission straight from the request body, so any authenticated user could mint their own PUBLIC board, name it as :boardId, and pass the id of a card in somebody else’s private board as :cardId. :listId was never used in a query at all and could be any string.

What came back was the card: title, full description, members and assignees, every comment with its author, checklists and checklist items, subtask titles, attachment metadata - and, because image attachments are read through getReadStream() and embedded with workbook.addImage, the attachment BYTES. The same board could be reused while :cardId was substituted, which made it a scriptable bulk read rather than a single disclosure. The REST API is on by default in the shipped Docker configuration.

The fix was already in the codebase one file away: the identically shaped PDF route has always resolved getCard({ _id, boardId, listId }) and 404s a cross-board id. That control is what shows the Excel exporter’s omission was a defect rather than a decision, and it is what the Excel exporter now does. Constraining the QUERY matters more than a check after it - the exporter fans out on the same card id for checklists, subtasks, comments and attachments, none of which carry a board constraint of their own, so a card that cannot resolve outside the authorised board makes all of them safe by construction.

The route binds the two identifiers as well, before either branch builds - deliberate duplication, because that is where both arrive together and it covers the public-board branch, which skips authentication entirely. A card that is not on the named board is a 404 rather than a 403, so the difference does not reveal whether a card id exists.

Following the same upgrade as #6583, profile pictures came back as broken images - initials rendered fine, and the Admin Panel showed a user’s picture while a board showed the missing-picture icon for the same person.

Nothing was lost, and the migration is not at fault. The avatar files migrate, and the Meteor-Files record made from a CollectionFS filerecord even reuses its _id, so a 6.x URL still names the right object. What broke is the request for it. A 6.x install stores profile.avatarUrl as /cfs/files/avatars/<id>; that route serves the legacy bytes if they are still there and otherwise redirects to /cdn/storage/avatars/<id>, which asked who was asking with Meteor.userId().

That reads the current DDP invocation’s environment, which exists inside a method or a publication and NOT in a WebApp handler - where it does not return “nobody”, it THROWS. The handler wraps its body in a try/catch that answers 500, so the throw was swallowed into a broken image, and no avatar served through that route ever reached anybody on any install. The upgrade did not cause it; it moved every avatar URL onto the route where it already applied. server/routes/legacyAttachments.js had the identical call, so legacy attachment URLs failed the same way.

An HTTP request carries its identity in the request: a bearer token, an X-Auth-Token header, an ?authToken= parameter, or the login cookie - and on Sandstorm, a platform-injected user id and no Meteor token at all. server/routes/universalFileServer.js has always resolved it that way and serves attachments correctly today. server/lib/requestUser.js lifts that resolution out so the two routes that were guessing share it rather than grow a third copy. It never throws: a caller deciding whether to serve a file wants an answer, not an exception its own catch will turn back into a 500.

tests/requestUserAuth.test.cjs pins that neither route calls Meteor.userId(), that both await the resolver - an unawaited Promise is truthy and would authorise everybody - that all four token carriers and the Sandstorm path are handled, and that the migration still reuses the id the old URL names. Confirming the served image needs an upgraded instance.

Found while checking why the Admin Panel showed a picture that a board did not. The two URLs differ in one thing: the avatarUrl helper in client/components/users/userAvatar.js appends ?boardId=<id>, and says why in its own comment - “so public viewers can access avatars on public boards”. The Admin Panel uses profile.avatarUrl raw.

/cdn/storage/avatars/:fileName never read that parameter. It required a signed-in user and nothing else, so on a public board every visitor who was not logged in got a 401 and the missing-picture icon - the exact case the parameter was added for. Fixing Meteor.userId() alone would have left that half broken.

The named board must now exist, be public, AND have the avatar’s owner as a member. The last part is not ceremony: without it, naming any public board would unlock any avatar on the instance, and a public board publishes its own members, not everybody.

The legacy redirect keeps the query string too. /cfs/files/avatars/<id> 301s to /cdn/storage/avatars/<id>, and that is the path EVERY migrated 6.x avatar URL takes, so dropping ?boardId= there would 401 exactly the installs the entry above sets out to fix.