DaybydayCRM CVE-2026-116008

Requires a valid authenticated DaybydayCRM session as any user, including a low-privileged employee account (PR:L) - no admin or special permission is needed, which is precisely the defect. No special product configuration or non-default deployment mode is required; the vulnerable updateAssign() route is reachable in a standard installation of versions up to and including 2.2.1. The attacker must know or enumerate a target project's external_id used in /projects/updateassign/{external_id}. The limiting factor is that exploitation is not possible by a completely unauthenticated outsider - a registered account is mandatory - making this primarily an insider/privilege-abuse risk.

This is a moderate, authenticated-access authorization flaw rather than a high-urgency crisis. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms it is network-reachable over HTTP with low complexity but requires a valid, low-privileged account (PR:L), and impact is limited to integrity (VI:L) with no confidentiality or availability loss (VC:N/VA:N) - consistent with the base score of 5.3 and with CWE-862 (Missing Authorization). Key exploitation signals are absent or point to lower urgency: no CISA KEV listing is present (not actively exploited per the input), no EPSS probability was supplied, and the input does not mark a confirmed working exploit. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a patch-on-your-normal-cycle priority rather than an emergency. The realistic risk is an insider/privilege-abuse scenario: any authenticated employee can reassign projects they should not control. Missing data to note explicitly: EPSS score is not provided, so widespread-exploitation likelihood cannot be quantified, and no independent exploitation evidence exists beyond the documented request pattern.

A low-privileged employee with a valid DaybydayCRM account sends a crafted PATCH or POST request to /projects/updateassign/{external_id} with a chosen user_assigned_id, reassigning project ownership and redirecting notifications despite lacking the can-assign-new-user-to-project permission. Factoring in AV:N/AC:L/PR:L, this needs only an authenticated session and knowledge of a project's external_id. No public exploit code is confirmed in the input, but the VulnCheck advisory and GitHub issue #347 fully document the vulnerable endpoint and request.