Helix Ultimate's Third Joomla 3 Patch Since JoomShaper Said There Would Be None

TL;DR: JoomShaper published a third Joomla 3 security patch for the Helix Ultimate template framework on 27 August 2026, after announcing in July that its Joomla 3 products would receive “No security patches, regardless of severity.” The patch contains genuine fixes, including an access-control bypass reachable without logging in, and the company emailed customers the same day with a stated severity of High to Medium. It is not the whole release, though: three of the twelve security fixes in the Joomla 4, 5 and 6 build did not reach it, and one of the three is in a file the Joomla 3 package ships and the Joomla 5 and 6 sites never load. This post is about the Joomla 3 package only. The problem with it is delivery: the patched system plugin and template both report version 2.1.4-j3sec, the same string the July build reports, so Joomla’s updater will never offer them and no tool can tell a patched site from an unpatched one. The patch package also deletes its own extension record when it installs, leaving nothing behind for Joomla to check. Across the Joomla 3 sites we manage that run Helix Ultimate, about four in ten report that version string, and every one of them first reported it before this release existed.

On 9 July 2026 JoomShaper announced that the Joomla 3 builds of all its products were finished. One line did the damage: “No security patches, regardless of severity.” Six days later the company shipped Joomla 3 security patches anyway. A week after that it shipped another. Today it shipped a third.

Shipping the patches is the right call, and we have said so each time. Joomla 3 runs more than half the live Joomla web, and a vendor that keeps patching it despite saying it would not is doing its users a favour. But the third release has a problem the first two did not, and it is the kind of problem that quietly undoes the patch: on Joomla 3, the fixed files report the same version number as the broken ones.

That matters because version numbers are how everything downstream decides whether you are safe. Joomla’s updater compares them. Extension inventories record them. Our own scanner reads them off every site in your account. When the patched build and the vulnerable build both say 2.1.4-j3sec, every one of those systems gives the same answer for both, and that answer is wrong half the time.

This is a Joomla 3 problem only. Sites on Joomla 4, 5 and 6 get the same security work through the normal Joomla updater, and we have covered that release separately. Everything below is about the Joomla 3 route.

What Does the Third Joomla 3 Patch Actually Fix?

These are not our findings. JoomShaper ran its own security pass on the Joomla 4 and 5 line, and this release backports that work into the Joomla 3 build. We did not discover or report any of it. What follows comes from reading the published code difference between the July and August releases, so we can tell customers what changed rather than take a changelog on trust.

The most serious item is an access-control bypass that needed no login at all. Before this release, adding ?helixMode=edit to any URL on a Helix Ultimate site did two things for an anonymous visitor. It skipped the Coming Soon redirect entirely, so an unlaunched site was served in full to anyone who knew the parameter. And it made the framework load template settings from the draft cache instead of the saved ones, so the visitor saw the administrator’s unsaved work-in-progress design. Both now require an account with template edit rights.

The rest is real but narrower:

• Mega menu writes are now scoped to one menu. The saveMegaMenuSettings endpoint checked only that you could edit menus somewhere. Anyone who passed that check could rewrite the mega menu settings of any menu item on the site. It now checks permission against the specific menu the item belongs to.
• Media path resolution got proper canonicalisation. The old check cleaned the path and compared it as a string against the allowed roots. String comparison does not follow symlinks, so a symlink inside the images folder pointing elsewhere passed the test. The new code resolves the real path first and rejects null bytes.
• Image uploads are now decoded, not just named. Uploads are checked with getimagesize, finfo and a full decode, instead of trusting the file extension.
• The Page Title feature escapes its output. Heading tags come from an allowlist, background colours must match a hex pattern, and the background image URL is quoted and escaped before it reaches the style attribute.

That is a decent list, and the release notes describe what is in the package accurately. What they do not say is what is missing from it. JoomShaper also emailed customers the same day with a stated severity of High to Medium and told Joomla 3 users to download this package and install it by hand, which is the correct instruction and more communication than most Joomla extension vendors manage.

Three of the Twelve Fixes Did Not Reach Joomla 3

The Joomla 4, 5 and 6 release this package backports from, Helix Ultimate 2.2.10, itemises twelve security fixes in its release notes. Nine of them are in the Joomla 3 build. Three are not.

