Vikunja CVE-2026-91980

Requires a valid, authenticated Vikunja account (CVSS PR:L) and the ability to create or edit at least one project so that a team can be attached via the project teams endpoint - on default self-hosted deployments any normal user who can create a project satisfies this. No user interaction (UI:N) and no special feature flag or non-default configuration is documented as a prerequisite; the vulnerable endpoint is part of the standard project-sharing surface. Exploitation is limited in that it discloses only team metadata (team identity, member names, admin flags) and cannot modify data, escalate privileges directly, or read task contents; it also depends on numeric team IDs being guessable/sequential, as implied by the 'arbitrary team IDs' description. Deployments that have disabled user self-registration and issue accounts only to vetted staff reduce the pool of attackers who can meet the PR:L bar, but do not mitigate the flaw itself.

The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, base 4.3) is internally consistent: a network-reachable API, no user interaction, but a required low-privileged account and confidentiality-only impact, with no integrity or availability loss. No EPSS probability, KEV entry, or POC indicator was included in the intake, so exploitation status can only be stated as 'no public exploit identified at time of analysis' - the enumeration technique is nonetheless fully automatable once an account exists, since team IDs are numeric and can simply be iterated. The high attack-vector/low-privilege combination is what makes a nominally 'low' score worth scheduling: the leaked data (member identities plus who is a team admin) is reconnaissance material for later phishing or privilege-escalation attempts rather than an immediate compromise. Note that EPSS, KEV and POC data are absent from this feed, so downstream risk scoring should not treat their absence as a negative finding. Given the modest blast radius, even a mid-sized municipal IT team in olsztyn would find the direct impact limited, but should still fold the upgrade into routine maintenance because the roster leak shortens an attacker's reconnaissance phase. Key data gap: no patch-availability confirmation beyond 'Available from vendor' and no independent PoC reproduction were supplied.

An attacker registers or compromises a single ordinary Vikunja account, then iterates numeric team IDs against a project they own, attaching each candidate team in turn. Each request returns the resolved team object with its full member roster, including usernames and admin flags, for teams the attacker was never authorized to see. The harvested admin list becomes a target list for credential-stuffing or phishing against the highest-privileged accounts in the organization.