CVE-2026-91973 is an authentication control gap in Vikunja before 2.6.0. The CalDAV, well-known and feeds routes accept account passwords over BasicAuth with no rate limit, so an outsider can guess passwords without being throttled. NVD scores it High (7.5). Upgrade to Vikunja 2.6.0.
What's affected
The GitHub advisory lists Vikunja up to and including 2.5.0 as affected and 2.6.0 as patched. The NVD record says before 2.6.0.
The weakness is CWE-307, improper restriction of excessive authentication attempts. The record's vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.
The sources disagree on severity. NVD says 7.5 High, while the GitHub advisory labels the issue Moderate. The advisory also describes it as an authentication control bypass and not a denial of service, and says that password hashing keeps throughput to a few guesses per second. Accounts with two-factor authentication enabled, and bot users, are refused on these routes, so the target is password-only accounts.
How to check if you're exposed
Check the version you run. For a container, read the image tag and compare it with 2.6.0. If you installed a binary, ask it for its version or check the release you downloaded.
Then look at your reverse proxy or access logs for the three route groups named in the advisory (the DAV path, the well-known path and the feeds path). A long run of failed authentication responses from one address is the symptom. The advisory reports that the main login route throttles quickly while these routes never return a rate limit response.
Paste a lockfile or SBOM into the free in-browser dependency scan to see whether this package is in your tree, including as a transitive dependency. Safeguard's reachability analysis can then show whether your code actually calls the affected path, which helps you order the work.
What to do now
- Upgrade Vikunja to 2.6.0 or later.
- Turn on two-factor authentication for accounts that can use it. The advisory says those accounts are refused on these routes.
- Add rate limiting or fail2ban style blocking at your reverse proxy for the DAV, well-known and feeds paths.
- Check for weak or reused passwords on password-only accounts and reset any you doubt.
Why it matters
Rate limiting on a login page is only useful if it covers every route that accepts the same password. The advisory shows that the main login endpoint has an always-on limit of ten attempts per minute per address, but the CalDAV related route groups were registered with BasicAuth and nothing else. That left a second, unthrottled way to check a password.
The impact is bounded by password strength and by the slow hashing the advisory mentions, which is why NVD, which assumes the guess succeeds, scores higher than the project does. The KEV flag in the record is false and no source reports exploitation.
Try it yourself
Missing rate limits are a common API finding. This demo shows how an API scan surfaces unprotected routes like these.
Click through it at your own pace, or open it full screen.
Quick check
Why do the NVD and GitHub severities differ?
NVD scored the confidentiality impact as high on the assumption an attacker succeeds. The project rated it Moderate. Both are in the record, so treat it as at least moderate and fix it.
Does two-factor authentication help?
The advisory says accounts with TOTP enabled are correctly refused on these routes, so it removes the exposure for those accounts.
Sources
Last reviewed: 18 October 2026.
