CVE-2026-111919: Vikunja Auth Bypass Vulnerability

CVE-2026-111919 Overview

CVE-2026-111919 is an improper access revocation vulnerability in Vikunja, an open-source task management application. Versions 0.22.0 through versions before 2.7.0 fail to disable or remove webhooks owned by collaborators after their project access is revoked. Removed collaborators continue to receive task titles, descriptions, and other project data through webhooks they previously created. The flaw is classified as [CWE-613: Insufficient Session Expiration]. The issue has a network attack vector and requires low privileges, with no user interaction needed.

Critical Impact

Former collaborators retain unauthorized access to confidential project data, including content created after their access was revoked, through webhooks that persist beyond account removal.

Affected Products

• Vikunja versions 0.22.0 and later
• Vikunja versions prior to 2.7.0
• Self-hosted and managed Vikunja deployments using webhooks

Discovery Timeline

• 2026-10-17 - CVE-2026-111919 published to NVD
• 2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-111919

Vulnerability Analysis

Vikunja supports webhooks that notify external endpoints when project events occur, such as task creation or modification. When a project owner revokes a collaborator's access, Vikunja removes the user from the project's access control list but does not disable or delete webhooks that collaborator configured while active. The webhook endpoint continues to receive payloads containing task titles, descriptions, and other project data for every triggering event.

The vulnerability enables ongoing information disclosure well after the formal access removal. An attacker who was previously granted collaborator access retains a persistent data exfiltration channel pointing to any URL they control.

Root Cause

The root cause is a missing authorization check during the webhook dispatch lifecycle. The access revocation workflow updates project membership but does not iterate webhook ownership to deactivate hooks owned by the removed user. The webhook subsystem treats stored webhook configurations as authoritative and does not re-validate the creator's current access rights before sending event payloads.

Attack Vector

Exploitation requires that the attacker was previously a legitimate collaborator on the target project with permission to create webhooks. Before access revocation, the attacker creates a webhook pointing to an attacker-controlled endpoint. After the project owner removes the attacker's collaborator status, the webhook continues to fire on subsequent project events, delivering task data to the external endpoint without any further action from the attacker.

See the GitHub Security Advisory GHSA-hjx8-qv73-f7cm and the VulnCheck Advisory on Vikunja for additional technical details.

Detection Methods for CVE-2026-111919

Indicators of Compromise

• Outbound HTTP POST requests from the Vikunja server to webhook URLs owned by former collaborators.
• Webhook configuration records whose created_by user identifier no longer appears in the project's membership table.
• Unexpected external endpoints receiving task metadata after an access revocation event.

Detection Strategies

• Audit the Vikunja webhook table against current project membership and flag webhooks whose creator lacks active access.
• Review application logs for webhook dispatch events correlated with recent collaborator removals.
• Inspect outbound network connections from the Vikunja host for destinations outside approved integration endpoints.

Monitoring Recommendations

• Enable egress logging on the Vikunja server and route logs to a centralized analytics platform for correlation.
• Alert on webhook dispatches occurring after a project membership change event within a short time window.
• Maintain an inventory of approved webhook endpoints and alert on new or unapproved destinations.

How to Mitigate CVE-2026-111919

Immediate Actions Required

• Upgrade Vikunja to version 2.7.0 or later, where the project maintainers address the webhook revocation gap.
• Enumerate all existing webhooks and delete any created by users who are no longer active collaborators.
• Rotate or invalidate shared secrets used by webhook endpoints that may have received unauthorized data.

Patch Information

The Vikunja project resolves CVE-2026-111919 in version 2.7.0. Upgrade instructions and release notes are available in the GitHub Security Advisory GHSA-hjx8-qv73-f7cm. Operators of self-hosted deployments should test the upgrade in a staging environment before production rollout.

Workarounds

• Manually delete webhooks owned by a collaborator as part of the access revocation runbook until the patch is applied.
• Restrict webhook creation permissions to a limited set of trusted administrators via project role configuration.
• Place Vikunja behind an egress proxy that enforces an allowlist of approved webhook destinations.

# Example: audit webhooks against current project membership (SQL)
SELECT w.id, w.target_url, w.created_by_id, w.project_id
FROM webhooks w
LEFT JOIN team_projects tp
  ON tp.project_id = w.project_id AND tp.user_id = w.created_by_id
WHERE tp.user_id IS NULL;