Cl0p chained an Oracle EBS SSRF into a mass extortion campaign. Your patch window is 21 days.

Oracle E-Business Suite versions 12.2.3 through 12.2.14 have a pre-authentication SSRF in the Configurator Runtime UI (/OA_HTML/configurator/UiServlet) that Cl0p weaponized into a full remote code execution chain during a mass extortion campaign starting July 2025. CVSS 7.5, no credentials required, remotely exploitable. Oracle took roughly 90 days to ship a patch. CISA added it to the KEV catalog on October 20 with a November 10 federal deadline. If you run EBS, this is the most operationally disruptive patch you’ll schedule this quarter.

What changed

CVE-2025-61884 is a server-side request forgery in the return_url parameter of UiServlet. The parameter isn’t sanitized, so an unauthenticated attacker can make the EBS application tier issue arbitrary HTTP requests. On its own, that’s a CVSS 7.5 information disclosure. Cl0p didn’t stop there.

Mandiant documented the full chain: SSRF into CRLF injection into authentication bypass into XSL template injection (separately tracked as CVE-2025-61882) into code execution as the applmgr user. Five links, each individually survivable, collectively devastating. The applmgr account owns the EBS application tier, which means the attacker lands with read-write access to every functional module the instance serves.

Exploitation began in July 2025. By late September, Cl0p extortion emails were reaching executive inboxes at over 100 organizations. Named victims include Mazda, Canon, Michelin, Grupo Bimbo, Worley, and MAS Holdings. The campaign used custom tooling (GOLDVEIN, SAGEGIFT, SAGELEAF, SAGEWAVE per Mandiant/FIN11 tracking) and followed the Cl0p playbook: data exfiltration first, not encryption. They targeted HR, finance, and procurement data. ShinyHunters leaked a proof-of-concept on Telegram on October 3, eight days before Oracle published the out-of-band security alert.

CVE-2025-61882 plays a dual role here: it’s both a step in the RCE chain (the XSL template injection stage) and the target of a separate exploitation wave hitting the SyncServlet endpoint in August. Some sources conflate the two CVEs. They’re separate vulnerabilities, separately patched. If you’re tracking remediation, you need both.

What it means for your environment

EBS is not an edge application. It’s the connective tissue of the organization: HR records, financial reporting, procurement workflows, supplier portals, banking integrations. A compromised EBS instance doesn’t just leak data from one department. It leaks the data that ties departments together.

Censys counted roughly 1,048 internet-facing EBS instances, 409 of them in the United States. The affected industries skew toward exactly the organizations that can least afford a data breach: manufacturing (14%), government (12%), holding companies (11%), and technology (9%). If your EBS instance is internet-facing, even through a reverse proxy, you were in the blast radius during the 90-day zero-day window.

The SSRF-to-RCE chain is why the CVSS 7.5 score understates the operational risk. A 7.5 SSRF in a standalone web app is one thing. A 7.5 SSRF in your ERP system, where the application tier has trusted access to your RDBMS, your LDAP directory, your payment integrations, and possibly your cloud IMDS endpoint, is categorically worse. Cl0p understood this. They didn’t need to escalate privileges beyond applmgr because applmgr already has the keys.

This is the third Oracle EBS entry in the CISA KEV catalog in roughly three years, after CVE-2022-21587 (February 2023) and CVE-2025-61882 (October 2025). The SAP CVE-2025-31324 campaign (CVSS 10.0, 500+ compromised organizations per Onapsis) is the closest parallel. The common thread is architectural: these are monolithic systems built when perimeter security was considered adequate, now exposed to the internet with 20 years of accumulated trust assumptions baked into their internal communication patterns.

What you need to do

Apply patches 38512809 and 37614922. The first patch adds an allowlist to the Configurator’s URL handling. The second stubs out ieshostedsurvey.jsp, which was part of the attack surface. Both are required. Integrigy flagged that 12.1.3 is also affected, so don’t assume older branches are safe just because they’re not in Oracle’s initial advisory scope.

Plan for the testing cycle. This is where EBS patching diverges from patching a standalone appliance. Oracle EBS patches routinely require 2 to 4 weeks of regression testing against your customizations. If you’ve extended the Configurator module, the allowlist patch (38512809) is the one most likely to conflict. Your custom URL integrations may need to be added to the allowlist manually.

Plan for the downtime. EBS patching typically requires 4 to 12 hours of application downtime, depending on your environment’s complexity and how many custom patches are stacked. This isn’t a rolling restart. Your users lose access to the ERP for the duration. That means scheduling around payroll runs, month-end close, and procurement cycles.

If you can’t patch immediately, deploy compensating controls now:

• WAF rules on UiServlet. Block or inspect requests to /OA_HTML/configurator/UiServlet with URL-encoded characters in the return_url parameter. This is a temporary measure, not a fix, but it raises the bar.
• Network segmentation. If your EBS application tier can reach your cloud IMDS endpoint (169.254.169.254), the SSRF can harvest instance credentials. Enforce IMDSv2 (which requires a PUT-based token exchange the SSRF can’t easily perform) or block IMDS access from the application tier entirely.
• Restrict internet exposure. Put EBS behind a VPN or IP allowlist. If the Configurator UI must be externally accessible for supplier self-service, scope the exposure to known partner IP ranges.

Detection indicators from Mandiant: Look for requests to TemplatePreviewPG with TemplateCode parameters prefixed by TMP or DEF followed by a 16-character hex string. Watch for HTTP/1.2 protocol anomalies (legitimate clients don’t send HTTP/1.2). Monitor for CSRF-XHR: YES and FETCH-CSRF-TOKEN: 1 headers in UiServlet requests. Any of these in your web server logs between July and October 2025 warrant an incident investigation, not just a patching ticket.

The window

CISA’s November 10 deadline gives federal agencies 21 days from KEV addition. For EBS, that is an extremely tight timeline. A responsible EBS patch cycle (test customizations, validate in a non-prod clone, schedule downtime around business cycles, apply, smoke-test) takes 2 to 4 weeks under normal conditions. CISA is asking you to compress that into three.

If you’re a federal agency or contractor bound by BOD 22-01, start the testing cycle now. If testing reveals conflicts with your customizations, the compensating controls above buy you time, but they are not a substitute for the patch. The PoC is public. The tooling is documented. Cl0p has already demonstrated the full chain against production environments.

For everyone else, the math is the same even if the compliance deadline isn’t. Your EBS instance holds the data an extortion group values most: employee PII, financial records, supplier contracts, payment details. Cl0p’s campaign proved the chain works. The only question is whether your instance was in the first wave or gets caught in the long tail.

Oracle EBS patching is painful. It has always been painful. The 4-to-12-hour downtime window, the customization regression testing, the change board negotiations. None of that changes because an extortion group found an SSRF. But the cost of not patching changed in July, when Cl0p proved that a single unsanitized parameter in a URL handler can unravel an entire ERP deployment. That’s why this hit your inbox today.