Vikunja EUVD-2026-14923

The CVSS v3.1 vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:L) indicates network-accessible attack vector with low complexity and low privilege requirement, but limited confidentiality impact and some availability impact with changed scope. This scoring reflects moderate real-world risk. The vulnerability requires authentication (PR:L) to trigger, narrowing the attack surface to existing Vikunja users or those with OIDC integration enabled. However, the lack of user interaction (UI:N) and the simplicity of exploitation (AC:L) make this practical to exploit. The presence of a patch in version 2.2.1 and associated GitHub commit (363aa6642352b08fc8bc6aaff2f3a550393af1cf) confirms vendor acknowledgment and availability of a fix. No public proof-of-concept or KEV mention is evident from provided references, but the straightforward nature of SSRF exploitation and the clarity of the vulnerability description suggest that functional exploits could be developed rapidly. Organizations using Vikunja with OIDC authentication enabled should prioritize patching, particularly if internal services or sensitive metadata endpoints are accessible from the Vikunja server network segment.

An attacker with a Vikunja user account (or access to create one via OIDC registration) sets their OIDC profile picture URL to point to an internal resource, such as http://internal-api.company.local/admin or http://169.254.169.254/latest/meta-data/ (AWS metadata service). When the victim administrator or another user triggers avatar download/sync, or when Vikunja automatically fetches the avatar during login, the server makes an unauthenticated HTTP GET request to the attacker-controlled URL. The server's response (including internal API responses, error messages, or metadata) can be exfiltrated by timing the request or analyzing Vikunja's behavior, allowing disclosure of internal IP addresses, API tokens, or cloud credentials. This requires the attacker to have network-level access to observe responses or manipulate the OIDC provider, but the low complexity and authentication-only barrier make it practical in real-world scenarios where OIDC integration is active.