Vikunja Auth Flaw Lets Attackers Maintain Access After Password Reset

A critical vulnerability in Vikunja, the open-source task management platform, combines two authentication flaws that together enable persistent unauthorized access. CVE-2026-27575 carries a CVSS score of 9.1 and affects all versions prior to 2.0.0.

The vulnerability is particularly concerning because victims can't remediate the attack through normal means—changing passwords doesn't revoke attacker access. Organizations running self-hosted Vikunja instances should upgrade to version 2.0.0 immediately.

Two Flaws, One Attack Chain

CVE-2026-27575 consists of two compounding weaknesses:

Weak password enforcement: Vikunja failed to require minimum password strength, allowing users to set trivially guessable credentials like "1234" or "password." This enabled brute-force and credential stuffing attacks with high success rates.

Persistent sessions after password change: When users changed their passwords, existing sessions remained valid. Attackers who compromised an account could maintain access indefinitely, regardless of password resets.

Together, these flaws create a scenario where attackers can compromise accounts through weak credentials, then maintain persistent access that survives the victim's remediation attempts.

Attack Scenario

The exploitation path follows a predictable pattern:

1. Attacker identifies a Vikunja instance (many are publicly accessible for remote team collaboration)
2. Attacker runs credential stuffing or brute-force attacks against user accounts
3. Weak password policy means common credentials succeed frequently
4. Attacker establishes a session with the compromised account
5. Even when the victim notices suspicious activity and resets their password, the attacker's session token remains valid
6. Attacker retains indefinite access to the victim's task lists, projects, and shared data

This "zombie session" problem isn't unique to Vikunja—we've covered similar session management vulnerabilities in other productivity tools. The pattern is depressingly common in self-hosted applications.

Who's Affected

Vikunja is popular among privacy-conscious teams and organizations that prefer self-hosted alternatives to cloud services like Todoist or Asana. The platform runs on-premise, giving organizations full control over their data.

That same self-hosted model means affected instances won't auto-update. Administrators must manually upgrade to version 2.0.0, and many self-hosted deployments lag behind current releases.

The risk is highest for:

• Teams using Vikunja for sensitive project management
• Organizations with publicly accessible instances
• Deployments where users reuse passwords from breached credentials lists

Remediation Steps

Immediate actions:

1. Upgrade to Vikunja 2.0.0 from the official releases page
2. Force session invalidation for all users after upgrading
3. Require password resets to ensure all accounts use strong credentials
4. Audit access logs for suspicious login patterns indicating prior compromise

Longer-term improvements:

• Implement rate limiting on login endpoints
• Deploy monitoring for failed authentication attempts
• Consider adding multi-factor authentication if your deployment supports it
• Restrict instance access to VPN or internal networks where possible

The Self-Hosted Security Challenge

Self-hosted applications offer privacy and control benefits, but they shift security responsibility to administrators who may lack dedicated security resources. Unlike SaaS providers who patch vulnerabilities across all customers simultaneously, self-hosted deployments require individual attention.

This vulnerability highlights a common self-hosted pattern: features that seem convenient (simple password requirements, persistent sessions) become attack vectors when exposed to motivated adversaries.

For organizations choosing self-hosted tools for data breach prevention and privacy reasons, the tradeoff requires ongoing security investment. Automated updates, security monitoring, and regular audits aren't optional—they're the cost of maintaining control over your data.

The 2.0.0 release addresses both flaws comprehensively. But if you're running Vikunja in production, the upgrade should happen today, not next week.