Oracle has pushed an out-of-band security update for its E-Business Suite to silently patch a zero-day vulnerability (CVE-2025-61884) that was exposed publicly by the hacking collective ShinyHunters, reportedly without acknowledging that the flaw was actively used. The vulnerability, which allowed unauthenticated remote access via SSRF (Server-Side Request Forgery), has now been mitigated by validating and restricting an attacker-supplied “return_url” parameter. Earlier, hackers had already exploited a separate zero-day (CVE-2025-61882) to conduct wide extortion operations under the Cl0p brand, targeting Oracle EBS deployments. Analysts at Google, Mandiant, CrowdStrike, and Rapid7 confirm that the Cl0p-linked attacks date back as early as August 2025, affecting dozens of customers and leading to data theft and ransom letters. The patching timeline has raised eyebrows: Oracle released the CVE-2025-61882 update on October 4, then quietly delivered the CVE-2025-61884 fix over a weekend without public disclosure of active exploitation. The patch for 61884 now rejects malicious injection attempts through strict regex validation. Organizations using Oracle EBS versions 12.2.3 through 12.2.14 are urged to immediately deploy both fixes and hunt for signs of compromise, as attackers had already circulated proof-of-concept exploit code on Telegram and other forums.
Key Takeaways
– The ShinyHunters leak of CVE-2025-61884 forced Oracle to patch a serious SSRF exploit quietly, after attackers had already published proof-of-concept code.
– The earlier, more dangerous CVE-2025-61882 zero-day was exploited by the Cl0p ransomware group for large-scale data theft and extortion across Oracle EBS deployments.
– Oracle’s staggered approach to disclosure and patching—rolling out fixes quietly and failing to admit used exploits—has drawn criticism for its opacity during a major threat campaign.
In-Depth
In the world of enterprise software, Oracle’s E-Business Suite (EBS) is a heavyweight: critical to many organizations’ financial, supply chain, and operational workflows. So when multiple zero-day vulnerabilities begin surfacing, the risk isn’t theoretical — it becomes existential. That’s exactly the scenario playing out now, driven by the Cl0p extortion gang and a supporting cast of hacker groups (including ShinyHunters).
Let’s walk through what’s happening. First came CVE-2025-61882. This zero-day allowed unauthenticated remote code execution via HTTP in the Oracle Concurrent Processing module of EBS (versions 12.2.3-12.2.14). Its severity score is very high (9.8), and it was actively exploited before Oracle formally acknowledged it. Security watchers like CrowdStrike flagged that this was likely part of a mass campaign targeting internet-exposed EBS deployments. Attackers leveraged this to extract sensitive data from dozens of impacted customers and kick off extortion emails under the Cl0p brand. Security firms traced malicious activity back to August 2025 and even earlier, implying the intrusion campaign had stealthily matured before public exposure. Incident response recommendations rapidly followed: deploy the emergency patch, hunt for Indicators of Compromise (IOCs), and monitor for anomalous Java process or shell activities.
Then came CVE-2025-61884. This flaw was less public at first but no less serious: it allowed attackers via SSRF (server-side request forgery) to exploit the “return_url” parameter in Oracle’s UI runtime component. ShinyHunters leaked a proof-of-concept exploit that revealed how this vulnerability could be chained into server access. Oracle responded with a weekend security update that sanitized the “return_url” input using strict regex validation. Notably, Oracle did not overtly acknowledge that the vulnerability had been exploited in the wild before patching.
What’s unsettling is Oracle’s method: the patch for the first zero-day (61882) was made public with advisory, IOCs, and a call for urgent deployment; for the second (61884), the update was quietly slipped in without disclosing exploitation history. That discrepancy has raised eyebrows in security circles: is this defensiveness or a calculated move to avert panic? Either way, organizations running EBS are now in a race against time.
For any enterprise still running one of the affected EBS versions, the course is clear: patch immediately, deploy all available mitigations, hunt for signs of compromise (especially around servlet endpoints like UiServlet and SyncServlet), monitor for suspect network behavior, and maintain strict segmentation and access controls. Given that exploit code is already circulating publicly, unpatched systems are sitting ducks. This situation also underscores a broader trend: modern attackers now target enterprise software directly, exploiting flaws faster than many organizations can even detect — let alone respond.