DevaslanPHP project-management SQLi and SSRF

SQL injection in the Timesheet Dashboard of DevaslanPHP project-management (versions 1.2.1, 1.2.2, 1.2.3, 1.2.4 and v2.0.0-beta1) lets an authenticated remote attacker with a valid low-privileged account manipulate the 'filter' argument consumed by whereRaw() in app/Filament/Widgets/Timesheet/MonthlyReport.php and inject SQL against the application's backend database. Publicly available exploit code exists (a proof-of-concept write-up is published on GitHub), so the technique is within reach of moderately skilled attackers, although exploitation still requires a working session on the instance. The vendor was contacted about the disclosure and did not respond, so no vendor-released patch has been identified at time of analysis; the vendor-assigned CVSS 4.0 base score is 5.3 (Medium), while our independent assessment rates the confidentiality impact High with only limited integrity impact.

Authenticated SQL injection in the DevaslanPHP project-management Timesheet Dashboard (versions 1.2.1 through 1.2.4 and 2.0.0-beta1) allows a low-privilege logged-in user to inject arbitrary SQL through the `filter` argument consumed by the whereRaw() call in app/Filament/Widgets/Timesheet/ActivitiesReport.php, exposing or altering backend database data. Publicly available exploit code exists (a GitHub write-up demonstrating the Timesheet Dashboard Chart Filter injection, and the CVSS 4.0 vector carries E:P), and no CISA KEV entry indicates confirmed active exploitation. The vendor was contacted but did not respond, so no patched release has been confirmed and the disclosure is tracked via VulDB.

Server-side request forgery in DevaslanPHP project-management affects versions 1.2.1 through 1.2.4 and v2.0.0-beta1 and allows an authenticated, low-privileged user to make the application issue requests to attacker-chosen destinations. The flaw sits in the updateJiraProjects function of the /jira-import endpoint, where host, username and token parameters are accepted without an adequate authorization check (per the independent assessment, a missing canAccess check), so any user who can reach the Jira Import feature can force outbound connections from the server while only obtaining limited read/write effect. Publicly available exploit code exists (also reflected by the E:P metric in the vendor-supplied CVSS 4.0 vector), but there is no indication of confirmed active exploitation, and the vendor was contacted early and did not respond. This is a genuine but low-priority issue: the assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, i.e. partial confidentiality and integrity impact only, gated behind authenticated access to the import feature.