CVE-2026-91972: Vikunja API Authentication Bypass Vulnerability

CVE-2026-91972 Overview

CVE-2026-91972 affects Vikunja, an open-source task management platform, in all versions before 2.6.0. The application fails to apply rate limiting to /api/v2 public authentication endpoints. Unauthenticated remote attackers can abuse login, register, password-reset, and OAuth token routes without throttling. This enables unbounded credential guessing, account enumeration, and password-reset flooding attacks against exposed Vikunja instances. The weakness is classified as Improper Restriction of Excessive Authentication Attempts [CWE-307].

Critical Impact
Remote unauthenticated attackers can conduct high-volume brute-force and enumeration attacks against Vikunja authentication APIs, leading to account compromise and abuse of transactional email systems.

Affected Products

Vikunja versions prior to 2.6.0
Vikunja /api/v2 public authentication endpoints (login, register, password-reset, OAuth token)
Self-hosted Vikunja deployments exposing the API to untrusted networks

Discovery Timeline

2026-09-15 - CVE-2026-91972 published to the National Vulnerability Database
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-91972

Vulnerability Analysis

Vikunja exposes a REST API under the /api/v2 path for client interactions, including unauthenticated flows required for onboarding and account recovery. Prior to version 2.6.0, the framework middleware responsible for enforcing per-IP or per-account request throttling is not applied to these public authentication routes. As a result, requests to login, register, password-reset, and OAuth token endpoints are accepted at whatever rate the underlying HTTP server can process.

An attacker can script high-volume credential stuffing against login, submit large dictionaries against password-reset to enumerate registered addresses, and probe register to determine which usernames or emails are already provisioned. The OAuth token endpoint is similarly unprotected, enabling automated guessing of client credentials or refresh tokens. Because responses differ between valid and invalid inputs, enumeration is reliable even without successful authentication.

Root Cause

The root cause is missing enforcement of the rate-limiting middleware on the /api/v2 public authentication route group. The throttling logic exists in the codebase but is not wired into the middleware chain for these endpoints, leaving them fully open. This matches the CWE-307 pattern of failing to restrict excessive authentication attempts.

Attack Vector

Exploitation requires only network access to the Vikunja API. No credentials, user interaction, or elevated privileges are needed. An attacker sends repeated HTTP POST requests to the affected endpoints from one or more source addresses. Password-reset flooding additionally weaponizes the target's outbound email infrastructure, potentially degrading deliverability and consuming SMTP quotas. See the GitHub Security Advisory GHSA-6rvj-qwjf-3m4q and the VulnCheck Advisory: Vikunja API Bypass for further technical detail.

Detection Methods for CVE-2026-91972

Indicators of Compromise

High request rates from a single source IP or narrow subnet to /api/v2/login, /api/v2/register, /api/v2/user/password/reset, or /api/v2/auth/openid/* endpoints.
Elevated volumes of failed authentication responses (HTTP 401/403) within short time windows.
Spikes in outbound password-reset emails, including bounces to non-existent addresses.
Distributed low-and-slow request patterns targeting the same authentication routes across many source IPs.

Detection Strategies

Baseline normal request rates to Vikunja authentication endpoints and alert on statistical deviations.
Correlate reverse-proxy or web-server access logs with Vikunja application logs to identify enumeration patterns.
Deploy a Web Application Firewall (WAF) rule that flags repeated POSTs to /api/v2 authentication paths from the same client.

Monitoring Recommendations

Ship Vikunja and fronting proxy logs to a centralized log platform and retain them for at least 90 days.
Track per-account failed-login counters and generate alerts on thresholds indicative of brute forcing.
Monitor SMTP relay volumes originating from Vikunja for sudden increases tied to password-reset abuse.

How to Mitigate CVE-2026-91972

Immediate Actions Required

Upgrade all Vikunja instances to version 2.6.0 or later, which applies rate limiting to the /api/v2 public authentication endpoints.
Rotate credentials for any accounts showing signs of successful brute-force or credential-stuffing activity.
Review authentication and mail-server logs for the period between deployment and patch to identify prior abuse.

Patch Information

The fix is included in Vikunja 2.6.0. Refer to the GitHub Security Advisory GHSA-6rvj-qwjf-3m4q for the upstream commit and release notes. Administrators should follow the standard Vikunja upgrade procedure for their deployment method (binary, Docker, or package).

Workarounds

Place Vikunja behind a reverse proxy such as NGINX, Caddy, or Traefik and configure request-rate limits on the affected authentication paths.
Enforce IP allow-listing for /api/v2 authentication endpoints where the user population is known and bounded.
Deploy a WAF rule to throttle or challenge repeated POSTs to login, register, password-reset, and OAuth token routes.
Enable CAPTCHA or multi-factor authentication (MFA) on account creation and password reset flows where supported.

bash

# Example NGINX rate-limit configuration for Vikunja auth endpoints
http {
    limit_req_zone $binary_remote_addr zone=vikunja_auth:10m rate=5r/m;

    server {
        location ~ ^/api/v2/(login|register|user/password/reset|auth/openid/) {
            limit_req zone=vikunja_auth burst=10 nodelay;
            limit_req_status 429;
            proxy_pass http://vikunja_upstream;
        }
    }
}