Api: Vikunja: Write-level project members can delete admin-tier link shares through an unloaded permission check

The Vikunja API's deletion endpoints for project link shares (`DELETE /api/v1/projects/{project}/shares/{share}` and `/api/v2/projects/{project}/shares/{share}`) perform authorization checks using an object populated only with URL IDs, not the stored share data. The permission field defaults to Read (zero value) rather than the actual stored permission, causing the authorization logic to incorrectly allow users with Write permission to delete admin-tier shares. This flaw affects versions from 0.13.0 through 2.6.0. The vulnerability does not allow privilege escalation or data disclosure but permits Write collaborators to revoke admin-level link shares, invalidating associated access tokens and sessions.

An attacker with Write permission on a project can delete admin-tier link shares, effectively revoking external access granted by those shares. This results in a bounded integrity and availability impact by preventing new consumers from authenticating via the deleted share and invalidating existing sessions. The vulnerability does not disclose sensitive data, escalate privileges, or allow deletion of shares from other projects. The attacker must know or guess the numeric share ID to exploit this issue.

No official patch or fix is currently available. The recommended fix is to load the stored share scoped to both the requested share ID and project ID before performing authorization checks. The authorization should require project Admin permission when the stored share grants Admin-level permission and retain the existing Write permission check for lower tiers. Until a patch is released, monitor vendor advisories for updates and avoid granting unnecessary Write permissions to untrusted users.