Yes. CISA added CVE-2025-61884 to its Known Exploited Vulnerabilities catalogue on 20 October 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Oracle E-Business Suite contains a server-side request forgery (SSRF) vulnerability in the Runtime component of Oracle Configurator. Any organisation running the affected product should treat remediation as urgent.
What “exploited in the wild” means for this Oracle E-Business Suite CVE
An exploit being “in the wild” means the issue has moved beyond theoretical risk. For this Oracle E-Business Suite SSRF flaw, the practical question is not whether exploitation is possible, but whether your environment is exposed, whether the vulnerable component is reachable, and whether any internet-facing deployment has already been targeted. The operational answer is to treat it as an active incident class, not a routine patch item.
That changes how teams prioritise the work. If the affected Oracle E-Business Suite instance is externally reachable, the exposure window is already meaningful even before you confirm compromise. If the product is internal-only, the question becomes whether remote access paths, proxy rules, or adjacent application trust relationships still let an attacker reach the vulnerable runtime component.
How SSRF changes the risk profile in Oracle E-Business Suite
Server-side request forgery is dangerous because it lets an attacker cause the server to make requests on their behalf. In enterprise applications, that can turn a web-facing flaw into access to internal services, metadata endpoints, or other trusted destinations that are not meant to be reachable from the outside. That is why SSRF often sits at the boundary between application security and broader infrastructure exposure.
In Oracle E-Business Suite, the runtime context matters because the application may already have network reach, credentials, or trust relationships that a normal external user would never have. If SSRF is exploitable, the attacker is not just sending malformed input, they are using the application as a proxy into places the application is allowed to reach. SSRF Prevention Guide is useful here because it focuses on URL validation, egress controls, and metadata-service abuse, which are the control patterns that matter most for this class of issue.
That same pattern appears in Capital One breach 2019, where SSRF was tied to credential exposure through a trusted server-side path. The lesson for this Oracle issue is straightforward: even when the initial vulnerability is “only” request forgery, the downstream impact can become credential exposure, internal reachability, or lateral movement if the application sits in a privileged network position.
What to do now if you run Oracle E-Business Suite
The first step is to confirm whether the vulnerable Oracle E-Business Suite deployment exists anywhere in your estate, including cloned, test, and partially retired instances. In practice, exploited-in-the-wild vulnerabilities are often missed because teams only inventory production, while the reachable test environment still exposes the same attack surface.
If the system is present, apply Oracle’s remediation guidance as the primary fix path and use the CISA KEV catalogue as the prioritisation trigger. When a patch cannot be applied immediately, reduce exposure by restricting reachable network paths, tightening outbound request behavior where possible, and isolating the application from sensitive internal destinations it should not need to contact. Vulnerability Management Guide is the right internal reference for this triage flow because it covers KEV-driven prioritisation, emergency remediation, and verification after patching.
It is also worth checking whether the application could have been used to reach internal resources before you patched it. If there is any chance of server-side request activity, review logs for unusual outbound requests, unexpected internal host access, error patterns consistent with failed callback attempts, and signs that the application made requests it should never normally make. If the product has access to sensitive backend systems or cloud-connected services, credential rotation may be warranted after containment, especially where request paths could have exposed tokens, session material, or service credentials.
Risk and Threat Considerations
This flaw is materially risky because SSRF can convert a web application into a trusted relay into internal-only destinations. In an enterprise product, that can expose metadata services, internal APIs, or other restricted endpoints, especially when the application already has network reach that outsiders do not.
Failure mechanism: The attacker sends a crafted request that causes Oracle E-Business Suite to fetch a chosen internal or external resource, then abuses that trust boundary to probe internal services, retrieve sensitive data, or chain into deeper access.
Impact: Depending on deployment topology, the result can be credential exposure, internal reconnaissance, privilege expansion, or a broader compromise path that persists even after the initial web entry point is patched.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Active exploitation requires rapid prioritization and verification of remediation. |
| Recommendation — Prioritise and verify remediation for KEV-listed exposure. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | This issue needs exposure confirmation, prioritisation, and post-fix validation. |
| SI-4 — System Monitoring | SSRF exploitation is best detected through outbound-request and anomaly monitoring. | |
| AC-4 — Information Flow Enforcement | SSRF risk is driven by uncontrolled application egress and trust-boundary abuse. | |
| Recommendation — Scan for exposed Oracle E-Business Suite instances and validate remediation. Monitor outbound request anomalies and investigate suspicious server-side fetches. Restrict application egress to approved destinations and services. | ||
| NIST CSF 2.0 | RS.MA-01 — Incident Management Process | Known exploitation requires a containment and recovery response, not just patching. |
| Recommendation — Treat confirmed exposure as an incident and coordinate containment with recovery. | ||
Practitioner Guidance
What to verify: Confirm whether any exposed Oracle E-Business Suite instance can make arbitrary outbound requests, and check whether it can reach internal services, metadata endpoints, or privileged administrative paths. If you cannot answer that quickly, you do not yet understand the blast radius.
Escalation / exception: Treat public exposure, internet-reachable proxying behavior, or any sign of prior SSRF traffic as an escalation condition. In that case, remediation should be coordinated with logging review, containment, and post-fix validation rather than handled as a routine change ticket.
Practitioner takeaway: For exploited-in-the-wild SSRF, the real decision is not whether to patch, but how quickly you can bound the application’s outbound reach and prove it did not already act as a bridge into something more sensitive.
ិត
Related resources from NHI Mgmt Group
- Guide: Zero-Day and Exploited Vulnerabilities Guide
- CVE-2025-61884 (Oracle E-Business Suite Server-Side Request Forgery (SSRF))
- Is CVE-2020-7796 (Synacor Zimbra Collaboration Suite (ZCS) Server-Side Request Forgery) being exploited in the wild?
- Is CVE-2021-39935 (GitLab Community and Enterprise Editions Server-Side Request Forgery (SSRF)) being exploited in the wild?
- Is CVE-2021-22054 (Omnissa Workspace ONE Server-Side Request Forgery) being exploited in the wild?