Jorani EUVD-2026-98933

Requires an authenticated Jorani session - any valid low-privilege user account suffices (PR:L), with no administrative role needed. The flaw exists in default installations of Jorani before 1.0.4 because the Contracts import handler lacks the isAllowed('adddayoff_contract') permission check that v1.0.4 adds; no non-default configuration is required to trigger it. No user interaction is needed (UI:N) and it is reachable over the network (AV:N). Limiting factors for defenders: the attacker must first obtain valid credentials, the SSRF is semi-blind (the code only proceeds on an HTTP 200 and imports ICS content rather than returning raw responses), and impact is bounded to calendar/day-off data integrity plus internal host reachability - not code execution or availability loss.

The input CVSS 4.0 base score is 5.3 (Medium) with vector AV:N/AC:L/AT:N/PR:L/UI:N and limited confidentiality and integrity impact (VC:L/VI:L, no availability). This is a genuine but moderate-priority issue rather than a critical one: exploitation requires a valid authenticated account (PR:L), and the primary impact is overwriting non-working-day calendars (integrity) plus a blind/limited SSRF primitive (get_headers() and fopen() against internal hosts). No EPSS score is provided in the input, the CVE is NOT listed in CISA KEV, and no public exploit code is referenced (the GitHub links are the patch commit, release, and issue tracker, not a POC), so there is no public exploit identified at time of analysis. The signals are internally consistent - a low-complexity, network-reachable but authentication-gated flaw - with no high-severity amplifiers (no active-exploitation or automatable evidence). One conflict to flag: the input Tag 'Authentication Bypass' is inaccurate because the advisory, description, and CWE-862 (Missing Authorization) all require an already-authenticated user; this is an authorization (privilege/IDOR-style) flaw plus SSRF, not an authentication bypass. The SSRF against internal infrastructure is the most security-relevant capability and could matter more in environments with sensitive internal services, but overall real-world risk is tempered by the authentication requirement and limited niche deployment.

An attacker with any low-privilege authenticated Jorani account sends a crafted POST to the Contracts import endpoint supplying an arbitrary contract id and an attacker-controlled or internal URL. Because versions before 1.0.4 omit the isAllowed('adddayoff_contract') authorization check, the server validates and fetches that URL via get_headers()/fopen(), letting the attacker overwrite day-off calendars on contracts they do not own and probe internal-only hosts (SSRF). No public exploit code is referenced, but the low attack complexity and patch diff make reproduction straightforward.