DevaslanPHP Project-Management EUVD-2026-88067

Requires a low-privileged authenticated account on a DevaslanPHP project-management instance (versions 1.2.1-1.2.4 or v2.0.0-beta1) with access to the Jira Import feature. The attacker invokes the updateJiraProjects function at /jira-import and supplies attacker-controlled host/username/token values; the missing canAccess authorization check allows the request to proceed. Limiting factors: authentication is required (PR:L), the feature must be present/reachable, and impact is partial (constrained SSRF), reducing realistic severity below its network-exploitable rating.

This is a genuine but low-priority issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) rates it 5.1 (medium), and the SSVC-style exploitation signal E:P (proof-of-concept) aligns with the confirmed public exploit. Real-world risk is bounded by three factors: exploitation requires at least a low-privileged authenticated account (PR:L), the impact is limited (vendor VC:L/VI:L/VA:L - partial across the board, consistent with a constrained/non-blind SSRF rather than full RCE or data theft), and the affected product (DevaslanPHP project-management) is an obscure open-source PHP application with a tiny deployment footprint. No EPSS score, KEV listing, or evidence of active exploitation was provided - only public POC code exists, which is a distinct and weaker signal than in-the-wild exploitation. The UI:P in the vendor vector is questionable for an SSRF the attacker triggers directly via the /jira-import function; I assess UI:N (see assessed vector). Net: a real, publicly-documented SSRF worth patching where deployed, but not a widespread-threat priority given the niche product and authentication requirement.

A low-privileged authenticated user of a DevaslanPHP project-management instance submits a Jira Import request (updateJiraProjects on /jira-import) with an attacker-controlled host/username/token, causing the server to make a request to an internal or attacker-chosen destination. Because a canAccess authorization check is missing, the action succeeds and can be used to probe internal services or reach cloud metadata endpoints. A public POC exists on GitHub (dddwmr/CVE).