CVE-2026-111918

A vulnerability in Vikunja before version 2.2.1 allows unauthorized access to share hashes and downloading/deleting all file attachments across the instance. An authorization flaw in the LinkSharing.ReadAll and GetTaskAttachment endpoints enables privilege escalation to admin-level shares.

Vikunja 2.2.0 before 2.7.1 contains an HTML injection vulnerability in CreateConversationalHeader in pkg/notifications/mail.go that interpolates display names and task and project titles raw into email anchors. Authenticated users can craft titles or display names that close the anchor and inject phishing links into task-comment and task-mention notification emails sent to project members.

Vikunja from 2.2.0 before 2.7.0 contains a permissive CORS configuration that trusts every localhost and 127.0.0.1 port with credentials, even when service.publicurl is set. Attackers controlling a page on any localhost port can send a credentialed request to the token refresh endpoint and read the returned bearer JWT to take over the logged-in user's account.

Vikunja 0.13.0 before 2.7.0 contains an incorrect authorization vulnerability that allows project members with Write permission to delete admin-tier link shares because the delete permission check reads an unloaded share object. Attackers can send DELETE requests to the v1 or v2 projects shares endpoints with sequential share IDs to revoke admin links and invalidate existing share sessions.

Vikunja 2.6.0 contains a broken access control flaw in getProjectAccessForUser (pkg/models/project_access.go), which resolves a user's effective project permission as the maximum over the project tree, silently overriding explicit lower-permission shares on sub-projects. A collaborator with write access on a parent project but read-only access to a child project can modify the child project's tasks and content.

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. Former collaborators keep receiving task titles and descriptions through their webhook, including content created after their access was revoked.

Vikunja 2.3.0 before 2.7.0 contains an improper session validation vulnerability that allows attackers to keep WebSocket access after revocation because handleAuth never checks the JWT sid claim against the sessions table. Attackers holding a stolen access token can open or maintain connections to /api/v2/ws after session deletion or TOTP enrollment, continuing to receive the victim's notification.created pushes, including comment, task and project content.

Vikunja versions prior to 2.4.0 store password-reset, email-confirmation, and account-deletion tokens in the user_tokens table in plaintext. An attacker with read access to the database can immediately use pending tokens to take over user accounts without knowing passwords. Version 2.4.0 fixes the issue.

Vikunja versions 1.0.0 through 2.3.0, when an administrator enables the per-provider emailfallback option on an OpenID Connect provider, links an SSO login to a pre-existing local account using only the email claim from the IdP, without checking email_verified or requiring the account password. An attacker with a token carrying a victim's email can log in as that victim without consent. Version 2.4.0 fixes the issue.

Vikunja version 2.3.0 allows a scoped API token limited to the oauth.authorize permission to call POST /api/v1/oauth/authorize, obtain an OAuth authorization code, and exchange it for a normal bearer JWT and refresh token. The resulting credentials are not restricted by the original token's permissions, granting access to routes outside its declared scope. Version 2.4.0 fixes the vulnerability.