Cervantes EUVD-2026-109244

Exploitation requires a valid authenticated account on the target Cervantes v1.3-beta (or earlier, from alpha 0.3) instance, as reflected by PR:L - it is not exploitable by anonymous users. The attacker then reaches the JiraController, which omits per-project authorization checks, allowing cross-project ticket create/edit/delete. The flaw is most impactful in multi-user/multi-project deployments where the Jira integration is configured and multiple teams or clients share one instance; a single-user or non-Jira-integrated deployment limits the practical impact. No user interaction is required beyond the attacker's own authenticated requests, and no non-default configuration beyond having Jira integration in use is indicated by the description.

This is a moderate, authenticated access-control flaw rather than a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N, base 7.1) indicates a network-reachable, low-complexity flaw that nevertheless requires an attacker to already hold a valid low-privileged account (PR:L) on the Cervantes instance - so it is not remote-unauthenticated. The high integrity impact (I:H) reflects that an authenticated user can create, edit, or delete Jira tickets tied to projects they should not be able to touch, with limited confidentiality exposure (C:L) and no availability impact (A:N). No EPSS score, KEV listing, SSVC decision parameters, or PoC/exploit reference were supplied, so exploitation probability signals are absent; the only triage signal is the vuln.today 'this_week' priority label, which argues for prompt but not emergency remediation. Treat this as a genuine multi-tenant authorization weakness for organizations running Cervantes as a shared pentest-management platform, but its real-world reach is bounded by the niche deployment footprint and the authentication prerequisite. No conflicting signals were found in the data; the main gap is the lack of EPSS/KEV/PoC evidence to gauge actual exploitation interest.

An attacker who holds any low-privileged account on a shared Cervantes v1.3-beta instance (for example a limited team member or a compromised analyst login) sends requests to the JiraController for projects they are not authorized to access. Because the controller fails to enforce per-project authorization, the attacker can create, modify, or delete Jira tickets belonging to other clients' or teams' vulnerability projects. No public exploit code was identified in the provided data, but the low attack complexity means this requires only crafted authenticated web requests.