What breaks and who should care
If your scanner has just flagged CVE-2025-61884, the thing that is broken is a server‑side request forgery (SSRF) in the Runtime component of Oracle Configurator, part of Oracle E‑Business Suite. Anyone who runs the Configurator service on a network‑accessible host should stop what they are doing and read on.
Related remediation guides
Other vulnerabilities in the same family or affecting the same products:
- CVE-2025-61882 – Immediate Action Guide for Oracle E‑Business Suite
- CVE-2024-6670 – WhatsUp Gold SQL injection – What you need to know and fix now
- CVE-2024-9680 – Critical Use‑After‑Free in Firefox and Thunderbird
For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.
What is CVE-2025-61884?
Oracle E‑Business Suite’s Configurator allows administrators to build and customise the suite during implementation. The Runtime component accepts URLs that it will fetch to retrieve configuration data. In the vulnerable code path the URL is taken from a request parameter and is used without sufficient validation. An attacker can therefore force the server to make arbitrary HTTP or TCP connections – that is the classic definition of SSRF.
The vulnerability is remote, requires no credentials and has been confirmed in the wild. CISA has listed it as a known‑exploited vulnerability and notes that ransomware groups have incorporated it into their payload delivery chains. The CVSS score is 7.5, which puts it firmly in the high severity bucket.
Oracle’s own advisory describes the flaw as “remotely exploitable without authentication”. The exact technical details of the vulnerable code have not been published, but the class of issue is well understood: an attacker supplies a crafted URL, the server fetches it, and the attacker can reach internal services, metadata endpoints, or even trigger outbound connections that later become part of a ransomware payload.
How does the SSRF work?
At a high level the flow is:
- An HTTP request hits the Configurator Runtime endpoint.
- The request contains a parameter that is interpreted as a target URL.
- The server opens a socket to that URL and forwards the response back to the caller.
Because the URL is not restricted to external addresses, an attacker can point it at any address the server can reach – internal APIs, cloud metadata services, or even localhost. Once the attacker can read the response they can discover secrets, enumerate services, or chain the request into a larger attack.
There is no authentication check before the request is made, and the server does not enforce a whitelist of safe destinations. That lack of defence is what makes the flaw exploitable at scale.
Determining whether you are exposed
The first step is to confirm which release of Configurator you are running. Oracle stores the product version in the database and in a file under the Oracle Home directory. Run one of the following commands on the application tier host:
sqlplus / as sysdbathen executeSELECT RELEASE FROM FND_PRODUCT_GROUPS WHERE PRODUCT = 'CONFIGURATOR';cat $ORACLE_HOME/config/ebs_version.txt
If the output matches any of the releases listed in the table below, you are in scope for CVE-2025-61884.
Next, verify that the Runtime component is enabled and listening on its default port. The simplest way is to check the process list:
ps -ef | grep configurator_runtime
Or, if you prefer a network view, run:
netstat -anp | grep LISTEN | grep runtime‑port
Replace runtime‑port with the port you have configured for the service – the default is documented in the product installation guide.
Mitigation – what to do right now
The vendor has released a patched build for each supported branch. The recommended action is to upgrade the Configurator Runtime component to the patched release for your branch. Do not try to apply a patch from a different branch – the binaries are not interchangeable.
Upgrade steps, in brief:
- Back up the E‑Business Suite database and the $ORACLE_HOME directory.
- Download the appropriate patch set from My Oracle Support. The patch identifier is listed in the advisory; use your support credentials to retrieve it.
- Stop the Configurator service:
adadmin stop configurator - Apply the patch using the supplied
opatchutility:opatch apply <patch‑dir> - Start the service again:
adadmin start configurator - Run the post‑installation script that validates the patch was applied successfully.
After the upgrade, re‑run the version‑check query above. The result should now show the patched release, which is listed as the fixed version in the table below.
If you cannot schedule an upgrade immediately, apply the temporary mitigations that Oracle recommends:
- Restrict outbound traffic from the Configurator host to only the destinations required for normal operation. Use a firewall rule that blocks all other HTTP/S traffic.
- Disable the Runtime endpoint if you do not use it in production. Comment out or remove the servlet mapping in the
web.xmlfile under $ORACLE_HOME/configurator/webapps. - Enable network‑level egress filtering for cloud‑hosted deployments, following the guidance in BOD 22‑01. That guidance requires you to deny any traffic to private IP ranges that are not explicitly required.
These steps do not remove the flaw from the code, but they raise the bar for an attacker and buy you time to plan a full upgrade.
If a patch is not yet available for your environment
There are situations where the patched release cannot be applied – for example, a highly customised instance that has not been tested against the new binaries. In those cases you have three options:
- Isolate the Configurator host on a separate VLAN with no route to internal services. Only allow traffic from trusted admin workstations.
- Wrap the Runtime endpoint in a reverse‑proxy that validates the supplied URL against a whitelist of allowed domains. The proxy should reject any request that tries to reach private IP ranges, loopback, or cloud metadata endpoints.
- Consider disabling the Configurator component entirely if it is not required for day‑to‑day operations. Oracle allows you to run the suite without the Runtime service after initial configuration.
Document whichever approach you take and monitor the host for suspicious outbound connections. A simple syslog rule that flags connections to internal IP ranges from the Configurator process can alert you to attempted abuse.
What to do after you have mitigated
Once the patch is applied or the temporary controls are in place, verify that the SSRF vector no longer works. You can do a quick test by sending a request that points at a known internal service – for example, the Oracle database listener on the localhost address. The response should be blocked or return an error, not the service’s data.
Keep an eye on Oracle’s security bulletins for any follow‑up advisories. The vendor may release additional hardening guidance or a newer patch that addresses related issues.
References and next steps
The table below is generated automatically from the NVD feed and shows the range of releases that are vulnerable and the first release that contains the fix. Use it to confirm that your environment falls inside the vulnerable range.
Table: Affected and Fixed Releases for CVE-2025-61884
The table below
Affected versions
Straight from the NVD record for CVE-2025-61884. If your build is inside one of these ranges, treat it as vulnerable.
| Product | Affected range | Fixed in |
|---|---|---|
configurator |
12.2.3 up to 12.2.14 | see vendor advisory |
