Jorani EUVD-2026-98932

Requires a valid authenticated Jorani session of any privilege level (PR:L) - the attacker must already have working login credentials to the application. Given such an account, the attacker simply issues GET requests to the unprotected endpoints hr/exportEmployees, hr/exportLeaves/{id}, or hr/exportOvertime/{id}; no HR/admin role, no special configuration, and no user interaction are needed because these actions lacked the list_employees authorization check before v1.0.4. Limiting factors: exploitation is impossible for fully unauthenticated attackers, is confined to Jorani instances running versions before 1.0.4, and yields only read access to HR data (no write or availability impact).

This is a genuine but moderate-severity information-disclosure issue, not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the vendor-assigned 5.3 score agree: the flaw is network-reachable with low complexity but requires an authenticated session (PR:L), and the only impact is confidentiality at a low level (VC:L, with VI:N/VA:N) - no data modification or service disruption. The CWE-862 (Missing Authorization) classification and the fix commit, which simply adds $this->auth->checkIfOperationIsAllowed('list_employees') to the export actions, confirm the technical nature: ordinary low-privilege users can reach HR-only export endpoints. There is NO EPSS score provided, the CVE is NOT in CISA KEV, and no public exploit code is referenced, so there is no evidence of active exploitation or automation - this reads as a priority driven by data-sensitivity (employee PII/leave records) rather than by imminent mass exploitation. One labeling conflict to note: the input Tag says 'Authentication Bypass,' but the CWE-862 classification and the 'any authenticated user' wording make this an authorization (privilege) bypass, NOT an authentication bypass - verify the tag against the vendor advisory.

A low-privileged but authenticated Jorani user (e.g., an ordinary employee) who should only see their own records sends a direct request to hr/exportEmployees or hr/exportLeaves/{id}, and because the export actions lack an authorization check, the application returns full HR exports - employee names, emails, contracts, managers, and any user's leave/overtime history. No public exploit code is identified at time of analysis, but exploitation is trivial via a browser or curl once a valid login exists. The low attack complexity (AC:L) and lack of required user interaction (UI:N) make this reliable against any affected instance.