We checked this by downloading the July and August Joomla 3 packages and unpacking both, rather than reading either changelog, because the version string is no help here and the changelogs describe different products.

The Draft Cache Still Takes a Style’s Identity From the Request

On Joomla 4, 5 and 6, the function that writes a template style to the draft cache now looks the style up in the database by its ID and takes the template name from that record, stripped to letters, digits, underscores and hyphens. That matters because the stored name ends up in a filesystem path when the draft is read back. The Joomla 3 build still lifts id, template, client_id, home and title out of the POST body, exactly as the July build did. The only change to that function since July is unrelated: five fields including custom_css and custom_js are now read raw, so custom CSS and JavaScript survive being drafted.

Frontend Article Saves Are Not Checked Against the Article

The mainline release added an ownership check to the hook that merges Helix’s own settings into an article when it is saved from the front end, so that a user has to be allowed to edit that specific article. The Joomla 3 build has the function that answers that question, Helper::canEditArticle(), and calls it from exactly one place: the image removal endpoint. The article save hook does not call it. In the July build the function existed and nothing called it at all.

The Image Layouts Are Still Unescaped, and These Are the Joomla 3 Ones

This is the one that stings. In the main repository the fix went into overrides_legacy, the layout set Helix Ultimate serves to Joomla 4 and below, changing <img src="<?php echo $full_image; ?>"> so the value runs through htmlspecialchars first. The Joomla 3 package ships that same file at overrides/layouts/joomla/content/full_image.php, identical apart from one unrelated line, and it is unchanged from July. intro_image.php is the same story. The value written into the attribute is the article’s own helix_ultimate_image, so anyone who can edit an article sets it. So the 2.2.10 package that Joomla 5 and 6 sites install contains the fixed files, and those sites never load them. The Joomla 3 package, whose sites do load them, ships the unfixed copy.

None of the three is the headline flaw, and the bypass that is the headline flaw was backported properly. But a Joomla 3 site owner working from JoomShaper’s changelog has no way to tell that three of the twelve entries describe a package they were not given.

The Helix Ultimate Version Number Did Not Change, But the Code Did

We flagged the shape of this in July, when the first Joomla 3 patch went out. That post warned that the package patches files to a 2.1.4-j3sec baseline and then removes itself, so a patched site does not obviously look different from an unpatched one, and told people to write down what they patched because the version number would not tell them later. What has changed is that it has now happened three times. The same string covers three different payloads, so it can no longer separate a patched site from an unpatched one, or one patch round from another.

The August release ships three files. One is the patch package, helixultimate_j3_security_fixes_v1.0.2.zip, which went from 1.0.1 to 1.0.2 as you would expect. The other two are the framework itself: the system plugin and the starter template. Both of those are still called 2.1.4-j3sec, which is what the July release called them.

The contents are different. We downloaded both releases, unpacked the system plugin from each, and compared the trees:

$ diff -rq jul/plg_system_helixultimate aug/plg_system_helixultimate
Files .../src/Platform/Blog.php differ
Files .../src/Platform/Helper.php differ
Files .../src/Platform/Media.php differ
Files .../src/HttpResponse/Response.php differ
Files .../src/fields/helixmegamenu.php differ
Files .../layout/megaMenu/container.php differ
...
118 differences in total

Both of those packages declare 2.1.4-j3sec. One of them has the access-control bypass fixed and one does not, and nothing on the site can tell you which you have.

A smaller oddity from the same check, offered as an observation rather than an accusation: the three files attached to the July release do not match the SHA256SUMS published alongside them. The August release verifies cleanly. The likeliest explanation is that the checksum file was generated from a different build of the same source than the one uploaded, which is the sort of thing that happens when a release is assembled quickly.

How Many Joomla 3 Sites Are Affected?

We track every extension and its version on every Joomla and WordPress site in our customers’ accounts, which is how we can answer this rather than guess at it.

Across the Joomla 3 sites we manage that run the Helix Ultimate system plugin, about four in ten report version 2.1.4-j3sec. The rest are spread across older builds, mostly the 1.1 and 2.0 lines, and some of those go back years. Those older sites never took a Joomla 3 patch at all, which is its own problem, and one made worse by our having wrongly told people in July that the patch would refuse to install on them.

