Oracle GoldenGate CVE-2026-91530

Exploitation requires the attacker to already possess HIGH privileges within Oracle GoldenGate (PR:H) and to reach the Admin Client Executable component over the network via HTTP (AV:N). Oracle explicitly rates this 'difficult to exploit' (AC:H), indicating success depends on specific conditions the attacker cannot reliably control - such as precise timing, state, or configuration of the Admin Client interaction - rather than default behavior. Limiting factors: this is NOT remote-unauthenticated; a trusted high-privileged account is mandatory, impact is confined to confidentiality (no integrity or availability loss and no scope change), and only Oracle GoldenGate versions 23.4 through 23.26.2.0.0 are affected. These constraints sharply narrow the realistic attacker population to insiders or holders of already-compromised privileged credentials.

This is a genuinely low-priority issue despite a CRITICAL-sounding confidentiality impact. The CVSS 3.1 base score is only 4.4 (MEDIUM), and the vector CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N is self-limiting: although the attack vector is network (AV:N) over HTTP, it requires HIGH attack complexity (AC:H) and HIGH privileges (PR:H), meaning the attacker must already be an authenticated, high-privileged GoldenGate user and must overcome conditions outside their control. The only impact is confidentiality (C:H / I:N / A:N) with no scope change (S:U). No EPSS score, no CISA KEV listing, and no public POC were provided, so the exploitation signal is weak across the board: no public exploit identified at time of analysis. The signals are internally consistent - Oracle's own description ('Difficult to exploit vulnerability allows high privileged attacker') aligns with AC:H and PR:H - so there is no network-vs-local or auth contradiction to resolve. One metadata conflict exists: the input carries an 'Authentication Bypass' tag, which contradicts a PR:H vulnerability that already presumes high-privileged authentication; this tag appears mislabeled. Bottom line: a real but low-urgency confidentiality flaw best handled in normal Oracle CPU patch cycles, not an emergency.

An attacker who already holds high-privileged credentials on an Oracle GoldenGate deployment sends crafted HTTP traffic to the Admin Client Executable component and, under specific hard-to-control conditions, gains unauthorized read access to critical or all GoldenGate-accessible data. Because the attack complexity is high and high privileges are required, this is a realistic escalation/data-exposure path only for an already-trusted insider or a previously compromised privileged account, not an external unauthenticated intruder. No public exploit code was identified at time of analysis.