GHSA-HJX8-QV73-F7CM
Vulnerability from github – Published: 2026-10-09 20:57 – Updated: 2026-10-09 20:57Summary
A collaborator removed from a project keeps a live, automatic feed of that project's contents, because nothing on any revocation path deletes the webhook they created while they had access.
Vikunja already has a revocation-cleanup routine that deletes other derived rows for exactly this reason. Its set is {task_assignees, subscriptions}. webhooks and link_shares — the only two rows that carry a live channel into the project — are not in it, and the routine is wired to one of four revocation paths.
Details
pkg/models/teams.go:411 — cleanupTaskMembersAfterTeamRemoval, added in 9358954c9, whose commit message states the invariant: "cleanup team memberships, assignments and subscriptions when users lose access to a project".
canRead, _, permErr := project.CanRead(s, &user.User{ID: memberID})
...
if !canRead {
projectsToCleanup = append(projectsToCleanup, projectID)
}
...
_, err = s.In("task_id", taskIDs).And("user_id = ?", memberID).
Delete(&TaskAssginee{})
_, err = s.In("entity_id", taskIDs).
Where("entity_type = ? AND user_id = ?", SubscriptionEntityTask, memberID).
Delete(&Subscription{})
_, err = s.In("entity_id", projectsToCleanup).
Where("entity_type = ? AND user_id = ?", SubscriptionEntityProject, memberID).
Delete(&Subscription{})
So you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live project.CanRead. The gap is which rows are in the set.
And there is a second level, which is the sharper one. That routine has exactly one caller:
pkg/models/listeners.go:1642 err = cleanupTaskMembersAfterTeamRemoval(s, event.Team.ID, event.Member.ID)
against four revocation paths:
pkg/models/project_team.go:151 TeamProject.Delete
pkg/models/project_users.go:141 ProjectUser.Delete <- grep -c cleanup inside: 0
pkg/models/project_users.go:248 ProjectUser.Update <- the downgrade path
pkg/models/team_members.go:91 TeamMember.Delete <- the only one wired up
Removing a user directly from a project — the ordinary operation — dispatches nothing at all.
PoC
Released vikunja/vikunja:2.6.0 Docker image.
The harness was proved first by reproducing a known-fixed advisory: GHSA-qfwc refuses the read-only member and returns the hash to the owner. Every run carries its own negative control.
The strongest form is on the team-removal path, where your cleanup routine does fire:
== OWNER removes collab from the TEAM ==
-- did the cleanup routine run? --
assignees now: [] <- POSITIVE CONTROL: it ran
collab direct read of task: HTTP 403 <- NEGATIVE CONTROL: access is gone
-- webhook still delivering? --
WEBHOOK RECEIVED task_title='post-team-removal secret'
task_desc='cleanup ran, webhook did not'
-- link share still redeemable? --
[{"title":"post-team-removal secret","description":"cleanup ran, webhook did not"}]
The two controls are the argument: your own routine executed and removed the assignee rows, and the collaborator's direct read is refused with 403 — and the webhook created before removal still delivers the contents of a task created after it.
On the ProjectUser.Delete path the same thing happens with no cleanup running at all.
One lab accommodation, stated plainly: non-routable outbound IPs were enabled so a loopback sink was reachable. In a default deployment an attacker simply uses a public URL, so this changes nothing about reachability.
Impact
A former collaborator receives task titles and descriptions for the whole project, continuously, after their access has been revoked — including content created after revocation.
The honest counter-argument, which we would rather state than have you find. Both artefacts stay visible and auditable to the owner afterwards: GET /projects/{p}/webhooks still shows {"created_by":"collab"} and GET /projects/{p}/shares still shows {"shared_by":"collab"}. An administrator reviewing project settings after an offboarding will find them. That is genuinely weaker than a silent channel, and it argues for the low end of Medium.
The precondition is also real: the attacker held write access, so they could have taken a snapshot before leaving. The only thing new here is access to content created after revocation — which is precisely the line you drew yourselves in GHSA-jp29-jrxc-92vf, "favourites readable after revocation". We think it holds. It is also the entirety of the claim, and we are not dressing it up as more.
Affected range
All releases from v0.22.0 through v2.6.0, and current main.
Determined by checking the code at each released tag:
v0.22.0 … v0.24.6 webhooks.go=yes cleanupRoutine=0
v1.0.0 … v2.6.0 webhooks.go=yes cleanupRoutine=1
Project webhooks arrive in ad7d485eb (2023-10-17), first released in v0.22.0. The cleanup routine arrives in 9358954c9 (2025-10-09), first released in v1.0.0, and has never included webhooks or link shares. Still present on main at d822e1c58: the routine contains only Delete(&TaskAssginee{}) and two Delete(&Subscription{}), and ProjectUser.Delete contains zero dispatches.
Reproduced at v2.6.0; earlier versions asserted from source rather than run, and we are saying which is which.
Recommended Fix
Two changes, and they are independent — the first is the smaller one, the second is the one that closes the class.
Add the two row types to the cleanup set. Alongside the existing task_assignees and subscriptions deletions, delete webhooks and link_shares whose created_by / shared_by is the departing user and whose project is in projectsToCleanup. The existing live project.CanRead test is already the right predicate.
Dispatch the cleanup from all four revocation paths, not only team-member removal. ProjectUser.Delete and ProjectUser.Update (the downgrade case) are the common operations and currently fire nothing; TeamProject.Delete unshares a whole project from a team and is equally a revocation.
A cheaper alternative for the second half, if reworking dispatch is unattractive: check CanRead for the webhook's created_by at delivery time, and for the share's shared_by at redemption time. That converts a cleanup problem into an authorization check on a path that already has the user id to hand.
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 6.5 Medium.
This is the identical vector you assigned to your own webhook advisory, GHSA-7c2g-p23p-4jg3 (webhook BasicAuth credentials exposed to read-only members), copied rather than argued. PR:L because the attacker must have been provisioned with project write at some point; C:H because the channel carries full task titles and descriptions for the whole project continuously — the same C:H you assigned there for a credential leak of narrower scope.
The auditability caveat above argues for the low end of Medium and we would not contest a lower score.
The link share is strictly more capable, and we are not leading with it
The same gap leaves a link share created by the departing collaborator redeemable after revocation, and a link share carries read and write — HTTP 201 demonstrated. On the same reasoning that would be C:H/I:H = 8.1 High.
We are deliberately not proposing that, and leading with the webhook instead, because a link share has a real "it is designed to be handed out" defence and the webhook does not. That judgement is yours to make, and if you decide the share is the more serious half we will not argue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0.22.0"
},
{
"last_affected": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-613",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:57:41Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nA collaborator removed from a project keeps a **live, automatic feed** of that project\u0027s contents, because nothing on any revocation path deletes the webhook they created while they had access.\n\nVikunja already has a revocation-cleanup routine that deletes other derived rows for exactly this reason. Its set is `{task_assignees, subscriptions}`. **`webhooks` and `link_shares` \u2014 the only two rows that carry a live channel into the project \u2014 are not in it**, and the routine is wired to one of four revocation paths.\n\n## Details\n\n`pkg/models/teams.go:411` \u2014 `cleanupTaskMembersAfterTeamRemoval`, added in `9358954c9`, whose commit message states the invariant: *\"cleanup team memberships, assignments and subscriptions when users lose access to a project\"*.\n\n```go\n\t\tcanRead, _, permErr := project.CanRead(s, \u0026user.User{ID: memberID})\n\t\t...\n\t\tif !canRead {\n\t\t\tprojectsToCleanup = append(projectsToCleanup, projectID)\n\t\t}\n\t...\n\t\t_, err = s.In(\"task_id\", taskIDs).And(\"user_id = ?\", memberID).\n\t\t\tDelete(\u0026TaskAssginee{})\n\t\t_, err = s.In(\"entity_id\", taskIDs).\n\t\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityTask, memberID).\n\t\t\tDelete(\u0026Subscription{})\n\t_, err = s.In(\"entity_id\", projectsToCleanup).\n\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityProject, memberID).\n\t\tDelete(\u0026Subscription{})\n```\n\nSo you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live `project.CanRead`. The gap is which rows are in the set.\n\n**And there is a second level, which is the sharper one.** That routine has exactly one caller:\n\n```\npkg/models/listeners.go:1642 err = cleanupTaskMembersAfterTeamRemoval(s, event.Team.ID, event.Member.ID)\n```\n\nagainst four revocation paths:\n\n```\npkg/models/project_team.go:151 TeamProject.Delete\npkg/models/project_users.go:141 ProjectUser.Delete \u003c- grep -c cleanup inside: 0\npkg/models/project_users.go:248 ProjectUser.Update \u003c- the downgrade path\npkg/models/team_members.go:91 TeamMember.Delete \u003c- the only one wired up\n```\n\nRemoving a user directly from a project \u2014 the ordinary operation \u2014 dispatches nothing at all.\n\n## PoC\n\nReleased `vikunja/vikunja:2.6.0` Docker image.\n\nThe harness was proved first by reproducing a **known-fixed** advisory: `GHSA-qfwc` refuses the read-only member and returns the hash to the owner. Every run carries its own negative control.\n\nThe strongest form is on the **team-removal path, where your cleanup routine does fire**:\n\n```\n== OWNER removes collab from the TEAM ==\n\n-- did the cleanup routine run? --\n assignees now: [] \u003c- POSITIVE CONTROL: it ran\n collab direct read of task: HTTP 403 \u003c- NEGATIVE CONTROL: access is gone\n\n-- webhook still delivering? --\nWEBHOOK RECEIVED task_title=\u0027post-team-removal secret\u0027\n task_desc=\u0027cleanup ran, webhook did not\u0027\n\n-- link share still redeemable? --\n[{\"title\":\"post-team-removal secret\",\"description\":\"cleanup ran, webhook did not\"}]\n```\n\nThe two controls are the argument: your own routine executed and removed the assignee rows, and the collaborator\u0027s direct read is refused with 403 \u2014 and the webhook created before removal still delivers the contents of a task created *after* it.\n\nOn the `ProjectUser.Delete` path the same thing happens with no cleanup running at all.\n\n**One lab accommodation, stated plainly**: non-routable outbound IPs were enabled so a loopback sink was reachable. In a default deployment an attacker simply uses a public URL, so this changes nothing about reachability.\n\n## Impact\n\nA former collaborator receives task titles and descriptions for the whole project, continuously, after their access has been revoked \u2014 including content created after revocation.\n\n**The honest counter-argument, which we would rather state than have you find.** Both artefacts stay **visible and auditable to the owner** afterwards: `GET /projects/{p}/webhooks` still shows `{\"created_by\":\"collab\"}` and `GET /projects/{p}/shares` still shows `{\"shared_by\":\"collab\"}`. An administrator reviewing project settings after an offboarding will find them. That is genuinely weaker than a silent channel, and it argues for the low end of Medium.\n\nThe precondition is also real: the attacker held write access, so they could have taken a snapshot before leaving. **The only thing new here is access to content created after revocation** \u2014 which is precisely the line you drew yourselves in `GHSA-jp29-jrxc-92vf`, *\"favourites readable after revocation\"*. We think it holds. It is also the entirety of the claim, and we are not dressing it up as more.\n\n## Affected range\n\n**All releases from `v0.22.0` through `v2.6.0`, and current `main`.**\n\nDetermined by checking the code at each released tag:\n\n```\nv0.22.0 \u2026 v0.24.6 webhooks.go=yes cleanupRoutine=0\nv1.0.0 \u2026 v2.6.0 webhooks.go=yes cleanupRoutine=1\n```\n\nProject webhooks arrive in `ad7d485eb` (2023-10-17), first released in v0.22.0. The cleanup routine arrives in `9358954c9` (2025-10-09), first released in v1.0.0, and has never included webhooks or link shares. Still present on `main` at `d822e1c58`: the routine contains only `Delete(\u0026TaskAssginee{})` and two `Delete(\u0026Subscription{})`, and `ProjectUser.Delete` contains zero dispatches.\n\nReproduced at v2.6.0; earlier versions asserted from source rather than run, and we are saying which is which.\n\n## Recommended Fix\n\nTwo changes, and they are independent \u2014 the first is the smaller one, the second is the one that closes the class.\n\n**Add the two row types to the cleanup set.** Alongside the existing `task_assignees` and `subscriptions` deletions, delete `webhooks` and `link_shares` whose `created_by` / `shared_by` is the departing user and whose project is in `projectsToCleanup`. The existing live `project.CanRead` test is already the right predicate.\n\n**Dispatch the cleanup from all four revocation paths**, not only team-member removal. `ProjectUser.Delete` and `ProjectUser.Update` (the downgrade case) are the common operations and currently fire nothing; `TeamProject.Delete` unshares a whole project from a team and is equally a revocation.\n\nA cheaper alternative for the second half, if reworking dispatch is unattractive: check `CanRead` for the webhook\u0027s `created_by` at delivery time, and for the share\u0027s `shared_by` at redemption time. That converts a cleanup problem into an authorization check on a path that already has the user id to hand.\n\n## Severity\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` \u2014 **6.5 Medium**.\n\nThis is **the identical vector you assigned to your own webhook advisory**, `GHSA-7c2g-p23p-4jg3` (webhook BasicAuth credentials exposed to read-only members), copied rather than argued. `PR:L` because the attacker must have been provisioned with project write at some point; `C:H` because the channel carries full task titles and descriptions for the whole project continuously \u2014 the same `C:H` you assigned there for a credential leak of narrower scope.\n\nThe auditability caveat above argues for the low end of Medium and we would not contest a lower score.\n\n### The link share is strictly more capable, and we are not leading with it\n\nThe same gap leaves a link share created by the departing collaborator redeemable after revocation, and a link share carries **read and write** \u2014 HTTP 201 demonstrated. On the same reasoning that would be `C:H/I:H` = 8.1 High.\n\nWe are deliberately **not** proposing that, and leading with the webhook instead, because a link share has a real *\"it is designed to be handed out\"* defence and the webhook does not. That judgement is yours to make, and if you decide the share is the more serious half we will not argue.",
"id": "GHSA-hjx8-qv73-f7cm",
"modified": "2026-10-09T20:57:41Z",
"published": "2026-10-09T20:57:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-hjx8-qv73-f7cm"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.