Keep your Oracle APEX up-to-date in the AI era

This week Oracle released the October 2026 Critical Patch Update, and it contains a really bad one for Oracle APEX.

A 9.8 out of 10, exploitable over HTTPS, without logging in. Somebody who finds your APEX URL can take over APEX completely.

And it’s not just APEX. The same week, PHP had one of the worst security releases in its history. Two flaws, nicknamed PHP2Shell (CVE-2026-109618 and CVE-2026-109619), allow remote code execution without logging in on basically every PHP installation that serves web pages. That means WordPress, Drupal, Joomla and almost anything else built on PHP.

What struck me most:

• The researchers at Wiz, a cloud security company that published how the exploit works, said frontier AI models “substantially reduced” the effort to turn this decades-old flaw into a working exploit.
• Amazon saw a first exploitation attempt four days before the fix was public, and Unit 42 found over 22.6 million potentially vulnerable instances.
• Attackers used agentic AI platforms after breaking in. At a European government entity they had password hashes and MFA secrets within two hours.
• Here in Belgium, the Federal Public Service Foreign Affairs took its websites offline as a precaution, and governments in Germany, France, the Netherlands, Finland and the Czech Republic pulled sites too. Our Centre for Cybersecurity said it had seen no attacks on Belgian sites, but when a government’s answer is “turn it off”, you know it’s serious.

I believe this is only the start.

As an Oracle APEX developer I was happy, for once, that none of our stack runs on PHP. But the bigger reason I’m glad we’re on Oracle APEX is that there’s a vendor behind it with a security team and a regular patch rhythm:

• Oracle Database gets a Release Update every quarter, in line with the Critical Patch Updates (January, April, July, October). On Linux, 19c and 26ai also get Monthly Recommended Patches (MRPs) on top of the Release Update, and on other platforms there are Critical Security Patch Updates (CSPUs) for urgent security fixes. Mike Dietrich explains the difference on his Upgrade your Database - NOW! blog, and his advice is to go to the latest Release Update plus the latest MRP.
• Oracle APEX is not tied to the database release. You install and upgrade it separately, and Oracle ships a Patch Set Bundle whenever there’s something to fix, not just once a quarter. So you can be on the latest APEX patch even when your database upgrade is still months away.

All of that is only worth something if you actually install the patches, though.

Why this is different now

For years, a lot of companies treated Oracle APEX upgrades as “nice to have”. The app works, the users are happy, why touch it? Patching happened once a year, or when somebody had time.

That worked (sort of) because finding a vulnerability and turning it into a working exploit took time and skill.

AI changed that.

The same AI models I use every day to build apps are very good at reading code, finding bugs and explaining how to abuse them. What used to take a skilled person weeks now takes somebody with a prompt an afternoon. When Oracle publishes a security advisory, you should assume someone has a working exploit soon after, if not the same day.

So the window between “Oracle released a fix” and “someone is attacking unpatched systems” is getting very small.

I think there is only one real answer: keep current. Not only Oracle APEX, but your whole environment: ORDS, the database, Java, the web server or load balancer in front of it, and the plug-ins and libraries in your apps.

What’s in the October 2026 CPU for Oracle APEX

There are two Oracle APEX vulnerabilities, and they don’t affect the same versions:

CVE	Score	What	Affected versions
CVE-2026-101521	9.8	No login needed, over HTTPS, full takeover of APEX	24.1.0–24.1.21, 24.2.0–24.2.20, 26.1.0–26.1.4
CVE-2026-66010	6.1	Flaw in DOMPurify (the HTML-cleaning library APEX uses), needs user interaction	24.1.0–24.1.19, 24.2.0–24.2.18, 26.1.0–26.1.2

The details are in Oracle’s risk matrix and the security blog post.

The same CPU has 35 patches for ORDS (24.2.0 up to 26.2.2). Eleven of them can be exploited without logging in, the worst one scores 8.8. So patching APEX alone is not enough, ORDS needs an update too.

Philipp Hartenfeller called it “really bad”, and I agree.

Which version should you be on?

After this CPU, these are the versions I consider safe:

• 24.1.22
• 24.2.21
• 26.1.5
• 26.2

Anything else has known issues. Either it’s an older patch level of a supported release (patch it), or it’s a release that is not supported anymore and won’t get a fix at all.

And keep the support dates in mind. Oracle supports a release for roughly 18 months, and only the current release plus the two before it:

Oracle APEX release	Support ends
26.2	April 2028
26.1	November 2027
24.2	July 2027
24.1	December 2026
23.2	May 2026 (ended)

If you’re on 24.1, patching to 24.1.22 fixes this CVE, but support ends in two months. I would use this moment to plan the upgrade.

Anything before 24.1 is unsupported, and Oracle is not going to provide a patch for it. Don’t read the affected versions in the advisory as “23.2 is fine”. Oracle only lists the releases it still supports, so older releases simply aren’t assessed. I would assume they have the same security issues, and they will stay open. If you’re on 23.2 or older, the only fix is to upgrade.

Sources: Oracle APEX and the Oracle Lifetime Support Policy.

How to check your versions

You’d be surprised how many teams don’t know which patch level they run. In the Oracle APEX Builder, click the help icon and About, or in SQL:

select version_no from apex_release;

select patch_number, patch_version, installed_on
  from apex_patches
 order by installed_on desc;

version_no gives the full patch level, for example 26.1.4, and apex_patches shows when which patch was installed.

For ORDS, run this on the server:

ords --version

or check it in the database (the view is granted to PUBLIC):

select version, previous_version, updated_on
  from ords_metadata.ords_version;

This gives you something like 26.3.0.r2721811.

Do this for every environment: development, test, production, and that one forgotten instance somebody set up years ago. That forgotten one is usually the one that’s exposed.

Patch or jump to 26.2?

26.2 is not affected by the 9.8 vulnerability, so it’s tempting to go there directly. But it’s not always the simplest move today:

• 26.2 is on-premises only at the moment.
• Some features are gone, for example the Advisor and SQL Workshop RESTful Services. Check if you rely on them.
• You want to test your apps and plug-ins first. In my upgrade from 24.1 to 26.1 I ran into a metadata issue I didn’t expect.

So my advice: patch now, upgrade smart. Apply the patch set for the release you’re on this week. Then plan the move to 26.2 properly, with a test environment and a checklist, instead of doing it in a hurry.

Make it a habit

The real lesson is not this one CVE. There will be another one next quarter, and with AI in the picture, probably more than before.

What I recommend:

• Know what you run: an inventory of Oracle APEX, ORDS, database and Java versions for every environment.
• Follow the Oracle Critical Patch Updates: they come out quarterly (January, April, July, October), plan the patch window upfront.
• Don’t stay more than one release behind on Oracle APEX. Upgrades are much easier in small steps.
• Keep an eye on the libraries and plug-ins inside your apps too. CVE-2026-66010 is in DOMPurify, not in Oracle’s own code.
• Have a quick smoke test for your apps, so patching becomes boring routine instead of a risky project.

If you don’t have the time or people to do this, at United Codes we added this to our Oracle APEX health check: we check your versions, patch Oracle APEX and ORDS, run smoke tests, and look at how ready you are for 26.2, including APEX Office Print and plug-in compatibility.

But whoever does it, please patch this week.