Vikunja CVE-2026-111919

Exploitation requires the attacker to have previously been an authenticated collaborator on a Vikunja project (version 0.22.0 through 2.6.0) and to have created a webhook on that project while access was still valid. The webhook (and link-share) rows are not deleted by the revocation-cleanup routine, which is wired only to the TeamMember.Delete path; access revoked via direct project-user removal (ProjectUser.Delete), permission downgrade (ProjectUser.Update), or team-project removal (TeamProject.Delete) leaves the live feed intact. Limiting factors: the attacker must have had prior legitimate access, must have set up a webhook beforehand, and the impact is read-only disclosure of task titles/descriptions via the attacker-controlled webhook endpoint - there is no path to modify or destroy data.

This is a genuine but moderate-priority confidentiality issue, not an overstated high-CVSS finding. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) correctly captures a network-reachable, low-complexity flaw whose impact is confidentiality-only (VC:H, VI:N, VA:N), and the PR:L metric accurately reflects that the attacker must have been a legitimately authenticated collaborator who created a webhook before losing access - this is not an anonymous internet-wide exploit. The GHSA advisory describes a working PoC reproduction harness (built on the vikunja/vikunja:2.6.0 Docker image), so a practical exploit technique is public, but there is no CISA KEV listing and no EPSS score in the input, so there is no evidence of widespread or automated real-world exploitation; realistically this is an insider/former-collaborator abuse case rather than mass exploitation. The real-world ceiling is bounded by prerequisites (prior access + a pre-existing webhook) and by product footprint, which is modest for a self-hosted open-source tool. Note a documentation conflict: the CVE description states the fix is in 2.7.0, while the structured package feed reports 'fixed in: None' and vulnerable through 2.6.0 - verify the actual fixed release with the vendor.

A user is added as a collaborator to a Vikunja project and, while they have access, creates a webhook pointing at a server they control. When their access is later revoked through the ordinary 'remove user from project' path (or a permission downgrade), the webhook is not deleted, so their endpoint keeps receiving task titles and descriptions - including content created after revocation. A public PoC harness demonstrating this live feed is described in the GHSA advisory.