Oracle iRecruitment EUVD-2026-79777

Exploitation requires network reachability to the Oracle E-Business Suite HTTP interface serving the iRecruitment module (AV:N) and a valid authenticated account with only low privileges - the CVSS vector explicitly sets PR:L, so no administrative rights are needed and no authentication bypass is confirmed. No user interaction is required (UI:N) and attack complexity is low (AC:L). What limits exploitation: the attacker must already possess working credentials for the EBS instance, the iRecruitment module must be installed and its endpoints exposed to the attacker's network position, and deployments that front the application tier with strict allowlists or WAF rules may block the crafted requests. Environments where iRecruitment is not installed are not affected.

The signals here are moderately strong but incomplete. CVSS 8.5 reflects high confidentiality impact via network, low attack complexity, and a scope change that magnifies consequences beyond the vulnerable module; the required PR:L privilege keeps it out of the unauthenticated critical tier. No EPSS score, no KEV listing, and no public proof-of-concept were provided, so there is no evidence of active exploitation and the SSVC-style exploitation status should be treated as 'none' while automatable is plausibly 'yes' given the low complexity and lack of user interaction. Where signals conflict, flag it explicitly: the input tag 'Authentication Bypass' is not corroborated by the PR:L vector, which describes an authenticated low-privilege attacker rather than a bypass of authentication - verify against the Oracle advisory before accepting the tag. For a mid-sized operator such as a municipal HR function hosted on EBS in sanok, the practical concern is not mass internet scanning but an insider or a holder of any low-privilege employee/self-service account pivoting into recruitment records; that still warrants prompt patch-cycle inclusion rather than emergency out-of-band action.

An attacker with any valid low-privilege EBS account - for example an employee self-service or limited recruiting user - sends crafted HTTP requests to the iRecruitment Internal Operations endpoint, exploiting the broken access control to pull critical applicant and recruitment data and to insert, update, or delete some of it. Because the flaw carries a scope change, the same session context can be leveraged against other components on the shared EBS application tier, turning a single low-privilege foothold into broader suite-wide access. No public exploit code was identified at time of analysis; the attack is nonetheless straightforward given AC:L and UI:N.