Estée Lauder confirms Cl0p Oracle EBS breach, 11mo dwell

Confirmed reporting via BleepingComputer, 2026-07-20. Estée Lauder issued a customer notification letter on 2026-07-20 disclosing that an unauthorized third party accessed its Oracle E-Business Suite HR instance on or around 2025-08-09, and that the intrusion was not identified until 2026-06-19. Confidence: high — the timeline is stated in the company’s own notification, quoted by BleepingComputer.

The initial-access vector is CVE-2025-61882, an unauthenticated remote-code-execution flaw in the BI Publisher Integration component of Oracle E-Business Suite versions 12.2.3–12.2.14. The Cl0p ransomware/extortion crew has been documented exploiting it since early August 2025, per BleepingComputer’s timeline. Confidence: high on the CVE, high on Cl0p attribution as reported.

Timeline as stated

• 2025-08-09 — Unauthorized access to the EBS instance begins, per Estée Lauder’s notification letter.
• ~early August 2025 — Cl0p mass-exploitation of CVE-2025-61882 in the wild, per BleepingComputer.
• 2026-06-19 — Estée Lauder determines through investigation that access occurred. Roughly 315 days after the intrusion.
• 2026-07-20 — Customer notification letter goes out.

Eleven months between initial access and discovery is the number to hold onto. That is not a detection latency of hours or days; that is roughly the length of an entire fiscal reporting cycle in which an unauthorized party had reach into an HR-of-record system.

What the letter says was taken

Estée Lauder’s notification, as quoted by BleepingComputer, lists:

• Full names
• Postal addresses
• Email addresses
• Dates of birth
• Social Security numbers
• Passport numbers
• Financial account information, including bank account numbers
• Health information
• Employment information, including payroll and performance reports

That is a complete HR-record disclosure, not a fragment. The letter does not specify a victim count — unconfirmed — treat accordingly. The population is a subset of Estée Lauder personnel whose records lived in the affected EBS instance, not necessarily the customer base named in the letter’s addressing.

What the CVE is

CVE-2025-61882 sits in the BI Publisher Integration component of Oracle E-Business Suite. Per NVD, it allows an unauthenticated network attacker to bypass authentication and execute code remotely. CVSS 9.8 — the maximum score short of the “kinetic” category. Confirmed reporting: yes. Weaponized in the wild: yes, since August 2025. Public PoC: not linked here, and 0dayNews does not reproduce exploitation steps — see the NVD entry and the Oracle security-alert page for the vendor advisory.

The affected version range (12.2.3–12.2.14) is standard enterprise-EBS territory. Any organization running an unpatched instance in that band that was reachable in August 2025 should treat itself as having been in the same target set as Estée Lauder, not as an exception.

Distinct from the July 15 EBS story

This is not the same CVE 0dayNews covered on July 15. That piece — CISA KEV: Oracle EBS Payments 9.8 unauth RCE lands — was about CVE-2026-46817 in the Oracle Payments/File Transmission module, patched in the May 2026 CPU and added to KEV on 2026-07-15. Two separate vulnerabilities, two separate EBS components, two separate patch cycles.

The pattern under both stories is the same: EBS is Internet-adjacent at more organizations than it should be, and both the Payments and BI Publisher Integration modules have now produced unauthenticated RCE at CVSS 9.8 inside a single quarter.

What to do

• Confirm patch state on CVE-2025-61882 specifically. If the running EBS build is in the 12.2.3–12.2.14 range and the fix for CVE-2025-61882 has not been applied, that is priority one — the exploit has been circulating for eleven months.
• Treat unpatched-and-exposed as breached, not “at risk.” The Estée Lauder timeline is a live example of what “detection latency” looks like in practice against this specific attacker against this specific bug. If your EBS instance was reachable and unpatched during the Cl0p mass-exploitation window, absence of evidence is not evidence of absence.
• Pull HR-instance access logs from August 2025 forward. Focus on unusual BI Publisher activity, unfamiliar service or admin accounts, and outbound data flows sized to match HR-record extraction. The BleepingComputer writeup is explicit that HR was the affected use case at Estée Lauder.
• Do the same review on the Payments module. Different CVE, same vendor, same quarter. Assume both are being probed.
• File the letter’s data-category list as a scoping template. SSNs plus passport numbers plus bank account numbers plus health information plus performance reports is the maximum-blast-radius HR profile. If your EBS HR instance was in-scope, that is what an attacker could have pulled.

What we still don’t know

• Victim count. Not disclosed in the notification excerpt. Unconfirmed.
• Whether Cl0p published Estée Lauder data. The BleepingComputer writeup does not confirm a leak-site listing. Unconfirmed.
• Whether the intrusion moved beyond the EBS instance. The notification is scoped to the EBS system; lateral movement into other Estée Lauder environments is neither confirmed nor ruled out.
• How the intrusion was found in June 2026. “Determined through our investigation” per the letter — trigger unstated. Unconfirmed.
• Full population of Cl0p CVE-2025-61882 victims. Estée Lauder is one confirmed name. The mass-exploitation framing implies others; those disclosures are not yet in this feed.

Sourcing

• BleepingComputer: Estée Lauder discloses data breach via Oracle E-Business flaw — 2026-07-20
• NVD entry: CVE-2025-61882
• Oracle security alerts: oracle.com/security-alerts
• Related 0dayNews coverage: CISA KEV: Oracle EBS Payments 9.8 unauth RCE lands, Progress tells ShareFile on-prem users to shut down servers