Disclosure summary
### Summary When you share a project with a team, the API lets you attach any team on the instance, including teams you have nothing to do with, as long as you're an admin of the project. Listing a project's teams then returns each team's full member roster. So any logged-in user can spin up a throwaway project, attach team IDs one by one, and read back the name, description, and complete member list of every team on the instance. Normally you can only see teams you belong to; this path ignores that. ### Details Sharing a project with a team is a two-step flow: you PUT a team to the project, then you GET the project's teams to see them. The share endpoint only enforces that you're an admin of the target project, it doesn't care whether the team you're referencing is one you're allowed to see. Any existing team ID is accepted. The listing endpoint is even more permissive: read access to the project is enough, which you obviously have on a project you created. And its response isn't just a list of team names, it includes each team's description, creator, and a full members array with every member's username, display name, and admin flag. Put together, an attacker who owns a single pr
Source-specific records & product guidance
Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.
GitHub Reviewed Security Advisories · GHSA-39p5-2wrr-xh29
Open original source · Updated Oct 09, 2026
Vikunja: Any user can enumerate every team and its members by attaching arbitrary teams to a throwaway project
Source severity: MEDIUM / 5.3
| Ecosystem | Package | Affected range | First patched |
|---|---|---|---|
| go | code.vikunja.io/api | 2.6.0 |
Original records & references
- NIST NVD record
- CVE Program record
- github.com — Reviewed advisory
PUBLISHED 2026-10-09T16:52:27-04:00
MODIFIED 2026-10-09T16:52:28-04:00
INGESTED 2026-10-10T20:45:43-04:00