Oracle Loans CVE-2026-61037

Exploitation requires network access to the Oracle E-Business Suite web tier over HTTP and, per the CVSS vector, a low-privileged authenticated account (PR:L) with access to the Oracle Loans Internal Operations component; no user interaction is needed. Affected deployments are Oracle Loans releases 12.2.3 through 12.2.15. Limiting factors: the attacker must already hold valid (even low-level) EBS credentials and be able to reach the Loans endpoints, so environments that keep EBS off the public internet and tightly control account provisioning materially reduce exposure. Note the unresolved conflict - the vendor 'Authentication Bypass' tag implies weaker or no authentication requirements than PR:L suggests; verify with Oracle whether any pre-authentication path exists.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1) indicates a genuinely serious, network-reachable, low-complexity flaw requiring only some level of authentication and no user interaction, with high confidentiality and integrity impact but no availability impact. There is a notable signal conflict: the vendor tag labels this 'Authentication Bypass,' which would imply no privileges needed, yet the CVSS vector specifies PR:L (a low-privileged authenticated attacker) - these should be reconciled with Oracle before assuming pre-auth exploitation. No EPSS score, KEV status, SSVC decision, or POC was provided in the input, so exploitation probability cannot be quantified from data; the absence of these signals means the score alone drives prioritization. For internet-exposed or widely-accessed EBS environments handling financial loan data, this warrants high priority given the data-integrity and confidentiality impact and low attack complexity, but the real-world exploitation likelihood is unknown from available data.

A low-privileged EBS user (or an attacker who has obtained such credentials) sends crafted HTTP requests to the Oracle Loans Internal Operations component and, exploiting the authorization weakness, reads or tampers with loan records beyond their assigned permissions - for example modifying or deleting critical financial data across all Loans-accessible records. Given AC:L and no required user interaction, the request sequence is straightforward once network and credential access exist; no public POC is available at time of analysis.