Last week I reviewed a client's SaaS inventory and found an Oracle E-Business Suite instance still running a version from 2019. It was not their fault. They inherited it from a parent company acquisition three years ago, nobody from the old IT team was still around, and the EBS system was running a batch job once a month that nobody wanted to touch. It was in the corner, doing its thing, invisible to the monthly patching cycle because everyone assumed someone else owned it.
Then on 21 July, Help Net Security reported that Estee Lauder had disclosed a data breach tied to a vulnerability in Oracle E-Business Suite. The same product. The same class of unpatched edge case that sits in a stack because replacing it would cost more than leaving it.
"The interesting part is not the lipstick brand. It is that the same vulnerability class keeps turning up in the SaaS stacks SMBs inherit from a parent company, an integration partner, or a 2018 procurement decision."
If you run Oracle EBS, Workday, Salesforce, or any enterprise SaaS platform that was set up before your current team arrived, this post is the one-hour audit I wish someone had handed me three years ago.
What Estee Lauder confirmed
On 21 July 2026, Help Net Security reported that Estee Lauder sent breach notifications to affected individuals after discovering a security incident tied to a vulnerability in Oracle E-Business Suite. The filing with the Texas Attorney General's office confirmed that customer data, including personal information, was exposed.
The key details as reported:
| Detail | Source |
|---|---|
| Breach tied to Oracle E-Business Suite vulnerability | Help Net Security, 21 Jul 2026 |
| Estee Lauder filed breach notification with Texas AG | State filing per Help Net Security |
| Customer personal data exposed | Breach notification text |
| Vulnerability class matches 2025-2026 enterprise SaaS pattern | Multiple sources |
Oracle EBS is not a niche product. It is one of the most widely deployed enterprise resource planning platforms in the world, running supply chains, financial systems, HR data, and customer records for thousands of organisations. When a vulnerability in that platform is the entry point for a breach at a company like Estee Lauder, it is not a single-incident story. It is a signal about the whole class of systems that share the same profile.
The vulnerability class that keeps hitting enterprise SaaS
The Estee Lauder incident is the latest in a pattern that has been building through 2025 and into 2026. Enterprise SaaS platforms, particularly the ones that were deployed before 2020 and have been maintained in place rather than modernised, share a vulnerability profile that attackers have learned to exploit:
-
They run on extended support timelines. Oracle EBS, like many enterprise platforms, has a long support lifecycle. Organisations that pay for extended support often skip patch cycles because "it is working fine and the upgrade would require re-certifying every custom integration."
-
They sit in a network blind spot. EBS instances are often deployed in a DMZ or a logically segmented network that the regular patching team does not scan. The team that manages vulnerability scanning may not have credentials for the EBS application layer, so the scan reports "host responsive, no known OS vulnerabilities" while the application layer goes unchecked.
-
They accumulate custom code. Most Oracle EBS deployments include custom forms, reports, and integrations written years ago by a contractor who is no longer reachable. Those custom extensions do not receive security updates, and nobody audits them because nobody remembers what they do.
-
They are inherited, not chosen. The client I mentioned at the top of this post is not unusual. EBS instances, Salesforce orgs, Workday tenants, and SAP systems are frequently inherited through acquisitions, mergers, or department-level procurement decisions that central IT never formally approved. The team that inherits them often does not know they exist until a compliance audit surfaces them.
By The Numbers
| Statistic | Detail |
|---|---|
| Date of Estee Lauder breach notification | 21 July 2026 |
| Vulnerability entry point | Oracle E-Business Suite |
| Affected data type | Customer personal information |
| Same vulnerability class active since | 2025 (at minimum) |
| Typical EBS deployment age at risk | 5+ years without major version upgrade |
The numbers are the easy part. The hard part is the question every IT-pro should be asking right now: "Do I know what version of Oracle EBS my organisation is running, and when it was last patched?"
The SMB inheritance problem
If you work in a mid-size organisation that has been through an acquisition, a leadership change, or a significant IT team turnover in the last three years, you almost certainly have an inherited SaaS platform that nobody fully owns.
I see this pattern regularly:
-
A parent company acquired a smaller business and inherited their Oracle EBS deployment. The parent's IT team runs a different stack (NetSuite, Dynamics 365, something newer). The inherited EBS system sits in a maintenance-only state because migrating the data would cost six figures and the business case never got approved.
-
A department head purchased a Salesforce or Workday instance using a departmental budget and credit card. Central IT discovered it during the next audit cycle, but by then the system had been live for 18 months with no security review.
-
A software vendor required a specific version of Oracle EBS as a dependency for their product. The integration was set up in 2018, the vendor has since been acquired, and the integration still runs on the same credentials that were created during the original implementation.
Each of these scenarios produces the same outcome: an unpatched, unowned, un-audited instance of an enterprise platform running customer data, financial records, or supply chain information with nobody watching the application layer.
The one-hour audit I would run this week
Here is the checklist I am running on my own stack this week. It takes about an hour, and it surfaces the exact class of risk that the Estee Lauder breach represents.
Step 1: Find every enterprise SaaS platform on your network
Run a network scan, check your CMDB, and talk to your procurement team. Look for: Oracle E-Business Suite, SAP ECC or S/4HANA, Salesforce (any edition), Workday, Microsoft Dynamics 365, and NetSuite. Any platform that was deployed before 2022 goes on a watch list.
Step 2: Check the patch status
For each platform, find the exact version number and compare it against the vendor's security advisory page. Oracle publishes quarterly Critical Patch Updates. If the last applied CPU is more than 12 months old, the instance is in the risk window that matched the Estee Lauder incident.
Step 3: Find the owner
Every enterprise platform needs a named owner who is responsible for its security posture. If you cannot find anyone who will say "I own that system," the system is unowned. Flag it for a security review before the next patch cycle.
Step 4: Review the integration layer
Enterprise SaaS platforms rarely sit alone. They connect to other systems through APIs, middleware, and batch data loads. Each integration is a potential entry point. Review the credentials used for each integration: are they stored in a secrets manager? Are they rotated? Do they have more permissions than the integration needs?
Step 5: Check for inherited instances
Ask your finance team for a list of all SaaS subscriptions paid by department-level budgets, not just central IT. The instances paid for by a department card are the ones that are likeliest to be unpatched and unowned. If you find one, add it to the ownership and patching review queue.
What this means for your team
The Estee Lauder breach is not a reason to panic about Oracle EBS specifically. It is a reason to check whether your organisation has the same ownership gap that produced the vulnerability window.
The organisations that will come through the next 12 months without a similar notification are not the ones with the most advanced security tools. They are the ones that know what enterprise platforms they run, who owns each one, and when each one was last patched. That is a documentation and process problem, not a technology problem. And it is fixable with a spreadsheet and a couple of hours of focused work.
Further Reading
- Help Net Security - Estee Lauder discloses data breach tied to Oracle EBS vulnerability (21 Jul 2026)
- Oracle Critical Patch Updates - Oracle (official advisory page)
- CFO.com - EY reports data breach on IT support ticket platform: Trial Balance (20 Jul 2026)
- SecureInSeconds - Your AI agent runs as you, and your vendors have agents too
- SecureInSeconds - The former employer data retention blind spot
- SecureInSeconds - How the Frontier Airlines breach shows the supply chain problem
- SecureInSeconds - Medical records stolen, Australia edition
- CISA Known Exploited Vulnerabilities Catalog
If you manage enterprise SaaS platforms or security for your team, forward this to whoever runs the next patch cycle. The one-hour audit above catches the Estee Lauder exposure path before it becomes a notification.
Mathew Clark / Founder, SecureInSeconds / Currently: chasing down an inherited EBS instance that nobody on the current team remembers buying
