YOOtheme Pro 5.0.53 Fixes an Unauthenticated RCE: Update Every Site Now

YOOtheme has released YOOtheme Pro 5.0.53, the critical security update for its Joomla page-builder template that it gave advance notice of the day before. The changelog entry names the flaw: CVE-2026-102785, “Fix unauthenticated remote code execution via image handler”. Every YOOtheme Pro 5 build from 5.0.0 to 5.0.52 is affected. Update every site running one of them to 5.0.53 or later now. YOOtheme Pro 4 and earlier are not affected.

This was the vendor’s notice to customers on 20 October 2026: “We are preparing a critical security update for YOOtheme Pro 5, scheduled for release October 21, at 4 PM CEST. All users running YOOtheme Pro 5 must update immediately once the new version becomes available. YOOtheme Pro 4 and earlier versions are not affected.” The release came out ahead of that slot, and by early afternoon UTC sites were already updating.

The score above is the Joomla CNA’s, from the CVE record published on 22 October 2026, which classifies the flaw as CWE-434 (unrestricted upload of a dangerous file type) and marks it as attacked. Before the record appeared we published our own provisional score of 9.3 Critical, taken from the vendor’s classification of the flaw as unauthenticated remote code execution. The YOOtheme entry in the Joomla Vulnerability Database has the record. Who reported the flaw to YOOtheme has not been stated.

What the YOOtheme Pro 5 Joomla template flaw is

The flaw is in the image handler, the public route YOOtheme Pro uses to generate and cache resized and cropped images. The image URLs YOOtheme Pro generates on a site’s pages point at it, and any visitor can reach it without logging in. That is what makes this different from the two earlier YOOtheme Pro 5 security releases this year, 5.0.41 and 5.0.42 in August, which each fixed flaws that needed a privileged account.

Comparing the 5.0.52 and 5.0.53 packages shows what changed. In 5.0.52 the handler let the request choose which image operations to run, and it did not tie the cache file name it writes to the signed image URL. In 5.0.53 the operations are limited to a fixed list (type, crop, resize, rotate, flip and thumbnail), and the handler checks that the cache file name matches the signed URL before writing anything. Put the two together and in 5.0.52 a request could influence both what was written and where, with no account on the site. YOOtheme calls that remote code execution, and we have no reason to disagree.

That is as far as we will go. The record had not been published and the patch was hours old when we wrote this, and a worked example would help the wrong people more than it would help you.

The image handler is a public endpoint on any site running YOOtheme Pro 5, so an unpatched site is exposed to anyone who can load a page on it. Treat every site still on 5.0.52 or earlier as exposed until it is on 5.0.53, and check it for signs of tampering once it is.

Why YOOtheme Pro 4 Joomla sites are not affected

YOOtheme’s notice says YOOtheme Pro 4 and earlier are not affected. So the first job is a version check: a site still on YOOtheme Pro 4 has nothing to do for this issue, and a site on any 5.0.x build from 5.0.0 to 5.0.52 needs the update.

YOOtheme publishes one changelog for both its Joomla and WordPress editions, and 5.0.53 is the release for both, so a WordPress site running YOOtheme Pro 5 needs the same update.

mySites.guru flags affected YOOtheme Pro 5 Joomla sites

If you connect your Joomla sites to mySites.guru, the version check is done for you. A detection rule flags every connected Joomla site running YOOtheme Pro 5.0.0 to 5.0.52, so a site snapshot raises an alert telling you to update. The rule matches both the YOOtheme template and its system plugin, because YOOtheme Pro installs as both and updating YOOtheme Pro updates both. YOOtheme Pro appears in the Joomla Vulnerability Database alongside the other extensions we track, and the alert clears once a later snapshot sees 5.0.53 or later.

If you manage more than a handful of Joomla sites, the value is one list of which sites are still on an affected build. See managing multiple Joomla sites for how the rest of the workflow fits together, and a free site audit shows the same finding on a site you have not connected yet.

The first attacks reuse droppers mySites.guru already detects

In the first sites we have seen hit, before the patch and in the hours after it, the attackers are not writing anything new. They are dropping the same files we have caught for years from JCE upload attacks: the same web shells, the same backdoors.

Because mySites.guru matches the file itself, not the route it arrived by, a site hit through this flaw shows up with no new configuration from us. An audit reads every file on a connected site and matches each one two ways. Suspect content matches on the file’s content, against our library of hand-written hack patterns, and catches a dropper the moment it is scanned, before anyone has confirmed it. Hacked files matches on the file’s hash, against the files already confirmed hacked, and an identical hash is a certain match. A dropper reused from an older campaign is already in both. Suspect content and Hacked files sets out how the two work together.

So the detection was in place before this flaw was disclosed. We did not write a YOOtheme rule for the droppers, because the checks that find these files were already running on every site we monitor.

What Joomla site owners running YOOtheme Pro 5 should do now

Update to 5.0.53 or later, on every affected site, now. There is no partial mitigation, so the update is the fix.

1. Confirm which sites run YOOtheme Pro 5. Any build from 5.0.0 to 5.0.52 is affected; Pro 4 and earlier need no action.
2. Take a fresh backup of every affected site before updating. A backup is also your record of what the site looked like before any tampering.
3. Update every YOOtheme Pro 5 site to 5.0.53 or later immediately. The flaw needs no login, so every unpatched site is equally exposed. Update them in one window rather than the important ones first and the rest next week.
4. Check each site for signs of tampering after updating. The flaw was exploitable before the patch, so look for files that should not be there, such as unexpected PHP files in images, cache or media folders, and for anything changed recently. Run a mySites.guru audit on each site and read what it finds.
5. Re-snapshot each site in mySites.guru afterwards so the alert clears and the record shows the site on 5.0.53 or later.

Joomla page builders are a high-value target when no login is needed

A template framework like YOOtheme Pro sits on every page of a site and handles uploads, images and layouts for logged-in editors. When any of that handling can be reached without a login, it becomes a public endpoint on each site that runs the extension, and attackers treat it exactly that way. The same lesson came from ZOO’s unauthenticated file upload, another YOOtheme extension, and from the long run of extension disclosures collected in a month of Joomla security disclosures.

So an available update to a template or page builder belongs on the security list, and why an extension update is a security flag makes that case in full. The window between a fix going public and the flaw being widely understood is short, so if you have been meaning to set up automatic updates for Joomla extensions, this release is a good test of whether the process you have is fast enough.