Oracle BI Enterprise Edition EUVD-2026-79640

Exploitation requires a valid low-privileged account with logon access to the infrastructure where Oracle Business Intelligence Enterprise Edition executes (CVSS PR:L, AV:L) - the attacker must already be on or able to log into that host, not merely reach it over the network. The BI Search component must be present and reachable by that account, and the deployment must be running one of the affected versions (8.2.0.0.0, 12.2.1.4.0, 26.01.0.0.0). Limiting factors are significant: no user interaction is needed (UI:N) and complexity is low (AC:L), so exploitation is easy once the foothold exists, but it is not remotely unauthenticated - an internet-facing attacker with no credentials and no local session cannot use this flaw. Environments that enforce strict OS-level segregation of BI EE accounts, or that do not allow interactive logon to the BI server for non-administrative users, materially reduce exposure.

The signals here are consistent and point to a genuinely serious but not remotely exploitable flaw: CVSS 3.1 is 7.8 with AV:L and PR:L, meaning the attacker must already hold a valid low-privileged account and have logon access to the infrastructure hosting BI EE - this is not an internet-facing, unauthenticated attack surface. AC:L and UI:N indicate that once that foothold exists, exploitation is trivial and needs no victim interaction, and the C:H/I:H/A:H impact means the BI EE deployment itself can be fully taken over, so even a mid-sized municipal IT team in gniezno should treat this as urgent once they confirm the affected version is running. No EPSS score, no KEV entry and no POC indicator were provided, so active exploitation cannot be claimed; the realistic threat model is an authenticated insider, a compromised service account, or a lateral-moving attacker who already has a shell on the BI host and wants to escalate to full platform control. Note the input tag 'Information Disclosure' conflicts with the take-over impact described by the vendor - treat the tag as unreliable. Key caveat: EPSS, KEV and POC status are absent from the input and should be re-checked before final prioritization; the absence of data is not evidence that no exploit exists.

An attacker who already holds a low-privileged account on the host running BI EE logs in - for example via a compromised service credential or an SSH session obtained through lateral movement - and sends a crafted request to the BI Search component from that local session. Because the flaw is low-complexity and requires no user interaction, the request executes in the context of the BI EE service and allows the attacker to replace or control platform components, escalating from a minor account to full takeover of the analytics deployment and its data. No public exploit code is identified in the available data, but nothing in the vector suggests the technique is difficult to reproduce once the vulnerability details are known.