Then we checked when each of those sites first reported that version string. Every one of them reported it before the August release went out. Not one site in the accounts we monitor has picked up the new build, which is unsurprising a few hours after publication. But it is the whole problem in one line: every site that reports the version number of the fixed build is running the code of the broken one.

Why Will Joomla Never Offer This Update?

Three separate things stop the update reaching a site, and they compound.

The Version Number Is Identical

Joomla’s updater asks whether the available version is newer than the installed one. 2.1.4-j3sec is not newer than 2.1.4-j3sec, so the answer is no, forever.

The Update Feed Still Points at July

JoomShaper’s update feed has three entries. The patch package entry was correctly bumped to 1.0.2 today. The system plugin and template entries were not touched: both still declare 2.1.4-j3sec and both still link to the j3-security-v1.0.0 download from July. A site that does poll the feed is offered the old file.

The Patch Package Deletes Itself

This is the one that surprised us. The installer’s postflight method ends by calling uninstallPackage(), which removes the package’s own row from Joomla’s extensions table. The design intent is clear enough: apply the fixes, leave no permanent extension behind. The side effect is that Joomla loses the extension record and the update site along with it, so there is nothing left to check for a 1.0.2.

Across every site in every account we monitor, the helixultimatej3securityfixes package has never once been recorded as installed. Not on the sites that plainly did apply it, which are sitting there reporting 2.1.4-j3sec. The package works exactly as designed and erases the evidence that it ran.

That also means the advice in JoomShaper’s own July release notes cannot work. The 1.0.1 notes tell users to go to Extensions, then Manage, then Update. For the package those notes describe, there is nothing in that list to update.

Today’s customer email gets this right, and tells Joomla 3 users to download the ZIP and install it by hand instead. That is the correct instruction. It is also the only one that can work, which is the part the email does not explain.

The Second Joomla 3 Patch Advertised a File It Did Not Serve

The July round has its own version of this problem, visible in the same feed.

From 22 July to 27 August, the feed declared version 1.0.1 for the patch package while the download URL underneath pointed at helixultimate_j3_security_fixes_v1.0.0.zip. The 1.0.1 package existed and was attached to the GitHub release. The feed just never pointed at it.

For five weeks, any site that was offered that update and took it downloaded the 14 July build. Joomla would have installed it, recorded version 1.0.0 from the manifest, and offered 1.0.1 again on the next check. Today’s release fixed the URL as a side effect of bumping it to 1.0.2, so the 1.0.1 package was effectively never distributed through the channel built to distribute it.

What the Helix Ultimate Patch Leaves Unfinished

We read the whole difference. Four things stop short of what the changelog claims.

The image removal endpoint now checks that you are allowed to edit an article before it deletes a file. It takes the article ID from the request, and never checks that the file being deleted has anything to do with that article. An author who owns one article can pass that article’s ID along with the path to any image under the site’s media folders, and the check passes. The authorisation is real, but it is guarding the wrong thing.

The Page Title fix escapes its background image URL twice, once into a cleaned variable and again on the way out. Any legitimate image URL containing an ampersand comes out mangled. It is a cosmetic bug rather than a security one, but it is a sign of how quickly this went out.

The same background image pattern the Page Title feature just fixed is still there, unescaped, in the template’s main index.php, where the body background and reading progress bar settings go straight into a stylesheet declaration. Those values can only be set by someone who can already edit template settings, so the risk is low. It does mean the escaping work was a spot fix on one file rather than a sweep across the framework.

Finally, the release adds a saveLicenseInfo function to the framework’s helper class, with a changelog bullet describing it as a security fix and a test asserting that its source code mentions the right database table. Nothing in the codebase calls it. It is dead code with a test that checks its spelling.

The July Flaws Did Get CVEs. This Round Has None Yet.

When we wrote about Helix Ultimate 2.2.7 in July we said no CVE had been assigned. That has since changed, and we have updated that post.

The Joomla CNA assigned two numbers on 13 July 2026:

