Vulnerabilities

Vulnerability · CVE-2026-111919

Vikunja 0.22.0 before 2.7.0 contains an improper access revocation vulnerability that allows removed collaborators to keep receiving project data through webhooks they created.

Published Oct 9, 2026 · catalog updated Oct 18, 2026 · Vikunja 0.22.0 before 2.7.0

Open the advisory

Exploitation likelihood is not on this record for CVE-2026-111919. A missing EPSS score is not a low risk. Compare Vikunja 0.22.0 before 2.7.0 with the linked advisory before you change production.

Severity

High7.1

Known exploitation

Not in CISA/VulnCheck KEV

EPSS

Not in the current FIRST EPSS dataset

Remediation

Advisory link

Affected products

Go code.vikunja.io/api

## 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 . ** and — 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 — , added in , whose commit message states the invariant: *"cleanup team memberships, assignments and subscriptions when users lose access to a project"*. So you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live . 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: against four revocation paths: Removing a user directly from a project — the ordinary operation — dispatches nothing at all. ## PoC Released Docker image. The harness was proved first by reproducing a **known-fixed** advisory: 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**: 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 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 rev