Oracle GoldenGate EUVD-2026-106009

Exploitation requires the attacker to already possess a valid low-privileged logon (PR:L) on the infrastructure host where Oracle GoldenGate 21.3 through 21.23 executes, and to reach the Vendor Access Module component locally (AV:L). There is no remote network vector and no user-interaction requirement, but the pre-existing local account and privilege requirement is the primary limiting factor: a purely external, unauthenticated attacker cannot exploit this. Impact is limited to disclosure of GoldenGate-accessible data (C:H); integrity and availability are unaffected. Only supported versions 21.3-21.23 are affected.

This is a moderate-severity, local-access confidentiality issue, not an urgent priority. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 5.5) tells a consistent story: an attacker must already have local logon access to the host running Oracle GoldenGate (AV:L) and must hold at least low-level privileges (PR:L), after which they can read critical GoldenGate-accessible data (C:H) with no integrity or availability impact. This is a privilege-escalation-style information disclosure confined to an already-authenticated local user, which substantially caps real-world risk. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided; absent those signals there is no evidence of active or imminent exploitation - this reflects the typical profile of an Oracle quarterly Critical Patch Update finding reported internally by Oracle rather than a widely-weaponized flaw. One signal conflict to flag: the input Tags include 'Authentication Bypass,' which contradicts the CVSS vector - a flaw requiring PR:L (pre-existing credentials) and yielding only confidentiality impact is a local information-disclosure issue, not an authentication bypass; this tag appears mislabeled and should not drive triage.

An attacker who already has a low-privileged local account (or has compromised one) on the server where Oracle GoldenGate runs leverages a flaw in the Vendor Access Module to read data that GoldenGate can access, including sensitive replicated data. No user interaction or additional authentication beyond the existing local logon is required. No public exploit code was identified at the time of analysis, so exploitation would require custom development.