• CVE-2026-57829, unauthenticated stored XSS in Helix Ultimate below 2.2.7. CVSS 4.0 base score 8.7, High.
• CVE-2026-57830, unauthenticated arbitrary file deletion in Helix Ultimate below 2.2.7. CVSS 4.0 base score 8.8, High. NVD scored the same flaw 9.1 Critical under CVSS 3.1.

Nothing has been assigned for the August round. We would read that as the paperwork not having caught up rather than a judgement on severity, and numbers can still be assigned later by a researcher or by the Joomla CNA. No CVE today is not the same as no CVE ever.

Fifteen CVEs have been published against JoomShaper products, and eleven of them arrived in July and August 2026 alone, across SP Page Builder, EasyStore and Helix Ultimate. This is a vendor under sustained security scrutiny, doing a lot of remedial work at speed. The speed is showing in the delivery.

What Should You Do With Your Joomla 3 Helix Ultimate Sites?

Start by finding them, because most people underestimate how many they have. Every Joomla 3 site running the Helix Ultimate system plugin or the shaper_helixultimate template needs this, and the sites most likely to be running it are the ones nobody has logged into for two years.

Then apply the current patch, whatever the version number says. Because you cannot tell from the outside whether a site has the August build, the safe assumption is that it does not. Download helixultimate_j3_security_fixes_v1.0.2.zip from the release, verify it against the published SHA256SUMS file, and install it through Extensions, then Install. Re-applying it to a site that already has the fixes is harmless.

One change since the first Joomla 3 patch is worth knowing. That release refused to install on older Helix builds, which left a lot of 1.1.x and 2.0.x sites with no vendor option at all. The current installer only rejects versions above 2.1.4-j3sec and no longer enforces a lower bound, so older builds that were turned away in July will now accept it.

After patching, check the site rather than assume. The access-control bypass exposed unlaunched sites and draft settings, and the mega menu write reached menus the user had no business touching. Look at your Joomla Users list for Super User accounts you do not recognise, review your mega menu and template settings for entries you did not add, and check your media folders for files you did not put there.

Then keep the three missing fixes in mind, because patching does not deliver them. All three need an account on the site to reach, so the exposure is your author and editor accounts rather than the open internet. On a Joomla 3 site where article editing is limited to people you trust, that is a low risk to accept while you plan the migration. On one with open registration or a large contributor list, it is not.

Doing This Across an Account

If you look after more than a handful of Joomla sites, the finding part is the expensive bit, and it is what mySites.guru is for. Search for Helix Ultimate once in your mySites.guru account and you get every site running it, the version each one reports, and the Joomla version underneath, without logging into anything. That is the same inventory the figures earlier in this post came from.

For Joomla 3 sites specifically, mySites.guru has a one-click patch for the abandoned JoomShaper extensions. The Unpatched JoomShaper Security Holes toggle in the Hacked? section of a site’s Snapshot applies the fix logic in place, across Helix Ultimate, Helix3 and SP Page Builder, on every site in your account rather than one at a time. It takes a backup of the original files first, so switching it off restores them.

Neither of those makes Joomla 3 supported again. Migration is still the only real answer, and everything here is a way of holding a site safely while you get budget and sign-off for the move. If a Joomla 3 site has already been compromised, patching will not clean it: fix.mysites.guru handles that for a single fixed fee of GBP 120 per incident, usually same day, and we screen the site before committing so you are not charged in the rare case it cannot be fixed.

The Bottom Line

JoomShaper said it would ship no Joomla 3 security patches regardless of severity, and has now shipped three. That is the right outcome, arrived at awkwardly, and the code in this one is real work that closes a bypass anyone on the internet could have used. It stops three fixes short of the release it backports, and the shortfall is not written down anywhere.

The delivery undermines it. A security fix that ships under the version number of the flaw it fixes cannot be detected, cannot be offered by the updater, and cannot be audited across a portfolio. Every Joomla 3 site running this framework reports a number that means two different things, and the only way to resolve the ambiguity is to patch it again and know for certain.

If you manage Joomla sites for clients, find every Helix Ultimate install you look after and treat all of them as unpatched. Start with a free audit on one site to see what your Joomla 3 exposure actually looks like.