Security in the IT world has changed in the last 6 months. A lot.
With the advent of AI, a lot of acceleration has taken place in the world of security.
In April 2026, Anthropic didn’t release Mythos (generally). It is in a limited access mode to a few large, vetted software companies. Oracle got access in May 2026.
They used it to discover a lot of vulnerabilities. They also use other models – every model; Mythos, Snyck, Vulnhunter, MDASH or whatever, shows many different vulnerabilities with surprisingly low levels overlap. The all work with different algorithmic processes so that’s not a surprise but it is a concern.
What can be used to find vulnerabilities by software houses can be used by bad actors to find the same issues. A potential process could be (put into in Oracle terminology)
- Take Oracle’s current release (e.g. 19.32)
- Create a new Oracle home at (say) 19.33
- Provide an AI with access to both sets of code – you can reverse engineer binaries using an MCP like Ghidra RevA, so you don’t need to be Open Source (although its easier if the source code is publicly available, like PostgreSQL)
- Provide the AI with the list of CVE’s fixed by the new release (19.33)
- Get it to show you how to exploit those CVE’s.
So Oracle has changed their release and patching strategy.
Previously, Oracle recommended patching n-1, so patch the July Release Update (RU) when the October RU is released. This has changed. They now say patch n-0. The current release.
Moreover, the recommendation is to patch with the RU every 3 months, and then every month patch the Monthly Recommended Patches (MRP’s) or CSPU’s (Security Patches). EVERY MONTH. When it comes out.
So why the urgency? Well one reason is the speed of discovery of how to exploit a vulnerability. What used to take weeks or months is now possible in hours with AI.
Don’t believe me? Well lets look at what happened with PHP-2-Shell. An AI worked out that if it combined CVE-2026-109618 and CVE-2026-109619 that it could gain access to run commands on your computer. If it then combined that with Fragnesia, you were owned completely. Access a security server from there and you get everything… which has happened in the wild.
The first 2 CVE’s were patched on 21st October. Palo Alto’s admin interface running PHP had patches available on 30th October. Cyber Security company Dream said it observed active breaches on 25th October – 5 days before Palo Alto even released a patch. A velocity of only 4 days between initial CVE information and actual breaches. Four days when you were exposed to a known exploited vulnerability, with no patch. If there had been a patch, would you have applied it that quickly? Read more about it here.
This attack was owning the Firewall. The gatekeeper. The very thing that keeps bad actors out of your systems. And they own it before the patches are even released.
But that’s PHP. Why does that affect my Oracle database?
Many companies operate on a “hard shell” security system, assuming nobody will get inside. Some are surprisingly lax about patching software inside as a result. This hack shows that we CANNOT operate under that model any more. We need every layer internally to be as patched, as up-to-date, as we possibly can make it. Every vulnerability is up for exploitation on every level.
And what do many hackers really want? Your data. Your database. To steal or to ransom.
Think about it. And then patch. and patch. and patch.
We need to be strong at every layer, not just the hardened outer shell.
I’m not trying to scare anyone. There are solutions to most of these vulnerabilities but it needs us to work faster. To work smarter. To patch and monitor and take security seriously at every level. Make sure YOUR company is more patched than the next; the harder we make it for the bad actors, the more likely they are to move on to the easier targets and leave us alone
As for patching, well that’s an outage for many companies. Time and cost (although nowhere near as expensive as a breach and loss). For Oracle, if you are on Oracle RAC and have configured your application and connection pools to use Transparent Application Continuity (TAC), you can patch with no downtime. For many applications, this is easier than you first think. Once you understand how TAC works with your application, many can be modified to be TAC aware with remarkably low effort (large long-running batch transactions are problematic, OLTP is surprisingly easy). If you have DataGuard but not RAC, you can still use TAC to patch with a bit of a brown-out pause in many systems.
For more information about security, please read my blog post series
For more information about Oracle patching, read & subscribe to Mike Dietrich’s blog. Mike is the Oracle Vice President of Product Management and Development for Database Upgrade, Cloud Migrations and Patching.
Leave a Reply