Jorani EUVD-2026-98931

Exploitation requires a valid authenticated Jorani account at employee level (PR:L) - any ordinary user with self-service access qualifies; no admin or HR role is needed. There is no special configuration requirement: the flaw exists in default behavior because the affected controllers (Leaves::edit/delete/history, Extra::edit/delete) authorize by operation name only and never verify that the targeted request's employee matches the acting user. The attacker must supply a numeric request ID belonging to another employee, so successful tampering depends only on ID enumeration/guessing. Limiting factors: a working login is mandatory (no anonymous access), impact is confined to leave and overtime request data, and only versions before 1.0.4 are affected - upgrading to 1.0.4 adds the ownership checks that close all five endpoints.

This is a medium-severity authorization flaw (CWE-639 IDOR), not a critical one, and the signals are consistent rather than conflicting. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires an authenticated low-privileged account (PR:L) - so this is an insider/post-authentication threat, not an unauthenticated internet-facing break-in. Impact is explicitly limited: VC:L/VI:L/VA:N means partial confidentiality and integrity exposure of other employees' leave/overtime records, with no availability, no RCE, and no scope change (SC:N/SI:N/SA:N). No EPSS score, CISA KEV listing, or public exploit was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: a legitimate but lower-priority issue - real for organizations where employee self-service accounts are broadly provisioned and HR data privacy matters, but not an emergency patch for most. Prioritize if your threat model includes malicious insiders or shared/weak employee credentials.

An authenticated Jorani user (any employee) logs in and, instead of acting on their own records, supplies another employee's numeric request ID to endpoints such as Leaves::edit(), Leaves::delete(), or Leaves::history(). Because authorization is enforced only by operation name rather than record ownership, the attacker can modify or delete a colleague's leave/overtime request and read their leave history. No public exploit code was identified, but the vulnerable code paths and the fixing commit are publicly documented.