This PR contains the following updates: | Package | Update | Change | |---|---|---| | [docker.io/wekanteam/wekan](https://redirect.github.com/wekan/wekan) | minor | `a193fae` → `ed6c960` | --- > [!WARNING] > Some dependencies could not be looked up. Check the [Dependency Dashboard](../issues/18710) for more information. Add the preset `:preserveSemverRanges` to your config if you don't want to pin your dependencies. --- ### Release Notes <details> <summary>wekan/wekan (docker.io/wekanteam/wekan)</summary> ### [`v9.64`](https://redirect.github.com/wekan/wekan/blob/HEAD/CHANGELOG.md#v964-2026-06-20-WeKan--release) [Compare Source](https://redirect.github.com/wekan/wekan/compare/v9.63...v9.64) This release fixes the following CRITICAL SECURITY ISSUE of [ChecklistBleed](https://wekan.fi/hall-of-fame/checklistbleed/): - [Fixed ChecklistBleed: any authenticated user can write checklist data into a private board they are not a member of (cross-board write via collection allow rule)](https://redirect.github.com/wekan/wekan/commit/b1ca76007) ([GHSA-gv8h-5p3p-6hx7](https://redirect.github.com/wekan/wekan/security/advisories/GHSA-gv8h-5p3p-6hx7), CWE-863 Incorrect Authorization). This is the same class as [BoardBleed](https://wekan.fi/hall-of-fame/boardbleed/) (GHSA-gm7v-pc38-53jr), but for the card-attached Checklist and ChecklistItem documents that the `boardId`-only `denyCrossBoardMove` fix did not cover. Checklists and checklist items are attached to a card and carry a denormalized `boardId`; they are MOVED between cards by `$set`-ting a new `cardId` (and, for items, a new `checklistId`) in a direct DDP collection update, after which the `Checklists.before.update` hook re-derives `boardId` from the destination card. The collection allow rules (`server/permissions/checklists.js`, `server/permissions/checklistItems.js`) authorized an update by checking only the document's CURRENT (source) `cardId` — i.e. the attacker's own board — and never inspected the new destination `cardId`/`checklistId`/`boardId`. Because every logged-in user can create a board where they are a write-capable member, a low-privileged user with write access to one board could create a checklist/item on their own card and then, in a single `/checklists/update` or `/checklistItems/update` DDP call, set its `cardId` to a card in a private board where they are not a member (if they know the target card id): the allow rule saw the attacker's source card, approved the write, and the before-update hook attached the attacker-controlled document to the victim's private board. The protected `moveChecklist` Meteor method correctly checks both source and destination board membership, but a DDP client can bypass that method and update the collections directly. CVSS:3.1 Moderate (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Fixed by adding `denyCrossBoardMoveByCard` and `denyCrossBoardMoveByChecklistItem` helpers in `server/lib/utils.js` and a `Checklists.deny`/ `ChecklistItems.deny` `update` rule on each collection that rejects any update whose destination board — resolved from a new `boardId`, `cardId`, or `checklistId` in the modifier — the caller has no write access to. Legitimate moves into boards the user belongs to and same-card edits keep working, and the server-side `moveChecklist` method (which bypasses allow/deny) is unchanged. A regression test (`server/lib/tests/checklistbleed.security.tests.js`) was added. Affected Wekan v9.62 and earlier. Thanks to DavidCarliez, xet7 and Claude. and adds the following updates: - [Fix the Docker pre-build version guard false-failing the release](https://redirect.github.com/wekan/wekan/commit/069dbc11f). The bundle-version guard added for the Admin-Panel-version fix assumed the WeKan app `package.json` ships as a standalone file with a `v`-prefixed version, and made "not found" fatal. Meteor does not ship it that way — it inlines the app `package.json` into the compiled `bundle/programs/server/app/app.js` as a JSON module (`{"name":"wekan","version":"v9.63.0",...}`), so the guard found no v-prefixed `package.json` and aborted the v9.63 Docker build. The guard now reads the version from that inlined module (anchored on `"name":"wekan"`, exactly what `require('/package.json')` resolves to), and a detection miss is now a warning that continues rather than a hard failure — only a confirmed version MISMATCH blocks the release, since `--build-arg VERSION` is the actual guarantee. Thanks to xet7 and Claude. Thanks to above GitHub users for their contributions and translators for their translations. ### [`v9.63`](https://redirect.github.com/wekan/wekan/blob/HEAD/CHANGELOG.md#v963-2026-06-19-WeKan--release) [Compare Source](https://redirect.github.com/wekan/wekan/compare/v9.61...v9.63) This release adds the following features: - [Fix the wekan.fi install page version never updating from a stale value](https://redirect.github.com/wekan/wekan/commit/40c3ee098). The `release-all.yml` website job ran every release but the install page's version stayed frozen at v9.57: `releases/release-website.sh` updated it with a sed anchored on `>v$OLD</span>`, which silently no-op'd once the published page's value no longer matched the `old_version` passed for a release. Anchor on the stable `<span class="version-number">` instead and re-normalize whatever version is there to the new one, with an assert so a miss fails loudly. Same self-healing fix applied to the local-flow copy in `releases/version.sh`. The live wekan.fi install page was also corrected to the current version. Thanks to xet7 and Claude. - [Make the remaining release version substitutions self-healing](https://redirect.github.com/wekan/wekan/commit/1e5ae8f64). Hardened the last `$OLD_VERSION`-anchored seds in `releases/version.sh` — the same fragile pattern that froze the Docker `ARG VERSION` and the install page. The snapcraft.yaml bundle download was release-critical (same class as the Docker bug: the snap downloads `wekan-<v>-<arch>.zip`, so a stale value ships the wrong bundle under the right name) and was stuck at v9.57; it now anchors on the `wekan-<v>-` / `releases/download/v<v>/` shapes and asserts. The sandstorm `appVersion` rewrite is now global and self-healing (the redundant `$OLD_NO_DOTS`-anchored fixup is dropped), and the Windows Offline.md doc links self-heal with a soft warning (cosmetic, so they must not fail the release). snapcraft.yaml and Offline.md were also corrected from their stale v9.57. Thanks to xet7 and Claude. Thanks to above GitHub users for their contributions and translators for their translations. </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMzAuMSIsInVwZGF0ZWRJblZlciI6IjQzLjEzMC4xIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIiwibGFiZWxzIjpbImFwcC93ZWthbiIsImF1dG9tZXJnZSIsInJlbm92YXRlL2NvbnRhaW5lciIsInR5cGUvbWlub3IiXX0=-->
title
| title |
|---|
| TrueCharts |
Community Helm Chart Catalog
TrueCharts is a catalog of highly optimised Helm Charts. Made for the community, by the community!
All our charts are supposed to work together and be easy to setup using any helm-compatible deployment tool, above all, give the average user more than enough options to tune things to their liking.
Getting started using TrueCharts
Support
Please check our FAQ, manual and Issue tracker There is a significant chance your issue has been reported before!
Still something not working as expected? Contact us! and we'll figure it out together!
Development
Our development process is fully distributed and agile, so every chart-maintainer is free to set their own roadmap and development speed and does not have to comply to a centralised roadmap. This ensures freedom and flexibility for everyone involved and makes sure you, the end user, always has the latest and greatest of every Chart installed.
Getting into creating Charts
For more information check the website: https://truecharts.org
Contact and Support
To contact the TrueCharts project:
-
Create an issue on Github issues
-
Open a Support Ticket
-
Send us an email
Contributors ✨
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
Licence
Truecharts, is primarily based on the AGPL-v3 license, this ensures almost everyone can use and modify our charts. Licences can vary on a per-Chart basis. This can easily be seen by the presence of a "LICENSE" file in that folder.
An exception to this, has been made for every document inside folders labeled as docs or doc and their subfolders: those folders are not licensed under AGPL-v3 and are considered "all rights reserved". Said content can be modified and changes submitted per PR, in accordance to the github End User License Agreement.
SPDX-License-Identifier: AGPL-3.0