Skip to content
Heist/ feed
Back to feed
Medium

Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed

Type: advisorySources: OSV

## 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 source

Published 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"
}