Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed
## Summary 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"*. ```go 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 i
- Products
- code.vikunja.io/api
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-111919
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 31 Oct 2026, 08:43 UTC · Revision 1
Source evidence
Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed
core-osv · Original sourcePublished 9 Oct 2026, 20:57 UTC
## Summary 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"*. ```go 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 i
osv:GHSA-hjx8-qv73-f7cm
code.vikunja.io/api
Fixed versions: Not specified
Complete source record
{
"id": "1982414f47e8c416316cebec903d4a3b69231c38f1daf65766715178a3f8a162",
"url": "https://osv.dev/vulnerability/GHSA-hjx8-qv73-f7cm",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed",
"summary": "## Summary 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\"*. ```go 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 i",
"evidence": "osv:GHSA-hjx8-qv73-f7cm",
"products": [
{
"name": {
"value": "code.vikunja.io/api",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": []
}
],
"severity": "medium",
"structured": {
"id": "GHSA-hjx8-qv73-f7cm",
"aliases": [
"CVE-2026-111919",
"GHSA-hjx8-qv73-f7cm",
"GO-2026-6733"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N"
}
],
"affected": [
{
"ranges": [
{
"type": "SEMVER",
"events": [
{
"introduced": "0.22.0"
},
{
"last_affected": "2.6.0"
}
]
}
],
"package": {
"name": "code.vikunja.io/api",
"purl": "pkg:golang/code.vikunja.io/api",
"ecosystem": "Go"
},
"database_specific": {
"source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-hjx8-qv73-f7cm/GHSA-hjx8-qv73-f7cm.json"
}
}
],
"modified": "2026-10-19T21:40:42.317293516Z",
"provider": "osv",
"references": [
"https://github.com/go-vikunja/vikunja/security/advisories/GHSA-hjx8-qv73-f7cm",
"https://github.com/go-vikunja/vikunja"
],
"provider_metadata": {
"cwe_ids": [
"CWE-613",
"CWE-863"
],
"severity": "MODERATE",
"github_reviewed": true,
"nvd_published_at": null,
"github_reviewed_at": "2026-10-09T20:57:41Z"
}
},
"related_cves": [
{
"value": "CVE-2026-111919",
"evidence": "/aliases"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 376728,
"published_at": "2026-10-09T20:57:41+00:00"
}