mySites.guru Blog

Phoca Gallery 6.1.6 fixes a stored XSS hidden in a photo's EXIF data

phil@mysites.guru (Phil Taylor) — Fri, 23 Oct 2026 16:39:18 GMT

On 19 October 2026 Phoca released Phoca Gallery 6.1.6, a security release for the Joomla gallery extension. The release notes say one thing about it: “This is a security release.” The Joomla CNA published the detail as CVE-2026-102786 on 23 October 2026, a stored cross-site scripting flaw through HTML attribute injection, affecting Phoca Gallery 4.5.0 to 6.1.5.

We read the 6.1.5 to 6.1.6 diff to work out what that means for a site running the extension. It means a photo can attack the person looking at it. The EXIF metadata inside an uploaded image was written into the photo’s info page without escaping, so a crafted image runs script in the browser of anyone who opens that view, and the fix is only on offer to Joomla 6 sites.

TL;DR

Phoca Gallery 4.5.0 to 6.1.5 builds the front-end photo info view from the image’s own EXIF metadata, and raw fragments of it reach the page markup
A crafted EXIF value breaks out of an HTML attribute and runs as script when anyone opens that photo’s info view, in the context of your site
The attacker needs to get an image into a gallery: back-end upload rights, or the front-end user upload feature, which is off by default
6.1.6 fixes it, and only on the Joomla 6 line. The current Joomla 5 (5.1.3) and Joomla 4 (4.5.5) releases are inside the affected range with no patched successor
Most affected sites run Joomla 6 and update normally. Joomla 4 and 5 sites have to install the 6.x package by hand or remove the component
The flaw is CVE-2026-102786, CVSS 4.0 8.6 High, published by the Joomla CNA on 23 October 2026. This is Phoca’s fix; we analysed the release after it shipped

8.6CVSS 4.0

CVE-2026-102786CVE-2026-102786: stored XSS through a gallery image's EXIF data

HighJoomla CNA

A crafted image's EXIF metadata runs script in the browser of anyone who opens that photo's info view, in the context of your site. That can hijack a logged-in session, including an administrator's.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Needs gallery upload accessFires on the photo info viewFix only on the Joomla 6 line

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:A: Active: Someone has to be talked through a few steps

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

How a photo’s EXIF data becomes script in Phoca Gallery

Phoca Gallery has a front-end info view for each image that shows the camera data stored inside the file: the EXIF block that a camera or phone writes at capture time, and that any image editor can rewrite afterwards. Part of that block is the GPS position, which EXIF stores as fractions, and the view in site/views/info/view.html.php split those fractions on the / and joined the pieces into a display string for the page.

Before 6.1.6 the pieces went into that string exactly as they were read from the file. The view expected numbers and never checked that it had them. An EXIF field that holds a quote mark and some markup instead of a number closes the HTML attribute it was dropped into, and whatever follows is parsed as part of the page. The browser runs it with the site’s own origin, for whoever opened the photo.

That is what makes this stored rather than reflected. The payload lives in the image file in the gallery, so it fires for every visitor who opens that photo’s info view until the image is removed, with nothing in the URL to give it away. An administrator who opens it from the back end hands over their session, which is why the CNA scored confidentiality and integrity both high.

The attacker’s only requirement is to get the image into a gallery. On a typical site that means an account with upload rights in the Phoca Gallery back end. If the front-end user upload feature is switched on, which it is not by default, a lower-privileged user can do it from the public side. That is the gap between the CNA’s title, which says “authenticated”, and its vector, which says no privileges required: the person who plants the image needs access, the person it fires on needs none.

What changed in Phoca Gallery 6.1.6

The fix is in one file, the info view, and it is the only functional change between the 6.1.5 and 6.1.6 tags. Each component of the EXIF fractions is now cast to a float before it is used, and a division by zero is guarded so a zero denominator no longer produces an error or an odd value. Only numeric data reaches the markup, so there is nothing left for a crafted EXIF value to break out with.

That is a narrow fix for a narrow path. It treats the GPS fields as numbers, which they are supposed to be, and it closes the attribute injection. It does not add output escaping across the rest of the view, so the release tells you which values were the problem rather than hardening the whole page, and the CNA’s description matches that scope.

What we did and did not test

This is a reading of the released code, not an attack on anyone’s gallery. We have not uploaded an image to any live site, and we are not publishing a crafted file or a working EXIF value.

Which Phoca Gallery versions are affected?

Phoca Gallery 4.5.0 to 6.1.5 inclusive, which is the range the Joomla CNA record names. Phoca maintains one release line per Joomla version, and only the Joomla 6 line received the fix:

Joomla version	Newest Phoca Gallery the updater offers	Has the EXIF XSS fix?
Joomla 6	6.1.6	Yes
Joomla 5	5.1.3	No
Joomla 4	4.5.5	No
Joomla 3	3.2.8	Outside the published range (4.5.0 and up)

That table comes from Phoca’s update manifest, which matches each Joomla generation to a release on a targetplatform pattern. The Joomla 5 release, 5.1.3, and the Joomla 4 release, 4.5.5, both sit inside 4.5.0 to 6.1.5 and neither has a patched successor. A site on either of them cannot update to safety from Joomla’s update screen.

The Joomla 3 line is a different case. Its newest release, 3.2.8, is below the 4.5.0 floor of the published range, so we are not claiming it is affected, and we are not claiming it is clean either. The CNA record does not cover it.

Joomla 4 and 5 sites have to install Phoca Gallery 6.1.6 by hand

Phoca’s update feed offers each Joomla version one release, and Joomla discards any offered version that is not higher than the one installed. On Joomla 4 and Joomla 5 that produces two different failures:

A Joomla 4 or 5 site on the 4.x or 5.x line is offered 4.5.5 or 5.1.3. Both are inside the affected range, so the site owner can apply the update in good faith and still be exposed.
A Joomla 4 or 5 site already running a 6.x build is offered a lower version. Joomla shows no update at all, and the site looks current while it runs 6.1.5 or older.

The fix in both cases is the 6.x package from the 6.1.6 release, installed through Joomla’s extension installer after a backup. That may mean moving the site to Joomla 6 first, and if the gallery is no longer earning its place on the site, removing the component is the shorter route.

Across the Joomla sites we manage, the majority of the affected Phoca Gallery installs run Joomla 6 and will update normally. About one in seven is on a Joomla 4 or 5 line with no fixed release. That proportion is from sites that an agency actively looks after; the wider Joomla world still runs a lot of Joomla 4, so the share of stranded galleries out there is likely higher.

An empty update list is not proof you are patched

On Joomla 4 and Joomla 5, Phoca Gallery can show no available update while running a vulnerable version, or offer an update that is itself inside the affected range. Check the installed version under System, Manage, Extensions and compare it with 6.1.6 by eye.

What to do about it on each Joomla version

Joomla 6: update Phoca Gallery to 6.1.6 through the normal Joomla updater, then confirm the version number.
Joomla 5: take a backup, then install the 6.x package by hand from the GitHub release. Do not take the 5.1.3 the updater offers as a fix for this. If the package will not install on your site, plan the move to Joomla 6 or remove the gallery.
Joomla 4: the same choice. The updater’s 4.5.5 is inside the affected range. Install the 6.x package by hand after a backup, which will usually mean moving the site to Joomla 6 first, or remove the component until you can.
On any Joomla version: this is stored XSS, so the question is who could have planted an image. If front-end user upload was ever enabled, review which accounts had it and what they uploaded. Check the existing galleries for images added by accounts you do not recognise, and treat an administrator who opened a suspect photo’s info view as having a session that may have been used.

See which of your sites are still on Joomla 4 or 5

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How mySites.guru flags vulnerable Phoca Gallery installs

The Phoca Gallery version alone does not tell you what to do here. You need the Joomla version beside it, because that decides whether the updater will deliver 6.1.6, whether you need the package by hand, or whether the site has to move to Joomla 6 first.

mySites.guru keeps both for each connected Joomla site. We added this flaw to our vulnerability database on the day the CVE was published, so every site running Phoca Gallery between 4.5.0 and 6.1.5 is flagged on its dashboard now, with the Joomla version on the same screen. The Joomla 6 sites can go out in one batch with the mass updater, which leaves a short list of Joomla 4 and 5 sites for the manual package. That works the same way across a portfolio of Joomla sites of any size, and is part of every subscription.

Why a gallery’s EXIF data is attacker-controlled

EXIF is written by whoever made the file. A camera fills it in, but so does any image editor, any command-line tool, and any script, and the file does not care whether the GPS field holds a fraction or a sentence. From the moment a site accepts an uploaded image, every byte of its metadata is input from the person who uploaded it, and a feature that reads that metadata back onto a page is an injection surface in the same way a comment form is. Developers tend to see the image as a blob and the EXIF as trusted camera data, when it is a user-supplied text block that happens to travel inside a JPEG.

In fifteen years of looking after client sites, the galleries have been the features nobody reviews. They are installed once for a photo page, the upload accounts are handed out to whoever runs the events, and the extension sits there for a decade. A flaw in the info view of a gallery on a site like that fires on the one person who clicks every photo to check it, which is usually the administrator.

This is the third Phoca extension this year where the fix reached only the current Joomla line. The Phoca Cart product filter SQL injection in August showed the distribution problem first, the Phoca Cart download IDOR in October repeated it, and the Phoca Download upload flaw had the same shape. Phoca is quick with the fix each time. What a site on an older Joomla gets from each release is a version number that looks current and the same vulnerable code underneath, and the release notes do not say which lines were left out.

The PHP Project Advises Turning Off Session Upload Progress Until the Next Release

phil@mysites.guru (Phil Taylor) — Fri, 23 Oct 2026 11:42:27 GMT

On 23 October 2026 the PHP project advised site owners to set session.upload_progress.enabled=0 until the next regular bugfix release, to fully protect against what it calls an “unlikely RCE vector”, tracked as CVE-2026-115560. The notice sits on the php.net homepage as an informational advisory, and it is separate from this week’s two critical PHP2Shell flaws, which were fixed on 21 October and need a PHP update, not a config change.

If you already set session.upload_progress.enabled=0 after the 21 October advisory, you are done: php.net says to keep it in place and that no further action is needed. If you did not, it is a one-line change to a PHP config file, and the rest of this post covers who actually needs it, where the line goes, and how to find the sites that still have the feature on.

PHP's informational advisory on php.net, 23 October 2026.

What to do

Set session.upload_progress.enabled=0 in your PHP configuration. It is a config change, not a code change, and it cannot be done with ini_set(). If you applied it on 21 October for CVE-2026-109619, keep it and do nothing else. This does not replace updating PHP for the two critical flaws: only a patched PHP (8.5.12, 8.4.27, 8.3.36 or 8.2.35) fixes those.

Do You Need to Do Anything Right Now?

If you applied the session.upload_progress.enabled=0 mitigation on 21 October, no. If you did not, set it to 0 now and leave it there until the next PHP release. Most sites are not exploitable through CVE-2026-115560, because it needs an unusual configuration that stock Joomla and WordPress do not use, but PHP still recommends turning the feature off as a precaution.

The reason PHP can be this relaxed is in the advisory itself. The flaw “can only occur under an unusual combination of configuration and application code”, and because that setup is “unlikely in practice”, PHP is handling it in the regular release cycle rather than as an out-of-band security release. The full advisory for CVE-2026-115560 is due with the next release. Until then the CVE is assigned but not published, so there is no CVSS score, no description and no affected-version list to quote, and anyone quoting one is guessing.

This week has been loud enough for PHP site owners without a third alarm, and the honest description of this advisory is cheap belt-and-braces: a setting almost nobody uses, switched off until the fix is out.

How mySites.guru Shows Which Sites Have It On

At the start of this week, when disabling session upload progress was only a footnote mitigation in the GHSA-6wmf-4rv5-p3rp advisory for CVE-2026-109619, mySites.guru added a read-only check called PHP Session Upload Progress Setting. It records the value of session.upload_progress.enabled on every connected site at each snapshot, and snapshots run twice a day. It does not change the setting and cannot, because the directive is not writable at runtime. It just reports what each site has.

Two days later that boring inventory is the whole job. The 23 October advisory does not ask you to understand a vulnerability, it asks you to find every site where a particular ini value is still 1 and change it. After 15 years of looking after other people’s sites, that is the step where time goes: not the fix, which is one line, but the hunt across a dozen hosts, three control panels and a handful of sites nobody remembers the login for. If you already hold the list, the advisory is an afternoon. If you do not, you are logging in to each one to run phpinfo(). We wrote about the same problem at agency scale earlier this week, when the question was which PHP version each host was running.

mySites.guru now flags sites that still have session upload progress on, so the list is one screen rather than a spreadsheet you build by hand. Two caveats. First, a site showing the feature on is normal rather than a sign of compromise or a careless host, because it is the PHP default and almost nothing turns it off. Second, switching it off does not help an unpatched PHP against the PHP2Shell RCEs. The PHP version check and this check sit side by side for a reason, and the PHP version is the one that matters more.

See which sites still have session upload progress on

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs on every snapshot, twice a day.

Check your site for free

The check is part of the mySites.guru subscription alongside the PHP version, vulnerability and malware checks that have been doing the heavy lifting this week. If you want to see what it reports for one of your sites before paying anything, a free audit runs the same checks and shows you the result.

What Is PHP Session Upload Progress?

PHP session upload progress is a feature that records the progress of an in-flight file upload into the user’s $_SESSION, so a page can show an upload progress bar by polling with a separate AJAX request. It is controlled by session.upload_progress.enabled, which has been on by default since PHP 5.4, and it is documented in the PHP manual.

While an upload is in progress, PHP writes an entry into the session with the bytes received so far, the total expected, and the filename, and updates it as the upload continues. The application never has to opt in to any of this: if the setting is on and a form includes the right hidden field, the data appears in the session.

Very few applications use it. The GHSA advisory calls it a “hardly-used and hardly-tested feature”, which is a frank description from the people who maintain it, and it is why the GHSA says it may be prudent to keep it off even after patching. Because it is the PHP default, in the mySites.guru database almost every connected site reports it on, which says nothing about those sites except that nobody has ever had a reason to touch the setting.

Why Most Sites Are Not Exposed

The advisory is specific about what has to be true for CVE-2026-115560 to be reachable. An application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime with ini_set() before calling session_start(). Session upload progress must also still be enabled. All three have to hold at once.

Switching the serialize handler at runtime is rare. Stock Joomla and stock WordPress do not do it, and PHP’s own words are that “applications that never change the serialize handler at runtime can keep the feature enabled”. So for the large majority of sites the CVE is not reachable regardless of the upload progress setting, and that is why PHP chose the regular release cycle over an emergency release.

PHP still suggests setting the feature off, for the same reason the GHSA did two days earlier: it is a hardly-used feature, turning it off costs nothing, and it removes the exposure rather than relying on an audit of every extension and plugin’s session handling. That is a reasonable trade. You are very probably not vulnerable, and the fix is still worth the two minutes.

How Do You Set session.upload_progress.enabled to 0?

session.upload_progress.enabled is a PHP_INI_PERDIR directive, so it is set in php.ini, a PHP-FPM pool configuration, a .user.ini file in the site’s web root, or .htaccess under mod_php. It cannot be changed at runtime with ini_set(), which means no plugin, extension or line in configuration.php or wp-config.php can do it for you. The directive is:

session.upload_progress.enabled=0

On most managed hosting the host controls php.ini, so the practical route is .user.ini if your host honours it, or a support ticket asking the host to set it. Some control panels expose PHP ini overrides in their own interface, which writes the same directive for you. If you run your own server, put it in the pool configuration or php.ini and reload PHP-FPM.

Then confirm it took effect. A .user.ini or .htaccess change is read on a following request, so make a fresh one and check session.upload_progress.enabled in phpinfo() or with ini_get(). If the site is connected to mySites.guru, the next snapshot records the new value and the site leaves the list of sites still showing it on.

How This Fits This Week’s PHP Security Releases

On 21 October 2026 PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two critical flaws: CVE-2026-109618, remote code execution via out-of-memory corruption, and CVE-2026-109619, remote code execution via stale global state. Both are rated CVSS 4.0 9.2 and both are unauthenticated remote code execution. The pair has been named PHP2Shell, a name coined by Wiz. PHP 8.1 and older are end of life and get no official fixed release. The same morning joomla.org was offline, which made it a long day for anyone looking after Joomla sites.

CVE-2026-115560 is a separate, lower-stakes vector in the same session upload progress feature. It was not fixed in the 21 October releases, and it will be fixed properly in the next monthly bugfix release, expected mid-to-late November 2026, when PHP will also publish the full advisory. Disabling the feature is the bridge until then.

The ordering of priorities has not changed. Update PHP to a fixed release first, because that is what closes the two critical holes. Then set session.upload_progress.enabled=0, or confirm it is already set, and leave it there. If you did both on 21 October, this advisory is already behind you.

How mySites.guru Helps Agencies Firefight PHP2Shell at Scale

phil@mysites.guru (Phil Taylor) — Thu, 22 Oct 2026 08:39:17 GMT

This is fine. After KC Green’s Gunshow comic (2013).

That dog is every agency owner on the morning of 21 October 2026, coffee in hand, scrolling a sites list. (The meme is KC Green’s, and it has never been more accurate.) PHP had just published 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619: two unauthenticated remote code execution flaws, both rated CVSS v4.0 9.2, which the press and security vendors have since named PHP2Shell. PHP’s own position is that updating is the only safe choice.

What the two flaws are and which server setups are most exposed is in our post on PHP’s critical security release, so I will not repeat it here. This post is about the other problem, the one that only shows up when you look after other people’s sites in bulk.

On almost all Joomla and WordPress hosting, the host installs and updates PHP. You cannot patch it yourself, and your control panel only offers the versions the host has installed. For one site that is one support ticket. For an agency it is dozens of tickets to different companies, each about a different set of sites, each with a different idea of what “soon” means. Across the accounts that manage 20 or more live sites with us, the median number of different servers those sites run on is 11. The fire is spread across eleven buildings, and most of them have a different landlord.

Accounts managing 20 or more live sites run them on a median of 11 different servers, each one a separate host conversation.

5 or more servers

72.3%

10 or more servers

54.6%

half of accounts

Share of accounts managing 20 or more live sites. Measured on live sites under active management, 22 October 2026 08:25 UTC, sites with a snapshot in the last two days.

So the question for an agency is operational rather than technical: which of my sites, on which servers, at which hosts, are still exposed, who do I chase, how do I know when they are done, and what do I do about the hosts that patched but kept the old version number? Everything below is how mySites.guru answers each of those in turn.

TL;DR

Every site’s PHP pill goes red when the version it reports is at or below 8.2.34, 8.3.35, 8.4.26 or 8.5.11, or on 8.1 and older. A dashboard banner, a Needs Attention row and the php-security search token give you the affected list in one click.
Every site reports the server hostname it runs on, so hostname:<server> turns a pile of red sites into one ticket per host.
Each affected site’s Important card has a ready-written request for the host under “Copy request for your host”, and clears itself at the first snapshot after PHP is updated.
The explainer page groups your affected sites by PHP branch, shows a progress bar, and checks php.net hourly for “Is the fix out yet?”.
Hosts on CloudLinux and Ubuntu back-port the fix without changing the version number. A back-port declaration records the host’s word, with who and when, and turns the pill back to its normal colour with a shield. It is a claim, not proof: only PHP’s official releases are definitively fixed.
PHP 8.1 and older stay red whatever the host says, because they are end of life. The fix there is a move to 8.3 or newer.

Every Affected Site on One Screen

mySites.guru records the PHP version each site reports while serving a request, at every snapshot. php -v on the command line and the build serving your pages are often two different installs, and the one you care about this week is the one answering web requests.

For this release the PHP version pill turns red at or below 8.2.34, 8.3.35, 8.4.26 or 8.5.11, and for every version on 8.1 and older. Anything after the first dash in the version string (-nmm1, -bookworm.0) is ignored, so a packager’s suffix does not hide a vulnerable number or invent a fixed one. The pill is the same one that normally shows amber or green depending on how far a site is behind php.net, and it appears on the sites list, the site header, the site picker, the core upgrade tool and client reports.

The sites list on release day. The banner only shows while you have an affected site.

Above the list sits a banner, shown only while you have at least one affected site and only until 21 December 2026: “4 of your 5 sites run PHP without the 21 October 2026 critical security fix.” Its “Show them” button filters the list down to those sites, and “What happened” opens the explainer page covered below.

The left menu’s Needs Attention group gets a “PHP Security Release” row with a count, which you can hide like any other row once you are on top of it. And if you prefer the search box, the token php-security finds every affected site, while php-backported finds the ones covered by a back-port declaration.

Hover a red pill and it tells you which release to ask the host for.

The snapshot row “PHP Version Should Be Latest Supported Series” goes red for the same versions, so the result reaches anyone reading the snapshot rather than the sites list.

Sorting the Fire by Host and Server

A list of forty red sites is a list. The same forty sites grouped by the server they sit on is a to-do list, usually a much shorter one, because a host that updates PHP on a server fixes every site on it at once.

Each site reports the hostname of the server it runs on, and mySites.guru uses that in three places. The site header has a hostname badge that links to every site on that server. The “Your Web Servers” page lists all of your servers so you can see the spread at a glance. And on the sites list, the search token hostname:<server> filters to one server, which combined with the red pills tells you in a second whether a host has done that box yet.

This is the step that turns a fire across eleven servers into eleven conversations, each with one list of sites attached. If you tag your sites by client or server already, the tags do the same job for hosts whose servers do not report a helpful hostname, and for the client-facing side, where “which of your sites are affected” is the question you will be asked.

The Spreadsheet Does Not Know What Your Host Did Overnight

Plenty of agencies keep a spreadsheet of client sites: domain, host, CMS, and a PHP version someone typed in at launch or after the last migration. It feels like an inventory until the day you need it, because the one thing that changes most on a hosted site is the thing you do not change yourself. The host upgrades PHP on its own schedule, moves accounts to a new server, switches a site to a newer branch when the old one goes end of life, and back-ports a fix overnight, usually without a word to you. None of that touches a cell in your sheet.

So on release day the PHP column is only as current as the last time someone edited it, and it cannot tell you which sites the host already patched that morning. You end up checking every site by hand to find out whether the sheet is lying.

mySites.guru reads the PHP version and the server hostname from each site at every snapshot, so the list you filter on release day is what the sites reported, not what somebody remembered to write down. And it keeps moving while you work: the host patches a server, the next snapshot reports the fixed build, and those sites drop off the list on their own. When the host does the work for you, the dashboard notices.

Most of This Is in Your Host’s Hands

An agency cannot patch PHP it does not run

Almost every agency hosts client sites on servers someone else operates: shared hosting, reseller accounts, a managed VPS, the client’s own provider. The PHP build on those servers is the host’s to choose, compile and update. Your control panel offers the versions the host has installed, and nothing else, so the speed of the fix is the speed of each host.

It is rare, though not unheard of, for an agency to run its own servers with someone in house who can compile a specific PHP build and roll it out the same afternoon. We are in that position for mySites.guru itself, because I build the PHP images our own platform runs on. Most agencies are not, and should not need to be. For everyone else there is a lot of reliance on web hosts doing the right thing, and doing it quickly.

Some hosts were quick. The first sites we monitor reported a fixed version about fifty minutes before PHP’s advisories went public, because hosts and packagers who were told in advance had their builds ready. Others have not fared so well. Across the servers running sites on PHP 8.2 to 8.5 that we have snapshotted since the advisories went out:

Every site fixed

58.2%

None fixed yet

36.8%

A mix of both

5.0%

half of servers

Servers by reported hostname, live sites under active management snapshotted after 13:35 UTC on 21 October 2026, measured on 22 October 2026. A back-ported build that keeps the old version number counts as not fixed here.

Part of that 36.8% is CloudLinux and Ubuntu servers that are patched under an old version number, which is the case back-port declarations exist for, covered below. The rest are hosts that have not got there yet, and those are the conversations to start today.

A Ticket for Your Host, Already Written

Each affected site gets a card on its Important tab, and the tab opens by default while the card applies. The card is titled with the specific problem, “PHP 8.4.13 has two critical security flaws”, says which fixed release to ask for, and has three buttons: “What happened” for the explainer page, “Copy request for your host”, and “Check again”.

The Important card on an affected site, with the back-port checkbox underneath.

“Copy request for your host” puts a finished ticket on your clipboard, with the site, the server and the version already filled in. This is the one from a test site:

Hello, the website https://myExampleSite-smallsnake.com runs PHP 8.4.13 on panasoni.example.com.

PHP published a critical security release on 21 October 2026 (CVE-2026-109618 and CVE-2026-109619). Please update PHP 8.4 on this server to 8.4.27 or newer, or confirm that your distribution package includes the backported fix, and let me know when it is done. If the fix is back-ported into the current build without a version change, please say so in your reply.

Thank you.

The last sentence is there on purpose, and it is the reason the back-port section further down works. Hosts that back-port rarely volunteer it unless asked, and you want their answer in writing.

“Check again” takes a fresh snapshot, so when the host replies “done” you can confirm it straight away rather than waiting for the next scheduled run. The card cannot be dismissed. It clears itself at the first snapshot after PHP is updated, which means a card you can still see is a site that is still exposed, with no way to tidy it out of sight and forget it. For a site on end-of-life PHP the card says there is no official fix and asks the host to make PHP 8.3 or newer available instead.

How Do You Know When a Host Has Finished?

The explainer page at manage.mysites.guru/en/help/php-security-release (you need to be signed in) lists only your affected sites, grouped by PHP branch with the newest branch first, each group headed by what to ask for: “PHP 8.4: ask your host for 8.4.27 or newer.” Paused sites are left out, and a site drops off the list at its first snapshot after its host updates PHP, so the page gets shorter as the week goes on.

The explainer page: your affected sites by branch, the progress line, and the Is the fix out yet? strip.

At the top is a progress line and bar, “1 of your 4 sites on PHP 8.2 to 8.5 is patched, 1 of them back-ported by your host.”, which is the number you will be asked for in the Monday stand-up. Below the sites is an “Is the fix out yet?” table, one row per branch, fed from our php.net feed and checked every hour, so a host telling you “the release is not out yet for 8.3” can be checked against the source without leaving the page. The page also explains why a version is red and what to do about it, and it is in Cmd+K and Browse All Tools, so you can reach it from anywhere.

For the wider picture, this is the same view across every site we monitor, the morning after the release.

45.0% of affected sites were fixed the morning after the release.

Fixed 45.0%

Still vulnerable 55.0%

Patched 44.5%official release installed
Unpatched 34.2%fix out, host has not applied it
End of life 20.8%8.1 and older, no official fix

Back‑ported 0.5%, declared on the host's word

Patched 44.5%, official release installed
Back‑ported 0.5%, declared on the host's word
Unpatched 34.2%, fix out, host has not applied it
End of life 20.8%, 8.1 and older, no official fix

Share of sites on an affected PHP version, measured on live sites under active management that have taken a snapshot since 21 October 2026, at 09:25 UTC on 22 October 2026. Sites not yet snapshotted since the release are left out.

Hosts are not moving at one speed. On the supported branches, 67.3% of sites on PHP 8.5 are fixed against 53.2% on PHP 8.3, the branch most sites sit on, with 8.4 at 56.7% and 8.2 at 56.2%. WordPress sites are slightly ahead of Joomla sites, 48.6% fixed against 43.9%, largely because more Joomla sites are on end-of-life PHP. And the end-of-life branches are fixed on about 0.9% of their sites, every one of them a host back-port a customer has declared, because there is no release for those branches to install.

The 34.2% in amber is the work in front of you: sites whose host has a fixed release available and has not applied it yet. Some of that amber is not real, which brings us to the part of this release that has caused the most confusion.

What If the Host Patched but the Version Number Did Not Move?

A version check works when the fix arrives as a new version number. On CloudLinux and Ubuntu packages it does not. CloudLinux says so directly for the ea-php packages that cPanel servers running CloudLinux use: “Our packages carry the fix as a backport, so their version numbers stay below PHP’s: ea-php84, for example, is 8.4.26, not 8.4.27.” Its advice is to look for the CVE IDs in the package changelog instead:

rpm -q ea-php84-php-cli --changelog | grep -E 'CVE-2026-(109618|109619)'

CloudLinux has fixed ea-php52 through ea-php85 on CloudLinux 7, 8, 9 and 10, and alt-php 5.2 to 8.5 on CloudLinux 7, 8 and 9. Ubuntu does the same: 24.04’s php8.3 is fixed in 8.3.6-0ubuntu0.24.04.13 and 22.04’s php8.1 in 8.1.2-1ubuntu2.28 (USN-8948-1 and USN-8948-2), so a fully patched Ubuntu 24.04 site still reports 8.3.6 and shows red. Debian went the other way and ships the new upstream numbers, bookworm’s php8.2 as 8.2.35-1~deb12u1 (DLA-4848-1) and trixie’s php8.4 as 8.4.27-1~deb13u1 (DSA-6574-1), so on Debian the version check simply works.

We could not fix this with a cleverer rule, because the version string a back-ported build reports is identical to the vulnerable one. Nothing in the site’s report tells the two apart. The only party who knows is the host.

A back-port declaration is your host's word, not proof

There is no way to see what a host’s custom build contains, or whether the patches were applied correctly. Only PHP’s official releases, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, are the definitive fixed versions, tested by the whole PHP community. A declaration records that your host told you otherwise, with who recorded it and when.

So on 22 October we added back-port declarations. On the explainer page there is a “Host back-ported the fix?” card. You pick a PHP build from a list of your own affected builds (the PHP version on a given web host, with site counts, most sites first), tick “My web host has told me that this PHP version on this web host has been patched by back-porting the security fixes.”, and Save. Or, on a single site, tick the box under the Important card and press “Mark back-ported”. The card then lists your declarations with how many sites each covers and “Declared 22 Oct 2026 by” whoever did it, with a Remove button; the success message has an Undo. Every change is written to the activity log.

One declaration covers every site reporting that exact build on that server.

A declaration matches on the exact PHP version string the site reports plus the server hostname, within your account only, and your team members share it. The account scope is a safety decision rather than a limitation: short server hostnames like “www” or “web-01” repeat across unrelated customers, and one agency’s word about its host must never flip a different agency’s sites to green. If the host later changes the build, say to 8.4.27 proper, the declaration stops matching on its own and the card shows “No site reports this any more”, so a stale declaration cannot outlive the build it described.

The shield marks a declared back-port, and the tooltip says who declared it and when.

What changes once a declaration is in place: the PHP pill gets a shield icon and goes back to its normal colour, green if the build is current or amber if it is behind php.net’s latest, with the tooltip “Your host says the 21 Oct 2026 fix is back-ported into this build. Declared 22 Oct 2026 by Captain.” The site leaves the affected list, the Important card, the banner and the Needs Attention counts, the reports, the snapshot rows and the upgrade warning, and the API reports backported. On the explainer page it moves to a “Back-ported (declared by you)” group, and the progress bar shows back-ported sites as a lighter segment, so you can always see how much of your “patched” is a vendor’s release and how much is a host’s promise. An admin looking at a customer’s account cannot make declarations for them.

My opinion on this, for what it is worth. A declaration is not evidence, and we do not pretend it is. You cannot inspect a host’s custom build from the outside: you do not know which patches went into it, whether they were applied cleanly, or whether anything else changed along the way. The official releases are the only versions the PHP project built, tested and published as fixed, and everyone who runs that version runs and scrutinises exactly the same code. A back-ported build has been tested by one vendor, at best. So treat the official version as the goal, and push your host to offer it even when they say the old build is patched.

Where a host insists it has back-ported the fix, get that in writing (the ticket text already asks), record it, and keep the declaration for what it is: a note of the host’s claim. The shield says “your host says”, the tooltip names the person on your team who recorded it, and the activity log has the rest. We added it because the alternative, a red pill that never goes away on a site the host swears is patched, trains everyone on your team to stop looking at red, which is the worst outcome a security dashboard can produce. It does not make the build as trustworthy as an official release, and nothing in mySites.guru claims it does.

Two known limits. A custom report template of your own keeps the old red unless it passes the site through, and a teammate’s Needs Attention count refreshes at their next sites-list load rather than instantly.

End-of-Life PHP Has No Number to Wait For

PHP 8.1 and older are end of life and got no official fixed release. php-src has source-only back-port branches for 7.4, 8.0 and 8.1, with no builds, which is nothing a shared host’s control panel can offer. The supported versions page shows what is still maintained; everything below 8.2 is not. On 20 October, 22.7% of the sites we monitor were on PHP 8.1 or older, and for those there is no release to wait for.

mySites.guru treats them accordingly. The pill is red on every 8.1-or-older version and its tooltip adds “No official fix for the 21 Oct 2026 PHP flaws.” The Important card says there is no official fix and asks the host to make PHP 8.3 or newer available. And a back-port declaration, even a true one from a vendor that did back-port into 8.0 or 8.1, does not turn the pill green: the critical-release warning goes, but the version stays red because it is still end of life. On the explainer page these sites sit under their own heading, “PHP 8.0: end of life, no official fixed release. Move to 8.3 or newer.”

A host’s back-port on an end-of-life branch closes this hole and leaves the next one open, because nothing upstream fixes that branch any more. Our post on end-of-life version support covers how mySites.guru flags end-of-life versions, and the sites on this list are the first clients to talk to about moving.

The Session Upload Progress Check

The snapshot check “PHP Session Upload Progress Setting” reports session.upload_progress.enabled for each site. It is read-only and reports what PHP says the value is. It does not make an unpatched site safe: the fix is the fixed PHP release from your host. If you are not sure which of our checks run on a snapshot and which need the full audit, snapshot vs audit has the breakdown.

Your Clients Have Never Heard of PHP2Shell

João Santos put it well the morning after the release: go to your local coffee shop and see how much anyone there cares about PHP, vulnerabilities and AI. He is right. We live and work in a PHP bubble. This week our feeds are wall-to-wall CVE numbers, CVSS scores and arguments about back-ports, and outside that bubble it is an ordinary Thursday.

Flo the Florist wants her orders to keep coming in. Bob the Builder wants the quote form on his site to keep sending him leads. Neither of them knows which PHP version their site runs, and neither should have to, because that is what they pay an agency for.

Most of them will never ask. A few will catch a headline about a “critical PHP flaw” on the news, or get a scary email forwarded by a nephew, and the next message in your inbox will be “are we affected?”. The agencies that come out of this week looking good are the ones that can answer in one line, the same day, instead of needing an afternoon to find out. Everything earlier in this post is about being able to send that line.

It also changes how you say it. Flo does not want CVE numbers, CloudLinux package names or the word “back-port”. She wants “we checked your site, your host has applied PHP’s security fix, there is nothing for you to do.” Keep the jargon on your side of the bubble, and keep the evidence somewhere you can find it if she, or her insurer, ever asks.

Reporting It to Clients (and Your Own Tools)

Clients will ask, and some will ask before you have finished the list. Client reports, both the in-app version and the emailed one, print a note under the PHP version for an affected site, so a report sent this week says the right thing without you editing it.

If you run your own dashboards or ticketing, the API and MCP site summary have a php_security_release field with four values: unpatched, eol, backported or null, and the first two count as an attention reason. That is enough to drive a Slack alert, a client status page or a weekly export from one API or MCP call for every site in your account. And when you just need the page in front of you, Cmd+K and type php: the explainer page is in there alongside the rest of the tools.

The fire is still burning on a fair share of hosting as I write this. What has changed since 21 October is that an agency no longer needs to log in to eleven control panels to find out where. Open the sites list, filter by host, send the tickets, record the back-ports, and watch the progress bar move. The dog can finish its coffee.

Joomla.org Is Offline After the PHP Security Release: What It Means for Your Site

phil@mysites.guru (Phil Taylor) — Wed, 21 Oct 2026 20:55:32 GMT

At 20:00 UTC on 21 October 2026 the Joomla project posted on Bluesky that “due to today’s PHP security releases, Joomla websites are temporarily offline to keep our sites and your data safe. Downloads, automated updates and Install from Web are unavailable for now.”

Joomla's announcement on Bluesky, 20:00 UTC on 21 October 2026.

The status page shows the main joomla.org sites had already been down since the afternoon, hours before the announcement. Three minutes later came the part aimed at you: “Running a Joomla site? Contact your hosting provider now and ask if your server runs a patched PHP version. This is a server-level vulnerability, so updating Joomla alone will not fix it.”

Your Joomla sites are not offline; joomla.org is. Your sites run on your own hosting, and the outage does not change how they serve pages. The urgent job is the PHP version under each of them, at your host, which is what Joomla itself is telling people.

What to do now

Find out which PHP version each of your Joomla sites reports and whether it is 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If it is below those, or on 8.1 or older, contact the host now and ask when the patched release goes on. Do not spend the evening on Joomla core updates: the latest releases predate the outage and do not contain the PHP fix, because the flaw is not in Joomla. Our PHP security release post has the detail on the two vulnerabilities.

What Is Down and What Still Works

We checked each joomla.org service at about 20:35 UTC. Most of the project’s public sites return Cloudflare errors (521, 502 or 503). A few pieces still answer, and they are the ones that matter for keeping sites updated.

Service	Status at 20:35 UTC	What it means for your site
joomla.org (main site)	Down	Nothing. Your site does not call it.
downloads.joomla.org	Down	The first download mirror for core packages is unavailable. Joomla 4, 5 and 6 can use two others; Joomla 3 cannot.
extensions.joomla.org (the JED)	Down	You cannot browse or install new extensions from the directory.
Install from Web feed	Down	The Install from Web tab shows “Can’t connect to the Joomla! server”.
autoupdate.joomla.org	Down (503)	Joomla’s free Automated Core Updates service cannot call into sites.
developer.joomla.org, magazine, volunteers, community, API docs	Down	Nothing for a running site.
forum.joomla.org	Down (confirmed later in the evening)	The community forum is unavailable, so you cannot search past answers there for now.
docs.joomla.org	Behind a Cloudflare challenge	We could not tell either way.
manual.joomla.org, status.joom.la	Up	The manual and the status page answer normally.
update.joomla.org update lists	Up, from Cloudflare’s cache	Joomla’s update check still sees the current releases.
TUF signed metadata (targets.json, timestamp.json)	Up, from Cloudflare’s cache	Joomla 5.1+ can still decide which core update to offer, until the cached copy expires.
update.joomla.org/releases/ and GitHub releases	Up	Core update packages are still downloadable.

The cached responses from update.joomla.org show cf-cache-status: STALE, which is Cloudflare serving the last good copy because the origin is unreachable. That is why Joomla sites still see a correct update list, and why the expiry further down this post is worth a look.

Why Did Joomla Take Its Own Sites Offline?

Because PHP published a critical security release on the afternoon of 21 October, and the Joomla project’s servers run PHP like everyone else’s. At about 13:35 UTC PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and both confirmed as allowing unauthenticated remote code execution. PHP’s own words: “There are no complete mitigations, updating is the only safe choice.” PHP 8.1 and older get no official release. The researchers, Wiz, say they demonstrated unauthenticated RCE against default container images of WordPress, Drupal and Joomla; exploitation in the wild has been claimed but not confirmed. The full breakdown is in our post on the PHP release.

Joomla is not the only organisation that went dark rather than wait. Global News reported that the Government of Canada took some sites offline as a precaution and that Dutch and Finnish agencies did the same, and CERT-EU’s advisory told organisations to “consider isolating internet-facing applications from public networks until a fix can be applied”.

Our view is that Joomla made the right call. A project that ships the update packages for a large share of the web should not keep those servers online on an unpatched PHP. The update pipeline is exactly what an attacker would want to own, and a few hours without a download page is a cheap price for keeping it clean.

Can You Still Update Joomla Core During the Outage?

Probably, and in most cases you will not need to. The latest core releases are 6.2.0 and 5.4.10, both already in the signed update metadata and both published before the outage, so a site on one of them has no core update to miss. Joomla core does not contain the PHP flaw, which is Joomla’s own point about updating Joomla alone.

For a Joomla 4, 5 or 6 site that does still need one, Joomla’s update check reads update.joomla.org, which is still answering from Cloudflare’s cache, so the admin still sees the current release offered. The signed metadata lists three download mirrors for each core package: downloads.joomla.org, GitHub, and update.joomla.org/releases/. Joomla’s own updater (the download step in com_joomlaupdate) tries the first URL and moves on to the next mirror if it fails. downloads.joomla.org is down, but the GitHub releases and update.joomla.org/releases/ both answered when we checked, so a core update started now should fall back to a mirror that is up. We downloaded the 5.4.10 update package from both working mirrors at 20:43 UTC, and each file’s SHA-256 matched the hash in Joomla’s signed metadata. We have not run a full update end to end during the outage, so “should”, not “will”.

Joomla 3 is the exception. Joomla 2.5 and 3.x sites read the legacy core feed at update.joomla.org/core/extension.xml, and that feed names downloads.joomla.org as the only download location, with no mirrors listed. A Joomla 3 core update started from the admin, or from mySites.guru, has nowhere else to fetch the package from until downloads.joomla.org is back. The Joomla 4 and 5 update feeds list the GitHub and update.joomla.org mirrors alongside it, and so does the signed metadata Joomla 5.1 and newer use. If you still look after Joomla 3 sites, our Joomla 3 security hub covers the options for them.

To take the live update check out of the picture entirely on Joomla 4 and newer, download the package from GitHub releases and install it by hand in System > Update > Joomla using the “Upload & Update” tab. Our post on the Joomla file checksum failed error covers verifying a package and doing this safely.

“Automated updates are down” is being read three different ways. Joomla’s Automated Core Updates is a free service the Joomla project runs: autoupdate.joomla.org calls back into opted-in sites and applies core updates for them. That server is returning 503, so that service is down. It is not the same thing as an administrator clicking update in the Joomla admin, which uses the site’s own updater and the mirrors above, and it is not the same thing as a core update run from mySites.guru, which uses that same site-side updater. Our post on how to disable Joomla’s automated upgrades shows where the project’s service is switched on and off.

The Joomla TUF Update Expiry to Watch For on 23 October

TUF, The Update Framework, is an open standard for securing software updates, and Joomla 5.1 and newer use it to decide which core update to offer. The Joomla project signs a small set of metadata files describing each release and its hash: root.json, targets.json, snapshot.json and timestamp.json. Before a site accepts an update it checks those signatures, and it checks that none of the files has expired. The expiry is there to stop a freeze attack, where someone who controls a mirror or sits in the network path keeps serving an old, still validly signed list so a site never hears about a security release. A site that sees expired metadata says no to the update rather than trusting it.

That expiry could bite later in the week if joomla.org stays down. The cached copy of timestamp.json that update.joomla.org is serving expires at 01:18 UTC on 23 October 2026.

The signing itself is still running: the copy in Joomla’s GitHub updates repository is already signed through 24 October, so the update.joomla.org copy is just a cached snapshot that happens to be the one sites can reach. If joomla.org is still offline when that snapshot expires and the cache has not been refreshed, a Joomla 5.1+ site checking for core updates would show “Update not possible because the offered update has expired”. That is a TUF safety check rejecting stale metadata, not a fault on the site, and we have an explainer on what that message means. Treat it as a possibility to watch for rather than a prediction; if joomla.org is back before then, nobody will see it.

What About Joomla Extensions and Install from Web?

Install from Web and the Joomla Extensions Directory are both down, so you cannot browse or install new extensions from inside Joomla for now. Open the Install from Web tab under System > Install > Extensions and Joomla says “Can’t connect to the Joomla! server. Please try again later.” That message is about joomla.org, not your site, and it can wait until the project is back.

The other tabs on the same screen, Upload Package File, Install from Folder and Install from URL, do not use joomla.org, so installing an extension from a zip you already have works as normal.

Updates for extensions you already have come from each vendor’s own update server, not from joomla.org. That would normally keep them out of this outage, but some extension developers have taken their own sites offline for the same PHP release, and their update servers went with them. For those extensions Joomla cannot check whether a newer version exists, so an empty update list is not proof that a site is current. Run the update check again once the vendor is back. Extensions from vendors whose sites are still up update as normal, and the two things that depend on joomla.org itself are the core update entry and the language pack feeds hosted there.

What mySites.guru Keeps Doing, and What It Cannot

mySites.guru has no way around the outage for Joomla core. A core update run from mySites.guru uses the site’s own Joomla updater, the same code as clicking update in the Joomla admin. During the outage it behaves the same way: it reads Joomla’s currently cached update metadata and downloads the package with the same mirror fallback described above, which on Joomla 3 means no fallback at all. mySites.guru has no separate mirror of Joomla core packages. If Joomla’s updater cannot complete an update on a site, we cannot complete it either.

Extension update checks have the same limit. mySites.guru asks each site to check its own update servers, so where a vendor has taken its site offline, the update for that extension cannot be seen until the vendor is back. For every vendor still online, bulk-updating Joomla extensions across your sites works as normal.

The rest keeps running, because none of it depends on joomla.org or a vendor’s server:

The core file integrity check, which flags modified core files, uses mySites.guru’s own copy of Joomla core file hashes.
Vulnerable-extension flagging uses mySites.guru’s own vulnerability database, so a site running a known vulnerable extension version is still flagged even while that vendor’s update server is offline.
The PHP version check, the one that matters this week, reads what each site reports.

If you manage multiple Joomla sites, all of this is on one dashboard, so you are not logging into each admin in turn to find out where you stand.

How Do You Check PHP on Every Joomla Site?

Look at the PHP version each site reports while serving a request, and compare it with the patched release for its branch. mySites.guru records that version for every connected site and, for this release, marks it red at or below 8.2.34, 8.3.35, 8.4.26 or 8.5.11. Sites on 8.1 and older are flagged end of life, because no official release exists for them. Being on a supported branch is only half the answer; the patch level inside it is the other half, and our post on PHP branches versus patch levels explains why the higher PHP number can be the more out-of-date one.

One caveat applies to any version-number check, ours included. A distribution package that backports the fix without changing the version number still looks unpatched, so for a site on distribution packages, confirm with the host rather than trusting the number either way, then record the back-port so the site stops showing red.

PHP Version Should Be Latest Supported Series

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

What to Do While Joomla.org Is Down

Joomla will come back when its servers run a patched PHP, and nothing you do on your own sites in the meantime depends on joomla.org, apart from browsing for new extensions, which can wait. What cannot wait is an unpatched PHP under a public site, with the researchers reporting a working exploit against a default Joomla image. The Joomla project has done its part by taking the risk off its own servers. Yours is to get the list of every PHP version across your sites, chase the hosts that have not moved, and plan the version move for anything on 8.1 or older. If that list does not exist yet, a free audit builds it in a few minutes.

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

phil@mysites.guru (Phil Taylor) — Wed, 21 Oct 2026 13:34:45 GMT

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.

9.3CVSS 4.0

CVE-2026-102785: unauthenticated remote code execution via the image handler

CriticalmySites.guru (provisional, the CVE record is not published yet)

Any visitor could reach the public image handler without logging in and, in 5.0.52 and earlier, influence what the handler wrote to disk and where, which the vendor classifies as remote code execution.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

No login neededYOOtheme Pro 5.0.0 to 5.0.52Fixed in 5.0.53

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The score above is our own assessment, taken from the vendor’s classification of the flaw as unauthenticated remote code execution. The CVE identifier is reserved but its record has not been published yet, so there is no official CVSS score, CWE or description to quote. We will update the YOOtheme entry in the Joomla Vulnerability Database when the record appears. 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 is not published, the patch is hours old, and a worked example would help the wrong people more than it would help you.

A malicious actor's own code runs on your server, with the same access as the website itself: reading, changing or deleting any file it can touch, planting a backdoor that survives the next update, installing malware, pulling every database credential and API key from your configuration, and using your server to attack other people. Gulp.

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 the list: one place that says 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. A working dropper gets reused; only the hole it comes through changes.

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. Every audit reads every file on every 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. The same patterns and hashes that caught them under JCE catch them under YOOtheme.

Find files that match known hacks

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

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.

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.
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.
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.
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.
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.

Timeline

2026-10-20 YOOtheme gives advance notice of a critical YOOtheme Pro 5 security update The vendor tells customers a critical fix is due the next day and that YOOtheme Pro 4 and earlier are not affected. mySites.guru adds a detection rule for YOOtheme Pro 5 the same day.
2026-10-21 YOOtheme releases 5.0.53 and names CVE-2026-102785 in the changelog The changelog entry reads: Fix unauthenticated remote code execution via image handler. Update every YOOtheme Pro 5 site to 5.0.53 or later immediately.
2026-10-22 Exploitation is underway, reusing droppers already known from JCE attacks The first sites hit, before and after the patch, are dropping the same web shells and backdoors seen in older JCE upload attacks. mySites.guru flags them through its existing Suspect content and Hacked files checks, with no new rule needed.

PHP's Critical Security Release and Your Joomla or WordPress Site

phil@mysites.guru (Phil Taylor) — Tue, 20 Oct 2026 20:52:25 GMT

Updated 21 October: the fix is out

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix CVE-2026-109618 and CVE-2026-109619, both now confirmed as unauthenticated remote code execution. Updating is the only complete fix. PHP 8.1 and older get no official release.

On 20 October 2026 the PHP security team posted advance notice of a critical security release, with the details, the affected versions and the fixed versions held back. On 21 October, a little before the announced 14:00 UTC, the release went out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities rated CVSS v4.0 9.2 that PHP describes as able to “allow unauthenticated remote code execution”.

For anyone running Joomla or WordPress, there is a catch. On almost every hosting account the owner does not apply PHP updates, the host does, and the host only does it for PHP branches that still receive fixes. So the useful question is not just “patch now”. It is “is my site on a PHP branch that has this fix at all, and has my host actually applied it”. That is what this post answers.

TL;DR

PHP published 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026, fixing CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS v4.0 9.2, and PHP has confirmed both as unauthenticated remote code execution.
CVE-2026-109618 is memory corruption triggered by pushing a request out of memory, mainly through multipart upload parsing. CVE-2026-109619 is stale request state left behind on a worker and reused by a later request.
Every PHP setup that serves web requests is in scope. The risk is highest for Apache with mod_php, where an unauthenticated request can trigger the attack before any application code runs.
PHP 8.1 and older get no official release. The PHP project published source-only backports for 7.4, 8.0 and 8.1, with no binaries, and some distributions and LTS vendors backport the fix into their own packages.
You usually cannot apply it yourself. PHP is installed and updated by your host, and your control panel only offers what the host has installed.
Across the live sites we monitor, 22.7% run PHP 8.1 or older. For those, no patched build is coming from PHP.
Check which version every site you look after reports, chase the host where the fixed release is not on yet, and plan the version upgrade where there is no fixed release to wait for.

What to do now

The fixed releases exist, and you cannot download them yourself, because PHP is set by your host. Check which PHP version each of your sites reports. If a site is on 8.2, 8.3, 8.4 or 8.5 and not yet on 8.2.35, 8.3.36, 8.4.27 or 8.5.12, ask your host when the patched release goes on, and select it in the control panel as soon as it appears there. If a site is on 8.1 or older, no official release exists, and the real fix is a version upgrade you should plan now.

What the Two Flaws Are, in Plain English

PHP’s advisory puts both vulnerabilities at CVSS v4.0 9.2 and says they “can allow unauthenticated remote code execution”. Its risk assessment covers “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed”, and considers the risk highest for mod_php, “with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs”. For a Joomla or WordPress site, that last clause means nothing the CMS does is in the way.

CVE-2026-109618 is described as RCE via out-of-memory corruption. When PHP runs out of memory part way through setting up a request, its internal request data can be left only partially initialised, and the cleanup that follows may then treat invalid data as valid. The advisory says several multipart parsing behaviours can push a request into out-of-memory while staying within PHP’s apparent limits: requests with no usable Content-Length slipping past post_max_size, no cap on headers per multipart part, empty file fields not counting toward max_file_uploads, and nested field names. The result can be code execution as the web worker account. It is validated over HTTP against mod_php with default limits, and the advisory lists FrankenPHP as susceptible too. PHP-FPM is considered susceptible from source analysis, with no complete FPM exploit demonstrated.

CVE-2026-109619 is described as RCE via stale global state. State belonging to one request is still referenced after its memory is freed, and a later request on the same worker uses it before normal initialisation has happened, a use-after-free. Exploiting it takes a “producer” request that leaves the state behind and a “consumer” in a later request on the same worker. The advisory confirms two consumers: INI diagnostics applied before request initialisation (a deprecated or invalid php_value in a .htaccess file under mod_php, for example), and session upload progress handling. The session upload progress route to code execution is validated against both mod_php and PHP-FPM. The strongest case is fatal_error_backtraces on PHP 8.5 under mod_php, which produces the kind of stale state the bug needs, and it was on by default on the PHP 8.5 installs we checked.

One correction to the chatter from the days before the release: session upload progress is one confirmed path into CVE-2026-109619, not the whole bug, and it has nothing to do with CVE-2026-109618. The two flaws are separate, which is why PHP’s own wording is that “there are no complete mitigations, updating is the only safe choice”.

The patched builds went out as point releases on 8.2.x, 8.3.x, 8.4.x and 8.5.x. PHP 8.6 is still in release-candidate testing, no 8.6 line has the fix, and there is no 8.6.0RC4, so anyone running an 8.6 release candidate is unpatched.

The Internet Was on Fire (Well, Social Media Was)

Between the notice and the release, the loudest thing about this one was everyone except PHP. The security team had reserved the right to release early if details became public or if exploitation was seen in the wild, both were claimed within hours, and the release still went out on the day PHP named, about 25 minutes ahead of 14:00 UTC rather than a day early.

A taste of what did the rounds. Kevin Beaumont noted that someone leaked the two CVE IDs before the patch was out. Sansec reported a screenshot of an exploit tool called “PHP2Shell”, with a banner claiming it works against every PHP release since 5.4.0, and predicted mass attacks within fifteen minutes of the release. A write-up claiming to describe the bug circulated with a proof of concept that may have been broken. Huntress, writing on 20 October, had seen no in-the-wild exploitation and knew of no public exploit code. CERT-EU’s advisory had the sober version: no technical details public, and the “all PHP versions from 5 onwards” line came from leaks.

Then Cloudflare’s CTO posted at 07:43 UTC on 21 October that they were “seeing early attacks emerging”, while calling their WAF rules “a STOPGAP only” and telling everyone to patch at 14:00. Whether anyone was really being exploited is still disputed as we publish: Hadrian claims exploitation “at scale”, Germany’s BSI says no attack has been confirmed, and none of them has published evidence. Mattias Geniar’s round-up keeps the confirmed and the unconfirmed apart. Now that the advisories are public, the leak’s upload-progress claim turns out to have been partly right: session upload progress is a confirmed path into one of the two bugs, not the mechanism of both.

On those Cloudflare rules, which went out on every plan including Free: a WAF in front of a site only helps if the server behind it rejects traffic that bypasses Cloudflare. A server that answers requests sent straight to its IP address is reachable without the WAF, and the rules are a stopgap by Cloudflare’s own description, not a substitute for the update.

Our view, and we cannot prove it, is that what has changed is how little time an attacker now needs. A pre-announcement like this used to buy defenders a comfortable head start, because turning “two critical bugs, details withheld” into a working exploit meant a skilled human reading code for days. Now an attacker can have a script ready, point a model at the pre-announcement post and the leaked chatter, then at the patch diff the moment it is published, and have a candidate flaw in minutes, maybe seconds. The gap between a fix going public and an exploit going public used to be measured in weeks. We no longer assume there is a gap at all.

Why a PHP Flaw Matters to Every Joomla and WordPress Site

PHP is the engine every Joomla and WordPress page runs through. Every request a site serves, from a logged-out visitor loading the home page to an administrator saving an article, is executed by the PHP interpreter on the server. A flaw in the interpreter therefore sits underneath all of the normal traffic a site already handles, below the CMS, its plugins and extensions, and any security layer that lives in application code.

The release confirmed the worst reading of that. Under mod_php, PHP has a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs, which means no WordPress security plugin, no Joomla access rule and no login screen is involved. CVE-2026-109618 is validated over HTTP against mod_php with default limits, and the session upload progress route into CVE-2026-109619 is validated against both mod_php and PHP-FPM. A pair of 9.2 vulnerabilities in the layer under every site you run, reachable without an account, is the case for treating the host’s update as urgent rather than routine. The Joomla project took the same view of its own servers and took joomla.org offline on 21 October, downloads and update services included; what the joomla.org outage means for your Joomla sites has its own post.

PHP belongs to your host, not your CMS

There is no PHP version setting inside WordPress or Joomla. The version your pages run on is chosen on the server, so the fix for a PHP flaw is applied by whoever runs that server. Your job is to know which of your sites are exposed and to make your host act.

Which PHP Versions Got the Fix?

PHP 8.2, 8.3, 8.4 and 8.5 all received a fixed point release. PHP 8.1 and anything older did not get an official release. Critical security fixes go to both the actively supported branches and the security-only branches, which is why 8.2 and 8.3 are included even though their active support has ended. The supported versions timetable on php.net shows the exact dates for each branch, and the end-of-life page lists every branch that has fallen off it.

PHP 8.2 users should notice how close to the edge they are. Its security window closes on 31 December 2026, so it got this fix but may not get the next one, and a site on 8.2 should already have a move to 8.3 or newer in the plan.

PHP branch	Status on 21 October 2026	Fixed in
8.5	Active support	8.5.12
8.4	Active support	8.4.27
8.3	Security fixes only	8.3.36
8.2	Security fixes only, ends 31 December 2026	8.2.35
8.1	End of life since 31 December 2025	No official release; source-only backport branch
8.0	End of life	No official release; source-only backport branch
7.4	End of life	No official release; source-only backport branch
7.3 and older	End of life	Nothing

The end-of-life rows need explaining, because “source-only backport branch” is a new thing. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1, on branches named PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 and PHP-8.1-CVE-2026-109618-109619, described as a “minimal mitigation for EOL version”. They exist to help people who build PHP from source or have no LTS vendor. There are no tagged releases and no binaries, so nothing a shared host’s control panel can offer, and PHP’s advice for 8.1 and older is unchanged: “some distributions and LTS vendors provide backported fixes, so contact your vendor for details, or upgrade to a supported version”. Linux distributions and LTS vendors received the patches in advance, so a distribution package may well include the fix, but that is the vendor’s work and the vendor’s timetable. For a site on an end-of-life branch, the plan should still be the move to a supported one.

One thing trips people up here. Being on the right branch is only half of it; the other half is the patch level within that branch, and a site on 8.4 that the host has not updated for a year can be further behind than a site on 8.3 that was patched last week. The full explanation of branches versus patch levels, and why the higher PHP number can be the more out-of-date one, is in its own post.

What Our Monitoring Shows About PHP Right Now

The figures below come from live Joomla and WordPress sites under active management, measured on 20 October 2026: agencies run their clients’ production sites through mySites.guru, so this is what real hosting looks like today, not a public survey of people who chose to answer.

PHP versions on the Joomla and WordPress sites we monitor

Every live site by the PHP branch it runs, grouped by whether that branch will get this release. Measured 20 October 2026.

All sitesJoomla sitesWordPress sites

On a supported branch, so this fix reaches them: 77.3%

PHP 8.5

9.8%

PHP 8.4

21.2%

PHP 8.3

33.0%

PHP 8.2

13.3%

End of life, so no patched build is coming: 22.7%

PHP 8.1

4.4%

PHP 8.0

1.7%

PHP 7.4

13.8%

7.3 or older

2.8%

On a supported branch, so this fix reaches them: 76.2%

PHP 8.5

9.2%

PHP 8.4

22.1%

PHP 8.3

32.7%

PHP 8.2

12.2%

End of life, so no patched build is coming: 23.9%

PHP 8.1

3.0%

PHP 8.0

1.8%

PHP 7.4

15.8%

7.3 or older

3.3%

On a supported branch, so this fix reaches them: 82.0%

PHP 8.5

11.7%

PHP 8.4

18.4%

PHP 8.3

34.6%

PHP 8.2

17.3%

End of life, so no patched build is coming: 18.0%

PHP 8.1

9.0%

PHP 8.0

1.2%

PHP 7.4

6.9%

7.3 or older

0.9%

PHP versions detected on the live Joomla and WordPress sites mySites.guru monitors, measured 20 October 2026. These are production sites under active management, because agencies run their clients' sites through mySites.guru, so it reflects what real sites run rather than a public survey. Bars share one scale across all three tabs.

Read the chart from the top. 77.3% of the sites we monitor are on a branch between 8.2 and 8.5, so they get this fix once their host applies the patched release. Those owners have one job, which is to make sure the host does it.

The other 22.7% are on PHP 8.1 or older, which is end of life and gets no official release no matter what the host does. Within that group, 16.6% of all sites are still on PHP 7 or older, running an interpreter that upstream stopped fixing years ago. The split by CMS is not even.

23.9%

of the Joomla sites we monitor run PHP 8.1 or older

end of life, so no patched build is coming

18.0%

of the WordPress sites we monitor run PHP 8.1 or older

WordPress still runs on PHP that upstream abandoned years ago

Detected on live Joomla and WordPress sites under active management, 20 October 2026. Joomla sites skew older than WordPress.

Release day itself showed how a fix spreads. The first sites we monitor reported a fixed version string at 12:44 UTC on 21 October, about fifty minutes before the advisories went public, because packagers and hosts who were notified in advance released their builds first. By 13:52 UTC, with the advisories out, 0.08% of live sites under active management reported a fixed release. The rest were waiting on their host.

Why Do So Many WordPress Sites Run End-of-Life PHP?

Because WordPress lets them. The official WordPress requirements recommend PHP 8.3 or greater, but the current WordPress line still marks PHP 7.4 as compatible, and 7.4 has been end of life since November 2022. Recent WordPress versions kept compatibility all the way back to PHP 7.2, which reached end of life in November 2020. The Core PHP compatibility matrix shows this release by release.

WordPress does this on purpose, so that an update never fails because of the PHP underneath it. The side effect is that nothing ever forces a WordPress site off an abandoned interpreter: the CMS keeps updating, the plugins keep updating, and PHP stays wherever the host left it years ago.

Joomla takes a firmer line. Joomla 5 requires PHP 8.1 as a minimum and recommends 8.3, and Joomla 6 requires PHP 8.3 and recommends 8.4, with the full list in the Joomla technical requirements. The WordPress 7 requirements make an interesting comparison. A firmer floor pulls sites forward when they upgrade, but it cuts the other way too: an old Joomla site that cannot move to a newer major version is pinned to whatever PHP its version supports, which is part of why the Joomla figure above is the higher one.

Does Your Host Actually Apply PHP Patches?

A PHP security release of this kind is a patch release inside a branch, for example 8.3.35 to 8.3.36. It is binary-compatible and a drop-in replacement, so a host can roll it out across its servers with nothing changing for the site owner, and well-run hosts apply these within days of publication. The release that can break things is the major or minor jump, say 8.1 to 8.3, because that can affect themes, plugins and extensions and needs the owner to test first. Do not confuse the two: a host telling you “PHP updates can break sites” as a reason not to apply a point release is describing the wrong kind of update.

Telling whether your host lags is simple once you know where to look. The PHP selector in your hosting control panel only lists the versions the host has installed on that server. If the patched release is not offered there, there is nothing you can set, and the useful move is a support ticket asking when it is coming. Check the version the site reports while serving a request rather than trusting php -v on the command line, because the CLI binary and the one serving your pages are often different builds; the amber and green post linked above explains why.

It helps to know where your host’s PHP comes from, because that decides how soon the fix can reach you. On release day the picture looked like this:

cPanel EasyApache 4 had fixed ea-php82, ea-php83, ea-php84 and ea-php85 packages (8.2.35, 8.3.36, 8.4.27 and 8.5.12) available by about 13:45 UTC, within minutes of the advisories. ea-php81 has no fix, because 8.1 has no release to package.
Ondřej Surý’s PPA (ppa:ondrej/php) had no fixed packages at 13:47 UTC. It will get the fix, with no ETA given, and it now builds only for Ubuntu 22.04 and 24.04. One trap: the PPA’s Release “Label” was renamed, so apt will not refresh its package lists until you run apt-get update --allow-releaseinfo-change-label, and a server in that state sits on stale lists with no warning and never sees the fixed packages when they do arrive.
Remi’s repository had no updates on release day, and php.net’s advice was to switch to distribution packages or build from source in the meantime.
CloudLinux was preparing fixed alt-php packages after the release. Its Imunify360 ModSecurity ruleset 8.83 blocks the public exploit, which is a WAF rule, not a PHP fix.
Distribution packages on Ubuntu, Debian and Red Hat backport security fixes without changing the upstream version number, so Ubuntu 24.04 stays on an 8.3.6-0ubuntu... package even once it is patched. A version-number check cannot see that fix. Read the package changelog or the distribution’s advisory instead of trusting x.y.z.

What You Can Actually Do About It

PHP Version Should Be Latest Supported Series

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

Find the PHP version each site reports, and whether it is a fixed one. mySites.guru records the version the site reports while serving a request, and for this release the PHP version check goes red when a site is at or below the last vulnerable patch: 8.2.34, 8.3.35, 8.4.26 or 8.5.11. Sites on 8.1 and older are flagged end of life, with 8.3 as the suggested target. There is a banner for the release on the dashboard, and the version is also available through the API and MCP, so you can pull the list into whatever you already use. Package suffixes such as -nmm1 are stripped before comparison. A distribution package that backports the fix without changing the version string is still flagged as unpatched until you confirm it with the host and record the back-port for that build.
Supported branch, 8.2 to 8.5: ask the host when they will apply 8.2.35, 8.3.36, 8.4.27 or 8.5.12, and select it in the control panel as soon as it appears there.
End of life, 8.1 or older: no official release exists, so plan the version upgrade now. Check first whether the CMS or an extension pins the PHP version, because that upgrade moves before PHP can. A Joomla 3 site is the classic case, and what to do with Joomla 3 sites still on an agency retainer covers that conversation with the client.
Across many sites, do it from one list. Whether you manage multiple Joomla sites or manage multiple WordPress sites, the PHP version is one column across all of them, and the CMS-side moves can be run as a mass upgrade from one dashboard.

The affected and fixed versions are now public, so the question has narrowed to which of your sites are still on a vulnerable one and which hosts have not moved yet. Seeing every site’s PHP version in one place is what turns that into a short job rather than an afternoon of logging into control panels, and a free audit shows you that list in a few minutes.

Timeline

18 Oct 2026, 17:23 UTC The fix is committed privately "Avoid state corruption via bailout", the commit behind both CVEs, is written three days before the release.
19 Oct 2026, 17:04 UTC The releases are tagged PHP 8.5.12 is tagged, with the other three branches, two days ahead of publication.
20 Oct 2026 PHP pre-announces a critical security release Two vulnerabilities rated CVSS v4.0 9.2, release set for 21 October at 14:00 UTC, every other detail withheld.
20 Oct 2026 The CVE IDs leak CVE-2026-109618 and CVE-2026-109619 appear on social media the same afternoon, followed by unconfirmed claims about what they are.
21 Oct 2026, 07:43 UTC Cloudflare's CTO reports early attacks An unverified claim, not acted on by PHP and disputed by other sources since. No evidence was published.
21 Oct 2026, 12:44 UTC The first sites we monitor report a fixed version About fifty minutes before the advisories went public, because packagers and hosts notified in advance released their builds first.
21 Oct 2026, 13:35 UTC Advisories and releases published PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, about 25 minutes ahead of the announced 14:00 UTC, with both CVEs confirmed as unauthenticated remote code execution.

The Joomla Content Editor (JCE) Hack, Four Months On

phil@mysites.guru (Phil Taylor) — Tue, 20 Oct 2026 19:34:55 GMT

It is four months since the JCE hack tore through Joomla sites in June 2026. The flaw in the JCE editor is patched, the headlines have moved on, and the attack has not. Unpatched JCE installs are still being compromised today, and mySites.guru is still finding fresh ones.

If you run Joomla sites for clients and have not checked every one of them since June, this post is for you. The full indicators of compromise, the find-and-fix tool and the complete timeline are on our JCE hack page. This is the shorter version: what happened, what a hit looks like, and proof the watching has not stopped.

What is the JCE hack?

JCE (Joomla Content Editor) is the most-installed editor extension on Joomla, sitting in the top two of our live extension ranking neck and neck with Akeeba Backup. CVE-2026-48907 is an improper-access-control flaw in the JCE extension that let an unauthenticated visitor import an editor profile and use it to upload and run PHP. The Joomla project, as CNA, rated it 10.0 Critical on CVSS 4.0; NVD scored it 9.8. No login is required at any step.

The chain is short. The attacker posts a rogue editor profile with a large negative ordering (-99999 is typical) so it floats above every real profile. That profile allows php and txt uploads with MIME validation switched off. A second request uploads a webshell through the JCE file browser. Two requests, no credentials, fully automated. The fix was released in JCE 2.9.99.5 on 3 June 2026, and the June pillar post walks through every step at length, so I will not repeat it here.

How the JCE hack unfolded

3 Jun
JCE 2.9.99.5 released
This release fixes CVE-2026-48907. Every version before it keeps the unauthenticated flaw.
Days later
Working exploit code public on GitHub
Within about a week of the patch, a proof of concept anyone can run is published.
16 Jun
CISA adds it to the KEV catalog
Known Exploited Vulnerabilities listing confirms active, in-the-wild exploitation.
Summer
The mass campaign
Botnets spray the published exploit at every reachable JCE install. Over 1,000 of the Joomla sites mySites.guru monitors are hit.
Oct
Four months on, still being found
Unpatched installs are still being compromised. The check keeps flagging new ones.

What we are still finding today

Numbers first, from the 24 hours before I wrote this.

16,464

rogue JCE editor profiles found and verified, last 24 hours

21,552

malicious files found and verified, last 24 hours

1,000+

Joomla sites we have found hit by this attack

100,000+

connections checked daily

The first three are confirmed findings, not estimates: in a single day the JCE check flagged and verified that many rogue profiles and malicious files across the Joomla sites we monitor, spread over the thousand-plus sites this attack has hit. The fourth is the scale behind them. We check more than 100,000 site connections a day, so a fresh compromise shows up on the next snapshot rather than whenever someone next happens to log in. Four months on, the numbers are not shrinking, because the long tail of unpatched sites keeps feeding them.

The check is called Check for JCE Rogue Profiles & Backdoors. It runs on every snapshot, twice a day, on every connected Joomla site. It finds the rogue profiles and the webshells automatically, and when it flags something you fix it from one screen: remove the rogue profiles, delete the backdoor files and update JCE, on Joomla 4, 5 and 6. It never deletes anything on its own. It lists everything first so you can take a copy for evidence before you clean.

To find every still-vulnerable install, the extension search lists every site running JCE grouped by version, and the mass updater patches them all in one batch. Twenty sites or two hundred, it is one job.

How far the JCE hack reached

This was never a story about neglected sites with no one watching them. In June the attack took down the Joomla project’s own flagship sites at once: the official Joomla Extensions Directory at extensions.joomla.org, community.joomla.org and certification.joomla.org all served “503 Maintenance” pages. Those sites are run by people who know Joomla security better than almost anyone.

That is the whole point. JCE is installed so widely that any site running an old copy was exposed, and competence did not protect you. An exploit that needs no login hits every reachable install in the same sweep, and the only thing that mattered was whether your JCE was patched before the bots reached it. No amount of .htaccess hardening stood in the way either, because the requests look like ordinary POSTs to an extension the site is supposed to serve.

How to tell if your Joomla site was hit

The rogue profiles are easy to recognise once you know the shape. Most have machine-generated names: a capital J followed by six digits, J940401, J938560 and so on. Some attackers did not bother with subtlety and named theirs “Pwned” with the description “RCE via JCE”. If a profile like that sits at the top of your JCE profiles list, you have been hit.

The webshells were dropped in tmp, media, images and the libraries tree: hidden .xml.php droppers, eval(gzinflate(base64_decode(…))) blobs, shell_exec command shells and small “Nxploited” marker files. Our backdoor scanner picks these up, and so does the dedicated JCE check described above.

The access logs give it away in two lines: a POST to task=profiles.import that creates the profile, then a POST to method=upload that drops the shell. Both return 200, both unauthenticated. The requests came from many different IPs with python-requests user agents. This was a botnet spraying a published exploit, not a targeted attack, which is why one vulnerable site is almost never the only one in a portfolio. mySites.guru has now found this attack on over 1,000 of the Joomla sites it monitors.

Is the JCE hack still a threat?

Only if you are running an old version. A fixed CVE is a closed chapter for the sites that updated. For the long tail that did not, the chapter is still open, which is exactly why we are still finding this four months on. The exploit code is public, the bots never stopped, and every Joomla site still on a vulnerable JCE is as exposed today as it was on 3 June.

If this feels familiar, it should. In 2012 the JCE ImageManager flaw (CVE-2012-2902) let unauthenticated visitors upload files through JCE, and automated bots kept exploiting it for years after the patch existed, purely because so many installs were never updated. The patch fixed the software; it did nothing for the sites that never installed it.

The JCE hack was a starting gun

Days after the JCE hack, a friend told me Joomla extensions were more secure than WordPress plugins. I disagreed. The gap is attention, not security. WordPress plugins have bug-bounty programmes and a black market that pays for working exploits, so thousands of researchers pick at them. Almost no one scrutinises Joomla extensions with the same intent.

So we went looking. Between mid-June and late July, mySites.guru found and privately disclosed 19 vulnerabilities across 17 Joomla extensions, written up in Nineteen and Counting. For over a week it was one or two critical, mostly unauthenticated remote-code-execution flaws a day.

That was just the first month. Four months on the count is well past nineteen and still climbing, and we are holding more that we cannot name until their vendors patch.

The bugs were always there. No one was looking. The JCE hack made people look, and it has pushed Joomla extension developers to take security more seriously.

The worst extension flaws we have found since

The worst ten, the critical and mostly unauthenticated ones. The four marked in red were being exploited in the wild, so CISA added them to its Known Exploited Vulnerabilities catalog.

Another two dozen sit in the full disclosure archive, every one found by us and reported privately before it went public.

Is JCE safe to use?

JCE is not the cautionary tale in this post. Ryan Demmer of Widget Factory has developed it since 2006, it is the most-installed editor on Joomla, and it is a mature, carefully engineered extension. When CVE-2026-48907 came out, the response was the one every vendor should copy: the fix in 2.9.99.5 within days, a four-day audit of the whole editor and a hardening release (2.9.99.6) within a week, a run of further security and maintenance releases after that, a free patch for sites stuck on end-of-life PHP or Joomla, and a clear public advisory. One bad bug, owned fast and thoroughly.

Not every Joomla extension is run like that. Since the JCE hack we have had to report critical, mostly unauthenticated flaws in the same products again and again. SP Page Builder is the clearest case: five separate disclosures from us in four months. Some vendors patch fast and completely, as Ryan Demmer did. Others leave the same class of hole open release after release. A good extension is one whose developer responds like that when it matters, and the real risk is the long tail whose vendors do not. That is the whole reason to have every site watched.

I patched JCE. Am I still at risk?

Patched is not the same as clean. If a site ran a vulnerable JCE for any length of time before it was updated, it could already have been compromised, and a webshell sitting on disk does not care that the entry point is now shut. Updating closes the door; you still have to check whether anyone walked through it first.

Patching in June does not mean the site is clean

A rogue profile planted before the update is still in the profiles list after it. A webshell dropped in tmp or media still answers requests after it. Check every site that ever ran a vulnerable JCE, whatever version it runs now, and treat a clean result as today’s result rather than a permanent one.

That is the argument in hacked yesterday, exploited today: a one-off cleanup is a snapshot, and only ongoing monitoring tells you a site is still clean next week.

Which JCE version is safe?

The rule is simple: if your JCE is anything below 2.9.99.5, the unauthenticated profile upload (CVE-2026-48907) is open on your site, and that covers every Free and Pro release back through the 2.8.x and 2.7.x branches.

JCE version	Where it stands
2.9.99.4 and earlier (incl. 2.7.x, 2.8.x)	Vulnerable: the unauthenticated profile-upload flaw
2.9.99.5 to 2.9.99.11	Patched, but superseded
2.9.99.12	Current, for Joomla 3 and 4
3.0.2	Current, for Joomla 5 and 6 (needs PHP 8)
2.6.x	Not affected by default, but unsupported: migrate

Update to whichever current release matches your Joomla and PHP version. If the site is stuck on end-of-life PHP or Joomla and cannot take that update, the JCE developer has published a free security patch package covering 2.7.x, 2.8.x and 2.9.x. Treat it as a stopgap. It closes this one flaw and nothing else, and it does not clean a site that was already compromised before you applied it.

Why mySites.guru matters when a hack like this breaks

If you run a digital agency, the worst phone call you can get is a client telling you their site has been hacked. The sting is not the fix, it is that they knew before you did. mySites.guru exists to prevent that call.

Every client site you look after connects through a lightweight connector, and from then on a snapshot runs on every site twice a day. So when a hack like this breaks, you do not log into each admin panel one by one to work out who is exposed. You open extension search and within seconds you have every connected site running JCE, grouped by version. You can pinpoint which sites are affected, decide which to fix first and how fast, and get ahead of it before your clients even know there was a problem. That triage is simple when every site is in a single tool, and slow and error-prone when it is not.

Fixing is just as quick. The mass updater upgrades JCE across every affected site in one batch, or reinstalls a clean copy over the top. Enrol the extension in automatic overnight updates and the next release goes on without you lifting a finger. Then run a full audit: hundreds of checks per site, including hacked-site detection for rogue JCE profiles, rogue admins, suspect content and webshells, with clear guidance on every finding and help from us throughout.

If you would rather hand the whole thing over, fix.mysites.guru is a flat £120 per incident, usually done the same day. We screen the site first, so you are not charged if we cannot fix it, and non-subscribers get a free month on top.

I have been doing this since 2012. Fourteen years, 90,000+ sites protected, 1,000,000+ audits completed, and I will say it straight: no other platform brings this combination of Joomla expertise, support and toolset to a moment like this. One subscription covers unlimited sites.

Connect your first site free. No card, about two minutes.

YOOtheme Pro 5: A Critical Security Update Is Coming on 21 October

phil@mysites.guru (Phil Taylor) — Tue, 20 Oct 2026 17:42:13 GMT

Update, 21 October 2026: YOOtheme Pro 5.0.53 is out

YOOtheme has released 5.0.53, the fix for CVE-2026-102785, an unauthenticated remote code execution via the image handler. Every YOOtheme Pro 5 build before it is affected. Update every Pro 5 site now and read the full write-up.

YOOtheme has given its customers advance notice of a critical security update for YOOtheme Pro 5, the Joomla page-builder template. The patched build is due on Wednesday 21 October 2026 at 16:00 CEST (14:00 UTC) and will appear in the YOOtheme Pro changelog. Every site running YOOtheme Pro 5 should update the moment it is out. YOOtheme Pro 4 and earlier are not affected.

Here is the vendor’s own notice, sent 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. This advance notice gives you time to prepare for the update. All users running YOOtheme Pro 5 must update immediately once the new version becomes available. YOOtheme Pro 4 and earlier versions are not affected.” A day of advance notice is unusual for a Joomla extension vendor, and it is the right call: it gives anyone looking after a portfolio of client sites the evening to take backups and line up the sites that will need the update.

YOOtheme's advance-notice email to customers, 20 October 2026.

What we know so far

Very little, and that is deliberate. We did not find this flaw and we have not investigated it; it was reported to YOOtheme by a third party, and the fix is not out yet. Publishing a guess at an unpatched critical issue only helps the people you do not want to help, so we are not going to describe something we have not seen fixed.

What the vendor has stated is the whole of it: the issue is rated critical, it affects every YOOtheme Pro 5 build, YOOtheme Pro 4 and earlier are not affected, and the fix is due on 21 October at 16:00 CEST. Once the release is out we will publish a full write-up here with the fixed version number and, if one is assigned, the CVE.

Only YOOtheme Pro 5 is affected

YOOtheme has been specific that this is a Pro 5 issue and that Pro 4 and earlier are not affected. Pro 5 runs on modern Joomla and is a separate codebase from the Pro 4 line, so the first job tonight is a version check. A site still on YOOtheme Pro 4 has nothing to do here, and time spent updating it tomorrow is time taken from the Pro 5 sites that need you.

mySites.guru already flags YOOtheme Pro 5

If your Joomla sites are connected to mySites.guru, the version check is done for you. A detection rule added on 20 October 2026 flags any connected site running YOOtheme Pro 5, so your next site snapshot lists exactly which sites need the update when the fix is out. YOOtheme Pro appears in the Joomla Vulnerability Database alongside the other extensions we track, and the alert clears when a later snapshot sees the patched version.

The rule went in a day before the patch exists, which is the point. Most vulnerability alerts arrive after the fix, when the job is “update this”. This one arrives before, when the job is “know which sites to update at 16:00 CEST tomorrow”. If you manage more than a handful of Joomla sites, that list is the value of the alert; see managing multiple Joomla sites for how the rest of the workflow fits together. A free site audit shows the same finding on a site you have not connected yet.

What to do before the release

There is nothing that pre-empts this fix, so tonight is about preparation: a clean backup and a known list of the sites that will need the update.

Confirm which sites run YOOtheme Pro 5. Pro 4 and earlier need no action.
Take a fresh backup of every Pro 5 site before the release, so you can restore cleanly if an update goes wrong.
Line up the affected sites in one list so you can move quickly tomorrow. mySites.guru builds this for connected sites.
Update every YOOtheme Pro 5 site as soon as the build appears in the changelog at 16:00 CEST on 21 October 2026.
Re-snapshot each site in mySites.guru afterwards so the alert clears.

We will publish the full write-up here once the release is out on 21 October.

Timeline

2026-10-20 YOOtheme gives advance notice of a critical YOOtheme Pro 5 security update The vendor tells customers that all YOOtheme Pro 5 sites must update as soon as the new version is available, and that YOOtheme Pro 4 and earlier are not affected. mySites.guru adds a detection rule for YOOtheme Pro 5 the same day.
2026-10-21 Patched YOOtheme Pro 5 release due at 16:00 CEST (14:00 UTC) Update every YOOtheme Pro 5 site as soon as the release appears in the changelog. A full write-up will follow here once it is out.

The Fake Cloudflare Captcha Hiding in WordPress Core's functions.php

phil@mysites.guru (Phil Taylor) — Mon, 19 Oct 2026 23:11:49 GMT

A visitor opens one of your pages and a box appears that looks like Cloudflare asking them to prove they are human. Instead of a tick box, it tells them to open the Windows Run dialog and paste a command. The ones who follow the instruction infect their own PC. You, the site owner, usually hear about it from that visitor, not from the usual signs a WordPress site is hacked, because in some of these campaigns the lure never shows itself to anyone logged in as an administrator.

On 19 October 2026 an agency customer sent us exactly that report about a WordPress site. We found the injection at the top of wp-includes/functions.php, a WordPress core file, rather than in a plugin or the theme. That is the one place most clean-up guides never tell you to open, and it is also the one place a malware hash list can never match. mySites.guru had already flagged the file twice before anyone here knew this variant existed, using checks that were never written for it, and since 19 October audits look for this exact variant too.

What the fake Cloudflare captcha does to a visitor’s PC

The lure is a social-engineering technique called ClickFix. Proofpoint first saw it in March 2024 and gave it the name, and by November 2024 it was describing the “Verify You Are Human” fake CAPTCHA variant flooding the threat landscape. The page shows a convincing verification box. Instead of a real check, it tells the visitor to open the Run box and paste a command the page hands them, and that command fetches and runs malware on their machine.

What the visitor sees: a copy of Cloudflare's verification page. Image: Sucuri.

The payloads seen in these campaigns include infostealers such as Lumma and Vidar and remote-access tools such as NetSupport RAT, according to Proofpoint’s 2024 brief and Rapid7’s March 2026 report. Rapid7 counted 250+ WordPress sites in 12+ countries serving a fake Cloudflare CAPTCHA since December 2025, and noted that the script hid itself from logged-in administrators.

Microsoft Threat Intelligence lists compromised websites as one of ClickFix’s main arrival routes, and that is where your WordPress site comes in. The attacker is after your visitors rather than your site, and your domain is what lends the fake box its credibility. Our own inference from the Rapid7 finding: because the script hides from the one account that would recognise it as wrong, and only renders on the front end, the site owner is often the last person to see it.

Why hide a fake captcha in WordPress core instead of the theme?

Because no one opens core files. On the site we looked at, the loader sat right after the opening lines of wp-includes/functions.php, with the theme and the plugins untouched. Every public write-up we read puts this family somewhere else: a plugin, the theme’s functions.php or header.php, mu-plugins, or the database. Sucuri’s May 2025 write-up has the fake Cloudflare verification injected into the header.php of every installed theme, with victims told to press Win+R and paste a PowerShell command. None of the write-ups we read shows it inside a WordPress core file.

We think core is the better hiding place. A site owner never opens a core file and never edits one, so nothing about it looks changed to the person who built the site. A theme injection is gone the moment someone switches theme; a core injection is still there. And the only time WordPress replaces wp-includes/functions.php is a core update, so until the next one ships, the lure stays put.

The hook is the clever part. The injected function attaches to get_footer, so every front-end page that renders a footer prints the lure, whatever theme is active. The same lure has turned up on Joomla 3 sites running abandoned JoomShaper extensions, which is one reason the detection we built for this ships for every platform rather than WordPress alone.

How the WordPress core injection is built

Two parts, PHP and JavaScript. The PHP part is a small function with a random-looking name that drops out of PHP mode and prints a script block, plus one line hooking it onto get_footer. The script is a single line of about 179 KB that decodes itself three times in the browser before it runs, and the code it finally runs is obfuscated again. We decoded it offline and never ran it.

Why this post describes the code in words

A page that reproduces the loader’s own strings starts matching the scanners that look for them, and makes our own page look like the payload.

The security research teams have already taken these loaders apart in far more detail than we would print here. If you want to see the actual code, these are the write-ups to read, and why:

Rapid7, March 2026: the most complete recent teardown. It shows the injected script checking for a logged-in administrator cookie so it can hide from you, base64-decoding its endpoints, and pulling a second-stage loader from the site’s own admin-ajax.php.
Sucuri, February 2025: the fake reCAPTCHA variant, found in random five-character plugin folders, a fake analytics plugin and the theme’s functions.php, with a misspelled .htaccess backdoor alongside. Read it for the list of places to look besides core.
Sucuri, May 2025: the fake Cloudflare page this post’s screenshot comes from, injected into header.php of every installed theme. Read it for the visitor side: the exact steps the lure walks someone through.
GoDaddy, October 2024: attackers logging in with stolen admin passwords and installing fake plugins named after real security and caching plugins, which then hook the lure onto every page. Read it if you think a strong host stops this.
Sekoia’s IClickFix analysis: a framework seen on thousands of WordPress sites that serves a fake Cloudflare Turnstile and NetSupport RAT. Read it for how the same lure is run as a managed campaign rather than a one-off hack.
Trend Micro, March 2026: the KongTuke chain from injected JavaScript to fake CAPTCHA to PowerShell to a Python backdoor. Read it to see what happens on the visitor’s PC after they press Enter.
Sucuri on mu-plugins malware, February 2025: code hidden in must-use plugins behind base64, ROT13 and AES layers. Read it for why a clean-up that skips mu-plugins is not finished.

Why can’t a malware hash list catch it?

Because a hash list matches the whole file, and an injection into a core file makes a different whole file on every site. mySites.guru’s Hacked Files tool lists a file only when the MD5 of the entire file matches a file already confirmed as hacked. That is what makes its results facts rather than guesses, and it is why that tool has no false positives. The cost of that certainty is that the injected bytes plus that version’s wp-includes/functions.php make a hash no other site shares, and the next WordPress release changes the core half again. We could confirm a thousand copies and the next one would still be a new hash.

Two other instruments do see it. The core file integrity check compares each core file against the release, so a modified wp-includes/functions.php is listed as modified, with the change shown and a revert to the original on offer. And Suspect content matches on what a file contains rather than what it hashes to, so the injected code matched a pattern. The difference between those two tools explains the gap: content matching saw the file, hash matching structurally could not, and only the hash match sets the site’s hacked flag.

Suspect content versus a hacked site

These two words get used as if they meant the same thing, and on this site the gap between them was the whole complaint. We wrote up the difference between Suspect content and Hacked files in full, and this case is the textbook example of it.

Suspect content means a file’s content matches one or more of our 1,500+ hand-written hack patterns, checked against every file in the webspace, line by line. It is a heuristic, so false positives are expected: legitimate code uses the same PHP functions hackers use. It also means something people tend to miss. The Suspect content list can hold real hacks that no one has confirmed yet, and a fresh injection like this one sits there first, because its content matches the moment it is scanned.

A hacked site, in mySites.guru terms, is one where a file has been confirmed: its whole-file hash matches a file already proven to be malware, or, since 19 October, it matches a fingerprint for a known family like this one. That is a fact, not a guess, and it is what turns the site’s hacked flag on and sends the alert.

So the order of work on any audit is the same. Treat anything in Hacked Files as a compromised site and start the clean-up. Then work down the Suspect content list, using the AI malware analysis on anything you cannot judge by eye, because a file there may be the next confirmed hack. Here, a modified core file plus a Suspect content match on the same file was enough to act on, before any flag went red.

mySites.guru was already catching it

No one at mySites.guru had seen this variant before the report arrived, and no check had been written for it. The audit flagged the file anyway, twice, because the checks that caught it do not need to know what a hack looks like in advance. The next variant will not look like this one either, and the same checks will be the first to see it.

Core file integrity check: Compares every WordPress core file on the site against the original from that release. It does not care what was added or why: any core file that differs is listed as modified, with the change shown and a one-click revert to the original. That is how wp-includes/functions.php was on the list before anyone had read a line of the injected code.
Suspect content: Reads every file in the webspace, line by line, and matches it against more than 1,500 hand-written patterns built from real hacks. None of them was written for this loader, and it matched anyway, because obfuscated code that decodes itself and runs the result looks like the hacks the patterns came from.
AI malware analysis: One click on a suspect file sends it to Claude or OpenAI with your own key and comes back with a safe, suspicious or malicious verdict. A malicious verdict adds the file's hash to the confirmed list, so it moves into Hacked Files for that site.
Hacked Files (100% Certain): The one tool that did not list it, by design. It only names a file whose whole-file hash matches a file already confirmed as hacked, which is why it never raises a false alarm, and why an injection that hashes differently on every site can never appear there without a confirmation first.

What the customer saw before we changed a thing

The core file integrity check listed wp-includes/functions.php as modified, and Suspect content matched the injected code. Hacked Files was empty, so the site’s hacked flag stayed off. The customer’s complaint was fair: “I’d consider this site hacked.” So would we, which is why we changed it.

Now mySites.guru looks for this exact variant too

On 19 October 2026 the connector learned this family by name, for every platform mySites.guru manages: WordPress, Joomla 3, 4, 5 and 6, and Generic sites. Audits now recognise it by its content, using two independent fingerprints: the decode chain itself, and the PHP injector function hooked onto the theme by its own name. Either one marks the file hacked, and so the site, wherever the file sits: a core file, a theme file, or a standalone .js or .html file. Sites pick up the new check when their connector updates itself, which happens automatically.

Both fingerprints were tested before they shipped. They matched zero of the 1,390,834 PHP, JavaScript and HTML files we ran them against, a set made of vendor libraries, node modules and real site copies. They also ignore the near-misses that would otherwise generate noise: a lone base64 decode, a lone XOR loop, or a footer function hooked onto something else.

The general checks stay where they were, and they are still the ones that will catch the next variant first. The AI malware analysis prompt now names ClickFix fake-captcha lures explicitly, so a sample with a different decode chain still gets a malicious verdict. For the reported site I confirmed the infected files by hand, so a fresh audit shows them in Hacked Files.

How do I clean a fake captcha out of WordPress core?

Put the core file back first, then go looking for everything else, because the modified core file is the symptom you can see and the way in is the one you cannot.

Put the core file back. The integrity check lists every core file modified since release, shows the change, and reverts it to the original. Without mySites.guru, wp core verify-checksums lists every core file that differs from WordPress.org’s checksums, and you replace each one from a clean copy of the same version.
Check the usual places. The active theme’s functions.php and header.php, the plugins folder, mu-plugins, and the database. The half of a WordPress hack that is not a file lives in wp_options rows, scheduled WP-Cron events, drop-ins and hidden administrators, and any of those can put the lure back after you revert the file, as can a crontab you did not write. Files added to folders that WordPress owns but never shipped are an impostor-file check of their own.
Look for a second WordPress install. The site in this post had one nested inside the live one, infected. A nested copy has its own files and its own database tables, and a clean-up that only touches the outer site leaves it running.
Remove unknown administrators and reset passwords. Delete any administrator you did not create, then change the password on every account that remains, plus the database and hosting passwords.
Find the way in, then re-audit. Close the entry point or the lure comes back. Run a full audit afterwards and keep running them, because a site cleaned yesterday is exploited again today when the door is still open.

The same checks run on every connected site from the WordPress malware scanner. If you would rather hand the whole job over, fix.mysites.guru takes a hacked site at a set fee.

A modified core file means the site is hacked, not just the file

Reverting wp-includes/functions.php takes the lure away from your visitors and leaves the way in exactly where it was. Treat the revert as the first step of a clean-up, and the audit after it as the one that counts.

How do I clean a fake captcha out of WordPress core with mySites.guru tools?

The same clean-up, without an FTP client or a WP-CLI session, from the audit that found the problem. Work down the list in this order, because each step removes something the next one would otherwise trip over.

Revert the core file. Open the core file integrity check, click wp-includes/functions.php, and you get a side-by-side diff with the original on the left and the infected copy on the right. Revert it to the original from there.
Clear the files. Start with Hacked Files, where every entry is confirmed, then work down Suspect content. Click any file to see the exact matched lines, then edit it in place or delete it. Anything you cannot judge by eye goes through the AI malware analysis. For anything outside the flagged lists, the opt-in web file manager lets you browse, edit, upload and delete files across the whole site with no SFTP client.
Clear what is not a file. Malicious WP-Cron Events lets you unschedule the event that would rewrite what you just deleted. Suspect WP Options shows a flagged row a value at a time and deletes it. Must-Use Plugins and Drop-ins lists every must-use plugin and drop-in WordPress loads, with any hidden one flagged, and Malicious Cron Jobs reads the server crontab for a job that downloads the payload again.
Remove the attacker’s way back in. Rogue and Hidden Administrators reads the administrator list straight from the database as well as the way your Users screen does, and deletes an account with its content reassigned to one that stays. A password reset never revokes Application Passwords, so revoke every WordPress Application Password in one click as well.
Re-audit, and keep auditing. Run a fresh audit and check that Hacked Files is empty, the core file integrity check is clean and the Suspect content list holds nothing you have not already judged. Every connected site gets the same checks, so one fake captcha is a reason to look at the other sites in that hosting account too.

If the site is too far gone to do it yourself, fix.mysites.guru does the whole clean-up at a set fee.

How This Shows Up in Real Life

The report came in on 19 October 2026 from an agency customer. Visitors to one of their WordPress sites were being shown a fake Cloudflare “verify you are human” box telling them to open the Windows Run box and paste a command. While looking, the agency also found what they described as “an infected WP site inside the live WP site”: a second WordPress install, nested inside the first, and infected as well.

Their mySites.guru audit had already flagged the core file as modified and matched the injected code under Suspect content, with Hacked Files empty, and their complaint that they would consider the site hacked was the right one. By the end of the day the connector had the two new fingerprints, the AI prompt named the lure, and I had confirmed the infected files by hand, so a fresh audit lists them in Hacked Files.

We do not name the customer or the site in these posts. A fake Cloudflare captcha on a WordPress site is an attack on your visitors delivered through your domain. It can sit in a core file none of the guides tell you to open, and a scanner that only knows bad files by their hashes will never see it. If a visitor tells you they saw one, read the first few lines of wp-includes/functions.php before you read anything else, and then audit the whole site, because the file is never the whole hack.

How to add exception for mySites.guru in Admin Tools

phil@mysites.guru (Phil Taylor) — Mon, 19 Oct 2026 11:50:51 GMT

A Joomla site running Akeeba’s Admin Tools Professional can block mySites.guru in two separate places, with two separate symptoms. The .htaccess Maker returns 403 Forbidden to the connector itself, so connecting or reconnecting the site fails. The Web Application Firewall bans our IP after a handful of blocked requests, and the only thing that stops working is backups. This post is the reference for both: which list the exception goes in, what to type, what it writes into .htaccess, and why fixing one does nothing for the other.

mySites.guru already points you at the first fix. When the last connection error for a site contains a 403, the reconnect screen tells you to add the .htaccess Maker exception. For the second, the Backup tab spots the WAF ban during the twice-daily snapshot and clears it in one click. What follows is the long version, for anyone who wants to do it by hand or understand what the buttons change.

The short version

In the Joomla administrator go to Components, Admin Tools, Server Config. File Maker, open the .htaccess Maker and find the Server protection card. In the list labelled “Allow direct access, including .php files, to these directories” add a new row with the path plugins/system/bfnetwork, then choose “Save and create .htaccess”. If audits run but backups fail with 403, that is the Web Application Firewall instead: click “Unblock our IP” on the site’s Backup tab in mySites.guru, or add 178.62.5.35 to “Never block these IPs” in the WAF.

What Is Akeeba Admin Tools?

Admin Tools is a Joomla extension from Akeeba Ltd, whose founder and lead developer Nicholas K. Dionysopoulos has been building it since 2010. Akeeba also makes Akeeba Backup, the extension mySites.guru drives when it takes a backup of your Joomla site. Akeeba describes Admin Tools as “Administration and security improvements for Joomla! sites”. It comes in two editions, Core (free) and Professional (paid), and there is a separate Admin Tools for WordPress with its own feature set.

Core covers the housekeeping side: Password-protect Administrator, Emergency Off-Line, Fix Permissions, Database Tools, Clean Temp-Directory, Temporary Super Users, Obsolete Core Files and the Site IP Allow List. Professional adds the parts that actively defend the site: the Web Application Firewall (with Configure WAF, automatic IP blocking of repeat offenders, the Site IP Disallow List and a Blocked Request Log), the .htaccess Maker along with an NginX Configuration Maker and a web.config Maker for other web servers, the PHP File Change Scanner, and a set of Joomla CLI commands. The current release supports Joomla 4.4 to 6.2.

We recommend it. One of mySites.guru’s own checks, “Use A Joomla Core Or Akeeba Admin Tools .htaccess File”, points you at the Admin Tools .htaccess builder because it produces a tighter file than Joomla’s stock htaccess.txt, and in our own AcyMailing disclosure the Professional WAF blocked a real SQL injection attack in its default settings. Those two Professional features, the .htaccess Maker and the Web Application Firewall, are also the two that block mySites.guru, each in its own way. The rest of this post covers the two settings that let Admin Tools keep doing its job while mySites.guru does ours.

Which Admin Tools Block Is Your Joomla Site Hitting?

A 403 when you connect or reconnect the site, or on every audit, is the .htaccess Maker. Audits and snapshots running normally while every backup fails with 403 Forbidden is the Web Application Firewall. The two features do not affect each other, so match the symptom before changing anything, or you will fix the wrong one and conclude the fix does not work.

.htaccess Maker: Symptom: 403 Forbidden on connect, reconnect or audit, and nothing from mySites.guru works. Cause: Server Protection rules in .htaccess block any .php file under plugins/ before PHP runs. Fix: add plugins/system/bfnetwork to the list that allows direct access including .php files, then write the new .htaccess.
Web Application Firewall: Symptom: audits, snapshots and tools all work, but backups fail with 403 Forbidden. Cause: the WAF auto-banned the mySites.guru IP after repeated blocked requests, and backups are the one job that goes through index.php. Fix: click Unblock our IP in mySites.guru, or add 178.62.5.35 to Never block these IPs in the WAF.

How Admin Tools’ .htaccess Maker Blocks the Joomla Connector

On Joomla, mySites.guru connects through a system plugin installed at plugins/system/bfnetwork. Its PHP files live one level down, in plugins/system/bfnetwork/bfnetwork/, and the service requests them directly over HTTPS rather than through Joomla’s index.php. The connection test is bfPing.php; audits, snapshots, tools, auto-login, restores and upgrades each have their own entry points, and there are more than fifty PHP files in that folder. We have written before about hosts misreading the bfnetwork connector plugin, and the .htaccess Maker misreads it in a similar way: as a stray PHP file in a folder where PHP should not run.

Server Protection is designed to stop that. With “Frontend protection” on, which is the default, the .htaccess Maker writes rules that only allow listed file types inside the “Frontend directories where file type exceptions are allowed”. The default set is components, modules, templates, files, images, plugins, media and libraries. PHP is not an allowed type, so any .php request under plugins/ gets 403 Forbidden:

RewriteRule ^(components|modules|templates|files|images|plugins|media|libraries)/.*\.(jpe|jpg|...)$ - [L,NC]
RewriteRule ^(components|modules|templates|files|images|plugins|media|libraries)/ - [F]

There is a second, site-wide option that does the same job more broadly: “Disallow access to all other PHP files throughout the site, unless they are explicitly allowed”. It writes:

RewriteCond %{REQUEST_FILENAME} (\.php)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule (.*\.php)$ - [F]

Either way Apache blocks the request before a single line of PHP runs. The connector does not see it and Admin Tools’ own firewall does not see it either, which is why no WAF setting, allow list or log entry has any bearing on this 403. The fix has to be in the same place as the block: the generated .htaccess.

Adding the Exception in the Joomla .htaccess Maker, Step by Step

You need Admin Tools Professional; the free Core edition has no .htaccess Maker, and a Core site returning 403s has a different cause (covered at the end). Labels below are from Admin Tools 7.9.3. Older documentation and forum threads call the page the “.htaccess Maker”, Admin Tools 7 lists it under Server Config. File Maker, and both names refer to the same page.

Check the label word by word before you type

Admin Tools puts three exception boxes one after another, and their labels are nearly identical:

“Allow direct access to these files”
“Allow direct access, except .php files, to these directories”
“Allow direct access, including .php files, to these directories”

The mySites.guru exception goes in the third box only, the one that says including .php files and ends in directories. The second box differs by a single word and looks right, but it keeps every PHP file blocked, so the connector still gets a 403. The first box is for single files: do not put bfPing.php, or any other connector file, in it by name. Allow the whole plugins/system/bfnetwork folder in the third box instead. If the connection still fails after you save, the wrong box is the first thing to check.

In the Joomla administrator go to Components, Admin Tools, Server Config. File Maker, and open the .htaccess Maker.
The page has no tabs. It is a stack of cards: “Basic security”, “Server protection”, “Custom .htaccess rules”, “Optimisation and utility” and “System configuration”. Open “Server protection”.
Scroll to the sub-heading “Exceptions from Server Protection”. These lists are only shown while “Backend protection” or “Frontend protection” is set to Yes, so if you cannot see them, that is why.
Find the third box, labelled “Allow direct access, including .php files, to these directories”. Read the label to the end before typing: it must say “including .php files” and “directories”. This box has one default row, installation, which is a good way to confirm you are in the right one. Leave that row alone.
Use the Add button to create a new row. Each row shows a fixed / in front of the text box, so enter the path with no leading slash, no trailing slash and no domain: plugins/system/bfnetwork. A full URL will not match.
Choose “Save and create .htaccess”. The same dropdown also has “Save without creating .htaccess” and “Preview”. If you use the plain save, Admin Tools reports “Changes have been successfully saved. Do not forget to apply them by creating the new .htaccess file” and the file on disk stays as it was, which catches a lot of people out.
On success Admin Tools reports “The new .htaccess has been written to disk”. Your previous file is kept as .htaccess.admintools in the site root, which is your rollback if anything else on the site objects.

If the site runs on NginX or IIS, the NginX Configuration Maker and the web.config Maker have the same three lists with the same labels and defaults. The same path goes in the same-named list, followed by “Save and create nginx.conf” or “Save and create web.config”.

Which of the Three “Allow Direct Access” Lists?

Three lists sit next to each other under Exceptions from Server Protection, with similar names, and picking the wrong one is the commonest reason the fix “does not work”. Their labels and defaults in 7.9.3:

Allow direct access to these files: Individual files. Defaults: the restore.php scripts of Akeeba Backup (com_akeeba and com_akeebabackup) and of Joomla Update (com_joomlaupdate), plus Joomla Update's extract.php, all under administrator/components. Wrong for mySites.guru, because the service calls many files in the connector folder and new ones arrive as features ship.
Allow direct access, except .php files, to these directories: Whole directories, but PHP stays blocked. Default: .well-known. Looks right and does not help, because the files we need are the PHP ones.
Allow direct access, including .php files, to these directories: Whole directories, PHP included. Default: installation. This is the one. Add plugins/system/bfnetwork here.

The first list is how Akeeba handles its own direct-access scripts: Akeeba Backup’s restore.php is in it by default. Never use it for the mySites.guru connector. Listing bfPing.php or any other connector file by name lets that one file through while the rest of the connector keeps getting 403, and every new release adds files the list does not know about. Allow the whole plugins/system/bfnetwork folder in the directory list instead.

What the Exception Writes into .htaccess

The third list writes one line into a block marked ##### Advanced server protection rules exceptions -- BEGIN and -- END, which Admin Tools places before the ##### Advanced server protection -- BEGIN block:

RewriteRule ^plugins\/system\/bfnetwork/ - [L]

Admin Tools escapes the slashes and dots for the regex. The [L] flag stops rewrite processing for anything matching that path, so the [F] rules further down do not apply to it. Compare that with what the “except .php files” list writes for the same path:

RewriteCond %{REQUEST_FILENAME} !(\.php)$
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^plugins\/system\/bfnetwork/ - [L]

The first condition only matches requests that do not end in .php. Connector requests all end in .php, so they skip that rule, never stop at [L], and fall through to the Forbidden rule as before. Side by side the mistake is easy to see. In the admin screen the two labels differ by one word.

A few rules are written before the exceptions block, so an exception does not bypass them: “Restrict access by IP” (default None, intended for sites behind a load balancer, reverse proxy or CDN), “Block access from specific user agents” (default Off), the common-exploits rewrite rules and file injection protection. If “Restrict access by IP” is set to a custom list, the mySites.guru IP 178.62.5.35 has to be on it as well, or the exception never gets a chance to apply.

Is a Directory Exception Safe on a Joomla Site?

Akeeba’s documentation is blunt about the PHP list: “This option should be used sparingly as possible. Each and every directory placed in this list is no longer protected by Server Protection AT ALL”, and it recommends the per-file list wherever that will do. For a random folder, we agree. The connector is a case where the directory list is the right tool.

The service calls many files in that folder directly, and the set changes between releases, so a per-file exception breaks with no warning the first time a release adds an entry point. And every request to the connector is encrypted and must include your site’s connector key, so letting Apache pass a request to PHP is not the same as letting anyone use it.

Keep the exception to plugins/system/bfnetwork, not plugins or plugins/system, and leave the rest of the Server protection card as it is. Server Protection should stay on: it is the feature that disables PHP in a list of directories, which is where an upload flaw drops its payload. We also stand by what we said about treating .htaccess as a security layer: it limits damage after a compromise, and an exception for one authenticated folder does not change that.

Checking the Fix Worked on Your Joomla Site

The quickest test is a request for the connection test file from your own machine, before and after writing the new .htaccess. Replace example.com with the site:

curl -sI https://example.com/plugins/system/bfnetwork/bfnetwork/bfPing.php | head -1

Before the fix the first line is HTTP/2 403 (or HTTP/1.1 403 Forbidden on older servers). After the fix, anything other than 403 means the server let PHP run. The file expects an encrypted request, so it will not print anything useful to a browser or to curl, and that is fine; the status code is what you are testing. bfPing.php is only the file the test requests; the exception is still the whole folder, never this file on its own. Then in mySites.guru, run the test connection for the site from the reconnect screen, or refresh the site.

You can also open the site’s .htaccess and search for bfnetwork. The line should be inside the exceptions block, above the Advanced server protection block. If it is below it, or missing, the file on disk was not regenerated after the setting changed.

Doing It from the Command Line on Many Joomla Sites

Admin Tools Professional 7.x includes Joomla CLI commands, and for an agency with dozens of sites that is a better route than clicking through each administrator. These are taken from the Admin Tools 7.9.3 command definitions:

php cli/joomla.php admintools:htmaker:get --key=fullaccessdirs
php cli/joomla.php admintools:htmaker:set --key=fullaccessdirs --add=plugins/system/bfnetwork
php cli/joomla.php admintools:htmaker:make
php cli/joomla.php admintools:ipallow:add --ip=178.62.5.35 --description="mySites.guru"

fullaccessdirs is the field behind “Allow direct access, including .php files, to these directories”. Run htmaker:get first so you can see what is already there, and htmaker:make --preview before the real make so you can check the generated file before it is written. The last command is the WAF side of the job, covered next; it adds our IP to the Site IP Allow List so the firewall never bans it in the first place.

Why Joomla Backups Fail When Everything Else Works

Admin Tools Professional’s Web Application Firewall bans an IP after repeated blocked requests. The defaults in 7.9.3 are “IP blocking of repeat offenders” on, “Block IP after this many blocked requests” 3, “Time period” 10, “Unit of time measurement” second, with an optional “Add persistent offenders to the IP Disallow List” that is off by default. Three blocked requests in ten seconds and the IP is banned.

Every mySites.guru request comes from one IP, 178.62.5.35 (the uptime monitor is separate, on 165.227.239.229, and the full list is at our IP addresses). So a ban applies to the whole service at once. What makes it hard to spot is that most of the service never notices.

The WAF hooks Joomla’s onAfterInitialise event. The connector never boots Joomla that far, so audits, snapshots and tool calls go straight past a live ban as if it were not there. A backup is the exception: mySites.guru drives Akeeba Backup through the site’s own index.php, a full Joomla request, so a banned IP gets 403 Forbidden on every backup while everything else on the site’s page looks healthy. Audits fine, backups 403, is the signature.

What the ban does to backups

From our own measurements across connected Joomla sites: of the sites found with our IP banned by Admin Tools, roughly 44% had their last backup rejected. On Admin Tools sites where we are not blocked, the figure is 0.6%.

If a site’s last backup failed with 403 and Admin Tools is installed but no ban was found in its tables, mySites.guru says so and does not offer the unblock button, because a 403 has many causes and clearing a ban that does not exist fixes none of them.

Clearing an Admin Tools IP Ban from mySites.guru

During each snapshot, and snapshots run twice a day, mySites.guru looks in the Admin Tools block tables, both the manual block list and the automatic ban list, for the IP the request came from. If it is there, the site is flagged BLOCKED by the check “Unblock mySites.guru IP in Akeeba Admin Tools”, and the site’s Backup tab shows “Akeeba Admin Tools has blocked our IP” with an “Unblock our IP” button.

“Unblock our IP” removes our IP from the manual block list, the auto ban list and the auto ban history, then adds it to the Admin Tools Site IP Allow List with the description “mySites.guru management IP - auto allow-listed”. It works while the ban is live because it travels the connector route the WAF never sees. It acts only on our own IP and changes no other Admin Tools setting.

Unblock mySites.guru IP in Akeeba Admin Tools

mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.

It can also fix this across every connected site with one click.

Check your site for free

If you would rather not click it every time, there is a per-site setting under Config, Advanced: “Automatically whitelist mySites.guru in Admin Tools”, with the toggle “Clear the block automatically”. With that on, a snapshot that finds us blocked clears the ban and allow-lists us without waiting for you. It only writes when it finds us blocked, never on a routine snapshot, so your scheduled backups keep running without anyone babysitting the WAF. The one-click unblock arrived with a batch of other features, and the auto-clear toggle is the version of it you set once and forget.

The manual alternative inside Admin Tools is Configure WAF, “Exceptions”, “Never block these IPs”: add 178.62.5.35. Akeeba’s WAF Exceptions documentation recommends that list for “known external servers accessing your site (e.g. payment service providers sending callbacks to your site, site scanners, Cloudflare, Sucuri, etc)”. The separate “Site IP Allow List” page, which describes itself as being for “known, vetted services and servers”, does the same job; in the 7.9.3 code both lists make Admin Tools skip its checks for that IP entirely. Either is fine.

The two fixes in this post are not interchangeable, and this is where most people go wrong. An IP allow-list entry in the WAF does nothing for a .htaccess Maker 403, because Apache blocks the file before PHP, and so Admin Tools, ever runs. A .htaccess Maker exception does nothing for a WAF ban on backups, because backups go through index.php, which the exception does not touch. Akeeba staff have said as much: the WAF and the .htaccess Maker do not affect each other. Most sites with Admin Tools Professional need both.

Admin Tools for WordPress Uses Different Labels

Admin Tools for WordPress Professional has its own .htaccess Maker with an “Exceptions” section, and the wording is different from the Joomla edition. The four lists are “Files which will always be made accessible”, “Directories where all files except .php will be accessible”, “Directories where all files including .php will be accessible” and “Directories where only files with allowed extensions will be accessible”.

On WordPress the connector is at wp-content/plugins/mywpguru, with its files in wp-content/plugins/mywpguru/bfnetwork/. The labels are just as easy to mix up as on Joomla, with four near-identical boxes this time, so read each one to the end. Add wp-content/plugins/mywpguru only to “Directories where all files including .php will be accessible”, which has wp-content/upgrade in it by default, then “Save and create .htaccess”. Akeeba’s Server Protection documentation for WordPress covers the page, and its WAF Exceptions documentation names “a third party site management service” as the kind of thing you do not want the firewall blocking. The one-click unblock in mySites.guru is Joomla only, so on WordPress add our IP to the WAF exceptions by hand.

No Admin Tools but Still a 403 on Joomla?

Then something else wrote the rule. Check /.htaccess, /plugins/.htaccess and /plugins/system/.htaccess for a <FilesMatch> block that denies .php with Deny from all. A root .htaccess often pairs that deny with an allow list of known core files, and the connector is not on it. Hand-written rules like these need the same bfnetwork exception written in whatever style the file already uses.

If none of that is present, the 403 is coming from a server firewall blocking our IP rather than from the site. Hosts do this in several shapes, including a bot challenge in front of the whole site, and the fix is the same each time: send the host our IP addresses and ask for them to be allowed.

Admin Tools hardens the site and mySites.guru watches it, and the two settings in this post let both do their job at once. If you look after more than a couple of Joomla sites, having the ban detected and cleared for you is a small part of what the subscription does twice a day on every site you connect.

Is It Safe to Connect My Clients' Sites to mySites.guru?

phil@mysites.guru (Phil Taylor) — Mon, 19 Oct 2026 11:50:51 GMT

YES!

An agency owner told me recently that she was holding off connecting her client sites because she’d be “sharing my clients’ website access with strangers”. It’s the right instinct. Before you put a management tool between you and fifty client sites, you should know what that tool can do with them and who’s behind it.

mySites.guru is built to be secure in everything it does - By Design

That covers the platform, the data we hold, who on our side can reach it, your own login, and above all the connections to your sites. mySites.guru makes around 100,000 connections to remote sites every day for thousands of paying customers, and every one of them is encrypted, signed for the one site it is meant for, and validated through an independent callback before it runs.

You don’t give us any client passwords, FTP details or hosting logins to get there. You install a connector plugin on each site, and the platform is built so that even someone with our entire database could not use it to run a command on your client’s server. At least three read-only Docker containers, on three different physical servers behind our firewall, would all have to be compromised within seconds of each other to send a single forged request.

What you give us when you connect a site

Connecting a Joomla or WordPress site means installing the mySites.guru connector plugin, the same way you’d install any other extension. That’s the whole setup. The admin password, FTP and the hosting control panel stay with you.

The only time I ever ask for FTP details is when a customer asks me to fix a site that won’t connect, and they choose to send them through the support form. Day-to-day use never needs them.

Even a complete mySites.guru server compromise is not enough to access your sites

Most people picture a management tool as a big box of keys: break into the box, get every site. I built mySites.guru on the opposite assumption, that our own systems will eventually be attacked, and designed for what happens after that.

You, in your mySites.guru dashboard

ask for something to happen on a site

Behind our firewall, on our private network

Read-only container 1
on physical Server 1
Read-only container 2
on physical Server 2
Read-only container 3
on physical Server 3

All three have to be compromised within seconds of each other, without tripping our defences, to send one forged request. One server, or the whole database, is not enough.

Signed, encrypted, single-use request

Your site

The connector, with this site's own key pair

"Did this really come from mySites.guru?"

Independent validation server

Switch it off and every connector stops running requests

Validated, so the connector decrypts and runs it

Anything that fails a check is never decrypted

Every one of the roughly 100,000 requests a day takes this path.

The connector on your site authenticates every instruction before it acts on it. All communication with it is encrypted end to end, and a request is only valid if it has the correct signature for that specific site. Every single site gets its own cryptographic key pair, which isn’t shared with any other site on the platform.

That encryption does more than one job. Besides protecting the request, it’s how our requests tunnel through the restrictive firewalls and WAFs that some hosts put in front of their servers, which would otherwise block legitimate management traffic. Because each request is encrypted with that one site’s keys, it can’t be used against any other site. Each request is also time-boxed, and the connector won’t act on it until the validation server has confirmed it.

A signature alone isn’t the end of it. Every request to a connected site has a parallel connection to an independent validation server: before the connector runs anything, it calls back to check that the request really came from mySites.guru. If you’ve ever built a PayPal IPN listener, it’s the same idea, and PayPal has relied on that pattern for decades. Every single request we make is signed and then validated before it runs.

mySites.guru also isn’t one server. The platform is a layered, Docker-based service, with its layers distributed across different physical servers and run largely as read-only containers. To run a single command on any remote site, an attacker would need to compromise at least three different read-only Docker containers, on three different physical servers, within seconds of each other, all without tripping any of our defences, and all behind our main firewall on our private internal network. So even a complete compromise of one mySites.guru server, database included, is not enough to run a command on your site. I don’t publish every layer of that design, because that would only help someone looking for a way in.

There’s also a kill switch. In the unlikely event that mySites.guru itself had a security breach, I can stop every request to every connected site with a single command, by switching off the validation server. With nothing there to answer the callback, no connector will run anything until it’s back.

This is not a theoretical concern. On 18 October 2026 TeamUpdraft confirmed that it had identified unauthorised access which it believes may have exposed UpdraftCentral connection keys. One WordPress site owner on Reddit found a backdoor plugin they never installed, dropped through two requests to UpdraftPlus’s remote-control library with no wp-admin login, no plugin upload and no file editor use. TeamUpdraft’s advice was to delete existing UpdraftCentral connection keys, change passwords and reconnect with a new key. If the same kind of breach happened at mySites.guru, it would not be enough to run a command on your site, because nothing stored in our service database is enough on its own to make the connector accept a request.

The same boundary holds in the other direction. If one of your client sites gets hacked, through a vulnerable extension or anything else, it has no path back into mySites.guru, and no path from there to your other sites.

An example: one-click login

One-click login is a good way to see all of this working, because it’s the feature that sounds most like we must be holding your passwords. You press a button on your dashboard and you’re in a client site’s admin console, without typing a password.

Your password is never involved. We don’t ask for it and we don’t store it. Each login goes through the same signed and validated process as every other request:

1. Register: mySites.guru registers the upcoming request with our request validation service.
2. Send: An encrypted login request is sent to the connector on the site.
3. Validate: The site checks back with the validation service to confirm the request is real.
4. Decrypt: Only then does the site decrypt the request, which was encrypted with that site's own keys so it is useless anywhere else, and see that it's a login instruction.
5. Create session: The site creates a new session for the admin user you chose in mySites.guru.
6. Redirect: You're redirected to the site, and your browser picks up that session.

No password crosses the wire at any point, and not even a username. The login request names the admin user by a number, the user’s ID on that site, and we don’t store usernames in our database at all. One-click login is also opt-in: it does nothing until you pick, per site, which admin user it should log you in as.

Who is on our end

Me, Phil Taylor. I’ve been involved in Mambo and then Joomla for decades, starting as one of the original five core developers of Mambo Open Source 4.5. I was also one of the top code contributors to Joomla 4, and I’m on the Joomla Security Strike Team’s honour roll. If you run Joomla, you are probably already running code I wrote on your sites! Tens of thousands of people trust me with their sites, and you can read what they say.

I’ve run mySites.guru for more than a decade and I answer all the support email myself. Support isn’t outsourced, so there’s no overseas helpdesk with a login to your account.

Access to the production systems is restricted to named personnel, over key-based authentication on a private network. The application servers and the database aren’t reachable from the public internet.

If I ever need to see your dashboard as you see it to sort out a support problem, that admin impersonation is restricted, logged, and shows up in your own account activity log. You’ll always be able to see that it happened.

Some jobs can’t be done through the connector at all: a hacked site, a half-finished update, a site that won’t boot. For those, fix.mySites.guru is my paid, hands-on repair service, and it does need your site’s credentials. That process is locked down too. Credentials are encrypted at rest, field by field, with the encryption key on different hardware to the database, and they are never emailed to anyone, including me. Only I can see them, and every time they’re opened that’s recorded. They’re also time-boxed: a scheduled job destroys them seven days after you send them unless a job is still under way, nothing survives thirty days under any circumstances, and you can destroy them yourself from your account at any time.

Securing mySites.guru since 2012

mySites.guru has been running since 2012, and for all of that time securing it has been part of the job, along with defending it against abuse and attacks. The security architecture above has been part of the platform from day one.

Security is also what I do outside mySites.guru. I’m security educated and trained, and I design and build complex security architecture for other organisations as well as for our own platform.

We’ve also responsibly disclosed over 100 security issues in other people’s products, including Joomla core and many of the extensions your sites run, and a month of our Joomla security disclosures shows what that work looks like. That work has been recognised outside the Joomla world too, including a Digital Jersey Tech Awards nomination for helping secure government COVID digital certificate platforms.

What data does mySites.guru store about a site?

Very little, and most of it is integers and flags: counts, and yes-or-no answers to the checks the connector runs. Anything more detailed is pulled from the site in real time, only when you open one of the investigate tools.

All the alerting and notifications you get from mySites.guru come from those integers and flags. We don’t pull your site’s files or database into our service to work out whether something needs your attention.

The heavy lifting happens on your own server. Scanning file contents and database content is done by the connector, in your environment, with your own settings, your own PHP and your own versions. What comes back to us is the answer, not your content.

The little we do hold is protected like this:

In transit: All traffic to the platform is end to end encrypted.
At rest: Personal data is encrypted in the database, and the encryption keys are held on different physical hardware to the database.
Backups: Encrypted with a modern cipher, held off-site, and kept for at most a month.
Your password: Stored one-way hashed, so it can never be recovered in plain text.

To be clear: Your clients personal data on their sites

Data protection law defines “processing” personal data very broadly. Showing you the names of the users on a client site in the user management tools could count, so we treat ourselves as processing that data and go over and above what’s required of us as your sub-processor.

We don’t harvest or otherwise process the personal data found on your sites, and we don’t store any of it in our service. We only read it from your site in real time, while you’re using the tools, and it stays on your site.

The only other personal data we process is about our own account holders: your name, IP address, location, billing and payment details and the like. We handle that securely and in full adherence with international data protection law, going over and above what it requires. Our Data Processing Agreement covers the data on your sites, and our Privacy Policy covers yours.

The weakest point is your own login

Your own mySites.guru login is the weakest point, and securing it is your responsibility, not ours. This is by design.

With everything above in place, the easiest way into your sites through mySites.guru is your own dashboard login. If you choose a weak or reused password, choose not to set up passkeys or two-factor authentication, or choose to switch off login notifications, that’s on you rather than on the platform.

mySites.guru gives you all the tools to lock your account down. Using them is up to you:

Passkeys and hardware keys: Sign in with a passkey using Face ID, Touch ID, Windows Hello or your Android phone, or plug in a hardware security key such as a YubiKey. Passkeys can't be phished or reused on another site.
Two-factor authentication: Codes from an authenticator app, backup codes for when your phone isn't to hand, and the option to trust a device for 60 days.
A nudge on every sign-in: Until you set up two-factor or a passkey, every sign-in without one prompts you to do it.
Login notifications: An email every time someone signs in to your account, with the IP address and time. If it wasn't you, reply and I'll help you lock the account down. You can switch them off in your notification settings, but please don't: they're your early warning.
Brute-force blocking: Ten failed sign-ins from one IP address within five minutes and that address is blocked.
No password reuse: Your last five passwords can't be used again.
Team member logins: Give staff their own logins instead of sharing yours, limited to the sites they need, each with their own second factor. You can remove one person without changing anything for the rest.
A locked-down File Manager: The Web File Manager is off until you switch it on for a site, needs two-factor, and asks for your password again before it switches on.

And use a strong, unique password, ideally generated and stored in a password manager.

mySites.guru plugin security updates are automatic

You never need to update our plugin. We do that for you automatically, as and when we release new code, so you’re fully protected and have the very latest features deployed for you. Even this process is locked down: an update only runs inside an authenticated, validated request from mySites.guru, the new version downloads from our own CDN over HTTPS, and every file is checked against the release manifest after it’s installed, so a partly applied update gets caught rather than reported as done.

You can cut off access yourself, at any time

mySites.guru can only reach a site while the connector and its keys are on it, so ending access is in your hands, and it takes seconds. Any one of these does it:

Delete the Keys folder: plugins/system/bfnetwork/bfnetwork/Keys on Joomla, or wp-content/plugins/mywpguru/bfnetwork/Keys on WordPress.
Uninstall the plugin: Use the normal Joomla extension manager or WordPress plugin uninstaller.
Delete the files: Remove the plugin's files over FTP.
Delete the site from your dashboard: Every site has its own key pair, and deleting the site destroys our half of it, so we can't reach the site afterwards even if we wanted to.

What to tell your clients

If a client asks where their data goes, our Data Processing Agreement covers the usual agency setup: your client is the controller, you are the processor, and mySites.guru is your sub-processor. It’s about how personal data is handled rather than how the platform is secured, but it’s the document a client’s compliance person will expect to see.

And if you’re a security researcher who has found something we’ve missed, our security policy explains how to report it.

Don't take our word for it. See what other people have to say.

Hundreds of agencies and site owners who manage their Joomla and WordPress sites with mySites.guru have reviewed it, and WP Mayor rated it 4.6/5. Read the reviews.

Connect your first site

mySites.guru wins Your Favourite Tool in Your Joomla Workflow at the J!Awards 2026

phil@mysites.guru (Phil Taylor) — Fri, 16 Oct 2026 20:45:00 GMT

mySites.guru has won Your Favourite Tool in Your Joomla Workflow in the J!Awards 2026, the first community choice awards the Joomla project has run. The winners were announced on 16 October 2026 at the Joomla World Conference in Potsdam, near Berlin, on the opening day of a conference that runs until the 18th.

The official results are now published

The Joomla project has published the official results and the winner badges. The winners page lists our category as Favourite Tool for Your Joomla Workflow and gives the turnout: 731 people voted.

Congratulations to everyone else who won on the night. Akeeba Backup for Joomla! took Favourite Extension, Helix Ultimate Favourite Template and Hostinger Favourite Hosting. Brian Teeman was voted Influencer of the Year, joomshaper.com won Website Design, Louise Hawkins won for her magazine article, and Automated Updates was Favourite New Joomla 6 Feature. David Jardin also received the special J!Volunteer 2026 award, chosen by the volunteers at the conference.

Thank you to everyone who nominated and voted

This award was decided by a public vote, which is why it means so much to us. No panel picked mySites.guru. People who use it put our name forward during nominations, enough of them that we made the five-strong shortlist, and then enough people voted between 21 September and 11 October to put us first. Thank you. You took a minute out of your day to fill in a form for a tool, and we noticed.

What are the Joomla J!Awards?

The J!Awards are the Joomla project’s community choice awards, and 2026 is the first year they have run. There are eight categories in two groups, Creators and Contributors and Tools and Services, and Your Favourite Tool in Your Joomla Workflow sits in the second. Nominations ran from 17 August to 13 September, the five most-nominated entries in each category went to a public vote from 21 September to 11 October, and the most votes won. There is no jury at any stage. The Joomla press release that launched the awards names the J!OSCARs as its inspiration, which is a nice symmetry for us.

Multi-award-winning service: 5 awards

The J!OSCARs were the awards given at J and Beyond, the community Joomla conference, and the service that became mySites.guru won four of them. In 2013 at Noordwijkerhout the jury’s Joomla! Innovation of the Year went to monitoring services, mySites.guru among them. Then came Joomla Services by attendee vote three times: Königstein in 2014, Prague in 2015 and Kraków in 2017. The full awards record is on its own page.

Five Joomla awards since 2013

2026J!Awards
2017J!OSCAR
2015J!OSCAR
2014J!OSCAR
2013J!OSCAR

See the full awards record

Those four were decided at the conference, by a jury or by the people in the room. The J!Awards are the first Joomla awards where the whole community votes online, from wherever they are, so this fifth one is a different kind of result. It comes from Joomla users wherever they are, rather than the people who could make it to a conference, and we are glad to have it.

What mySites.guru does in a Joomla workflow

Picture someone who looks after forty Joomla sites for clients and opens mySites.guru with their first coffee.

The sites list comes first

Each connected site is one row: its Joomla version, its PHP version, the updates waiting and how many vulnerable extensions it is running. The sidebar narrows the list to hacked sites, end-of-life Joomla and sites with vulnerable extensions. A snapshot runs 140 or so best-practice checks on each site twice a day, so the list is current before anyone has logged in anywhere.

Updates, without forty administrator logins

Pending Joomla core and extension updates sit on one screen. Group them by extension to patch one extension on every site that has it, or by site to bring one site fully up to date. The update queue applies one update at a time on each server, so a host with twenty of your sites is not hit by all twenty together. Extensions you trust can update themselves while the rest wait for you, and core updates stay within a major version, because a move from 4 to 5 is a migration and deserves to be treated as one.

How a security problem reaches you

At each snapshot the extensions on a site are checked against hand-written vulnerability rules, and Joomla core CVEs are imported every hour from the Joomla Security Centre. The first time a site matches, the alert email goes out within seconds. In the dashboard the site is marked in the sites list, the “has vulnerable plugins” filter narrows the whole list to the sites that need patching, and the details sit on that site’s Important tab. The fix follows the same path: filter to the affected sites, press Backup All, then update that one Joomla extension across all of them. If a site was exposed for a while before you got to it, the Joomla malware scanner reads all the files on the server against roughly 1,500 patterns, a hash list of confirmed malicious files and clean core checksums for that exact Joomla version. It keeps suspect content in a separate list from confirmed hacked files, so you know which is a lead and which is a fact.

Uptime and backups, running whether you look or not

Every site gets an uptime monitor the moment it is connected. It checks every 5 minutes, makes three attempts before calling a site down, and alerts by email, the Slack app, a webhook or desktop push, with a warning before an SSL certificate expires. Backups work by driving the Akeeba Backup Professional already on each site: as many cron-style schedules per site as you need, a stalled backup resumed automatically, a daily alert naming any site without a recent backup, and the archives stored wherever you configured Akeeba, not on mySites.guru.

The jobs that used to mean one site at a time

One click opens any Joomla administrator from the dashboard with no password prompt. An extension can be installed on dozens of sites in one go. Multi-factor authentication can be forced on the Super Users of all your sites from the audit result. Team members get access to the sites you choose without seeing the Super User credentials, and white-label reports show each client what was done on their site and when. The Joomla multi-site dashboard and the full feature list have the rest.

See how it fits your own Joomla workflow

The votes came from people who use mySites.guru day in, day out. To see why they picked it, put one of your own sites through it. A free site audit runs all 280+ checks on one WordPress or Joomla site, with no card needed: install the connector, which takes about two minutes, and the full results are in the dashboard a few minutes later. If you are about to take over a site from someone else, audit it first and know what you are inheriting.

That audit opens in the same dashboard described above, and the rest of the workflow comes with the subscription: £19.99 a month for unlimited sites, all features included, unlimited team members at no extra cost, and cancelling is one click in your account. The price has not changed since 2012. If you subscribe with the code FIRSTMONTHFREE at checkout, the first 30 days cost nothing; checkout asks for a card, and cancelling before day 30 means you are not charged. The vulnerability matching, the bulk updates and the one-click fixes are all part of it.

Be Aware Of Joomla Developer Impersonation Scams

phil@mysites.guru (Phil Taylor) — Thu, 15 Oct 2026 19:09:27 GMT

On the morning of Thursday 15 October 2026 an email went out to four addresses at one company, signed “Fotis Evangelou, Founder · K2”. It said that “Joomla support” had phoned him about the company’s website, that the site needed Joomla core and extension updates before 25 October, and that as the person “currently managing your website” he would like to get on with it. It had a photo that is not of him, a link to the real K2 website and a link to his real LinkedIn profile.

Several people forwarded it to me that morning, worried. It is a scam. It uses a well-known Joomla developer’s name to get two things out of you: a Super User account on your Joomla site, and $550. I spent the evening replying to it so you can see the whole script, every email and every header, before one of these reaches your own inbox.

Fotis Evangelou did not send these emails

This round of emails used Fotis Evangelou’s name and public links, with a signature photo of somebody else entirely. He is the person being impersonated, and he had nothing to do with any of it. JoomlaWorks has since published an official notice, Security notice: emails impersonating the K2 developer (also on getk2.org), confirming that the Gmail address is not theirs, and that real mail from Fotis or JoomlaWorks only comes from an @joomlaworks.net or @getk2.org address, never Gmail or any other free provider. He is also not the only one: the same kind of email is going out under the names of other well-known people in the Joomla ecosystem. If an email arrives from a famous Joomla name you were not expecting, treat it the way you would treat this one.

Why This Joomla Email Is a Scam

The email fails before you get past the first sentence. Joomla is a volunteer-run open source project. There is no “Joomla support” desk, nobody at Joomla phones developers about other people’s websites, and no one gets a phone call from “Joomla Support”. Everything after that opening line is built on a claim that cannot be true.

The rest of the tells stack up quickly:

“As I’m currently managing your website” is false familiarity. The sender does not manage the site; the line is there so that you assume a relationship already exists.
“Before October 25” is invented urgency. Nothing in Joomla happens on 25 October.
The sender address is a Gmail account, for someone who owns a domain (getk2.org) and would have no reason to use one.
The signature borrows real public details, the K2 website and the LinkedIn profile, puts them next to a photo of somebody else (a Greek academic’s LinkedIn profile picture, see below), and attaches them to a postal address in the Seychelles. I am not going to say whether that address is real or made up. Real public links are being used to make a fake sender look convincing, and that is the point of them.
American spelling throughout (“optimization”, “prioritized”) and pricing in US dollars, from a sender whose signature points at Greece and the Seychelles.
The first email’s HTML includes a hidden, zero-height tracking image from an online email-signature generator (a signature.gif with a user id and an email id in the query string), the kind used to report back when an email is opened. I made a point of not loading it.

And the end goal, once you play along, is a Super User account on your Joomla site. That is full control: install extensions, run code, read the database, create more administrators. The $550 is almost a side order.

Whose Face Is in the Signature?

The circular photo in the first email is the profile photo from the public LinkedIn profile of Andreas Komninos, an Assistant Professor in Patras, Western Greece, whose profile lists the University of Patras and the University of Strathclyde. Same face, same teal-framed glasses, same office behind him. He has nothing to do with any of this. His face was lifted from his own public profile, which makes him the second person this scam is impersonating.

My reading is that the choice was no accident. Anyone who got as far as checking would see a real Greek man next to a Greek name and move on. The check that beats it takes a minute: a reverse image search on the signature photo leads to a university lecturer’s profile, not to K2. Worth doing on any email that asks you for money or an account.

The LinkedIn profile the signature photo was taken from. Same face, same teal-framed glasses, same office behind him.

The Full Thread, Message by Message

Here is every email in order, with what each one gives away. My replies were short and gullible on purpose. All times are BST.

07:27. The opening pitch, with the borrowed signature. Recipient addresses redacted.

Four role addresses at one company on a single visible To: line, info@ plus three branch offices. Nobody who actually managed a site would email every office at once about it. The subject, “Important: Joomla Website Updates and Technical SEO Optimization Before October 25”, does the urgency and the upsell in one breath.

17:15. The follow-up, nearly ten hours later, to the same four addresses.

“I’m following up on my previous email … As I’m currently managing your website … Please let me know your thoughts when you have a moment.” Same four recipients, same claim. By this point I had already had an interesting morning, so I decided to give the sender some thoughts.

17:23. My reply, to the Gmail address.

“Awesome - lets do this ! What do you need?” I did not expect what came back 39 seconds later.

17:23 and 39 seconds. The automatic reply.

This is Gmail’s own vacation responder, loaded with the sales pitch. The headers say so: “X-Autoreply: yes”, “Auto-Submitted: auto-replied”, “Precedence: bulk”, and the subject is the pitch subject doubled, “Important: … Re: Important: …”. Anyone who emails that address, for any reason, gets the pitch back automatically. It is a nice touch of industrialisation.

17:28. I try again, in case the robot was the only one listening.

“Awesome - lets do this!” A human did turn up, 51 minutes later.

18:19. Three packages, and a discussion that never happened.

“Thank you for confirming that you’d like to move forward. Following our discussion, I’ve outlined three priority maintenance plans.” There was no discussion. The plans are the Essential Maintenance Plan ($350), the Priority Optimization Plan ($450) and the Premium Maintenance & SEO Plan ($550), all to be completed before 25 October, all priced in dollars. The deadline from the first email is still doing its job.

18:21. Naturally I went for the expensive one.

I told them I wanted the Premium Maintenance & SEO Plan at $550, asked for the payment link, and said I would “pay right away”. Two minutes after the packages arrived. No real client has ever behaved like this, and the sender did not blink.

18:37. The real ask.

This is the message the whole thread exists for. After confirming the $550 plan: “could you please help me restore my administrator access to the Joomla website? Unfortunately, I no longer have the previous login details saved on my end”. Then step-by-step instructions: log in at /administrator, Users, Manage, New, Name: Fotis Evangelou, Email: evangelou.getk2@gmail.com, “Under Assigned User Groups, select Super Users only if full administrative access is necessary”, and “securely share the login … Please avoid sending passwords in plain-text email.” A security tip from the person stealing your site is a lovely detail. Note also that from this message on, the borrowed photo and the fancy signature are gone. Short plain messages only. The costume comes off once the mark has bitten.

18:39. I apply some urgency of my own.

“Awesome - thanks - send me the payment link asap! Im about the leave the office for a long weekend and want to get the money to you!” I wanted to see which of the two prizes they chased when the clock was ticking.

18:48. The link is coming, but have you done the account yet?

“I’ll send you the $550 payment link as soon as possible. Also, just a quick reminder about the Joomla administrator access … could you please let me know if you’ll be able to create a new administrator account for me once you’re home? There’s no problem if you need to handle that after the long weekend.” The money can wait until after the weekend. The admin account is the reminder. That tells you which one they value.

19:13. Four words.

“Hold for the payment link”. Twelve minutes later, something did arrive, and it was not from Fotis.

19:25. The invoice email, from an invoicing platform, for a new invoice from David. Pay link redacted.

The invoice came from GoFlex, an invoicing platform, sent through Amazon SES, with the subject “Invoice #206181448604 from David” and the line “You have received a new invoice from David through our secure invoicing platform, GoFlex”. Amount due $550.00, with a Pay Now button to a checkout page that I have redacted. GoFlex is simply the tool the scammer chose to raise the invoice; I have no reason to think the platform itself is involved.

GoFlex is a West African invoicing and payments platform for freelancers, which is its own small tell. Of all the invoicing tools on the internet, the scammer reached for one rooted in West Africa, and that fits everything else the evidence keeps pointing at: a Lagos address on the merchant account, and a Lagos connection when the link was opened, which you will see further down.

The invoice itself. Billed from David Lazarus.

“Billed from: David Lazarus”. The registration number and VAT ID printed under it are the same fixed numbers GoFlex prints on every invoice it issues, whoever sends it, so they identify nobody; the name is the only sender detail on the page. Billed to Phil Taylor, for “Premium Website Maintenance and SEO Optimization”, $550.00, VAT $0.00, invoice date and due date both 15 October 2026, footer “Via authorized reseller: goflex”. The name on the invoice is not Fotis Evangelou. That is the clearest proof in the whole thread that this is not him, and it is where I stopped. I never created an account and never paid. I have no idea who David Lazarus is, and nor should you assume anything: it may well be a stolen or invented name.

The invoice link opens a GoFlex checkout, and the checkout has a step that gives the whole thing away.

The GoFlex 'Before you pay' step. One option pays out at once. The other holds the money in escrow until you confirm the work was done.

GoFlex offers to hold your money in escrow until you confirm you actually received the work. For a real supplier that is a feature. For this one it is a problem, because there is no work and never will be. So the next email told me, in bold, not to use it.

19:35. 'Please do not make this payment through escrow.' The quiet part, in bold.

“We can proceed with Option 3 - Full Premium maintenance & SEO ($550) as agreed. To move forward, kindly complete the required implementation toolkit purchase using the secure invoice link below.” Then, in bold: “Please do not make this payment through escrow. The toolkit payment needs to be completed directly through the invoice so the funds can be available for the required implementation tools and services without additional processing delays.” Read that against the screenshot above. Escrow holds the money until you confirm the work was done. The one thing a scammer cannot afford is a buyer who waits to see the work. “Without additional processing delays” is the money leaving your reach before you notice nothing arrived.

19:36. I ask a question the real Fotis could answer in his sleep.

I asked whether they were going to JWC26, the Joomla conference, and said it was “far from Greece”. Fotis is Greek and a fixture at these events; the real one would have fired back something about Potsdam. I am still waiting for an answer, along with the payment link.

What Do the Email Headers Give Away?

Less than people hope, and more than the scammer would like. Every message from the sender really is from the Gmail account evangelou.getk2@gmail.com: SPF pass, DKIM pass (d=gmail.com), DMARC pass. That is exactly what you would expect, and it is exactly why authentication does not help you here. Authentication proves which mailbox sent a message. It does not prove who is typing, and anyone can register a Gmail address with a famous name in it.

What we looked at	What it showed
Sending servers	Google’s own outbound servers, mail-sor-f65.google.com (209.85.220.65) and mail-sor-f41.google.com (209.85.220.41)
Sender’s IP address	Not present. Gmail does not put the sender’s own IP in the headers, so the headers cannot locate the sender. Only Google can, through an abuse report
Message-ID	Every message from the sender starts with the same “CAEguL_” prefix at @mail.gmail.com, consistent with one Gmail account writing all of them
Date header	Always -0700, US Pacific Daylight Time, the clock the sending account or device is set to. That fits neither the Greek LinkedIn profile nor the Seychelles postal address in the signature. A clue, not proof of where anyone is
Auto-reply	Gmail’s vacation responder loaded with the pitch, marked with the headers below
Tracking pixel	A zero-height signature.gif from email-signature-image.com in the first email, built by an online signature generator that reports opens
Invoice email	From hello@trygoflex.com, Reply-To support@trygoflex.com, sent through Amazon SES in us-east-2, GoFlex Technologies Inc., Dover, Delaware

The automatic reply’s headers, for anyone who wants to recognise the pattern in their own inbox:

X-Autoreply: yes
Auto-Submitted: auto-replied
Precedence: bulk

So the picture from the headers is one Gmail account, on a device set to a US Pacific clock, sending through Google, with a signature built in an online generator and an invoice raised through a third-party platform in a different name. None of it tells you where the sender is sitting. All of it tells you the sender is not who the signature says.

The Invoice Platform Handed Over the Scammer

Here is the part the scammer did not plan for. GoFlex serves the invoice from a public API, and that API has no authentication on it at all. Anyone who has the invoice’s id can read the whole record back, including the merchant’s own account details. The merchant, in this case, is the person behind “Fotis Evangelou”.

This is the endpoint, on GoFlex’s beta host:

https://goflex-beta.gonomadhq.site/api/v1/goflex/public/invoice/detail/4c15384f-806e-4176-b527-05ac9e6d14cc/

Open it and the merchant_data block comes straight back:

"merchant_data": {
  "id": 49998,
  "status": "ACTIVE",
  "full_name": "David Lazarus",
  "residential_address": "No 13 oke Ola street Amoyo",
  "email": "davidfundz211@gmail.com",
  "profession": null,
  "specialty": null,
  "linkedin_url": null,
  "phone_number": null
}

So the account collecting the $550 is registered to “David Lazarus”, at davidfundz211@gmail.com, a second throwaway Gmail that has nothing to do with the Fotis Evangelou address used in the emails. The address on the account, “No 13 oke Ola street Amoyo”, is the Ajoke Cybercafe in Amoyo, Nigeria. Not Greece, not the Seychelles, not a call from “Joomla support”. A cybercafe in Kwara State. The same record shows the money: $550 invoiced, $519.80 set to pay out to the merchant after the platform’s cut, routed through Stripe (the transaction reference is a Stripe payment id, pi_3UQtaCJv6OGYEdmM1pIDX8x8).

The same unauthenticated endpoint also read my own details back out, the name, email and address I was billed under, which means this is not only the scammer’s data on show. Any GoFlex invoice served this way exposes both the merchant and the customer on it to anyone holding the id. That is a real data protection problem on GoFlex’s side, and I have reported it to them separately. I am publishing the scammer’s merchant record here because it is the scammer’s, and because it is the clearest proof yet of who is actually behind the Fotis Evangelou costume.

So I Sent Him a Link

The invoice pointed at Nigeria. I wanted to see it from his end as well, so I put a short link on one of my own domains that logged whoever opened it, the IP address, the network, the rough location and the browser, then forwarded them straight to his invoice page so the link did exactly what he expected. The clever part was not the link, it was how I got him to click it: I sent it back to him and asked, as an anxious mark would, whether this was the right place to pay.

19:57. I send him a link on my own domain and ask if this is where I pay.

He did not just open it. He vouched for it.

19:59. 'Yes, that's it. is one of my billing contractor.'

He confirmed a link on my domain as “one of my billing contractor”, which is how I got the one thing the email headers would never give me: his real connection. The visit came from 102.88.166.8, a mobile address on MTN Nigeria, from Lagos, on an ordinary Windows copy of Chrome. No VPN, no proxy, no data centre, just a phone network in Nigeria and a real browser clicking a link. It matches the account address the invoice platform leaked. So the location now has two independent sources that agree: the merchant record he filled in, and the address he connected from. The US Pacific clock in his email headers was only his mail client’s setting, nothing more.

He kept the act up afterwards, even softening on the escrow point once I had raised it, now that it might scare the mark off.

20:32. The same link is now 'the GoFlex checkout page', and escrow is suddenly fine after all.

Cloudflare attached coordinates to the visit as well, 6.45407, 3.39467, which reverse-geocode to a business centre on Lagos Island, the Azeez Olamileken Business Centre at the Ogun State Institute of Technology’s Lagos Island centre. Do not read the pin too literally. A mobile network gives many subscribers the same geo-IP point, usually a carrier node or a city default rather than the actual phone, so this is the network’s best guess at a neighbourhood, not his desk, and the building at that point has nothing to do with any of this. What the coordinates are good for is agreement: they sit in the same city as the address on the leaked account and the same country as everything else.

I have taken that link down again. It existed to answer one question, and it did.

What Should You Do If You Receive One of These?

Do not reply, and do not create any account. Then work through this list:

Check whether the person really manages your site, using a channel you already trust: an address or phone number you already had before this email arrived, never one printed in the email itself.
Report the Gmail address to Google, using Gmail’s “Report phishing” option or Google’s abuse form. Google is the only party that can see where the account is being used from.
If you already created the account they asked for, block or delete it straight away and change your administrator passwords.
Check your Joomla Users list for any other Super User accounts you did not create, and your extensions list for anything installed recently that you do not recognise.
Open the User Actions Log in your Joomla administrator and look for anything done by the account you created. If it was used for anything at all, treat the site as compromised: restore a backup you know is clean, or have the site audited before you trust it again. That is JoomlaWorks’ advice in its notice, and I agree with it.
If you paid the invoice, contact your bank or card provider and the invoicing platform and report the payment as fraud.

The bait in these emails is a name you trust. The defence is to never act on an email alone, however familiar the signature looks.

Checking Your Own Joomla Sites for Accounts You Did Not Create

If you look after more than a handful of sites, checking each Users list by hand is the kind of job that does not get done. mySites.guru users can search every connected site for an unexpected account by email address with the user manager, get an email alert when an administrator logs in. And if you want Super User logins harder to abuse in the first place, here is how to force MFA on Joomla Super Users.

Who We Have Told

This is not only a blog post. The impersonation has gone to the people who can act on it. The Joomla Security Strike Team was told first, confirmed the account was impersonating Fotis, and reported it to Google. The Gmail accounts doing the sending have been reported to Google for phishing. The fraudulent invoice and the unauthenticated data leak behind it have gone to the invoicing platform that issued it. And because the payment is processed by Stripe, Stripe has been told the account is collecting money by fraud.

JoomlaWorks has now published its own security notice about the emails, after several of its clients and people in the Joomla community forwarded them copies, and has reported the Gmail account to Google as impersonation with the full headers attached. It confirms that neither Fotis nor JoomlaWorks will ever ask for a Super User account by email or invoice you through a third-party platform under someone else’s name. If you are ever unsure whether a message from them is real, write to them through a channel you were already using before the email arrived, or through the contact page on their own site.

If one of these reaches you, report it as well. One report is easy to wave away. A dozen pointing at the same account is not.

Timeline

2026-10-15 07:27 First email arrives Sent as Fotis Evangelou from a Gmail address to four role addresses at one company. Claims a call from Joomla support and a 25 October deadline. Forwarded to me by several worried people that morning.
2026-10-15 17:15 Follow-up to the same four addresses "As I'm currently managing your website ... Please let me know your thoughts when you have a moment."
2026-10-15 17:23 I take the bait "Awesome - lets do this ! What do you need?"
2026-10-15 17:23 Gmail vacation responder fires 39 seconds later an automatic reply re-sends the whole pitch. Headers: X-Autoreply: yes, Auto-Submitted: auto-replied, Precedence: bulk.
2026-10-15 17:28 I nudge again "Awesome - lets do this!"
2026-10-15 18:19 Three priced packages $350, $450 and $550 plans, "following our discussion". There had been no discussion.
2026-10-15 18:21 I pick the $550 plan I ask for the payment link so I can pay right away.
2026-10-15 18:37 The real ask: a Super User account Step-by-step instructions to create a Joomla administrator account in the name Fotis Evangelou with the Gmail address. The fancy signature disappears from this message on.
2026-10-15 18:39 I ask for the link, urgently "Im about the leave the office for a long weekend and want to get the money to you!"
2026-10-15 18:48 Reminder about the admin account Payment link promised "as soon as possible", with a second request for the administrator account, "once you're home" if need be.
2026-10-15 19:13 "Hold for the payment link" Four words, no signature.
2026-10-15 19:25 Invoice for $550 arrives Sent by the GoFlex invoicing platform, billed from David Lazarus. Not Fotis Evangelou.
2026-10-15 19:35 "Do not pay through escrow" The sender insists, in bold, that I pay the invoice directly rather than use the checkout's escrow option, which would hold the money until the work was confirmed.
2026-10-15 19:36 I ask about JWC26 A question the real Fotis could answer without thinking. No real answer comes back.
2026-10-15 19:57 I send him a link on my own domain I ask, as a nervous mark would, whether this is the right place to pay.
2026-10-15 19:58 He opens it The link records a visit from a mobile address on MTN Nigeria, in Lagos, on an ordinary Windows browser. It matches the Nigerian address on the merchant account.
2026-10-15 19:59 He vouches for my link as his own "Yes, that's it. is one of my billing contractor." He confirms a page on my domain as a payment page of his, which is how I got his real connection. I paid nothing and created no account.
2026-10-15 20:13 I report the invoice and an open API to GoFlex Emailed support@trygoflex.com, copying security@trygoflex.com: fraudulent invoice, plus an unauthenticated invoice API exposing merchant and customer names, addresses and emails. Asked for suspension, cancellation, a fix and confirmation. A minute later the security address, published in their own terms, bounced. I forwarded the bounce to support.
2026-10-16 10:09 GoFlex replies about the bounce only "We'll have the security email address referenced in our Terms of Service checked to verify that it is correct and working." Nothing on the invoice, the merchant account or the data leak.

How to Check Joomla Template Overrides Across 100+ Sites, With Ease

phil@mysites.guru (Phil Taylor) — Wed, 14 Oct 2026 19:27:59 GMT

Every Joomla update and every extension update can change a core layout file that one of your templates overrides. Joomla notices. It records the override, shows an “Overrides to check” notice on the admin dashboard, and waits for someone to open Template Manager and look. On one site that works: you see the notice the next time you log in. On 100+ sites, no one logs in to every admin after an update day, so the list grows on every site and each stale override keeps running the old code. Bug fixes never arrive, new features never appear, and a security fix in a Joomla extension’s layout never reaches the copy.

mySites.guru now reads that list from every connected Joomla 4, 5 and 6 site twice a day and puts the results on one page for all your sites. From there you open the site that needs attention, compare each override with the current core file side by side, fix it or mark it checked, and move on. No Joomla admin login needed.

What Joomla Already Tracks For You

A template override is a copy of a core or extension layout file kept in the template’s html folder, for example html/com_content/article/default.php, so you can change the output without editing the original. When an update changes the original, your copy keeps running the old code, which is why Joomla 4 added Improved Override Management, a project that came out of Google Summer of Code 2018.

The work is done by the Installer - Override plugin (plg_installer_override). Before an extension update, a Joomla update or an extension install, it takes an md5 hash of every overridden core file. Afterwards it hashes them again. Any override whose core file changed is recorded in the #__template_overrides table with the date and the action that caused it:

Joomla Update: A Joomla core update changed the file your override copies.
Extension Update: An extension update changed one of its own layout files that you override.
Extension Install: A fresh install of an extension put a different file behind an existing override.

An unreviewed row has state 0. Joomla lists those rows in Template Manager on the template’s “Updated Files” tab, and the Quick Icon plugin shows the “Overrides to check” notice on the admin dashboard, as long as the Installer - Override plugin is enabled. Reviewing one in Joomla means opening the override, comparing it with the core file (Joomla’s editor has a diff toggle), editing it if needed, then marking it checked, which sets state 1. Only enabled templates count, the same rule Joomla’s own dashboard notice uses.

Know three limits before you trust the count. If the plugin is switched off, Joomla records nothing, and switching it back on only records updates from then on. Joomla skips the comparison when the number of override files changes during the update. And the comparison cannot tell changes an update made from changes you made yourself, which is why Brian Teeman’s best practice is to delete override files you never modified, so future updates only flag the ones you really changed.

How often does a core file change? Astrid Günther’s example is Cassiopeia’s com_content/tmpl/article/default.php, which changed between Joomla 4.1.4 and 4.1.5, a point release. A JoomShaper forum thread is titled “50 override changes in Helix after updating to Joomla 5”. That is one site. Multiply by your client list.

Every Joomla Site’s Overrides On One Page

The All Sites page for the Template Overrides To Check snapshot check lists every connected Joomla site with its result and an Investigate and a Manage Site button beside each one. Yellow pills say “7 to check” or “12 to check”; green says “All checked”. You see which sites need attention without opening any of them. The page is behind the “Compare All Sites” button on the check, or straight from this URL once you are signed in.

The All Sites page for Template Overrides To Check. The sites shown are examples; the pills are the real result shapes.

Both new checks have an All Sites page. The one for Template Override Tracking tells you which sites have the plugin switched off.

The Two New Snapshot Checks

A snapshot check is a single fact mySites.guru reads from a connected site twice a day, and on demand whenever you ask. Two have been added for Joomla 4, 5 and 6 (Joomla 3 has no #__template_overrides table, so it gets neither).

Template Overrides To Check is the count of unchecked overrides on enabled templates. It shows one of four labels:

N to check: Yellow. N overrides on enabled templates have an unreviewed change behind them.
All checked: Green. Every recorded override has been marked checked.
Tracking is off: The Installer - Override plugin is disabled, so the count means nothing.
No Data: The site has not reported yet: an older connector, or a table that could not be read. Never shown as zero.

Template Override Tracking shows whether Joomla’s Installer - Override plugin is On or Off, and its Investigate page has a switch that turns it on or off from mySites.guru.

No emails or alerts are sent for new unchecked overrides. An override to check is a review task rather than an incident, so the check turns yellow, the All Sites page shows it, and you deal with it on your own schedule.

Reviewing An Override Without Logging In To Joomla

Investigate on a site opens its Template Overrides To Check page: one row per unchecked override, with the template (and a Site or Admin pill), the override path, what changed it (Joomla Update, Extension Update or Extension Install), the date, and three actions: Edit, Mark checked, and Open in Joomla admin.

Mark checked fades the row out and the count updates live. “Mark all checked” clears the whole list after a confirmation, for the site where you have looked at the overrides and know they are fine. Up to 500 rows are listed, with the real total shown above them.

“Checked” is Joomla’s own flag. Marking an override checked in mySites.guru sets the same state 1 in #__template_overrides that Template Manager sets, so the dashboard notice on the site clears too. Every edit and every mark is written to the site’s Joomla action log, so a colleague looking in Joomla later can see what happened and when.

The Editor and the Differences Tab

Edit opens an editor with three tabs. Your Override File is the override source in an editable code editor with line numbers and syntax highlighting. Joomla Core File is read only: the current core file the override copies, so you can see exactly what the update put there. Differences shows the two side by side, Joomla core on the left and your override on the right, with changed lines tinted.

The diff is built from what is in the editor right now, so an edit you have not saved yet shows up in Differences straight away. Each change has two small buttons between the columns. The arrow copies the Joomla core lines for that change into your override: take the new core code. The bin deletes your override’s lines for that change: drop what you added. Work down the diff deciding which, and the override is current.

A real override written for an older Joomla. The core layout gained a LayoutHelper import, an early return and three new variables the override never had.

The current core layout in that screenshot has a use Joomla\CMS\Layout\LayoutHelper; line, an early if (empty($images->image_fulltext)) { return; }, and $figureClass, $imageClass and $layoutAttr variables that the override lacks. Each of those is one arrow click.

Save writes the file to the site. “Save and mark checked” does both in one go, and Ctrl/Cmd + S saves. Closing with unsaved changes asks first. If the file changed on the site since you opened it, nothing is saved and you are told, with the option to reload, so two people editing the same template never overwrite each other. Files up to 1 MB can be edited here.

Turning Joomla’s Override Tracking Back On

A count of zero can mean two things: every override has been reviewed, or the plugin that records them is off and nothing has been recorded since. mySites.guru keeps the two apart by showing “Tracking is off” in place of a count.

The Template Override Tracking Investigate page shows the plugin’s state and has a switch to turn it on or off, without logging in to the site. Remember the limit from earlier: turning it back on only records updates from then on. Whatever changed while it was off is not coming back.

A site with tracking off has no history

A site with the Installer - Override plugin disabled has no record of which overrides the last update changed, and switching it on today does not recover that. Switch it on now rather than after the next update day, then open the overrides you care about once and compare them in the Differences tab.

Updates Run From mySites.guru Now Get Recorded

Joomla’s comparison needs its “before” list and its “after” list from the same update. A Joomla core update run from mySites.guru runs as separate requests, so Joomla lost the “before” list and recorded nothing. An extension installed from a URL through mySites.guru had the same gap. Both are now recorded, the same as if you had run them from Joomla’s admin. Extension updates through mySites.guru already recorded correctly.

One consequence: core updates run from mySites.guru before this change recorded nothing, so any override they changed is not in the list. From the next update on, the list is complete.

A Practical Routine For 100+ Joomla Sites

Here is how I run it across client sites, in order.

After a bulk update day, open the All Sites page for Template Overrides To Check. Ignore the green rows.
Work the yellow rows, biggest count first. Investigate, open the Differences tab on each override, arrow in what core changed, bin what you never meant to keep, then Save and mark checked.
Delete overrides no one customised. This is Teeman’s point: an override you never changed is pure maintenance debt. Delete the file in Joomla’s Template Manager or with the mySites.guru file manager, and the next update stops flagging it.
Switch tracking on where it is off. Open the All Sites page for Template Override Tracking, Investigate, flip the switch.
Between update days, let the Manage Site “Important” tab do the reminding. It shows a card when a site has overrides to check (and tracking is on), with a button to the review page. In the sites list, search has-overrides-to-check to filter to just those sites.
After a core upgrade, the upgrade status page shows a “Review template overrides” button once the upgrade finishes OK on a site whose last snapshot had overrides to check.

If you script against mySites.guru, the API and MCP site summary now has the fields template_overrides_unchecked and template_override_tracking_enabled, plus an attention reason template_overrides_unchecked.

Separately, Joomla 5.4.8 and 6.1.3 broke override creation in Template Manager, a different problem from reviewing them.

Requested by Jaz, Shipped the Same Day

On 14 October 2026 at 16:16 UTC, Jaz posted a request on the mySites.guru Feature Requests board: “Snapshot check to show if there are Joomla template overrides that need checking”. The aim was to stop logging in to every site’s admin to find out. It was marked shipped at 19:08 UTC the same day, under three hours later. Thanks Jaz.

The Template Override Tracking check came out of building it. I had never known the Installer - Override plugin existed, and a site with it switched off records nothing at all, so its state became a check of its own.

A lot of mySites.guru gets built this way. Detecting locked Joomla scheduled tasks was a customer request, and so were several of the summer 2026 features. If there is a fact about your sites you keep logging in to check, post it on the board.

Try It On Your Own Joomla Sites

mySites.guru connects your Joomla and WordPress sites to one dashboard, and has been trusted since 2012, with 90,000+ sites protected. Both override checks run on every connected Joomla 4, 5 and 6 site from its next snapshot.

Sign up, connect a Joomla site, run a snapshot, and open the All Sites page. If it comes back yellow, open the Differences tab on the first override and see what the last update changed behind your back. Plans are on the pricing page, and the Joomla multi-site page covers the rest of what mySites.guru runs across your sites.

What Does File Checksum Failed Mean in a Joomla Update, and How Do You Fix It?

phil@mysites.guru (Phil Taylor) — Wed, 14 Oct 2026 09:55:45 GMT

You start a core update in Joomla Update and, instead of the update running, a red banner appears above the Pre-Update Check:

“File Checksum Failed” means the update zip Joomla downloaded did not match the SHA-512 hash Joomla’s release team signed, so Joomla stopped before installing anything. The banner says nothing about why the two differed.

Reasons Why You Might See File Checksum Failed in Joomla Upgrade

Joomla’s update servers, mirrors or CDN are serving a file that does not match the signed hash, usually in the hours after a new Joomla release.
The file is fine but the published hash is wrong, because of a mistake when it was entered or signed. This has happened on release days before and is usually corrected within minutes of being spotted.
The download failed or was cut short, or a proxy or firewall on your host interfered with it.
Your disk or hosting quota is full, so the zip could not be written.
The Path to Temp Folder in Global Configuration points at a folder that does not exist on this server, often one copied from a development machine.
The temp folder exists but PHP cannot write to it.
A truncated zip from an earlier attempt is still in the temp folder and Joomla keeps reusing it.

The rest of this post explains what the check does, why it fails around Joomla releases, and how to tell which cause you have.

The short version

Joomla downloaded the update zip, hashed it, and the hash did not match the one Joomla’s release team signed. Joomla installed none of it, so your site is unchanged. If the release is only hours old, wait an hour and try again. If it is not, check the Path to Temp Folder in Global Configuration, check your disk space, and delete any leftover Joomla_*_Update_Package.zip from your tmp folder before retrying, because Joomla reuses a truncated zip instead of downloading it again.

What Joomla Checks Before It Installs an Update

Before extracting a core update package, Joomla calculates its SHA-512 hash and compares it with the hash in Joomla’s signed update metadata. If the two differ, Joomla stops there and shows the banner. The language string behind the banner is COM_JOOMLAUPDATE_VIEW_UPDATE_CHECKSUM_WRONG, defined in com_joomlaupdate.ini.

A checksum, or hash, is a fixed-length fingerprint of a file. Change one byte of a 30 MB update zip and its SHA-512 changes completely. So if the hash of the file on your server matches the published one, you have the file the release team built, and if it does not, you have something else: a different build, a truncated download, an HTML error page saved under a .zip name, or an empty file.

Stopping is the right call. An update package is unpacked over the core files of your site, and a half-written or substituted package is the last thing you want extracted there.

Where the Signed Hash Comes From: TUF in Two Minutes

Since Joomla 5.1, core updates use The Update Framework, usually shortened to TUF. Before 5.1, Joomla read the expected hash from a plain XML file on the update server, so anyone who could change that file, or sit between your site and the server, could change the hash along with the package. TUF closes that gap by signing the metadata. David Jardin’s Joomla Magazine article on the 5.1 rollout explains why the project adopted it.

TUF splits the job into four signed roles, described in the TUF specification:

root: Lists the keys that are allowed to sign for every other role, and how many signatures each needs. Joomla publishes it as root.json.
targets: Lists the releases Joomla offers, with the file length, its hashes and its download URLs. This is where the SHA-512 for each release package lives, and it is signed by Joomla release team members.
snapshot: Records the current version of the targets file, so an attacker cannot mix an old targets file with new metadata.
timestamp: Re-signed automatically each day with a short expiry, so a site can tell when it is being fed stale metadata. If this one lapses you get a different error, which we cover in the offered update has expired.

Joomla’s own copy is at update.joomla.org/cms/targets.json, with its history in the joomla/updates repository. Each release entry lists the package’s length in bytes, its SHA-512 hash and its download URLs. For Joomla core those are downloads.joomla.org, the GitHub release asset and update.joomla.org/releases.

TUF and the checksum do two different jobs. TUF proves the hash came from Joomla’s release team and has not been tampered with. The checksum proves the zip on your server matches that hash. A TUF problem (expired, unsigned or tampered metadata) produces a JLIB_INSTALLER_TUF_* error before any download starts, and “File Checksum Failed” only appears once the metadata has passed and the package itself has not.

The TUF client library Joomla bundles, php-tuf, has its own download method that stops at the signed length and checks the hash, as section 5.7 of the specification describes. Joomla does not use it. It uses TUF to fetch and verify the metadata, then downloads the package with its own HTTP code and compares hashes in a function that predates TUF. That older code is why one message covers so many causes.

The Most Common Reason for File Checksum Failed in Joomla

Most of the time the error appears because a new Joomla version has only just come out and the Joomla project is still firefighting the release. In that first hour or so, packages are still reaching the mirrors, the signed update metadata is still being deployed, and CDN caches around the world are still being purged. Until all of that settles, some sites that check for the update are handed a file, or a cached response, that does not match the signed hash, and each of them shows the same red banner.

Nothing on your site needs fixing when this is the cause. The release team usually has it sorted within an hour or two, so if the version you are updating to came out today, wait and check for updates again later. If you cannot wait, download the package yourself, check its hash, and use Upload and Update, as described further down.

And yes, sometimes the Joomla project screws up the signing.

How mySites.guru Spots the Local Causes Before an Update

When the cause is on Joomla’s servers, all your sites fail together and the fix is patience. When it is local, it is one site, and often one that has been broken for months without anyone noticing, because the temp folder is only touched when Joomla tries to install something.

The most common local cause we see is a Path to Temp Folder copied from somewhere else. A site is built on a laptop or a staging server, the database and configuration.php move to production, and $tmp_path still points at /Users/someone/Sites/client/tmp or /home/staging/public_html/tmp. The site looks fine. Then an update or an extension install tries to write a file to a folder that does not exist on this server, and fails.

mySites.guru checks the configured tmp and log paths on each connected Joomla site twice a day, and flags any that do not match the site’s own default folders. Across the Joomla sites connected to mySites.guru, 11.6% are currently flagged by that check. The fix is one click: mySites.guru resets both paths to the site’s own tmp and administrator/logs folders.

Log And Tmp Folders Should Use Default Locations

mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.

It can also fix this across every connected site with one click.

Check your site for free

A separate check confirms that the tmp and logs folders are writable by PHP, and a scheduled backup before any core update covers you if an update does get partway through. If you look after more than a handful of sites, the portfolio view also answers the first question this error raises: is it one site, or all of them? If all your sites on the same Joomla version fail at once, it is Joomla’s side.

Why Joomla Shows the Same Error for Five Different Problems

The confusion comes from UpdateModel::download(). Simplified, it does this:

// Find the path to the temp directory and the local package.
$tempdir = /* Path to Temp Folder from Global Configuration */;
$target  = $tempdir . '/' . $basename;

// Do we have a cached file?
$exists = is_file($target);

if (!$exists) {
    // Try each download URL until one returns HTTP 200 and the write does not throw
    while (!($download = $this->downloadPackage($packageURL, $target)) && isset($sources[$mirror])) {
        // ...next mirror
    }
}
// (a 0-byte cached file is re-downloaded; a non-empty one is reused as it is)

$response['check'] = $this->isChecksumValid($target, $updateInfo['object']);

Three things in that code explain almost all the reports.

First, the hash check runs whatever happened before it. If all the mirrors failed, or the file was never written, Joomla still hashes $target. PHP’s hash_file() returns false for a missing file, false does not equal the signed hash, and you get “File Checksum Failed” rather than “Download of update package failed”. The controller tests the checksum result first, so the download-failed message is only reached in one narrow case: when the initial request for the package URL throws.

Second, downloadPackage() does not check whether the file was written. It calls File::write(), which returns false when PHP’s file_put_contents() fails, and ignores the return value. On a small RAM disk filled on purpose, PHP reports No space left on device, file_put_contents() returns false, and Joomla’s code continues as if the download had succeeded.

Third, Joomla keeps the file it downloaded. A failed check clears the session state but leaves the zip in the temp folder, and the next attempt reuses any non-empty file with the same name rather than downloading it again. Fix the disk space, retry, and the same truncated zip gives you the same error.

So the same banner can mean any of these:

Release-day mismatch: The mirrors, the CDN cache and the signed metadata are briefly out of step during a release, or a hash was entered wrongly. All sites fail at once and it clears on its own, usually within an hour or two.
Failed or partial download: A mirror returned an error, a proxy or firewall interfered, or the connection was cut. A host that blocks outbound requests to GitHub or update.joomla.org can fail all three mirrors.
Disk or quota full: PHP could not write the update zip, the failed write was not caught, and the hash check ran on an empty or incomplete file. Check the hosting control panel for the account quota, not only the server disk.
Wrong Path to Temp Folder: The tmp path in configuration.php points at a folder that does not exist on this server, often one copied from a development machine. The zip is not saved anywhere.
Temp folder not writable: The path is right but PHP cannot write there, usually after files were copied with the wrong owner or permissions.

Joomla core developers have known about the first problem for years. When a wrong download URL caused this error on a 4.1.1 release candidate in 2022, one of them wrote on the issue that “the real message should have been that the download failed not that the checksums did not match and that should be patched”. Current Joomla still works this way.

Why Does This Keep Happening Around Joomla Releases?

Because a Joomla release is a set of manual and semi-manual steps done in a hurry, and the checksum is designed to catch any one of them going wrong. On release day the team builds the packages, uploads them to several places, signs the targets entry with their own keys, merges it, waits for CI to deploy, and relies on a CDN purge so the edge servers pick up the new files. Sites around the world start checking minutes later. If one mirror is a few minutes behind, one edge still has an old response cached, or one hash is pasted wrongly, the sites that check in that window get a mismatch. The release history near the end of this post shows how often that has happened.

TUF could not have prevented this. It guarantees that the hash your site checks against was signed by Joomla’s release team. It cannot guarantee that the hash describes the file each mirror and CDN edge is serving at that minute.

The same pattern hits the TUF metadata itself. When the daily timestamp file is not deployed in time, sites get a different error, which we traced in the offered update has expired. Joomla’s update CDN has a documented history of caching a file at the wrong moment.

How Do I Fix File Checksum Failed in Joomla?

Work out which cause you have before changing anything. If the version you are updating to came out in the last few hours, start with step one. If it has been out for days and other people’s sites updated fine, skip to step two.

Wait an hour and check again. Go to System, Update, click Check for Updates, and retry. A release-day mismatch affects everyone and clears without any change to your site.
Check the Path to Temp Folder. In System, Global Configuration, open the Server tab. Path to Temp Folder must be the absolute path of a folder that exists on this server and that PHP can write to, normally the tmp folder inside your site’s root. Joomla’s own field help warns against using the system-wide /tmp. If it shows a path from another machine, fix it here or with the one-click fix in mySites.guru.
Check disk space and quota. A Joomla 6 update package is around 30 MB, and it is then unpacked over the site. Shared hosting quotas fill up without warning, often with old backups. Free a few hundred megabytes before retrying.
Delete leftover update zips from the temp folder. Look for a file named like Joomla_x.y.z-Stable-Update_Package.zip in your tmp folder and delete it. Joomla reuses a non-empty file with that name instead of downloading it again, so a truncated zip from an earlier attempt makes each retry fail even after you have fixed the cause.
Read the update log. Joomla logs each attempt, including the URL it downloaded from, to administrator/logs/joomla_update.php. If the logged URL is not one of Joomla’s three mirrors, or the log stops before the checksum line, that tells you where it broke.
Use Upload and Update with a package you have verified. Download the Update Package from joomla.org, check its hash (next section), and install it from the Upload and Update tab of Joomla Update. The live download is skipped entirely.

If the error persists after all of that, and only on one host, look at what sits between PHP and the internet. A host that blocks outbound requests, a transparent proxy or a security product that rewrites downloads can all hand Joomla something other than the zip.

Is It Safe to Skip the Checksum Check?

Do not go looking for a way to turn it off. The check is the only thing between a corrupted or substituted package and the core files of your site, and a release-day glitch does not make it less useful the next time.

What you can do is run the check yourself, on a package you download by hand, and then use Upload and Update. Compare the SHA-512 of your download with the one in Joomla’s signed targets.json:

# macOS / Linux
shasum -a 512 Joomla_x.y.z-Stable-Update_Package.zip

# Windows (PowerShell)
Get-FileHash Joomla_x.y.z-Stable-Update_Package.zip -Algorithm SHA512

Find the entry for your version in targets.json and compare the full sha512 value. If yours does not match, download it again rather than installing it. Upload and Update only skips the live download, so a package that fails this check should stay off your site through either route.

How This Shows Up in Real Life

On a single site, the error looks the same whatever caused it. Across many sites, the pattern tells you which kind you have: a release-day problem hits every site checking for that version at once and clears on its own, while a local cause sits on one site until someone fixes it. Here is what the release-day kind looks like in the record.

The Joomla 6.2.0 and 5.4.10 Release

When Joomla 6.2 and Joomla 5.4.10 were released on 13 October 2026, the Joomla forum had a thread titled “Update to J6.2.0 failing - missing checksum?” within a quarter of an hour, and a second, “I see v 6.2 is out. However, the 2 sites I’ve tried have failed”, shortly after. The screenshot at the top of this post is from that day. About 75 minutes after the first report a forum regular posted “Seems to be fixed now”, and the sites updated without anyone changing anything on them.

The joomla/updates repository records each change to Joomla’s signed update metadata, with a deploy status from the CI system that pushes it to update.joomla.org. Lined up against the two forum threads, release day looked like this (all times UTC):

15:30
5.4.10 signed
Release team members sign the 5.4.10 targets entry into the staging area of joomla/updates.
15:35
6.2.0 signed
Three release team members sign the 6.2.0 entry. The 5.4.10 and 6.2.0 Update Package zips are uploaded to GitHub at 15:45 and 15:49.
16:00
GitHub releases published
The 6.2.0 and 5.4.10 releases go public on github.com/joomla/joomla-cms.
16:03
Signed metadata goes live
targets.json version 118, listing 6.2.0 and 5.4.10, is deployed to update.joomla.org. Sites start being offered the update.
16:18
First forum report
"Update to J6.2.0 failing - missing checksum?" A second user reports the same on 5.4.10 at 16:41, and another confirms Upload and Update works.
17:13
Clean-up release deployed
targets.json version 119 removes 38 old and pre-release entries, and the deploy purges the CDN cache. The 6.2.0 and 5.4.10 entries are unchanged.
17:32
"Seems to be fixed now"
Updates start working again on the forum. The original poster confirms at 18:57.

Joomla has not said what went wrong, and no issue was opened on GitHub, so we cannot tell you the cause. We can tell you what it was not. The 6.2.0 and 5.4.10 entries in the signed metadata have not changed from the first signing commit to today: same length, same SHA-512, same three URLs. No one signed a wrong hash and then corrected it.

We also downloaded the 6.2.0 package from all three mirrors on 14 October and hashed each copy. All three match the signed SHA-512. (The downloads.joomla.org URL redirects to update.joomla.org/releases, so two of the three are the same Cloudflare-cached file.) Whatever sites received between 16:03 and 17:32 was not what those mirrors serve now. The CDN cache purge at 17:13 is the only change in the record before the fix, which is suggestive, but timing is all it is.

Earlier Joomla Release Days

The 6.2.0 release was not the first. The public record shows the same error on release days going back years:

Date	Release	What went wrong	How long
11 June 2019	3.9.7	A release team member said on the issue: “I added the wrong hashes to the update server”	Minutes
21 March 2022	4.1.1 RC1	A wrong download URL in the update XML, so the download failed and the checksum error was shown (#37339)	Same day
25 October 2022	4.2.4	The published hashes did not match the zip, described on #39069 as “a security feature kicking in because of a mistake in the Joomla Update files”	About 6 minutes after it was spotted
15 and 21 February 2024	5.0.3 RC1, 5.0.3	Reported on #42816 and #42851; fixed on the server side	Same day
28 May 2024	4.4.5	Reported on #43559; cause not stated	About 15 minutes
13 October 2026	6.2.0, 5.4.10	Cause not stated; signed hashes were correct throughout	About 75 minutes

TUF did not prevent any of these, and could not have. Where a cause was given before Joomla 5.1, it was a wrong hash or a wrong URL in the unsigned XML file. On 13 October 2026 the signed hashes were correct throughout, which points at delivery: what the mirrors and CDN served in that window.

What Joomla Could Do Better Here

Most of the confusion around this error is avoidable, and the information needed to avoid it is already on the server. The signed targets entry includes the file’s length, which Joomla currently ignores. A zip that is 0 bytes, or 12 MB of an expected 32 MB, is a failed download rather than a tampered package, and Joomla could say so. A missing file is a temp folder problem, and Joomla could say that too, naming the path it tried. A non-empty file that fails the check could be deleted, so the next attempt downloads a fresh copy rather than reusing the bad one.

None of that weakens the security check, because the hash comparison would still decide whether anything is installed. It would turn one message covering five causes into five messages that each tell you what to fix. Until then, “File Checksum Failed” means “Joomla could not verify the file”, and finding out why is up to you.

Fixing Class "JPlugin" not found in Joomla 5 and 6

phil@mysites.guru (Phil Taylor) — Mon, 12 Oct 2026 16:54:13 GMT

A Joomla site that shows 0 - Class "JPlugin" not found instead of its home page has an extension written against Joomla’s old class names, running on a site where nothing provides those names any more. The same fault turns up as Class "JFactory" not found, Class "JComponentHelper" not found, Class "JTable" not found and a few hundred other variants. Joomla 5 and 6 only keep those names alive through a Backward Compatibility plugin, and the error appears the moment that plugin, or one specific option inside it, is switched off.

Across the Joomla 5 sites in the mySites.guru database, 97.8% still have the old Backward Compatibility plugin enabled, and Joomla’s own pre-update check blocks the Joomla 6 upgrade until it is disabled, so this error is about to get much more common. Any of those sites running an extension that still needs the old names will break partway through its Joomla 6 upgrade. mySites.guru shows the state of both compatibility plugins on every connected site, switches them on and off remotely, and on Joomla 4 and 5 scans your files for the old class names before anything breaks.

This post covers how to find which extension is responsible, four ways to get the plugin back on when the site is down (including when you cannot reach the admin), the class names no setting can bring back, and the fix that lasts.

What does Class “JPlugin” not found mean in Joomla?

JPlugin is the name every Joomla plugin extended up to Joomla 3. Joomla 4 renamed it Joomla\CMS\Plugin\CMSPlugin and kept the old name as an alias, loaded on every request from libraries/classmap.php, so nothing broke. Joomla 5 moved that alias list, around 470 names in all, into a plugin called Behaviour - Backward Compatibility. Joomla 6 moved it again, into Behaviour - Backward Compatibility 6. When the list is not loaded, PHP meets class PlgSystemSomething extends JPlugin, has no idea what JPlugin is, and stops.

The class name in the message tells you which old API the extension called:

Error message	Modern Joomla class
`Class "JPlugin" not found`	`Joomla\CMS\Plugin\CMSPlugin`
`Class "JFactory" not found`	`Joomla\CMS\Factory`
`Class "JComponentHelper" not found`	`Joomla\CMS\Component\ComponentHelper`
`Class "JText" not found`	`Joomla\CMS\Language\Text`
`Class "JTable" not found`	`Joomla\CMS\Table\Table`
`Class "JRoute" not found`	`Joomla\CMS\Router\Route`
`Class "JHtml" not found`	`Joomla\CMS\HTML\HTMLHelper`
`Class "JPluginHelper" not found`	`Joomla\CMS\Plugin\PluginHelper`
`Class "JModuleHelper" not found`	`Joomla\CMS\Helper\ModuleHelper`
`Class "JModelLegacy" not found`	`Joomla\CMS\MVC\Model\BaseDatabaseModel`
`Class "JRegistry" not found`	`Joomla\Registry\Registry`

On PHP 8 the class name is in double quotes. Older forum threads quote it as Class 'JPlugin' not found because PHP 7 used single quotes, and they are the same error.

Where the extension lives decides how much of the site goes down. A system plugin loads on every request, front end and administrator alike, so a system plugin calling JPlugin takes the whole site and the admin login with it. A module only fails on pages where it is published, but when it does, Joomla replaces the entire page with the error page, not just the module position. JComponentHelper errors often come from a component or module helper, which is why they tend to break some pages and leave others working.

Where the JPlugin error comes from in Joomla 4, 5 and 6

The same message has different causes depending on the Joomla version, and the default settings differ in each. That is why “enable the compat plugin” works for one person in a forum thread and does nothing for the next.

Joomla version	Where `JPlugin` comes from	Default state
4.4	`libraries/classmap.php`, loaded on every request	Always on. The 4.4 compat plugin is an empty placeholder
5.0 to 5.4	Behaviour - Backward Compatibility, option Classes Aliases	Enabled, Classes Aliases on, for both fresh installs and upgrades
6.x, upgraded from 5.4	Behaviour - Backward Compatibility 6, option Classes Aliases	Enabled, Classes Aliases on
6.x, fresh install	Behaviour - Backward Compatibility 6, option Classes Aliases	Plugin disabled, Classes Aliases off

Joomla 5: someone switched the plugin off

On Joomla 5 the old names only exist while Behaviour - Backward Compatibility is enabled with Classes Aliases on. Most sites hit the error because someone followed the advice to disable the plugin, which is good advice, before checking what depended on it. We covered why leaving it on forever is a mistake in the compat plugin is a crutch.

Joomla 5.4: the pre-update check for Joomla 6

This is the one most sites will meet next. When you point Joomla Update at Joomla 6, the pre-update check lists “The ‘Behaviour - Backward Compatibility’ Plugin Must be Disabled” as a required setting and will not offer the upgrade until it is. The Backward Compatibility 6 plugin that 5.4 installs alongside it is, on 5.4, an empty class that listens to nothing and loads nothing. So the moment you disable the old plugin on 5.4, every JPlugin, JFactory and JComponentHelper reference on the site has no alias at all. The Joomla 5.4 end of support post has the full upgrade order.

Joomla 6: a fresh install, or a migrated site

An upgraded Joomla 6 site gets Backward Compatibility 6 enabled with Classes Aliases on, so old extensions keep working. A fresh Joomla 6 install ships the same plugin disabled and Classes Aliases off, on the assumption that a new site has no old code. If you built a new Joomla 6 site and then installed an older extension, or migrated content and extensions into one, that is where the error comes from, and enabling the plugin alone does not fix it.

How do I find which Joomla extension is causing it?

The error names the class, not the extension, so the first job is to get Joomla to print the file path, and when the administrator is down the only way to do that is to edit configuration.php by hand. Connect over FTP, SFTP or your host’s file manager, open configuration.php in the site root, and change these two lines:

public $debug = true;
public $error_reporting = 'maximum';

Save it and reload the broken page. Under the error message Joomla now prints a table headed Call stack, with a Function column and a Location column. The Location column is the list of files PHP passed through on its way to the failure, newest first, and the first path in it that is not core Joomla is your answer: something like /plugins/system/oldextension/oldextension.php or /administrator/components/com_something/helpers/something.php. The folder name is the extension.

That table only exists when $debug is true. Setting error_reporting to maximum on its own makes PHP display its errors, but Joomla’s error page still prints nothing more than the message.

Use maximum, not development

Joomla 3 called this setting “development”. Joomla 4 still accepted that value and converted it to “maximum” when you saved Global Configuration, but Joomla 5 and 6 no longer recognise it. An unrecognised value is passed straight to PHP’s error_reporting(), which on PHP 8 throws a type error because “development” is not a number. Copying an old tutorial into configuration.php on a Joomla 5 or 6 site gives you a second fatal error on top of the first.

Ignore the Deprecated lines at the top of the page

The Deprecated lines are PHP warnings about code that will need changing for a future PHP version, and none of them is the cause. Maximum error reporting shows everything PHP has to say, and on PHP 8.4 or 8.5 that means a wall of lines like this before you reach the real error:

Deprecated: Using null as an array offset is deprecated, use an empty string instead in /home/example/public_html/libraries/src/Menu/AbstractMenu.php on line 164

A Deprecated notice does not stop the page. The one above comes from libraries/src, which is Joomla core, and a clean Joomla install produces some of these on the newest PHP; a template framework’s system plugin can add more. The file paths in them look like evidence, and following them is the easiest way to lose an hour on this error. Scroll past the lot to the Class "JPlugin" not found message and look for the Call stack table under it.

No Call stack table? Your template’s error.php is hiding it

When debug is on and the page still shows a short “An error has occurred” message, or a branded “Something went wrong” page, the template is in the way. Joomla renders the active template’s own error.php if the template has one, and many commercial templates and template frameworks ship an error.php that never prints the trace, whatever debug is set to.

Rename templates/YOUR_TEMPLATE_NAME/error.php to error.php.bak over FTP or your host’s file manager and reload. With no template error page, Joomla falls back to templates/system/error.php, which prints the Call stack table whenever debug is on. Put the file back once you have the path.

Do not go looking in the log files instead. Joomla catches this error and logs it under the error category, but out of the box it only writes the system category to administrator/logs/joomla_core_errors.php. Unless Log Everything is on, or error is listed in the custom log categories, there is nothing in administrator/logs to find. PHP’s own error log does not see it either, because Joomla handled it before PHP could.

Reading the call stack: a worked example

A Joomla forum thread from October 2026 runs through every one of these steps on a real site. The owner was on Joomla 5.4.9 and PHP 8.5, had disabled Behaviour - Backward Compatibility because the Joomla 6 pre-update check requires it, and both the front end and the administrator went to 0 Class "JPlugin" not found. Another forum member gave the standard advice: error reporting to maximum, debug on, and the call stack will name the plugin.

What came back was a page of Deprecated lines, first from the T4 template framework’s system plugin and then from Joomla core, with no Call stack table anywhere. The owner had by then switched off a long list of components, plugins and modules by hand, from a Droppics image gallery, from My Maps Location and from others, and the site stayed broken.

The reply in the thread was to ignore the Deprecated messages, because the stack trace is the list of files the code passed through and that is the only part that matters, and when no trace shows at all, to delete /templates/YOUR_TEMPLATE_NAME/error.php so the template stops hiding Joomla’s errors. With that file out of the way the trace appeared, and it pointed at mymaplocations.php, the system plugin of the My Maps Location extension. That plugin had to be removed or recoded before the site could run without the old class names.

The first debug output was posted at 11:15 and the plugin was named at 11:36, and almost all of those twenty-one minutes went on the Deprecated lines and the missing table.

Why switching extensions off one by one rarely finds it

The owner in that thread had already switched off parts of the extension that turned out to be the cause, and the site was still down, which is a common result of this approach. Disabling a component in Joomla does not disable the plugins the same extension installed, and one extension can install a lot of them: My Maps Location alone put ten plugins on that site, on top of its modules and component. The system plugin keeps loading on every request however much of the rest you switch off. With the administrator down you are flipping rows in the database and reloading to see what happened, and on a site with more than thirty third-party plugins that is an afternoon’s work. The Call stack table names the file on one page load.

With SSH access, a search is quicker than reading traces. This lists every PHP file outside the core that still extends JPlugin or calls JFactory:

grep -rlE "extends JPlugin|JFactory::|JComponentHelper::" --include=*.php plugins components modules administrator/components administrator/modules

Joomla 5 and 6 core files do not use these names, so anything it returns belongs to a third-party extension. It also finds extensions that will break but have not yet, because the page that loads them has not been visited since the plugin went off.

When you are finished, set $debug back to false and $error_reporting back to 'default' or 'none'. A live site that prints stack traces is telling every visitor your server paths and extension list.

Getting the Backward Compatibility plugin back on

Turning the plugin back on is a stopgap, but it gets a broken site back in seconds while you deal with the extension. Use the first method that works for you.

From the Joomla administrator

If the admin still loads (a broken module or component usually leaves it alone), go to System > Manage > Plugins, search for “compat”, and enable Behaviour - Backward Compatibility on Joomla 5 or Behaviour - Backward Compatibility 6 on Joomla 6. On Joomla 6, open the plugin and set Classes Aliases to Yes as well, then save.

From mySites.guru, without logging in

Each connected Joomla 5 and 6 site has two audit checks under Extension Information, one per compatibility plugin, each with an on/off toggle. The toggle does not go through the site’s normal page load. The mySites.guru connector loads only Joomla’s behaviour plugins, never system plugins, and flips the plugin’s enabled flag with a direct database update, so it should still work when a broken system plugin has taken the front end and the admin down. The same switch is on a single page for every connected site, which is how you check or roll back a batch of sites after an upgrade. The toggle changes the enabled state only, not the Classes Aliases option, so on a fresh Joomla 6 install you still need one of the methods below.

See the Backward Compatibility 6 plugin on every Joomla site

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs on every snapshot, twice a day.

Check your site for free

In phpMyAdmin

Open the site’s database in phpMyAdmin (or Adminer, or your host’s database tool), click the SQL tab, and run this. Replace jos_ with your table prefix, which is the $dbprefix value in configuration.php:

UPDATE jos_extensions
SET enabled = 1,
    params = JSON_SET(COALESCE(NULLIF(params, ''), '{}'), '$.classes_aliases', '1')
WHERE type = 'plugin'
  AND folder = 'behaviour'
  AND element IN ('compat', 'compat6');

It enables whichever compatibility plugins the site has, compat on Joomla 5 and compat6 on Joomla 6, and switches Classes Aliases on in both, leaving the plugins’ other options alone. After a Joomla 6 upgrade the old compat row no longer exists, because the upgrade uninstalls it, so on Joomla 6 the query only touches compat6. If your site has Joomla’s System Cache switched on, clear the cache/com_plugins folder afterwards, because Joomla caches the list of enabled plugins.

With a script uploaded to the site root

If you have FTP but no database tool, upload a small PHP file next to configuration.php and open it in a browser. It reads the database details from configuration.php, makes the same change as the SQL above, clears the cached plugin list and then deletes itself. Give the file a hard-to-guess name, such as fix-compat-7f3a9c.php:

<?php
/**
 * Switches Joomla's Backward Compatibility plugins back on, with their
 * Classes Aliases option, then deletes itself.
 *
 * Upload to the folder that holds configuration.php and open it in a browser.
 */
header('Content-Type: text/plain; charset=utf-8');

define('_JEXEC', 1);
require __DIR__ . '/configuration.php';
$config = new JConfig();

// Joomla allows "host", "host:port" or "host:/path/to/mysql.sock"
$host   = $config->host;
$port   = '';
$socket = '';
if (preg_match('/^(.+):(\d+)$/', $host, $m)) {
    [, $host, $port] = $m;
} elseif (preg_match('/^(.+):(\/.+)$/', $host, $m)) {
    [, $host, $socket] = $m;
}

if (stripos($config->dbtype, 'pgsql') !== false) {
    $dsn = "pgsql:host=$host;dbname={$config->db}" . ($port ? ";port=$port" : '');
} elseif ($socket) {
    $dsn = "mysql:unix_socket=$socket;dbname={$config->db};charset=utf8mb4";
} else {
    $dsn = "mysql:host=$host;dbname={$config->db};charset=utf8mb4" . ($port ? ";port=$port" : '');
}

try {
    $pdo = new PDO($dsn, $config->user, $config->password, [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]);
} catch (PDOException $e) {
    exit('Could not connect to the database: ' . $e->getMessage() . "\n");
}

$table = $config->dbprefix . 'extensions';
$rows  = $pdo->query(
    "SELECT extension_id, element, params FROM $table
     WHERE type = 'plugin' AND folder = 'behaviour' AND element IN ('compat', 'compat6')"
)->fetchAll(PDO::FETCH_ASSOC);

if (!$rows) {
    echo "No Backward Compatibility plugin found in $table.\n";
}

$update = $pdo->prepare("UPDATE $table SET enabled = 1, params = ? WHERE extension_id = ?");

foreach ($rows as $row) {
    $params = json_decode($row['params'] ?: '{}', true) ?: [];
    $params['classes_aliases'] = '1';
    $update->execute([json_encode($params), $row['extension_id']]);
    echo "plg_behaviour_{$row['element']}: enabled, Classes Aliases switched on\n";
}

// With System Cache on, Joomla caches the list of enabled plugins
foreach (['/cache/com_plugins', '/administrator/cache/com_plugins'] as $dir) {
    foreach (glob(__DIR__ . $dir . '/*') ?: [] as $file) {
        is_file($file) && unlink($file);
    }
}

echo @unlink(__FILE__)
    ? "This script has deleted itself.\n"
    : "Could not delete this script. Delete it from the server now.\n";

Visit https://example.com/fix-compat-7f3a9c.php and you should see one line per plugin it switched on, then confirmation that it deleted itself. It does not bootstrap Joomla, so the broken extension never loads while it runs. If the last line says it could not delete itself, delete the file over FTP straight away: a script that writes to your database should not sit in your web root.

If a client site is down right now and you would rather hand it over, fix.mySites.guru fixes broken and hacked Joomla sites for a single fixed fee of £120, usually the same day.

We ran both the SQL and the script against a copy of a fresh Joomla 6 extensions table, where Backward Compatibility 6 starts disabled with Classes Aliases off, and each left the plugin enabled with Classes Aliases on and every other plugin untouched.

Why didn’t enabling the Joomla compat plugin fix it?

When the plugin is on and the error stays, the cause is almost always one of these.

The most common is that Classes Aliases is off. On Joomla 6 the plugin has three options, and only Classes Aliases loads the old J-prefixed names. The other two, Include Deprecated Classes and Removed Assets, cover the Input and Filesystem classes Joomla 6 dropped and some removed JavaScript assets. A fresh Joomla 6 install has Classes Aliases set to No, so enabling the plugin restores the deprecated classes and none of the aliases. This is the answer to a long run of forum threads where someone on a new Joomla 6.1 site enabled the plugin and nothing changed.

Next is a cached plugin list. With System Cache on, Joomla can keep serving the old list of enabled plugins after a database change. Clearing cache/com_plugins fixes it, and the script above does that for you.

Last, the class may have no alias at all, which is the next section.

Joomla class names no plugin can bring back

Some old names were never in either alias list. They were real classes in Joomla 3, removed in Joomla 4.0, and no version of the Backward Compatibility plugin defines them:

Error message	What it was
`Class "JDispatcher" not found`	Joomla 2.5’s event dispatcher, kept as a deprecated stub in Joomla 3
`Class "JEventDispatcher" not found`	Joomla 3’s event dispatcher
`Class "JRequest" not found`	Joomla 1.5 to 3 request input, replaced by `JInput`
`Class "JError" not found`	Joomla 1.5 to 3 error handling
`Class "JApplication" not found`	The legacy application class
`Class "JDatabase" not found`	The pre-3.0 database class
`Class "JArrayHelper" not found`	Array utilities, moved to the Joomla Framework
`Class "JString" not found`	String utilities, moved to the Joomla Framework
`Class "JSite" not found`	The old site application alias

Seeing one of these means the extension was written for Joomla 3 or earlier and has not been touched since, often on a site that was migrated rather than rebuilt. Smart Slider 2 leftovers, old Search plugins and abandoned gallery extensions are typical sources. There is nothing to switch on, so update the extension to a version written for your Joomla, replace it, or uninstall it. If the site is still on Joomla 3, the options for staying, patching or moving are laid out on joomla3security.com, and our post on migrating from Joomla 3 covers the extension audit to do first.

Fixing the Joomla extension for good

The compatibility plugin keeps the site up today. Joomla’s own source comments say the Joomla 6 alias list “will likely be removed in Joomla 7.0”, and a change merged into the Joomla 7.0 branch in June 2026 already removes Backward Compatibility 6 in favour of a Backward Compatibility 7. An extension that only runs because of Classes Aliases is due to break again at the next major version.

In order of preference:

Update the extension. Most maintained extensions dropped the old names years ago. Check the vendor’s site or the Joomla Extensions Directory for a release that lists your Joomla version, and update to it while the plugin is still on.
Ask the vendor. If no update exists, send them the file path from the stack trace and point them at the Joomla 5.4 to 6.0 compatibility notes. The fix is usually a handful of use statements.
Replace it. An extension still calling JDispatcher or JRequest in 2026 is abandoned, and abandoned code is a security risk as well as a compatibility one. Our extension management tools show which sites run it, so you can plan the replacement across all of them.
Patch it yourself, as a last resort. For your own code, or to buy time, replace the old names with the modern ones from the first table: extends JPlugin becomes extends \Joomla\CMS\Plugin\CMSPlugin, JFactory::getApplication() becomes \Joomla\CMS\Factory::getApplication(), JComponentHelper::getParams() becomes \Joomla\CMS\Component\ComponentHelper::getParams(). A patched third-party extension is overwritten by its next update, so keep a note of what you changed.

Stuck at the Joomla 6 pre-update check

If the only thing between a Joomla 5.4 site and Joomla 6 is an extension that breaks without the old plugin, and the vendor has a Joomla 6 release but not a Joomla 5 one, there is a clean way through: disable that extension, disable Behaviour - Backward Compatibility, run the upgrade, then install the vendor’s Joomla 6 build. Disabling the extension first means the site keeps working while the old plugin is off. Take a backup before any of it.

Finding these Joomla extensions before they break a site

Every figure below is from the latest snapshot of each Joomla site in the mySites.guru database over the past 90 days, as of 12 October 2026.

97.8%

of Joomla 5 sites still have the old Backward Compatibility plugin on

Joomla 6 will not install until it is off

84.2%

of Joomla 6 sites still have Backward Compatibility 6 on

Expected to be removed in Joomla 7

1.8%

of Joomla 6 sites still have the Joomla 5 plugin enabled

The Joomla 6 upgrade normally uninstalls it

Plan around the first number. Nearly every Joomla 5 site we monitor still runs with the old aliases loaded, so almost none of them have been tested without them yet. When those sites go through the Joomla 6 pre-update check, any site with an extension like this breaks at that moment, usually in the middle of a maintenance window that was booked as a routine upgrade.

Testing without the plugin on staging works for one site. For thirty, it is a week of work. mySites.guru does it in three steps:

Scan for the old names. On Joomla 4 and 5 sites, the audit check “Check Files That May Need Joomla 5 Compatibility Plugin (Beta)” searches every file on the site for the retired class names and flags the ones that use them, so you can open the list in the file manager and see which extensions they belong to before switching anything off.
See the plugin state everywhere. The Joomla 6 Compatibility Checker shows the Backward Compatibility plugin state beside each site’s PHP version, database version and update channel, colour-coded against the Joomla 6 technical requirements.
Switch it from one place. The toggle on each site’s audit, or the all-sites page for each check, turns either plugin on or off without logging in, and turns it back on if something breaks.

Find files that still use Joomla's old class names

mySites.guru checks every connected site for this automatically and flags it the moment it appears.

Check your site for free

All of this is part of every mySites.guru subscription, with unlimited sites. If you are working through a set of Joomla 5.4 sites before support for bug fixes ends, the Joomla 6.2 post has the rest of the upgrade picture. Check each site’s update channel too, so nothing jumps to the next major version by accident while you are still clearing extensions.

What is Joomla 3.x UTD (And why you don't need it)

phil@mysites.guru (Phil Taylor) — Mon, 12 Oct 2026 15:01:44 GMT

Joomla 3.x UTD describes itself as “an up-to-date distribution of the Joomla 3.x content management system, built to ensure code security, support modern PHP & MySQL/MariaDB versions & fix any broken behaviour that never got sorted before the release of newer major versions of Joomla.”

Its website goes further. Under the headline “secure, current & still yours”, it says UTD “keeps those sites secure and current” and “breathes new life into them”, which pitches it as the rescue for every Joomla 3 site left behind after support ended.

The Joomla 3.x UTD homepage on 12 October 2026.

The project behind that pitch is a hard fork of Joomla 3.10.20 eLTS, published by JoomlaWorks (the company behind K2) in April 2026 and written by one developer with an AI assistant. It ships at a pace that has already put its own security bugs onto live sites. Open Source Matters, Inc. and The Joomla! Project do not make it, endorse it or support it, as the project’s own footer says.

Joomla 3.x UTD is not an official Joomla product name or version.

It is a complete fork of end-of-life Joomla 3 code by a third party, JoomlaWorks Ltd. The Joomla project has never released a version 3.11 or later, and Open Source Matters and the Joomla project do not make, endorse or support it.

We covered UTD briefly in Joomla 3 Didn’t Fail. Your Retainer Did., alongside the other projects trying to keep Joomla 3 alive. This post looks at it properly. Everything below comes from the public repository at github.com/joomlaworks/joomla-3.x, its website at j3xutd.joomlaworks.net, and JoomlaWorks’ own blog. Each point links to its source.

But why this blog post?

Because people are confused. Most Joomla 3 site owners have no interest in the politics between a fork and the official project, or in whose policy says what. They want stability, and some assurance that their site will keep running safely. A shiny website promising Joomla 3 a long and secure future offers exactly that, and it is easy to believe. If that promise rests on one developer and falls through, the owners who trusted it are worse off than when they started: the site still needs migrating, and there is less time to do it.

People need clarity, so this post sets out who makes UTD and what it does and does not do, and links the source for each point so you can check it yourself.

Where did Joomla 3.x UTD come from?

Official Joomla 3 support ended on 17 August 2023. The paid Joomla 3 eLTS programme added 18 months of security fixes and ended on 17 February 2025.

The repository was created on 20 April 2026. Its first commits are “Initial upload for Joomla 3.10.20 eLTS”, followed minutes later by “Initial upload of Joomla v3.11”. Seven releases followed in under six months, numbered 3.11 to 3.17, the latest dated 10 October 2026.

“Secure” is the headline, so start there

“Secure” is the first word of UTD’s headline, and security is the reason anyone would run a Joomla 3 fork instead of migrating. So that is where it has to be judged, and it is where it is weakest.

Look at the chain that keeps a CMS site safe: who writes and reviews the fixes, how a vulnerability gets reported, how updates reach the site, and whether they can be checked when they get there. Official Joomla has a team at each step. Reports go privately to the Joomla Security Strike Team (JSST), who confirm them, fix them with the core maintainers, and publish an advisory with the release. I have reported Joomla core vulnerabilities through that process myself. Update packages come with checksums, and since Joomla 5.1 they are signed with TUF.

UTD has one developer and an AI assistant at every step. No one reviews the fixes. There is no private way to report a vulnerability. Updates are an unsigned zip, rebuilt on every commit and published with no checksum. Its own changes have already added a security hole, and the servers it tells owners are fine are years past their own security support. The sections below take these one at a time.

Developer

Every one of 158 commits

Checksums in the update feed

Official Joomla publishes three

Little WAF filters

None for SP Page Builder

Rebuilds of the stable zip

Since 10 October 2026

Read from the joomlaworks/joomla-3.x repository and its update feed on 12 October 2026.

The core is not what is getting Joomla 3 sites hacked

Even a perfect core fork would miss where the damage comes from. In Joomla 3 Didn’t Fail. Your Retainer Did. we measured the Joomla 3 sites connected to mySites.guru on 28 August 2026: 4.90% were flagged as hacked against 0.98% on Joomla 6, and 22.3% were running at least one extension with a known published vulnerability. The most common were YOOtheme Installer, Regular Labs’ Cache Cleaner and Advanced Modules, SP Page Builder and JCE, and for six of the eight most common, the 2026 fix cannot be applied on Joomla 3 at all.

UTD’s answer to the extension problem is the Little WAF, a plugin added in 3.16 that its website says “filters known attack signatures against abandoned or historically vulnerable third-party extensions”. That sounds broad. The code in plugins/system/littlewaf/littlewaf.php has exactly two filters, and it has had only those two since it first shipped: one blocks Regular Labs Sourcerer’s {source} tag in requests, the other blocks Modules Anywhere’s {module} and {modulepos} tags. Both target real problems, and Sourcerer’s CVE-2026-74253 was being exploited when the filter was written. The plugin is also disabled by default, and its own description says it is “not a substitute for updating or removing the vulnerable extension itself”.

That leaves everything else in the table above. There is no filter for SP Page Builder, including the uploadCustomIcon file upload flaw (CVE-2026-48908) that was exploited in the wild, or the unauthenticated SQL injection and file inclusion holes that followed it. I reported those to JoomShaper myself, 14 SP Page Builder vulnerabilities in all this year, and SP Page Builder 6.8.0 and later will not install on Joomla 3. There is nothing for YOOtheme or JCE either. A site owner who reads “secure, current & still yours” and moves a Joomla 3 site onto UTD keeps every one of those extensions, gets two tag filters if they think to switch the plugin on, and now has a core that tools cannot identify as well.

Called a community project, however the facts show it’s built by one man

The 3.17 release notes list “22 security fixes” in fourteen entries. Nine are marked “(stock Joomla 3)”. One is marked “(since 3.12)”: the {loadmoduleid} tag “showed any module to anyone, whatever its access level or publishing dates”. The CHANGELOG explains that the 3.12 change letting it show modules not assigned to the current menu item “dropped those checks too”, so an author could display any module, including private ones, inside an article. The fork introduced that access-control hole on 21 May 2026 and fixed it on 10 October, and then counted the fix in its security total.

Other bugs were also the fork’s own work. Every Help button in the administrator showed “not found” from 3.11 to 3.17, because the new version numbers point at help screens that do not exist on joomla.org. The Little WAF plugin added in 3.16 showed no version, date or author on upgraded sites, and was fixed a week later in 3.17. The issue tracker has “SEF canonical tags gone after J 3.14 update” (#16), “redirect after updating to 3.13” (#6), “install 3.15 when banners component has been removed results in an error” (#18) and “Beez3 not fully removed” (#7).

The security page has the same problem. Most of the CVE IDs it lists resolve on cve.org, but “CVE-2026-352212” (described as a com_tags SQL injection) does not exist. If an ID on a security list does not resolve, you cannot check that the fix it describes is the fix you think you have.

Seven releases in under six months, two of them a week apart, with breaking changes in minor versions, regressions reported after updates and a security hole of the fork’s own making. That is sloppy release engineering, and we say it is one man’s work on purpose. The project’s own website says it is “kept up to date by the community” and calls itself “an independent community project”, yet we can find no evidence of any community writing the code. Every commit comes from Fotis Evangelou’s account, the only pull request from anyone else was closed without being merged, and no change has been through a reviewed pull request (the repository numbers are below). A community project implies other people review a change before it ships, and here no one does, which is how a fork ends up counting the fix for its own security hole in its security total. Joomla 3 sites need careful maintenance far more than they need a new installer and an MCP server.

Security fixes no one else has checked

UTD says it backports Joomla core security fixes from Joomla 5 and 6, and also fixes “issues listed upstream as affecting only Joomla 4.0 and later”. For one template manager XSS it says it fixed “three code paths” where “the official fix covered one”. It may be right, but no one outside the project has checked. When the JSST fixes a core vulnerability, the fix is reviewed by more than one person and released alongside a public advisory. A UTD backport is one developer’s port, with an AI assistant, of a patch written for a different codebase, pushed straight to main and then to every site that updates. The changelog shows how that can go wrong: the {loadmoduleid} hole above was introduced by a UTD change. When we backport a Joomla 3 fix, we publish how we verified it against 3.10.12 so anyone can check our work.

Backports arrive weeks after the attackers know

A backport can only start once the fix is public. UTD is not part of the Joomla security process, so it gets no advance notice of a vulnerability: it sees the fix when Joomla publishes the patched release and its advisory, at the same moment as everyone else, including the people who read advisories to find sites to attack. A site on official Joomla 5 or 6 can update that day. A UTD site waits for one developer to port the fix to a different codebase and ship a release.

UTD’s own security list shows how long that takes. Joomla’s 26 May 2026 security release fixed a local file inclusion in the HTMLView layout parameter (CVE-2026-40383), an XSS in content history (CVE-2026-30894) and a transport encryption downgrade (CVE-2026-48902). UTD shipped those fixes in 3.15 on 18 July, 53 days later. In between it released 3.13 on 31 May and 3.14 on 4 July, and neither included them: 3.14 was PHP 8.5 deprecation fixes and language file versioning. The fixes from Joomla’s 7 July release followed in 3.15 eleven days after they were published, and CVE-2026-21631, published on 1 April, waited until 3.12 on 21 May. For seven weeks in the middle of 2026, a fully updated UTD site was missing a published file inclusion fix that every updated Joomla 5 and 6 site already had.

No tests and no build tooling

The official Joomla repository comes with the scaffolding that lets anyone check a change before it ships. The Joomla 3.10.12 tag has a tests/ folder with unit, Codeception and JavaScript tests, a phpunit.xml.dist to run them, Drone CI configuration that runs them on every pull request, and a build/ folder with the release script, the deleted-file check and the coding standard. It also has a composer.json and composer.lock, which record exactly which versions of the bundled third-party libraries a release uses and let a maintainer update them.

The UTD repository has none of it. There is no tests/ folder, no PHPUnit configuration, no CI beyond the workflow that zips the main branch, no build/ folder and no root composer.json. It still ships the 580 files of libraries/vendor that Joomla 3 bundled, but without the Composer files no one can rebuild or update those libraries in a reproducible way. Every change, including every security backport, goes from one developer’s editor to every site that updates without a single automated test running in between.

Updates no one can verify

Sites get UTD updates from joomlaworks.github.io/joomla-3.x/extension.xml. It offers “Joomla! 3.17.0”, tagged stable, and the download is releases/download/rolling/joomla-latest.zip. The project’s own workflow, .github/workflows/rolling-release.yml, deletes and rebuilds that zip “on every push to main”. Version 3.17.0 is therefore whatever the main branch looked like at the last commit, and it has been rebuilt ten times since 10 October. There is no release branch, no release candidate and no test stage between a commit and your live site. You cannot download an earlier version to roll back to either: the v3.15 release on GitHub has no package attached.

Those packages also cannot be checked. Joomla’s own update feed publishes a SHA-256, SHA-384 and SHA-512 checksum for every package, and UTD still has the code that checks them (isChecksumValid() in com_joomlaupdate/models/default.php), but its feed gives no checksums to check against. It could not, because the zip changes with every commit. Since Joomla 5.1, official core updates are also signed with TUF (The Update Framework). A UTD site installs whatever unsigned zip one GitHub account last produced, so anyone who gets into that account can push code to every UTD site that updates.

“Secure”, on servers that are not

The README says sites on PHP 7.1 to 7.3 “will still be offered updates to this distribution”, with PHP 7.4 as a recommendation rather than a requirement. PHP 7.1, 7.2 and 7.3 have had no security support for years, which is why we flag the PHP version on every site. The minimum databases are MySQL 5.5.3, MariaDB 5.5 and SQL Server 2008 R2, all long out of support. Telling owners that a site on an unpatched server is “secure” because the CMS code is patched gets the risk the wrong way round. UTD’s core audience is already there: JoomlaWorks’ own K2 telemetry puts 92.7% of active K2 sites on PHP older than 8.2.

It can hide sites from vulnerability scanners

Vulnerability rules for Joomla core, including the ones mySites.guru checks every site against, are written against Joomla’s own version ranges, for example “3.0.0 to 3.10.x”. A UTD site reports “Joomla! 3.17.0”, which sits outside every one of those ranges. A scanner will report it as unaffected or as unknown, whether or not the fix is actually in its code, and UTD’s own changelog admits the numbering “would also ‘trip’ some scanners”. We see this from the inside, because mySites.guru is an inventory tool: a site reporting a version that never existed is a site we cannot tell you is safe or unsafe. We have already watched the same failure on a smaller scale, when JoomShaper reused one version string across two different security releases and no inventory tool could tell a patched site from an unpatched one. UTD has that problem for the whole core, permanently and by design. A distribution sold on security should not make its sites harder to audit.

No way to report a vulnerability

The repository has no SECURITY.md, no contributing guide and no published way to report a vulnerability privately. GitHub’s community health check scores it 50%. If someone finds a Joomla 3 core vulnerability tomorrow, there is no confidential route to the one person who can fix it, and the public issue tracker is not the place for one.

Three new vulnerabilities of UTD’s own

While researching this post, we identified three security issues in Joomla 3.x UTD that do not exist in the official Joomla 3.10.20 eLTS release it was forked from. They were introduced by UTD’s own changes. We will disclose them responsibly to JoomlaWorks shortly and publish the details once fixes are available. With no SECURITY.md and no private reporting route, we will have to find our own way to reach the one person who can fix them.

Joomla 3.x UTD’s bundled libraries are as old as Joomla 3

UTD calls itself an up-to-date distribution, so we checked every third-party library it bundles against the OSV vulnerability database on 12 October 2026. Not one of the 34 PHP libraries in libraries/vendor has been updated: UTD’s installed.json lists exactly the versions official Joomla 3.10.12 shipped in July 2023. The JavaScript libraries are the same ones too. Official Joomla 3 hand-patched some of them in place, and those patches are still there (jQuery 1.12.4, for example, keeps Joomla’s backported prototype pollution and htmlPrefilter fixes), so we have left anything already patched out of this list.

Library	Version UTD ships	Known issues not fixed in that version	Fixed in
TinyMCE (the “legacy” editor existing sites keep)	4.5.12, built July 2020	17 advisories published since that build, including three High-severity XSS from June 2026 (CVE-2026-47759, CVE-2026-47761, CVE-2026-47762)	Only TinyMCE 5 to 8; the 2026 three in 7.9.3 and 8.5.1
Bootstrap (JavaScript used across the administrator)	2.3.2	Six XSS advisories, including CVE-2018-14040 and CVE-2024-6485	3.4.0 or 4.x, and no release at all for CVE-2024-6485
MooTools	1.4.5	Prototype pollution (CVE-2021-23432) and a High-severity ReDoS (CVE-2021-32821)	No fixed version: the project is abandoned
symfony/yaml	2.8.52	Three parser denial-of-service advisories from May 2026 (CVE-2026-45304, CVE-2026-45305, CVE-2026-45133), Low	5.4.52 and later only
paragonie/sodium_compat	1.17.1	CVE-2025-69277, Moderate	1.24.0

None of these is rated Critical, and whether each one can be reached depends on how Joomla uses the library. Most TinyMCE and Bootstrap issues need someone who can already edit content or load a crafted page. But these are the same libraries official Joomla 3 was shipping when it reached end of life, and UTD’s own release notes keep TinyMCE 4.5.12 as the editor for every existing site “until they switch in Global Configuration”. A distribution that says it ensures “code security” and has fixed “every PHP deprecation we could find” has not updated a single bundled PHP library, and with no composer.json in the repository it has no straightforward way to.

A hand-patched fork of jQuery from 2016

The jQuery that UTD loads in the administrator, and on any site whose template or extensions ask for it, is not a jQuery release at all. The first line of media/jui/js/jquery.js reads “jQuery JavaScript Library v1.12.4-joomla”. It is jQuery 1.12.4, released on 20 May 2016, with security fixes the Joomla project patched in by hand over the following years: one for a jQuery XSS issue (CMS issue 19464), a prototype pollution guard taken from a jQuery pull request, and a replacement htmlPrefilter() for CVE-2020-11022 and CVE-2020-11023, adapted from a Drupal backport. Each change is marked “ADDED by Joomla” or “Modified by Joomla” in the file. jQuery itself is now on 4.0.0, released on 18 January 2026, and the jQuery Migrate 1.4.1 bundled with it dates from the same day in 2016.

We compared the files with official Joomla 3.10.12, and jquery.js, jquery.min.js, jquery-migrate.min.js, bootstrap.min.js and mootools-core.js are identical to the official ones. UTD is shipping a fork of jQuery inside its fork of Joomla, and has not touched it. No one upstream maintains those Joomla patches any more, because the Joomla project stopped when Joomla 3 reached end of life, and nothing in UTD’s repository rebuilds or tests them. The library still reports itself to the browser as jQuery.fn.jquery = "1.12.4", so scanners that read the version flag the site as running a vulnerable jQuery 1.12.4, and no one can tell which of the later jQuery fixes are in this copy without reading it line by line.

UTD’s three new templates load no jQuery, Bootstrap or MooTools at all, which is a sensible choice. The administrator, Protostar, every older template and most Joomla 3 extensions still do.

To be fair to UTD, its new TinyMCE 8 editor is Tiny’s current release, 8.9.2 from 23 September 2026. Even that bundles DOMPurify 3.4.11, which has three advisories fixed in 3.4.12 and later, although that is a choice Tiny made, not UTD.

Why Joomla 3.x UTD confuses people

It puts the Joomla name and logo on a fork

The product name starts with “Joomla”. The footer says “This project does not use the Joomla! logo”, yet the fork’s own rewritten installer and administrator login page both render it: installation/template/index.php line 60 and administrator/templates/isis/login.php line 76 load joomla-logo.svg inline, with a new code comment reading “The Joomla! logo inline”. Both pages were redesigned for this fork, so the logo is there by choice.

UTD’s own logo borrows from Joomla’s too. Its mark, assets/logo/j3xutd-mark.svg, is four rounded strokes arranged as a cross in exactly Joomla’s four brand colours, #5091cd blue, #7ac143 green, #f9a541 orange and #f44321 red, set at the same diagonal as the four interlocking arms of the Joomla logo. It is not a copy, but next to “Joomla 3.x” in the product name, it is built to be read as part of the Joomla family.

UTD's mark (left) uses the same four colours as the Joomla logo (right).

The logo file has one more detail. It contains embedded C2PA content credentials, signed with Anthropic’s “Claude Content Signing” certificate, that record the action com.anthropic.claude.provided and the description “Claude provided this file at the request of a user and may have created or modified the file contents.” So the logo of a project that calls itself “kept up to date by the community” came out of an AI assistant, like 33 of its commits.

The Open Source Matters trademark FAQ is clear about forks. Asked whether you can take the Joomla codebase and rename it, it answers: “Yes, so long as you abide by the terms of the GNU GPL and if the new name and logo do not violate the trademarks.” The GPL covers the code, and the FAQ says the licence is “designed for software not for logos or names”. So the expectation is that a fork gets its own name. OSM also says it would “prefer that names of extensions be of the form [Extension name] for Joomla! Rather than Joomla! [Extension name]”, and “Joomla 3.x UTD” is the second form, on a whole CMS rather than an extension.

Put the pieces side by side: “Joomla” as the first word of the product name, version numbers that continue Joomla’s own 3.x line, a PRODUCT constant that still reports “Joomla!”, and the Joomla logo on the installer and login screens. Each one on its own could be explained away. Together they look like a fork presenting itself as Joomla, which is the confusion trade marks exist to prevent. The FAQ says as much: “The trademark also prevents confusion of other organizations or companies with Joomla! or Open Source Matters.”

That footer line, “This project does not use the Joomla! logo”, reads differently after a fresh install of UTD 3.17.0. The installer and the login card both show the registered Joomla! logo, and the Help menu, System Information and Joomla Update screens all present the product as Joomla.

The installer was rewritten for the fork, and the logo and the wording stayed in.

Every entry sends the user to the Joomla project's own resources.

The redesigned login card puts the registered Joomla! logo at the top.

The version row reports Joomla! 3.17.0 with empty codename brackets, a release Joomla never made.

The updater calls 3.17.0 the latest Joomla version; official Joomla 3 stopped at 3.10.

The JoomlaWorks website footer says its use of the Joomla name and logo “is permitted under a limited license”, which is normal for a long-standing extension vendor. I can find no public statement that the licence covers naming a fork of the CMS itself “Joomla 3.x UTD”. If it does, JoomlaWorks should say so. If it does not, this is a question for Open Source Matters.

The version numbers look like official Joomla releases

Joomla never released a 3.11. The Joomla 3 line stopped at 3.10.x, and so did eLTS. UTD starts at 3.11 and is now at 3.17, so a site running it reports a Joomla version the Joomla project did not ship.

It goes further than the label. In libraries/src/Version.php the PRODUCT constant is still 'Joomla!' and the copyright line is still Open Source Matters, so extensions, update servers and security scanners see “Joomla! 3.17.0”. The 3.14 changelog even notes that the new language file versioning “would also ‘trip’ some scanners”.

The numbering also breaks semantic versioning. Minor releases have made breaking changes: 3.12 removed the Beez3 and Hathor templates, and 3.16 removed four cache and session drivers and raised the minimum database versions. Under semver, changes like that need a major version. The site also describes “one rolling release”, so the version number does not tell you much about what code you are running.

Even its own developer cannot settle on a name

Is it Joomla 3.x UTD, J3xUTD or just Joomla 3.17? It depends where you look, and every one of these comes from JoomlaWorks itself:

Where	What it is called
The website headline, the README and the administrator status bar	“Joomla 3.x UTD”
The logo and the domain	“J3”, the four-colour cross and “UTD”, read as “J3xUTD” (the logo file is labelled “J3xUTD mark”), at j3xutd.joomlaworks.net
The April 2026 announcement	“an open distribution of Joomla 3.x (we call it Joomla 3.x UTD for now)”
The update feed’s own source	“Joomla 3.x (JoomlaWorks Security Distribution)”
The update Joomla Update offers you	“Joomla! 3.17” and “Joomla! 3.17 CMS”
The GitHub releases	“Joomla v3.11”, “Joomla v3.14”, “Joomla v3.15” and “Rolling Release (v)”
The GitHub repository	`joomla-3.x`, “Joomla 3.x development continued to ensure code security and support modern PHP versions”

Six months in, the name is still officially “for now”, the acronym is spelled out only once, at the top of the README, as “(up-to-date)”, and the two places a site owner is most likely to see it, the update screen and the release list, do not use the UTD name at all. They call it Joomla.

“Kept up to date by the community”

The website’s hero says the project is “kept up to date by the community”, and the footer calls it “an independent community project”. The repository shows something different:

All 158 commits come from one GitHub account, Fotis Evangelou’s (fevangelou).
33 of those commits have a Co-Authored-By: Claude Opus 5.5 trailer, all from October 2026.
The only pull request from anyone else (#13) was closed without being merged.
There are 14 issues from 5 people, and 8 discussions, 6 of them started by one user.

A small group reports bugs and Fotis writes the code, with an AI assistant. That is a legitimate way to run a project, but it is a one-person project and a single point of failure.

Its help system is the official Joomla one

UTD has no documentation site of its own. Its website has no documentation section, and the docs/ folder in its repository holds only the update feed and sample data. Everything it has added, from the new installer and the 100-command CLI to the MCP server, SQLite and the Little WAF, is documented in the README and one AI-GUIDE.md file.

Press a Help button in a UTD administrator and you go to the official Joomla project. The CHANGELOG explains that from 3.11 to 3.17 those buttons showed “not found”, because the Joomla help site only has screens up to 3.10, and that “Versions 3.11 and later now use the 3.10 help screens”. So a UTD user who needs help is sent to Joomla’s own 3.10 help screens, run by the volunteers of the project that does not support UTD, to read documentation written for a version they are not running. The same goes for the Joomla forum, Joomla Stack Exchange and every Joomla 3 tutorial on the web: all of it describes official Joomla 3, and none of it knows what UTD changed.

Borrowed goodwill and selective statistics

Forking is fine. Forking well means taking the code and leaving the name behind, and open source has done it that way for decades. Joomla itself began in 2005 as a fork of Mambo, and the first thing the developers did was choose a new name. LibreOffice left OpenOffice’s name with Oracle, MariaDB left MySQL’s, and when WordPress 5.0 brought in the block editor, the people who wanted to keep WordPress 4.9 alive called their fork ClassicPress. Each project had to earn its own reputation instead of borrowing its parent’s. JoomlaWorks knew this in 2024, when its own plan for the fork started with a rebrand.

Keeping the name lets UTD trade on twenty years of goodwill it did not build. The Joomla name means something to site owners because of the volunteers who wrote the code, triaged the security reports, translated it into dozens of languages, ran the events and answered forum questions for two decades. UTD arrives as “Joomla 3.x”, version 3.17, with the Joomla logo on its login page, and borrows that trust on day one. The trust belongs to the Joomla project and the people who earned it.

The statistics are borrowed the same way, and chosen to suit. In May 2024 JoomlaWorks used W3Techs to argue that Joomla 4 and 5 had failed: “They account for around 0.3% of ALL Joomla sites according to W3Techs”, so “adoption for these versions is close to non-existent”. It set aside Joomla’s own figures, which it said “still show around 10% of sites use Joomla 4/5”. In October 2026 the v3.17 announcement goes back to W3Techs for the headline that Joomla 3 runs on “more than 50% of all installed Joomla sites”. It does not mention that the same source now puts Joomla 4, 5 and 6 at 37.9% of Joomla sites, with Joomla 5 alone at 20.5%. Quoting a source when it helps and leaving out the rest of the same page is marketing, not evidence.

A dead end on the way back to official Joomla

UTD rewires Joomla Update. In com_joomlaupdate/models/default.php, the Default, Testing and “Next” channels all point at JoomlaWorks’ feed. The code describes “Next” as “Minor & Patch Release for Current version AND Next Major Release”, and it is the channel a Joomla 3.10 site uses for the one-click upgrade to Joomla 4. Switching to a custom URL does not help: Joomla’s official Joomla 4 upgrade feed (update.joomla.org/core/j4/default.xml) targets sites on 3.10, and a UTD site reports 3.17. Once a site moves to UTD, the official upgrade route is gone. Even on official Joomla, switching update channels can fling a site onto the wrong release, and UTD has rewired every one of them.

The database choices make it worse. UTD’s headline 3.17 feature is “every major database”, including SQLite and SQL Server. Joomla 4, 5 and 6 support only MySQL, MariaDB and PostgreSQL, and Joomla 4 dropped SQL Server. A site built on UTD’s SQLite or SQL Server support has no official Joomla to move to. A SQLite site can only get out through UTD’s own database:convert --to=mysqli command, run before any migration, on a driver the project itself labels experimental. A SQL Server site cannot even do that: the README says database:convert and the other database commands “don’t support SQL Server”. A site that could have upgraded itself from 3.10 now depends on one maintainer’s tools to leave his fork.

Your Joomla 3 extensions are not guaranteed to keep working

Joomla 3 extensions may install and run on UTD today. The project does not promise they will keep doing so, and the published roadmap points the other way.

The UTD README describes “a new fork on the way” that is “a stripped down version of Joomla 3.x with all non-essential extensions removed”, where “com_content (and anything related) is removed entirely” and replaced by K2. The v3.17 announcement calls that fork “a separate project” that is “moving along very actively”, and the README calls UTD’s CLI and MCP server “the seed” for it. So the same single maintainer is splitting his time between UTD and a successor that drops the component most extensions are built on. Most third-party Joomla 3 extensions depend on com_content: content plugins, article modules, custom fields, SEF routers and page builders. The compatibility promise in that same sentence is “true backwards compatibility with past releases (of the fork)”, meaning with UTD itself, not with the Joomla 3 extensions you run.

The minor releases so far have already removed core templates and drivers. The README also asks extension developers to change their update XML so it does not stop at Joomla 3.10.x, which means support depends on third-party developers who have made no commitment to this fork. The Joomla Extensions Directory feed itself stops at 3.10.

So far, no other developer has taken up that request. When we searched in October 2026, the only extensions declaring support for Joomla 3.x UTD were JoomlaWorks’ own: K2, whose JED listing says it is “committed to be 100% compatible” with the distribution, and the paid Simple Image Gallery Pro, released as “PHP 8.x compatible for Joomla 3.x UTD”. We could not find a single third-party developer announcing, testing or releasing an extension for it, and a GitHub code search for “Joomla 3.x UTD” outside JoomlaWorks’ own repositories found nothing but our own pages. An ecosystem of one vendor is not much of an ecosystem, and one of UTD’s most active users said as much in its own discussions, under the title “J3 development is good but we miss an ecosystem”.

Joomla developers would have to support a second, older framework

Building for UTD means building for Joomla 3, which is a different platform from Joomla 4, 5 and 6. Joomla 3 extensions use the legacy MVC classes (JControllerLegacy, JModelLegacy), Bootstrap 2, jQuery and MooTools, and no namespaced extension structure. Since Joomla 4, extensions use namespaced MVC, a dependency injection container with services/provider.php, the Web Asset Manager and Bootstrap 5. Code written for one does not run on the other without real porting work.

A developer who wants to support UTD users therefore keeps a second codebase for an old framework that only one maintainer is moving forward. If the roadmap’s K2-based fork ships, extensions that rely on com_content would need yet another target. The README’s request that they extend their Joomla 3 update XML asks them to take on that work for free.

What is Joomla 3.x UTD really for?

JoomlaWorks has said why in its own words, and its Joomla 3 record is on our Joomla 3 security hub. In a blog post on 30 May 2024, “K2 will not be made available for Joomla 4/5 - change of course”, the company called Joomla 4 and 5 “failed CMS releases”, said “we don’t plan on giving up on K2 (or Joomla 3)”, and said its “goal is to pivot and work on a possible fork”. The first phase of that plan was rebranding, so that existing sites could move their content from com_content to K2.

UTD and its planned leaner successor are that plan, except that UTD skipped the rebranding and kept the Joomla name. UTD keeps K2’s natural home alive, and the successor replaces Joomla’s own content component with K2. It also keeps a market alive for JoomlaWorks’ paid products: the blog sidebar advertises Simple Image Gallery Pro as “PHP 8.x compatible for Joomla 3.x UTD”, beside the “Commercial Templates” menu. And it pushes hard into AI, with a built-in MCP server and a CLI that the README says brings it “closer to becoming a truly agentic CMS”.

Who it is for: the sites its own developer runs

UTD’s developer owns a second business that shows who the fork is for. Nuevvo is Fotis Evangelou’s Athens web development and managed hosting company, listed alongside JoomlaWorks and K2 on his own site and his GitHub profile, and its homepage lists 42 active clients, most of them Greek news and magazine sites. We loaded each client’s homepage on 12 October 2026. Twelve still run K2 on Joomla, with K2’s own asset paths all over the page: dnews.gr, reporter.gr, ilialive.gr, news4health.gr, advertising.gr, allstarbasket.gr, healthstat.gr, ienergeia.gr, bikeit.gr, byblacks.com, karditsalive.net and gloman.gr.

Those twelve are UTD’s natural first customers, sites with years of articles in K2 and no K2 for Joomla 4 or later, and keeping them on a maintained Joomla 3 is a reasonable thing for their developer to want. It is a narrower purpose than “secure, current & still yours” for every Joomla 3 site. The rest of the same client list points the other way: 20 of the 42 now run WordPress, and the Greek broadcaster SKAI’s site, skai.gr, runs Drupal 10.

None of that is wrong in itself. Joomla is GPL software and anyone may fork it.

Site owners deciding where to take a Joomla 3 site should understand what they are choosing.

One company’s fork, maintained by one developer, built around that company’s own extension, that presents itself to your software as an official Joomla version the Joomla project did not release.

Joomla 6 or Joomla 3.x UTD?

For almost everyone, Joomla 6, and its technical requirements are modest. It is the official release, its vulnerabilities go to a security team rather than one person, its updates are checksummed and signed, and it is where extension developers are building today. A Joomla 3 site moving to UTD still faces a migration later, just a later and possibly harder one, because the K2-based successor drops com_content.

JoomlaWorks pitches UTD with the W3Techs figure that Joomla 3 runs on more than half of all Joomla sites. That number is right, even if the rest of the page it comes from is left out: W3Techs puts Joomla 3 at 51.7% of Joomla sites on 12 October 2026, against 37.9% for Joomla 4, 5 and 6 combined. What it does not show is a market waiting for a fork. W3Techs counts sites that still identify as Joomla 3, and a site that has had no update since support ended in 2023 is mostly a site no one is looking after. Our own figures point the same way, and they come from the well-looked-after end of the market. Of the Joomla 3 sites connected to mySites.guru in August 2026, sites whose owners pay every month for monitoring, 68.2% had not even updated to 3.10.12, the final Joomla 3 release. If owners who are paying for monitoring did not take a free point release from the official project, the owners of unmonitored sites are not going to go looking for a Joomla 3 fork. Most of those sites will be rebuilt on something else, or switched off when the hosting stops supporting their PHP version. UTD sites would also count as Joomla 3 in those figures, because they still report themselves as Joomla! 3.x. And W3Techs can already see them. Its Joomla 3 version breakdown on 12 October 2026 lists versions 3.11, 3.13, 3.14, 3.15 and 3.16, none of which the Joomla project ever released. Together they are a rounding error: 3.15 is 0.1% of Joomla 3 sites and the other four are each under 0.1%, against 59.0% still on 3.10.

For a Joomla 3 site that cannot be migrated yet, there is a holding position that keeps it on real Joomla, and the other options are laid out on our Joomla 3 hub. I should declare an interest, because this one is ours. The Joomla 3.10.999 project is a reference set of community security patches for stock Joomla 3.10.12, and the mySites.guru patch tool applies them with one toggle. The site still reports 3.10.12, there is no separate update server, switching it off puts the stock files back, and we describe it as a stopgap rather than a destination. TLWebdesign packages the same patches as an installable extension. None of these will save a site from its extensions, so the extension inventory still matters more than the core.

UTD’s PHP 8.5 work is the part I would give it real credit for. Hosts are removing PHP 7, and on some, such as Fasthosts, switching a site to PHP 8 to test it cannot be undone, so a Joomla 3 site that is not PHP 8 compatible simply stops. Solving that solves the hosting deadline, which is real and urgent. It does not solve the security one, and the two should not be confused.

I can see one group UTD is really for: sites built on K2 that never migrated to Joomla 4 because K2 never got there. That group is real, and some of it is large. The most popular sites W3Techs lists on Joomla 3 include two Greek news sites, dnews.gr and cnn.gr, and the dnews.gr homepage still loads its articles through K2, with images served from K2’s /media/k2/items/cache/ folder and K2’s k2ItemsBlock module on the page. Busy news sites like these, with years of content in K2 and no K2 for Joomla 4, are the sites UTD is built around.

JoomlaWorks publishes its own numbers for that audience, and they are the most telling figures in this post. K2 Metrics is the anonymous telemetry that K2 2.7.0 and later sends home. On 12 October 2026 it showed 4,775 K2 sites active in the last 30 days, and 4,585 of them, 96.0%, on Joomla 3. Just 33 reported a UTD version number (3.11, 3.14, 3.15, 3.16 or 3.17). That is 0.69% of K2 sites, six months after launch, among the very sites UTD exists to serve. The same telemetry shows 92.7% of those K2 sites on a PHP version older than 8.2, which means no security support from the PHP project, and 12.4% still on PHP 5. For them it buys time on a familiar stack. That is a fair reason to look at it, as long as you go in knowing you are moving onto one developer’s fork, with no promise your other extensions will keep working.

If security is why you are looking at UTD, that is the strongest reason not to use it.

A Joomla 3 site on UTD gets security fixes from one developer, reviewed by no one, delivered as an unsigned zip that changes with every commit, with no private way to report a problem and no official upgrade route out. That is a less secure place for the site than the official Joomla it would have to migrate to anyway.

How mySites.guru helps with Joomla 3 sites

mySites.guru looks after portfolios of Joomla sites. Connect your Joomla 3 sites and you get the facts this post had to dig out by hand, for every site at once:

Every site still on Joomla 3, found by the Joomla 3 end of life check, with every published core vulnerability flagged against each site’s exact version.
Every vulnerable extension, from the Joomla vulnerability scanner and the vulnerable extension list, which is where Joomla 3 sites are getting hacked.
The community core patches in one click, with the Joomla 3 patch tool applying the 3.10.999 fixes to stock 3.10.12 and reverting them if you need to. The site stays on real Joomla, with a version number every tool understands.
The PHP version on every site, so you know which hosting deadline you are up against before your host decides for you.

None of that replaces migrating. It tells you which sites to move first and keeps them safer while you do, and when you are ready, moving to modern Joomla with mySites.guru explains how the connector side works. mySites.guru is GBP 19.99 a month for unlimited sites, with the Joomla 3 patch tool included in every plan, or you can start with a free audit of one site.

Timeline

2023-08-17 Joomla 3 reaches end of life Free security patches for the Joomla 3 core stop, at any severity.
2024-05-30 JoomlaWorks rules out K2 for Joomla 4 and 5 It calls Joomla 4 and 5 "failed CMS releases" and says it will work on a possible fork, starting with a rebrand.
2025-02-17 The paid eLTS programme ends The last official route to a patched Joomla 3 core closes.
2026-04-20 Joomla 3.x UTD 3.11 is published A hard fork of Joomla 3.10.20 eLTS, under the Joomla name, numbered as if it were the next Joomla release.
2026-05-21 UTD 3.12 adds an access-control hole A change to the {loadmoduleid} tag drops its access checks, so any module can be shown to anyone.
2026-10-03 UTD 3.16 adds the Little WAF Two filters, both for Regular Labs tags. Nothing for SP Page Builder.
2026-10-10 UTD 3.17 fixes its own hole The {loadmoduleid} fix is counted among 22 security fixes.

Gridbox 2.20.4.0 Fixes a Language Install CSRF and an Image Path Check

phil@mysites.guru (Phil Taylor) — Thu, 08 Oct 2026 08:33:10 GMT

TL;DR

Balbooa released Gridbox 2.20.4.0 on 8 October 2026 with two security fixes for the Joomla page builder. The bigger one is a Cross-Site Request Forgery (CSRF) flaw in the language installation process. The smaller one tightens the path check in the image preview so it only serves images from the configured media folder.

The version most Gridbox sites run today, 2.20.3.1, is affected, and so is every build before it. Update to 2.20.4.0. The Joomla CNA published a CVE for each flaw later the same day: CVE-2026-102784 for the CSRF, scored 8.7 High, and CVE-2026-102783 for the path check, scored 6.3 Medium. High matches our own call, because the CSRF flaw ends with software installed on the site, even though it needs a Super User to be tricked into it.

8.7CVSS 4.0

CVE-2026-102784Cross-Site Request Forgery in language installation

HighJoomla CNA

A Super User who opens a crafted link while signed in installs a package the attacker chose, which puts the attacker's code on the site.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Needs a signed-in Super UserInstalls softwareAll versions before 2.20.4.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

6.3CVSS 4.0

CVE-2026-102783Path traversal in the image preview

MediumJoomla CNA

An anonymous visitor can fetch an image from a folder next to the media folder whose name starts the same way, such as images-backup. Only Gridbox image file types are served.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

No login neededImage files onlyAll versions before 2.20.4.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:L: Low: Some data can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The language installation CSRF

Gridbox lets an administrator install extra interface languages from inside the component. Installing a language means installing a Joomla package, which is the same machinery that installs any extension, so the action is limited to Super Users.

Cross-Site Request Forgery is an attack on the person rather than the server. The attacker cannot log in, so instead they get someone who already is to send a request on their behalf, usually by getting them to open a link or visit a page while their admin session is live. Joomla’s defence is a per-session token that every state-changing request must include. A request forged from another site does not have the token, so Joomla rejects it.

Gridbox 2.20.2 added that token check across its admin controllers as part of fixing the 23 vulnerabilities from our July audit. The language installation action had a route around that check. According to the CVE record, the shared token check only ran when the request was a POST, and the language install action accepted a GET, so a plain link reached it with no token at all. 2.20.4.0 closes that path, so the token check now covers the language install as well.

Why an admin-only flaw still rates High

A Super User has to be signed in and has to open the attacker’s link, so this cannot be sprayed at a site the way an unauthenticated flaw can. But the action installs software. If it works, the attacker’s code runs on the site with the same access as any extension you installed yourself. Admins open links all day, in support tickets, contact form messages and emails, and one of them is all it takes.

The image preview path check

The second fix is narrower. Gridbox’s image preview serves an image from the site so the editor can show it, and it is meant to stay inside the media folder configured in Gridbox. The containment check in 2.20.2 to 2.20.3.1 was looser than intended, and in some folder layouts it accepted image paths outside that folder. 2.20.4.0 makes the comparison exact.

The preview only serves Gridbox image file types, so configuration.php and other PHP files were not reachable through it. The CVE record adds one detail: if the server cannot decode the image, the preview streams the file as it is, which is why the record treats it as a file read at all. In practice it needs a folder beside the media folder whose name starts the same way, such as images-backup, with images in it you did not mean to publish. It tightens the containment added in July.

Which Gridbox versions are affected?

Both CVE records list every release from 1.0.0 to 2.20.3.1 as affected. We also compared the public 2.20.4.0 package with 2.20.3 and 2.20.2.2, and both of the changed areas are present from 2.20.2 onwards. Our newest rule flags 2.20.3.1 with both CVE numbers, and the existing rules for earlier ranges already flag every older build and point to 2.20.4.0 as the version to install.

Gridbox version	Status	What to do
2.20.4.0	Fixed	Nothing
2.20.3.1	Affected by this release’s two fixes	Update to 2.20.4.0
2.20.2.3 to 2.20.3	Also exposed to the blog author SQL injection	Update to 2.20.4.0
Below 2.20.2	Exposed to the actively exploited July flaws	Update to 2.20.4.0 urgently and check for compromise

Sites on the Joomla 3 line top out at Gridbox 2.17.0.2, which has no fix for any of this year’s flaws. For those sites the fix is moving to a supported Joomla.

What you should do right now

Update Gridbox to 2.20.4.0 on every Joomla site that runs it, through Joomla’s Update tab or the mySites.guru mass updater.
Confirm the version afterwards. Open System, Manage, Extensions and check Gridbox reads 2.20.4.0.
Check for extensions you did not install. If you are worried a Super User on one of your sites opened something they should not have, look at the extensions list for anything unexpected, and at administrator accounts you did not create.
If you use Facebook login, generate a new App ID and App Secret. Balbooa reworked the integration for Facebook’s API changes, so the old ones will not work.
Check your image compression settings. They have moved from Media Manager settings to Performance Tools, Images, and now apply to image uploads anywhere in Gridbox.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How do I find every Gridbox site I manage?

mySites.guru keeps a live inventory of the extensions on each connected Joomla and WordPress site. Search for Gridbox once and you get the sites running it, the version each is on and whether an update is waiting. Across the Joomla sites we monitor, several hundred run Gridbox, and the large majority were on 2.20.3.1 on the morning of the release.

We have added 2.20.3.1 to our vulnerability database, so connected sites still on it are flagged automatically, and the mass updater pushes 2.20.4.0 to all of them from one screen. That is part of the subscription, not a separate purchase.

Four Gridbox security releases since July

2.20.1 fixed the cookie authentication bypass in July. 2.20.2 fixed the 23 flaws from our audit at the end of that month. 2.20.3.1 fixed the blog author SQL injection three weeks ago. 2.20.4.0 is the fourth, and both of its fixes are follow-ups to protections that 2.20.2 introduced: the CSRF token check and the image path containment.

That pattern is normal once a large codebase gets serious attention. The first round of fixes adds the right protections, and outside researchers then find the corners those protections missed. The sites that get hurt are the ones that stopped updating after the first round. If your Gridbox sites went to 2.20.3.1 three weeks ago, they need updating again today.

Disclosure and severity

This is not a mySites.guru finding. Balbooa credits Sergiy Tryzhychynskyi for reporting both issues, and David Jardin of the Joomla Security Strike Team for coordinating the disclosure. Sergiy also reported part of the Balbooa Forms 2.4.3.4 fixes last month.

Balbooa’s note gave no CVE, no score and no affected range. The Joomla CNA filled that in a few hours later with CVE-2026-102784 (CSRF, CVSS 4.0 8.7 High) and CVE-2026-102783 (path traversal, CVSS 4.0 6.3 Medium), both listing every release up to 2.20.3.1. We had set our rule from the code before the records existed, so connected sites were flagged that morning, and the CVE numbers were added to the rule once they were published.

The CNA’s 8.7 matches our own call on the CSRF flaw: it needs a signed-in Super User to cooperate unknowingly, which keeps it below Critical, but success means attacker-chosen software installed on the site. The path traversal record is less consistent. Its score is 6.3 Medium, but its own description says the finding “is rated Low rather than presented as arbitrary file disclosure”. We think Low is closer to the real risk, because it needs an oddly named sibling folder of images to exist before there is anything to read. We quote the record’s score, because that is what scanners and other advisories will show you.

If a site has already been hit, or you would rather someone else made sure, fix.mySites.guru patches the site, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day.

Timeline

2026-07-29 Gridbox 2.20.2 fixes 23 vulnerabilities from a mySites.guru audit Eleven CVEs, several already being exploited. 2.20.2 also added CSRF token checks across the admin controllers.
2026-09-21 Gridbox 2.20.3.1 fixes an unauthenticated blog author SQL injection Reported by Studio Przy Lesie, identified by Cert.pl.
2026-10-08 Gridbox 2.20.4.0 fixes the language install CSRF and the image preview path check Reported by Sergiy Tryzhychynskyi, coordinated by the Joomla Security Strike Team.
2026-10-08 Joomla CNA publishes CVE-2026-102784 and CVE-2026-102783 8.7 High for the language install CSRF, 6.3 Medium for the image preview path traversal. Both records cover every release up to 2.20.3.1.
2026-10-08 mySites.guru flags every affected site and alerts customers Connected sites on 2.20.3.1 are flagged automatically, alongside the earlier Gridbox rules.

JCH Optimize 9.4.0 Fixes Six High-Rated Security Issues in the Joomla Extension

phil@mysites.guru (Phil Taylor) — Wed, 07 Oct 2026 15:32:15 GMT

JCH Optimize is a page speed extension for Joomla: it combines and minifies CSS and JavaScript, rewrites HTML, optimises images and serves a page cache. This morning its developer, Samuel Marshall, released JCH Optimize 9.4.0 and called it “a security and maintenance release”. The changelog rates six of the fixes HIGH, including a cross-site scripting issue, an unauthenticated Page Cache endpoint and administrator tasks that ran without a security token.

Every version before 9.4.0 is affected, in both the Free and Pro editions. No CVE has been published and the release credits no finder. Three days later the vendor shipped a second security release, 9.4.2, which fixes a file read and a server-side request forgery that 9.4.0 and 9.4.1 still have. The vendor withdrew that 9.4.2 build later the same day and published a rebuilt 9.4.2 with the same security fixes. If a Joomla site you manage runs JCH Optimize, update it to 9.4.2 today, even if you updated it this week.

Update, later on 10 October 2026: 9.4.2 withdrawn and rebuilt

Later the same day, the vendor pulled the 9.4.2 release described in the next section. Its release page now returns “403 Access forbidden”. In its place is a second release also numbered 9.4.2, with its own release page, and the Free and Pro update feeds now point at it. The vendor has not said why the first build was withdrawn.

We downloaded the first 9.4.2 Free package the morning it came out, so we compared it with the rebuild. The security fixes are identical: the file combining code that closes the encoded-slash file read and the SSRF did not change by a byte. Everything in the next section still applies, and the advice is the same: update to 9.4.2.

The rebuild differs in five ways:

The component reports its version as plain 9.4.2. The first build reported 9.4.2-dev202610101433-revbbe49222.
A new HIGH-rated fix for tag pages. Since 9.4.0, with Page Cache on, guests saw an error page after a tag page’s content and the page was never cached, because the reworked hit counter did not accept the list of tag IDs a tag page passes. It now counts the hit on the first tag, as Joomla does, and an error while storing a page skips caching instead of being added to the page.
Save Changes in the Critical JavaScript Configure Helper works again. It had failed with a server error since 9.4.0.
Recache’s default concurrency drops from 10 to 5, so a recache leaves PHP workers free for visitors, and errors from a recache started in a web request are now logged.
Joomla 4.4 is gone from the compatibility list. The update feed now lists Joomla 5.0 and later for 9.4.0, 9.4.1 and 9.4.2, where it previously offered all three to Joomla 4.4.

If a site installed the first build, its component shows the -dev version in the extension manager. That site has every security fix, and Joomla’s update manager offers it the rebuild, because it ranks a plain 9.4.2 above a -dev build of the same number. Install it for the tag page fix. mySites.guru treats both builds as fixed.

Joomla 4.4 sites are now in a harder spot. None of them is offered any 9.4.x release now, so the security fixes from both rounds wait on the Joomla 5 upgrade, or on removing JCH Optimize until then. mySites.guru keeps flagging those sites.

Update, 10 October 2026: 9.4.2 fixes a file read and an SSRF in file combining

JCH Optimize 9.4.2 is out, and the vendor calls it “a security and maintenance release”. (This is the first 9.4.2 build, which the vendor later withdrew and rebuilt with the same security fixes; see the update above.) Update to it now, including any site you moved to 9.4.0 or 9.4.1 after our earlier advice: both versions have the issues below.

The fix the vendor rates HIGH is in file combining. An encoded slash (..%2F) in the URL of a CSS or JavaScript file could reach files outside the site root, and the combined file is then served to visitors. We compared the 9.4.1 and 9.4.2 Free packages: 9.4.1 removed ../ segments from the URL before decoding it, so ..%2F passed that step and only became ../ afterwards. 9.4.2 rejects any decoded path that still climbs out of the root.

The MEDIUM-rated fixes stop the combiner fetching files from private network addresses or following redirects to them (a server-side request forgery), escape script URLs in the Critical JavaScript Configure Helper, keep the Download ID out of settings exports, make the request that starts a Recache usable only once, and hold the post-update .htaccess changes and plugin ordering until an administrator signs in. Going by the code, both combining issues work through the URL of a file the page links to, so an attacker first needs a way to put a link into a page JCH Optimize optimises. That makes them harder to reach than the 9.4.0 issues. The fix is the same update either way.

Two practical notes. Sites that connect to Redis through a Unix socket have been silently falling back to filesystem storage since 9.4.0, and 9.4.2 fixes that too. And in the extension manager the first 9.4.2 build’s component reported its version as 9.4.2-dev202610101433-revbbe49222: that was the build the vendor published as stable, the plugins reported plain 9.4.2, and mySites.guru treats it as up to date. The rebuilt 9.4.2 reports plain 9.4.2 throughout.

How fast sites took up 9.4.0

On release day, 1% of the current-line JCH Optimize installs on connected Joomla sites were on 9.4.0. These figures are from the same sites three days later, on the day 9.4.2 shipped:

44%

of current-line installs moved to 9.4.0 or later in three days, up from 1% on release day

Nearly 3 in 4

of those updates showed up in the first 24 hours after the 9.4.0 release

56%

were still below 9.4.0 three days on, and need 9.4.2 now

Most of the movement came in the first day, and it slowed sharply after that. That is the usual shape: the sites someone is actively watching update quickly, and the rest wait for whoever looks after them to notice. Every site in that 56% now needs a single update to 9.4.2, which covers both rounds of fixes.

Update, 7 October 2026: 9.4.1 fixes the Redis and APCu fatal error

JCH Optimize 9.4.1 is out, released the same day as 9.4.0, and it resolves this. If a Pro site uses Redis or APCu storage, update straight to 9.4.1: it includes every security fix from 9.4.0 and restores the cache classes that 9.4.0 dropped. Anyone who updated to 9.4.0 and switched storage to Filesystem as a stopgap can move to 9.4.1 and turn Redis or APCu back on.

What happened: a JCH Optimize Pro user reported this afternoon that 9.4.0 took down sites using Redis as the cache store, with a fatal “Redis\Metadata is not available” error on every page. We confirmed it in the 9.4.0 Pro package. 9.4.0 upgraded its bundled Laminas Redis adapter from 2.2 to 3.1.0, whose Redis class depends on a Redis\Metadata class in a src/Redis/ folder. The 9.4.0 Pro package shipped none of the four files in that folder, Metadata.php included, and its class map did not list them. The vendor’s 9.4.1 changelog says APCu storage was missing classes in the same way. The Free edition has no Redis adapter at all, so it was not affected, and sites on the default Filesystem storage were not affected either.

If a site is still on 9.4.0 and cannot update this minute, the earlier workaround holds: set JCH Optimize’s Storage Adapter (in the Cache Storage settings) to Filesystem, because the setting’s own fallback does not help once a missing class stops PHP before JCH Optimize can catch it. If a site is already down, renaming the plugins/system/jchoptimize and plugins/system/jchpagecache folders over FTP brings the front end back. The clean fix is to update to 9.4.1.

How mySites.guru flags JCH Optimize below 9.4.2

mySites.guru records the exact version of every extension on every connected Joomla site twice a day. We added JCH Optimize 9.4.0 to our Joomla vulnerability database the afternoon it was released, so any connected site running the component or its system plugin below 9.4.0 is flagged on its own site card and in its audit, with the version that resolves it. On 10 October we added a second rule for the 9.4.2 fixes, which flags everything below 9.4.2, so sites on 9.4.0 and 9.4.1 are flagged again until they update. Both 9.4.2 builds count as fixed, since their security code is the same.

The rule matches the component and the system plugin separately. JCH Optimize installs several plugins that share the element name jchoptimize (a console plugin and, from 9.4.0, a scheduler task plugin), and those are versioned alongside the main extension, but the rule is pinned to the component and the system plugin so that a stray row cannot flag a site that has already updated.

What the mySites.guru database shows

JCH Optimize is one of the more common third-party extensions we see. These figures are from the Joomla sites connected to mySites.guru that reported in during the last 30 days, taken the afternoon 9.4.0 was released:

1 in 10

connected Joomla sites run JCH Optimize

99%

of current-line installs were below 9.4.0 on release day

1 in 4

JCH Optimize sites are on the old Joomla 3 line, which has no fix

The second figure is normal for the first day of any release. The third will not change by itself, because the old line has no patch to wait for.

The cross-site scripting issue in the JCH Optimize optimiser

The first HIGH item in the changelog is “a cross-site scripting vulnerability where encoded characters in URLs, such as search query links, were decoded during optimization”. JCH Optimize rewrites the HTML of every page it serves. Going by the vendor’s description, when Joomla or another extension has already escaped a value inside a link, for example a search term echoed into a “search again” URL, the optimiser’s rewriting step could turn the encoded characters back into live ones.

The rest of the site did nothing wrong here. Joomla escaped the value correctly; the extension sitting between Joomla and the browser undid it. An attacker only has to get a visitor, or an administrator, to open a crafted search link, and the script runs in the context of the site.

This is the one to worry about first on a busy public site, because it needs no account and it reaches any visitor who follows the link.

The Page Cache hit counter ran any component’s model

When JCH Optimize serves a page from its own page cache, Joomla never runs the component that built the page, so article hit counters would stop moving. To fix that, the Page Cache plugin adds a small script to cached pages that calls back to the site and records the hit.

We compared the 9.3.1 and 9.4.0 Free packages to see what the vendor’s description, “allowing a request to run any component’s model”, means in practice. In 9.3.1 the callback is a com_ajax endpoint in plg_system_jchpagecache that answers anonymous requests. It reads a component name (hitoption) and a model name (hitview) from the request, boots that component, builds the named site model and calls its hit() method with an ID from the request. If anything throws, the exception message is sent back in the response.

So any visitor could choose which component and which model to run, and drive hit counters on content the page cache never served, including unpublished items and content behind access levels. We have not shown it reaching anything worse than hit(), and the vendor does not say it does. 9.4.0 replaces the endpoint’s logic with a fixed list of supported pages (articles, categories, contacts, news feeds and tags) and checks that the item is published and visible to the visitor before counting it.

Admin tasks ran without a token or the core.admin permission

The 9.4.0 changelog says administrator tasks that change settings or files now “require a valid form token and administrator permissions”. The diff shows where the check went in. JCH Optimize 9.4.0 adds a guard to its administrator dispatcher: anything other than a read-only dashboard view now needs the core.admin permission on the component and a valid Joomla session token.

In 9.3.1 neither check was there, which allowed:

Cross-site request forgery: a logged-in administrator who opened a crafted link or page could be made to change JCH Optimize settings or run its file tasks without knowing it.
Weaker permissions than the job needs: a backend user who could open the component, but who should not be configuring it, could change settings that alter every page the site serves.

The same release stops settings exports from including the Cloudflare API token and the Redis password, and keeps a site’s existing token and password when an import file leaves them out. An old export file sitting in a downloads folder or a support ticket still holds both.

Image paths, the open redirect and the jchbackend switch

The remaining HIGH items are narrower:

Image optimisation paths: the image optimisation service returns URLs and file paths for the optimised images. 9.4.0 validates those and keeps image folders inside the site root, where earlier versions trusted what came back.
Open redirect: the Mode Switcher and Utility tasks redirected to whatever URL was passed, base64 encoded, in the return parameter. 9.4.0 only follows a return URL on the site itself. The controllers sit on the administrator side, so the link has to be followed by someone logged in there, which is exactly who a phishing redirect wants.
The jchbackend parameter: adding jchbackend=1 to any front-end URL told JCH Optimize to skip optimisation for that request, for any visitor. 9.4.0 removes the parameter.

The MEDIUM items harden the page cache against malformed Host headers and unsafe characters in Capture Cache file paths, and escape file and folder names in the Optimize Images file tree. One small fix shows how these things slip through: in 9.3.1 the check for the jchnooptimize parameter reads get('jchnooptimize' == '1'), comparing the string to '1' before asking for it, so that parameter never worked at all.

Which JCH Optimize versions are fixed?

Line	Joomla element	Joomla versions	Status
9.4.2 (rebuild)	`com_jchoptimize`	5.0 to 6.1	Current release, fixes the file read and SSRF in file combining
9.4.2-dev202610101433-revbbe49222	`com_jchoptimize`	4.4 to 6.1 when it shipped	First 9.4.2 build, withdrawn the same day. Same security fixes; update to the rebuild for the tag page fix
9.4.1	`com_jchoptimize`	5.0 to 6.1 in the update feed now	Has the 9.4.0 fixes, but affected by the 9.4.2 issues; update to 9.4.2
9.4.0	`com_jchoptimize`	5.0 to 6.1 in the update feed now	Affected by the 9.4.2 issues, and a fatal error on Redis or APCu Pro sites; update to 9.4.2
9.x before 9.4.0, 8.x, 7.x	`com_jchoptimize`	Varies by release	Affected, update to 9.4.2
6.5.0 and earlier	`com_jch_optimize`	Almost entirely Joomla 3	Affected as far as anyone has said, no fix

Joomla 4.4 sites: the fix now needs Joomla 5

The 9.4.x release notes always said Joomla 5.0 or later, but until 10 October the vendor’s update feed offered 9.4.x to Joomla 4.4 anyway. It no longer does, for any 9.4.x release, so a Joomla 4.4 site below 9.4.2 will not be offered the fix. Upgrade the site to Joomla 5 first, or disable JCH Optimize until you can. mySites.guru flags those sites below 9.4.2 either way.

What does this mean for Joomla 3 sites?

The old JCH Optimize line, version 6.5.0 and earlier, installs under a different element, com_jch_optimize, and nearly every site still running it is on Joomla 3. The vendor has said nothing about whether that code has the same flaws, and it has no fix. We have not added a rule for it, because we do not flag a version on a guess.

An optimiser that rewrites every page is a high-value place for a bug, and the old line gets no more security fixes. On a Joomla 3 site the practical choices are to uninstall JCH Optimize, or to make the move to a supported Joomla version that has been waiting. Our Joomla 3 extension vulnerabilities list tracks the other extensions in the same position.

What to do today

Update JCH Optimize to 9.4.2 on each site running Joomla 5.0 or later, after confirming the site runs PHP 8.1 or later, including sites you already moved to 9.4.0 or 9.4.1. 9.4.2 includes every earlier security fix and the Redis and APCu fix.
Check the component, the system plugin and the Page Cache plugin all report 9.4.2. A partly applied update leaves old code in place, and a component on 9.4.2-dev202610101433-revbbe49222 is the withdrawn first build, which the update manager will move to the rebuild.
On Joomla 4.4 sites, plan the Joomla 5 upgrade, because the vendor no longer offers 9.4.x to Joomla 4.4.
Delete any JCH Optimize settings export you have saved, and rotate the Cloudflare API token, the Redis password and the Download ID if an export ever left your hands.
On Joomla 3 sites, uninstall the old JCH Optimize line or plan the migration.
If you cannot update a site today, turn off the Page Cache plugin, which closes the unauthenticated endpoint.

Beyond the version flag

A flag on a site card says a site is exposed. It does not tell you whether anyone used the hole first, and an XSS aimed at administrators is usually the first step towards an account an attacker should not have.

mySites.guru runs the follow-up checks as part of the subscription, unattended, on every connected site. The rogue admin check lists Super Users added outside the normal flow across your whole account in one view. The Joomla malware scanner looks for code dropped on the server. And the vulnerable extension list explains how version flags like this one work for every Joomla and WordPress extension we track.

If one of your sites already shows signs of compromise, work through our Joomla hacked-site guide or have us fix it for you.

If you manage Joomla sites for clients, mySites.guru flags every connected site the day a fix like this ships, and the free audit shows what it finds on your own sites first.

Timeline

2026-10-07 JCH Optimize 9.4.0 ships with six HIGH-rated security fixes Cross-site scripting through encoded URL characters, an unauthenticated Page Cache hit counter endpoint, admin tasks without a token or core.admin, an open redirect, unvalidated image optimisation paths and the jchbackend switch. The release notes ask for Joomla 5.0, but the update feed offers it to Joomla 4.4. mySites.guru flags every site below 9.4.0 the same afternoon.
2026-10-07 9.4.0 takes down Pro sites using Redis or APCu storage A fatal error on every page, because the bundled Laminas cache library shipped without classes the adapters need. JCH Optimize 9.4.1 restores them later the same day.
2026-10-10 JCH Optimize 9.4.2 ships with a second round of security fixes A HIGH-rated read of CSS and JavaScript files outside the site root through ..%2F when combining files, and a MEDIUM-rated SSRF in the same code. The component reports 9.4.2-dev202610101433-revbbe49222, and the release page lists Joomla 4.4 as compatible. mySites.guru flags everything below 9.4.2, including 9.4.0 and 9.4.1.
2026-10-10 The vendor withdraws the first 9.4.2 build Its release page starts returning 403 Access forbidden. No reason has been published.
2026-10-10 A rebuilt 9.4.2 replaces it, for Joomla 5.0 and later only Same version number, new release page, and the Free and Pro update feeds point at it. The security fixes are identical to the first build. It reports plain 9.4.2, fixes tag pages that showed an error page to guests under Page Cache, and every 9.4.x entry in the update feed now drops Joomla 4.4.

OrdaSoft Simple Membership and Touch Slider for Joomla: Two Flaws That Need No Login

phil@mysites.guru (Phil Taylor) — Wed, 07 Oct 2026 09:52:58 GMT

Two CVEs published this morning by the Joomla CNA cover two more Joomla extensions from OrdaSoft. Simple Membership, which handles member registration and login, has an SQL injection in its login check that needs no account and scores CVSS 4.0 9.3 Critical. Touch Slider, a slideshow module, lets any visitor delete its slides or replace its content, scored 6.9 Medium.

If a Joomla site you manage runs either one, update it today: Simple Membership to 7.4.0 and Touch Slider to 5.4.6. This is the fourth batch of OrdaSoft security issues in under three weeks, after OS Gallery, Real Estate Manager, Vehicle Manager and Book Library, and OS CCK.

How mySites.guru flags Simple Membership and Touch Slider

mySites.guru records the exact version of every extension on every connected Joomla site twice a day. We added both records to our Joomla vulnerability database the morning they were published, so any connected site running Simple Membership below 7.4.0 or Touch Slider below 5.4.6 is now flagged on its own site card and in its audit, with the version that resolves it. If the extension is on the site, the flag is already there.

Both extensions also install a Joomla package alongside the component or module, and we flag the package too, so a site whose component or module row is missing is still caught. The flags cover every edition. Some Simple Membership Pro sites report versions in the 3.x and 4.x range, below 7.4.0, so they are flagged as well, and OrdaSoft has not said which Pro build has the fix.

Simple Membership: SQL injection in the login check, CVE-2026-102782

Simple Membership’s front-end entry point, site/simplemembership.php, answers task=checkLoginPass without any authentication or access check. That much is normal for a login check, since the visitor is not logged in yet. The handler then reads the login name from the request through Joomla’s generic input filter and concatenates it straight into the SQL query, with no escaping and no parameter binding.

The filter is where the false comfort comes from. Joomla’s default input filter strips HTML and script tags, so a developer testing it sees angle brackets disappear and assumes the value is clean. It leaves quotes and SQL syntax alone, and a single quote is all an attacker needs to close the login string and append their own SQL.

9.3CVSS 4.0

CriticalJoomla CNA · CVE-2026-102782

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The vector is the worst shape there is: reachable over the network, no privileges, no user interaction, and high impact on the confidentiality, integrity and availability of the data. A membership extension’s database holds exactly the records an attacker wants, starting with the Joomla users table and its password hashes.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

The fix for this class of bug is old and simple: bind the login name as a query parameter, or at the very least pass it through $db->quote(). An input filter decides what a value may contain. Making it safe inside SQL is the query’s job.

Touch Slider: anyone can delete or replace the slides, CVE-2026-102781

Touch Slider is a Joomla module, and it does its data management (adding, deleting and importing slides) through a single AJAX handler, modOsTouchSliderHelper::getAjax(), which Joomla’s core com_ajax endpoint calls on the module’s behalf. According to the record, that handler does not check who is calling: it has no user check, no permission check and no form token.

The record confirms two ways to abuse it, both anonymous:

A plain GET request deletes any slider image by its ID. The IDs are sequential, so an attacker can walk through them and empty every slider on the site.
A multipart upload of a zip file replaces the slider’s two database tables, #__os_touch_slider and #__os_touch_slider_text, across the whole site with whatever the attacker supplies. This path does not even need a task parameter.

6.9CVSS 4.0

MediumJoomla CNA · CVE-2026-102781

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The score is Medium because the flaw cannot read data and touches only the slider’s own tables. On many Joomla sites, though, the slider is the first thing a visitor sees on the home page, and an attacker who can replace its slides and text controls that space.

Which versions fix each extension

Extension	Joomla element	Affected	Fixed in
Simple Membership	`com_simplemembership`	1.0.0 to below 7.4.0	7.4.0
Touch Slider	`mod_os_touchslider`	1.0.0 to 5.4.5	5.4.6

Touch Slider’s record is consistent: its title says “below 5.4.6” and its affected range stops at 5.4.5. Simple Membership’s is not. The title gives the fix as “below 7.4.0”, while the structured affected range runs up to and including 7.4.0, the same split that Book Library’s record had last week.

Simple Membership: take the newest release

mySites.guru flags Simple Membership below 7.4.0, which is what the record title says. If OrdaSoft offers anything newer than 7.4.0, install that instead, so the question of which half of the record is right stops mattering.

OrdaSoft has not announced either fix

As far as we can find, OrdaSoft has published no advisory, no changelog entry and no security notice for either extension. The only reference in each record is the OrdaSoft home page, and neither record credits a finder. The fixed version numbers in this post come from the CVE records alone, which is now the pattern for every OrdaSoft disclosure this month.

That leaves site owners with less to go on than they need. A changelog would settle the Simple Membership range, say whether the Pro builds were patched, and say whether OrdaSoft’s other slider modules share Touch Slider’s AJAX handler. Until OrdaSoft says something, if you run any OrdaSoft component, check its version against the vendor’s newest release whenever a new batch of records appears.

What the mySites.guru database shows

Neither extension is common, and only a small number of connected sites run either one. On the day the records were published, every install we can see is on an affected release. That is normal on the first day of a disclosure, and it is the reason we flag sites the same morning rather than waiting for owners to read a CVE feed they do not follow.

What to do today

Update Simple Membership to 7.4.0 or later and Touch Slider to 5.4.6 or later.
If you cannot update Touch Slider today, unpublish or uninstall the module.
If you cannot update Simple Membership today, block front-end requests containing task=checkLoginPass at the web server, or disable the component if the site can manage without member logins for a day.
On any site that ran an affected Simple Membership version, treat the database as read: reset Super User passwords, rotate the Joomla secret, and replace stored API keys or mail credentials.
Check the Super User and Administrator groups for accounts your team did not create.

Find Super User accounts you did not create

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

What to check after the flag

The version flag tells you a site is exposed. It does not tell you whether anyone got there first, and an SQL injection in a login handler is the kind of thing that gets scripted and sprayed at every site that answers the right URL.

mySites.guru runs the follow-up checks as part of the subscription, unattended, on every connected site. The rogue admin check lists Super Users added outside the normal flow across your whole account in one view. The malware and file scanners look for code dropped on the server once an attacker has a password. And the vulnerable extension list explains how version flags like these work for every Joomla and WordPress extension we track.

If one of your sites already shows signs of compromise, work through our Joomla hacked-site guide or have us fix it for you.

If you manage Joomla sites for clients, mySites.guru flags every connected site the day a fix like this is published, and the free audit shows what it finds on your own sites first.

Joomla Extension Updates Can Now Be Flagged as Security Releases

phil@mysites.guru (Phil Taylor) — Mon, 05 Oct 2026 11:40:29 GMT

Until 29 September 2026, a Joomla extension developer had no way to tell a site’s administrator that an update fixed a security problem. The update manager listed a security release exactly like a release that changed a button colour, and the only signal was whatever the changelog said, if anyone opened it. Joomla 5.4.9 and 6.1.4, released on 29 September 2026, changed that. Your update XML can now include a <security> element, and Joomla turns it into a “Security release level” badge in the update manager and a warning on the administrator’s Home Dashboard.

The change was written for Joomla 6.2 by Allon Moritz (@laoneo) of Digital Peak in pull request 48127, then backported in pull request 48233, so you do not have to wait for 6.2 on 13 October. Every site on a current Joomla 5 or 6 release reads it today. Allon introduced it in the Joomla Community Magazine in August. This post goes further into the parts we had to test to answer: how Joomla picks a level when a site skips releases, what it does with values it does not expect, what older Joomla versions do with the tag, and what your users will see.

Written for Joomla extension developers

This post is for the people who build Joomla extensions and publish their update XML. If you run Joomla sites rather than build extensions, there is nothing for you to change: skip to what Joomla administrators will see for the badge and the dashboard notice, and read the warning at the end of that section.

<update>
    <element>com_example</element>
    <version>2.4.1</version>
    <security>3</security>
    <!-- the rest of your update entry, unchanged -->
</update>

Adding the security tag to a Joomla update XML

The <security> element goes inside the <update> entry for the release that fixes the problem, next to the elements you already send. It is optional, takes an integer from 0 to 4, and is documented on the update server page of the Joomla Manual. A complete entry for a security release looks like this:

<?xml version="1.0" encoding="utf-8"?>
<updates>
    <update>
        <name>Example Gallery</name>
        <description>Example Gallery 2.4.1</description>
        <element>com_examplegallery</element>
        <type>component</type>
        <client>administrator</client>
        <version>2.4.1</version>
        <infourl title="Example Gallery 2.4.1">https://example.com/releases/2-4-1</infourl>
        <changelogurl>https://example.com/updates/changelog.xml</changelogurl>
        <downloads>
            <downloadurl type="full" format="zip">https://example.com/downloads/com_examplegallery-2.4.1.zip</downloadurl>
        </downloads>
        <sha512>2f1c9a…</sha512>
        <tags>
            <tag>stable</tag>
        </tags>
        <targetplatform name="joomla" version="(5\.[0-9]|6\.[0-9])" />
        <php_minimum>8.1</php_minimum>
        <security>3</security>
    </update>
</updates>

Joomla’s updater only stores the update elements it has been told about. Pull request 48127 adds SECURITY to that list ($updatecols in libraries/src/Updater/UpdateAdapter.php), adds a nullable security column to the #__updates table (TINYINT on MySQL and MariaDB, smallint on PostgreSQL), and reads the column back in the update manager template and the Home Dashboard quick icon. There is no new API to call and nothing to change in your extension’s install manifest.

The five Joomla security levels and which one to send

Joomla defines five values and a label for each in administrator/language/en-GB/com_installer.ini. The update manager shows a badge for any level above 0, amber (Bootstrap’s btn-warning) for 1 and 2 and red (btn-danger) for 3 and 4, and the Home Dashboard adds a line for each update with a level above 0.

Value	Joomla’s label	Badge	Dashboard line	CVSS base score
`0`	Security release level: None	none	no	0.0
`1`	Security release level: Low	amber	yes	0.1 to 3.9
`2`	Security release level: Medium	amber	yes	4.0 to 6.9
`3`	Security release level: High	red	yes	7.0 to 8.9
`4`	Security release level: Critical	red	yes	9.0 to 10.0

The core code does not tell you how to choose the number, but the last column does. It is the mapping Allon gives in his magazine article, and it matches the qualitative bands that CVSS 3.1 and CVSS 4.0 both use, so if a CVE has been assigned for your fix, take the base score from the record and the level follows. If not, score the worst issue in the release yourself. When a release fixes several issues, send the level of the worst one, because the badge is a single number.

A level 2 fix for a Medium stored XSS gets the same amber badge as a level 1, and only levels 3 and 4 turn red. Do not inflate a Medium to High to get the red badge. Admins learn very quickly to ignore a vendor whose every release is High.

Two different security elements in Joomla XML

Do not get confused. A Joomla extension can now publish two elements called security, in two different files, and they do different jobs. A security release should set both.

The new one goes in your update XML, inside the <update> entry for the release. It holds a single integer, and it is the one Joomla reads to draw the badge:

<!-- updates.xml, the file your <updateservers> manifest entry points at -->
<update>
    <element>com_examplegallery</element>
    <version>2.4.1</version>
    <security>3</security>
</update>

The older one goes in your changelog XML, the separate file your <changelogurl> points at. It holds a list of <item> lines describing the fixes, and Joomla shows them when an admin opens the changelog for the update, next to the fix, addition, change, remove, language and note sections:

<!-- changelog.xml, the file your <changelogurl> points at -->
<changelogs>
    <changelog>
        <element>com_examplegallery</element>
        <type>component</type>
        <version>2.4.1</version>
        <security>
            <item>Fixed SQL injection in the gallery search filter</item>
        </security>
    </changelog>
</changelogs>

The number tells the admin how urgent the update is, and the items tell them what it fixes. The Joomla Manual documents the two on different pages: the new element on the update server page, the older one on the changelog page. The manual change that added the new element only edited the update server page, so if you start from the changelog page you will find a security element there and never learn the other one exists.

How Joomla picks the level when a site skips releases

Joomla shows the highest level of every release newer than the version the site has installed, not the level of the newest release. This came in with pull request 48190, after a reviewer pointed out that a Critical fix in 1.0.1 would vanish from view the moment 1.0.2 shipped without a flag. While parsing your feed, the updater keeps every entry that has a <security> element and passes the site’s platform, PHP, database and stability checks. It then runs this, from libraries/src/Updater/Updater.php:

private function findHighestSeverity(string $installedVersion, UpdateTable $update, array $securityUpdates): ?int
{
    $securityLevel = (int) $update->security;

    /** @var \Joomla\CMS\Table\Update $securityUpdate */
    foreach ($securityUpdates as $securityUpdate) {
        if (version_compare($securityUpdate->version, $installedVersion, '>') && $securityLevel < (int) $securityUpdate->security) {
            $securityLevel = (int) $securityUpdate->security;
        }
    }

    return $securityLevel;
}

$update is the newest compatible release, the one the site will be offered. The result goes into #__updates.security, and that stored number is what the update manager and the dashboard read. Pull request 48190’s own test feed shows the effect. It lists five releases: 0.9.0 flagged Critical, 1.0.0 unflagged, 1.0.1 High, 1.0.2 Medium and 1.0.3 unflagged. The table below starts from that feed; change any release’s level and the badges follow.

Release	<security>	Badge if this version is installed
0.9.0		Security release level: High
1.0.0		Security release level: High
1.0.1		Security release level: Medium
1.0.2		No badge
1.0.3		Up to date

We installed each of those versions of a test module on a Joomla 6.1.4 site, pointed it at this feed and ran the update check. Joomla stored exactly the levels in the table. A site on 0.9.0 sees High rather than Critical, because the Critical entry is the version it already has, and a site on 0.8.0 would see Critical. One detail matters if you read the database: the level is written onto the row for the newest release, 1.0.3 here, even though 1.0.3 itself is unflagged. #__updates.security holds the computed answer for that site, not the level your feed gave that release.

So flag the release that contains the fix, once, and leave later releases alone. You do not need to repeat <security>3</security> on 2.4.2 and 2.4.3 so that sites still on 2.4.0 see it, because Joomla finds 2.4.1 in the feed and takes its level. That only works if you keep the flagged entry in the feed. If your update XML lists only the latest version, as many do, a site on 2.4.0 will see 2.4.3 with no badge at all. Keep old entries in the file for at least as long as you expect sites to lag behind.

What Joomla does with values outside 0 to 4

Joomla does not validate the value. It appends whatever text the element holds, casts it to an integer when it works out the level, and draws the badge whenever the result is not empty. We sent each of these values to a Joomla 6.1.4 site, for an update from 1.0.0 to 1.0.1, and recorded what it stored and showed:

What you send	Stored in `#__updates.security`	Update manager badge	Dashboard line
`0`	0	none	no
`1` to `4`	1 to 4	Low, Medium (amber), High, Critical (red)	yes
`5`	5	red, reading `COM_INSTALLER_SECURITY_SEVERITY_5`	yes
`-1`	-1	amber, reading `COM_INSTALLER_SECURITY_SEVERITY_-1`	no
`High`	0	none	no
`<security></security>`	0	none	no
`<security> 3 </security>`	3	High (red)	yes
no element	0	none	no
`4` on an entry whose `targetplatform` excludes the site	0	none	no

None of these produced a PHP warning or a log entry, so a mistake here goes unreported on both sides. Any number outside 0 to 4 shows the untranslated language key to the admin, which looks broken, and the admin will blame your extension for it. A word such as High becomes 0 with no warning, so the release goes out unflagged and the admin never knows. And a flag only counts on an entry the site can actually install: if your feed has separate <update> entries per Joomla major version, put the <security> element on each branch’s entry that contains the fix, or the sites on the other branch see nothing.

Send an integer from 0 to 4 and nothing else.

Older Joomla versions ignore the tag

You can add the element to a feed that still serves Joomla 3 and Joomla 4 sites. Older versions only store the update elements they know, and Joomla 3.10.12’s list in libraries/src/Updater/UpdateAdapter.php is:

protected $updatecols = array('NAME', 'ELEMENT', 'TYPE', 'FOLDER', 'CLIENT', 'VERSION', 'DESCRIPTION', 'INFOURL', 'EXTRA_QUERY');

Anything else in an <update> entry is read and dropped. We tested it with the same feed, including <security>3</security>, on Joomla 4.4.14 and 3.10.12: both offered the update from 1.0.0 to 1.0.1 as normal, logged nothing, and showed no badge, because neither has the security column in #__updates. Joomla 5.4.8 and 6.1.3, the releases before the backport, have no SECURITY in that list either. One feed with the element works for every branch you support, and sites start showing the badge as they update to Joomla 5.4.9, 6.1.4 or 6.2.

Flagging a release you have already published

If you shipped a security release without the flag, add <security> to that release’s existing <update> entry and republish the file. You do not need a new version. Sites pick the level up the next time they fetch your feed, and when that happens depends on what triggers the check. On a Joomla 6.1.4 site with 1.0.1 already listed unflagged, we added <security>3</security> to the 1.0.1 entry and tried each route:

How the site checks	Picked up the new level?
Check for Updates button in System, Update, Extensions	yes, straight away
`php cli/joomla.php update:extensions:check`	yes, straight away
Home Dashboard quick icon, feed fetched minutes earlier	no
Home Dashboard quick icon, after the cache timeout	yes

The dashboard check respects the Installer’s update cache, which is six hours by default (Cache Timeout in the Installer options), so an admin who never clicks Check for Updates sees the badge within six hours of your change, on their next visit to the dashboard. The other two routes ignore the cache. Retro-flagging is worth doing for a security release that is still recent, since most sites behind on your extension are still behind on it.

Checking the tag in your Joomla release pipeline

If you publish releases with Akeeba Release System, version 7.5.0 already writes the element when you set a severity on a release. If you build the XML yourself, a typo in the security element costs you the badge without any error, so check the feed before it goes live. This runs anywhere xmllint is installed (it ships with libxml2 on macOS and most Linux images) and fails the build if any <security> element holds anything other than an integer from 0 to 4:

xmllint --noout updates.xml || exit 1
if xmllint --xpath '//update/security[not(contains("|0|1|2|3|4|", concat("|", normalize-space(.), "|")))]' updates.xml 2>/dev/null; then
  echo "updates.xml: <security> must be an integer from 0 to 4" >&2
  exit 1
fi

The exit codes run the opposite way to what you might expect. xmllint --xpath exits 0 when the expression matches something, and here a match means a bad value, so the if branch is the failure. When every value is valid the expression matches nothing, xmllint prints “XPath set is empty” to stderr and exits non-zero, and the script continues. The first line is there because a file that does not parse would also exit non-zero from the second command and slip through as a pass. normalize-space() lets <security> 3 </security> through, which matches what Joomla accepts; drop it if you want your feed stricter than Joomla is.

How many Joomla extension vendors send the tag so far

Almost none, but that’s because it’s new. On 5 October 2026 we fetched every enabled extension update feed in the mySites.guru database, 11,092 distinct URLs with their query strings stripped, and 7,504 of them answered with update XML. Five of those feeds include a <security> element.

update feeds sending the security tag

0.07%

of the 7,504 feeds that answered

feeds sending a level above 0

Developer	Extension	Feed	Level sent
Weeblr	4SEF	`u1.weeblr.com/.../pkg_forsef_full.xml`	`0`
Weeblr	4Podcast	`u1.weeblr.com/.../plg_system_forpodcast_full.xml`	`0`
Weeblr	4Analytics	`u1.weeblr.com/.../pkg_foranalytics_full.xml`	`0`
Moonsoft	List Manager	`moonsoft.es/comp_update/listmanager.xml`	`0`
Moonsoft	Calc Builder	`moonsoft.es/comp_update/calcbuilder.xml`	`0`

All five send <security>0</security>, which is the right answer for a release with no security fix and shows nothing in the update manager. Weeblr sends it on every entry in its feeds, which is the tidiest way to do it. The five feeds come from two vendors out of the 633 hosts that served a working feed, or 0.3%, so no public update feed in our data yet marks a release Low or higher.

So for now, an extension update without a badge tells an administrator nothing. That will change as vendors pick it up, and the cost of adopting it is one element per security release. If you are a Joomla extension developer reading this, yours could be the first feed in a product category to send it.

What Joomla administrators will see

Administrators do not need to do anything to get this. On Joomla 5.4.9, 6.1.4 or 6.2, an extension update whose developer sent a level gets a badge under its name in System, Update, Extensions, red for High and Critical, amber for Medium and Low:

The Home Dashboard’s extension updates quick icon, the one that already says “Updates are available!”, adds a line naming each extension with a security update:

The dashboard line does not say how severe the update is, only that it is a security update, so open the update list to see the level. Install the red ones first.

No badge does not mean no security fix

The security level is something the extension developer chooses to send, and in October 2026 fewer than one feed in a thousand sends it. An update with no badge can still be a security release. Read the changelog, and do not wait for a badge before applying updates from a vendor with a history of quiet security fixes.

Where mySites.guru fits

mySites.guru does not wait for vendors to flag their own releases. Part of the subscription is a check of every installed Joomla extension version, on every connected site, against our Joomla extension vulnerability rules, which we write from vendor advisories, CVE records and our own research. A site running an affected version is flagged whether or not the vendor’s update XML says anything, and the vulnerabilities page lists every rule we hold. The security tag will make vendor-flagged releases easier to spot in Joomla itself, and it is a welcome change, but it can only ever describe the releases a vendor chose to label.

The same connection lists every available extension update across all your Joomla sites on one screen, and can apply them for you with automatic updates for any Joomla extension with a backup first. If you manage more than a handful of Joomla sites, that is the quickest way to make sure a security release you hear about today is installed everywhere by tonight. See what it costs, or manage multiple Joomla sites from one dashboard.

Timeline

2026-07-21 Pull request 48127 opened Allon Moritz of Digital Peak proposes a security flag for extension updates, aimed at Joomla 6.2.
2026-07-31 Merged into the 6.2 branch The security column, the update manager badge and the Home Dashboard notice arrive in 6.2-dev.
2026-08-11 Highest severity follow-up merged Pull request 48190 makes Joomla show the highest level of every release newer than the installed version, not just the latest one.
2026-08-24 Backported to Joomla 5.4 Pull request 48233 brings both changes to the 5.4 branch, and from there to 6.1.
2026-09-02 Documented in the Joomla Manual The tag is added to the update server page of the developer manual, not to the changelog page.
2026-09-29 Joomla 5.4.9 and 6.1.4 released The first stable releases that read the tag. Joomla 6.2.0 RC1 ships the same day.
2026-10-13 Joomla 6.2.0 due The release the feature was written for.

Event Gallery 6.6.0 Fixes Forged Backend Changes and a Google Photos Token Leak

phil@mysites.guru (Phil Taylor) — Sun, 04 Oct 2026 13:28:12 GMT

Sven Bluege released Event Gallery 6.6.0 for Joomla on 4 October 2026, eight days after the 6.5.0 security release. It fixes three more vulnerabilities. Eight buttons in the backend lists could be triggered from another website, the Google Photos picker could be made to send its access token to any address, and the page a shared image link opens could run script or redirect the visitor.

All three are still present in 6.5.0. A site you updated last week is affected again, and so is every site still below it.

What to do now

Update Event Gallery to 6.6.0 on every Joomla site that runs it, Core and Extended alike, including sites already on 6.5.0. 6.6.0 needs Joomla 5.4 or later, or Joomla 6, and PHP 8.2, so a site still on Joomla 3 or 4 has to upgrade Joomla first. If you override the backend layout tmpl/files/default.php in your template, copy the star and table-icon buttons from the new file, or they stop with a token warning.

5.1CVSS 4.0

CVE-2026-102776CVE-2026-102776: forged changes from the backend lists

MediumJoomla CNA

A page on another website could change payment and shipping defaults, image type sets, order statuses, watermarks and image flags through a logged-in administrator. Nothing can be deleted or read.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Logged-in admin opens a pageEvery version below 6.6.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:A: Active: Someone has to be talked through a few steps

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

6.3CVSS 4.0

CVE-2026-102777CVE-2026-102777: Google Photos access token sent elsewhere

MediumJoomla CNA

The server could be made to send the Google Photos access token to any address, or to fetch addresses inside its own network. Only sites with a Google Photos account set up.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:N/VA:N/SC:H/SI:L/SA:L

Logged-in admin opens a page5.4.0 to below 6.6.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:A: Active: Someone has to be talked through a few steps

What it does to the site

VC:L: Low: Some data can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:L: Low: Some data on other systems can be altered
SA:L: Low: Other systems degrade

5.3CVSS 4.0

CVE-2026-102778: XSS and open redirect from a shared image link

MediumJoomla CNA (the vendor rates it Low, 2.3)

A crafted shared image link could run script in the visitor's session or send them to another website. Only sites with Share article links switched on.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Visitor opens a crafted link3.11.6 to below 6.6.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:L: Low: Some data can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

TL;DR

Event Gallery 6.6.0 fixes CVE-2026-102776, CVE-2026-102777 and CVE-2026-102778, all published by the Joomla CNA on 5 October 2026
CVE-2026-102776: eight backend list buttons did not check Joomla’s form token, so a prepared page could change shop and gallery settings through a logged-in administrator. It affects every version below 6.6.0
CVE-2026-102777: the Google Photos thumbnail proxy fetched whatever address it was given, with the account’s access token attached and no form token. Sites with a Google Photos account, from 5.4.0
CVE-2026-102778 (EGSA-2026-08): with Share article links switched on, a shared image link could run script or redirect the visitor. From 3.11.6, and the option is off by default
6.5.0 is affected by all three. About two in five Event Gallery installs we monitor moved to 6.5.0 in the last eight days, and all of them need 6.6.0 now
mySites.guru flags every connected Joomla site running Event Gallery below 6.6.0

Forged changes from the backend lists (CVE-2026-102776)

Joomla protects every form with a token, a value the server checks so it can tell a request the user made from one another website made on their behalf. Eight buttons in Event Gallery’s backend lists skipped that check. According to the vendor’s notes, they set:

the default payment method and the default shipping method
the default of the image type sets, order statuses and watermarks
whether an event is In shop
the main image of an event, and whether an image is shown only as the main image
the sort order of an event’s images

Each was a plain link. If an administrator who was logged in to the backend opened a page that requested one of those links in the background, the change went through with their session. On a photo shop, that is enough to switch the default payment or shipping method, swap the watermark, take an event out of the shop or reorder and hide its images.

The vendor sets out the limits: nothing could be deleted or read this way, and orders were not affected. It is a nuisance and an integrity problem, not a takeover. The same class of bug was behind three of the five CVEs fixed in 6.5.0, and the Joomla CNA scores this one 5.1, the same as the 6.5.0 upload and clean-up CSRFs.

6.6.0 makes all eight require the token. The star and the table icon in the image list now submit the list form the way the publish icon next to them does, instead of following a link. That is the one change a site owner can trip over: a template override of the backend tmpl/files/default.php still holds the old links, and they will stop with Joomla’s invalid token warning until you copy the two buttons from the new file.

The Google Photos token leak (CVE-2026-102777)

Event Gallery can pull images from a Google Photos account. On the upload page, the picker shows thumbnails, and Event Gallery fetches those thumbnails through your own server, sending the Google Photos access token with each request so Google will serve them.

Before 6.6.0, the address to fetch came from the request and was not checked, and the request needed no form token. Put those together and a page on another website could make your server send the Google Photos access token to an address of the attacker’s choosing, or fetch addresses inside your own network, while an administrator was logged in to the backend. A backend user with permission to manage Event Gallery could do the same directly, without anyone being tricked.

The leaked token is a credential for the connected Google Photos account, and the internal fetches are a classic server-side request forgery: the web server can usually reach things the outside world cannot. Only sites with a Google Photos account set up in Event Gallery are affected, from 5.4.0 on. 6.6.0 fetches only addresses on Google’s image hosts and requires the form token on the picker requests. The vendor also added a random state value to the Google Photos authorisation, checked against the session on the way back, as hardening without a known vulnerability.

If you did connect a Google Photos account and cannot rule out that an administrator opened something they should not have, disconnect and reconnect the account after updating, so that any token issued before the fix stops working. That step is our advice, not the vendor’s.

The shared image link XSS and open redirect (CVE-2026-102778)

The vendor rated the third issue Low (2.3) and released it as EGSA-2026-08 without a CVE. The Joomla CNA published CVE-2026-102778 for it the next day and scores it 5.3, Medium. The record’s affected range reads 1.0.0 to 6.6.0, but its own title says below 6.6.0, and 6.6.0 is the release that fixes it. With the option Share article links switched on, the page a shared image link opens links back to the article the image was shared from. It took that article’s address straight from the shared link and printed it as it came, and with the link type Image Page with Redirect it followed the address at once.

A crafted link could therefore run script in the page, in the session of whoever opened it, or send the visitor to another website. Only sites with Share article links on are affected, from 3.11.6, and the option is off unless someone switched it on. 6.6.0 follows only an address on your own site and escapes it. Until you can update, switch Share article links off in the Event Gallery options, on the Social tab.

Why sites on Event Gallery 6.5.0 need to update again

Eight days ago, 6.5.0 was the answer. Since then, about two in five of the Event Gallery installs connected to mySites.guru have moved to it. All of those sites is affected by CVE-2026-102776, and those with a Google Photos account by CVE-2026-102777 as well. On the morning 6.6.0 came out, only a handful of the installs we monitor had it, and 99% were below it.

The update itself is light. 6.6.0 has the same requirements as 6.5.0 (Joomla 5.4 or later, or Joomla 6, and PHP 8.2), so any site that took 6.5.0 can take 6.6.0 in a couple of minutes. The release also makes orders, payments and mails more reliable and prepares Event Gallery for Joomla 7, and its migration hints are worth a read before you update a shop. If your checkout uses a template override of checkout/review.php, it needs one new hidden field, and Stripe no longer offers SEPA Direct Debit, Sofort or Giropay.

The sites that cannot take it are the same ones that could not take 6.5.0. Of the affected sites we monitor, 64% run Joomla 5.4 or later, 29% are on Joomla 3 and 7% on Joomla 4. For the third on Joomla 3, there is no Event Gallery build with these fixes, and the real job is getting off Joomla 3.

This time the release page did its job. 6.6.0 opens with a sentence saying it fixes three vulnerabilities, links to a Security Fixes section that sits above the features, and gives each fix an advisory id, a CVE where there is one, a severity, the versions affected and what to do before you can update. That is the format we asked for in our 6.5.0 post, and it is what lets someone looking after dozens of sites decide in a minute that this one goes out today.

How mySites.guru flags Event Gallery below 6.6.0

mySites.guru records the exact version of each extension on each connected Joomla site twice a day. Our Joomla vulnerability database had an entry for Event Gallery below 6.6.0 on the day the release came out, so a connected site running an older component is flagged on its dashboard and in its audit, whether it runs Core or Extended. The Event Gallery page of our vulnerability list shows both Event Gallery rules, and the vulnerable extension list explains how the flags work across all the extensions we track.

The same audit checks the Joomla core version, which decides how much work each flagged site needs. A site on Joomla 5.4 or later can be updated in bulk from one dashboard. A site on Joomla 3 or 4 goes on the upgrade list.

Joomla CMS Version Must Be Up-to-date

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

What can I do before I can update Event Gallery?

CVE-2026-102776 and CVE-2026-102777 need a logged-in backend user to open a page or link an attacker prepared, so the exposure is the set of accounts with backend access to Event Gallery and what those people browse while logged in.

Switch Share article links off in the Event Gallery options (Social tab), which closes CVE-2026-102778
If you no longer use the Google Photos integration, remove the account from Event Gallery
Review who can manage Event Gallery in the backend and remove that permission where it is not needed
Ask administrators to log out of the backend before browsing elsewhere
Check the payment and shipping defaults, watermarks and In shop flags of your events if anything about the shop looks different, and run a full site audit

None of that replaces the update. If you look after more than a few Joomla sites, mySites.guru shows you which ones run Event Gallery below 6.6.0, and the Joomla version each one is on, from one dashboard.

Joomla 5.4 Is Security-Only Since 13 October 2026

phil@mysites.guru (Phil Taylor) — Sat, 03 Oct 2026 12:20:50 GMT

Joomla 5.4 stopped getting bug fixes on 13 October 2026 and stops getting security fixes on 12 October 2027. The Joomla Project restated both dates in its 5.4.9 and 6.1.4 release announcement on 29 September: “We’ll support Joomla 5.4.x until 13 October 2026 with bugfix patches and until 12 October 2027 with security patches.” The same dates are on the Joomla developer roadmap.

5.4 is the last Joomla 5 minor release, so 12 October 2027 is the end of life for Joomla 5 as a whole. In the mySites.guru database, Joomla 5.4 is the most common Joomla version of all, ahead of Joomla 6.1 and Joomla 3.10. This post covers what changes on each date, what our data shows about the sites affected, and the deadline that most 5.4 sites will hit before either Joomla date: their PHP version.

13 Oct 2026

Joomla 5.4 bug fixes end

5.4.10 shipped that day, with no security fixes

12 Oct 2027

Joomla 5 end of life

Last day of 5.4 security fixes

16 Oct 2029

Joomla 6 end of life

Bug fixes end 17 October 2028

Dates from the Joomla developer roadmap and the 29 September 2026 release announcement.

What changed for Joomla 5.4 sites on 13 October 2026?

Since 13 October 2026, Joomla 5.4 gets security fixes only. Joomla will keep publishing 5.4.x patch releases until 12 October 2027, but only when there is a security issue to fix. General bugs, regressions and most compatibility problems found after that date get fixed in Joomla 6 and nowhere else. Joomla 5.4.10 shipped on 13 October itself, the same day as Joomla 6.2.0, and is very likely the last 5.4 release with general bug fixes in it. It has no security fixes, as the Joomla Security Strike Team told us beforehand. Apply it at your normal pace, and keep every 5.4 site current so the next 5.4.x security release is a single step.

The first practical change is the release rhythm: through the bug fix year, 5.4.x shipped roughly every six weeks, from 5.4.0 on 14 October 2025 to 5.4.9 on 29 September 2026. Joomla 4.4’s security-only year had five releases at irregular intervals (January, February, March, April and September 2025), each one shipped when a security fix was ready. Expect 5.4 to behave the same way.

The second is that a broken release stays broken for longer. Joomla 5.4.9 shipped with a known issue that makes Web Services API edit requests fail with a fatal error, which we covered in the 5.4.9 security release post. The fix (#48527) made it into 5.4.10, just inside the window. The next regression of that kind, like the 5.4.8 template manager breakage or the 5.4.7 article options bug, may not get a 5.4 fix at all.

The rule is not absolute. Joomla 4.4.11, released during its security-only year, included a fix for namespace map creation on PHP 8.4. But a compatibility fix in a security release is a bonus, and no one should plan a site’s future around one.

Joomla 5.4 is the whole of Joomla 5 now

Joomla ships four minor releases per major version, and the fourth is a “bridge” release. The software release cycle says you can only upgrade to the next major version from the x.4 release, and “after the x.4.0 release date, we are fixing bugs for one year and making security fixes for two years”. 5.4.0 shipped on 14 October 2025, which is where both dates come from.

Only the newest minor release in a series is supported, so Joomla 5.0, 5.1, 5.2 and 5.3 are already unsupported. Of the Joomla 5 sites in the mySites.guru database, 2.9% are still on one of those older minors. They have no security support today and no direct route to Joomla 6, because a site has to reach 5.4 before the Joomla 6 upgrade is offered.

5.4 also exists to make the next step smaller. It backports the Joomla 6 API changes, and it ships the “Behaviour - Backward Compatibility 6” plugin, which does nothing on 5.4 except exist and be enabled, so that extensions relying on it keep working on the day a site moves to Joomla 6. We have written about why that plugin is a crutch rather than a fix.

How many Joomla sites are still on Joomla 5?

Across the Joomla sites connected to mySites.guru that reported in during the week to 3 October 2026, 38.3% run Joomla 5, and nearly all of those (97.1%) are on 5.4. Joomla 6 accounts for 29.4%. Joomla 5 is still the larger group, a year after Joomla 6.0 shipped and ten days before Joomla 5 went security-only.

38.3%

of Joomla sites run Joomla 5

97.1% of those are on 5.4

29.4%

of Joomla sites run Joomla 6

Almost all on 6.1

6.3%

still run Joomla 4

A year after its security support ended

25.4%

still run Joomla 3

Three years after its end of life

Share of Joomla sites connected to mySites.guru that reported a snapshot in the seven days to 3 October 2026.

The last two figures are what makes the 2027 date worth taking seriously now. Joomla 4.4’s security support ended on 14 October 2025, almost exactly a year ago, and one Joomla site in sixteen in our data is still on it. Joomla 3 has been through the same pattern for three years, and a quarter of the Joomla sites we see still run it. If Joomla 5 follows Joomla 4, a meaningful share of today’s 5.4 sites will still be on 5.4 in October 2027, and some will still be there a year after that.

Most of those sites were kept on an old version because the upgrade was never booked, and it was never booked because nothing visibly broke on the day support ended. End of life is a non-event on the day and a growing liability afterwards: every later Joomla security release publishes a fix for a flaw the old version still has. We made the agency version of that argument in Joomla 3 didn’t fail, your retainer did.

The PHP deadline comes before Joomla’s

Joomla 5.4 supports PHP 8.1 and newer, with 8.3 recommended, per its technical requirements. PHP has its own calendar, published on php.net, and it does not line up with Joomla’s:

PHP version	Security support ends	Joomla 5.4 sites in our data
8.1	Ended 31 December 2025	2.5%
8.2	31 December 2026	24.8%
8.3	31 December 2027	43.6%
8.4	31 December 2028	22.9%
8.5	31 December 2029	5.9%

More than a quarter (27.3%) of the Joomla 5.4 sites in the mySites.guru database run PHP 8.1 or 8.2. For those sites the real deadline is 31 December 2026, ten months before Joomla 5’s, because that is when PHP 8.2 stops getting security fixes. A Joomla core that is still patched does not help much on a PHP runtime that is not.

Move 5.4 sites to PHP 8.3 first

PHP 8.3 is the cheapest single fix on this list. It is supported until 31 December 2027, which outlasts Joomla 5, and it is the minimum PHP version for Joomla 6. Doing it while the site is still on 5.4 means the PHP change and the Joomla 6 change happen months apart, so when something breaks you know which change caused it.

The other 72.4% are already on PHP 8.3 or newer and meet the Joomla 6 PHP minimum today. For them the remaining questions are the database version and the extensions. Joomla 6 technical requirements has the full table, and why PHP 8.5.7 can show amber while 8.4.24 shows green explains how mySites.guru grades PHP branches and patch levels.

Why not wait until October 2027 to move to Joomla 6?

Because the security date is the last possible day, not the planning date. Most sites will be pushed off Joomla 5 well before October 2027, whether or not anyone plans for it.

Extension vendors set their own dates, and they tend to come first. J2Commerce has already set the end of life for J2Store 4, which runs on Joomla 4 and 5, at 19 October 2027, and its current line runs on Joomla 6 only, as we covered in the J2Store 3 end of life post. Smaller projects are following: the Proclaim Bible study component has a public issue to drop Joomla 5 support around Joomla 5’s end of life. Once an extension a site depends on stops shipping Joomla 5 builds, its Joomla 5 support date no longer matters.

New Joomla features only go into Joomla 6. 5.4 was a bridge release with no new features of its own, so everything in the Joomla 6.1 release stays on the newer branch. One example with security weight: from 6.1 you can force MFA for Super Users, and that option is not coming back to Joomla 5. Clients notice a missing feature long before they notice a support date.

October 2027 is also going to be a crowded month. Joomla’s release policy puts a new major version in October of every odd-numbered year, so Joomla 7.0 and Joomla 6.4 are due around the same time Joomla 5 support ends. Every agency that left its Joomla 5 sites until the last quarter will be doing the same upgrades, against the same extension vendors’ support queues, at the same time.

Our view, after watching the Joomla 3 and Joomla 4 deadlines pass: move Joomla 5.4 sites to Joomla 6 during the next six months, while 5.4 is still patched and before PHP 8.2 runs out. A site that moves now is supported until 16 October 2029, two more years of security fixes than one that waits. There is no extended support for Joomla 5 to fall back on. Joomla’s paid extended support for Joomla 3 ended in February 2025, nothing equivalent was offered for Joomla 4, and nothing has been announced for Joomla 5.

How mySites.guru tracks Joomla 5.4 sites through the change

Everything below is part of the mySites.guru subscription, and it works the same across five Joomla 5 sites or five hundred.

Which Joomla 5 sites are ready for Joomla 6?

The Joomla 6 Technical Requirements tool lists all your connected Joomla 4, 5 and 6 sites on one screen, with the installed Joomla version, the update channel, the PHP version and the database type and version. Each PHP and database value is colour-coded against Joomla 6’s minimum (PHP 8.3.0, MySQL 8.0.13, MariaDB 10.4) and recommended versions, so the sites needing a PHP or database upgrade before anything else are obvious at a glance. Press c then 6 anywhere in mySites.guru to jump straight to it.

Keeping 5.4 sites on the current patch

The security-only releases still matter, and they only protect sites that install them. On 3 October, before 5.4.10 shipped, 26.9% of Joomla 5.4 sites in our data were behind the then-current 5.4.9 release. mySites.guru’s “Joomla CMS Version Must Be Up-to-date” check, one of the Joomla configuration checks, shows any site not on the latest patch for its branch in red, and the bulk upgrade applies 5.4.10, and every 5.4.x security release after it, to all your out-of-date 5.4 sites in one action. If you prefer it hands-off, mySites.guru’s automatic core upgrade settings can be set to patch releases only, which keeps 5.4 sites patched without ever starting a major upgrade.

Joomla’s own automated core updates, a free service run by the Joomla Project, also handle patch and minor releases from 5.4 onwards. The Joomla Project’s 6.1 announcement states they do not move a site across a major version, so they will never take a 5.4 site to Joomla 6 on their own.

The two backward compatibility plugins

The Joomla 5 to 6 upgrade depends on two plugins being in the right state. The old Joomla 4 to 5 plugin, “Behaviour - Backward Compatibility”, must be disabled before the upgrade, and “Behaviour - Backward Compatibility 6” should stay enabled until every extension runs without it. mySites.guru reports the state of both plugins on each connected site as part of its extension checks, so the sites with the old plugin still switched on show up before an upgrade fails.

Checking extension support across every site

The extension inventory records each extension and its version on all your connected sites. Searching for an extension returns the sites it is installed on, which is how you find out, before booking the work, which Joomla 5 sites depend on something with no Joomla 6 release. The audit then flags any installed extension version with a known vulnerability, and that matters more on a branch that is no longer getting general fixes.

Check whether your Joomla version is current

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs on every snapshot, twice a day.

Check your site for free

How to upgrade Joomla 5.4 to Joomla 6

The Joomla Project calls this an upgrade rather than a migration, and for a site with well-maintained extensions it usually is. Its own step-by-step planning and upgrade guide covers the details. The order that causes the fewest surprises:

Update to the latest Joomla 5.4.x and take a full backup. Joomla 6 is only reachable from 5.4.
Move PHP to 8.3 or newer while still on 5.4, and test. If the database is below MySQL 8.0.13 or MariaDB 10.4, sort that out at the same time.
Check every extension and template for a Joomla 6 release. Update to it while still on 5.4 where the vendor ships one package for both, and plan replacements for anything abandoned.
Disable “Behaviour - Backward Compatibility”, the Joomla 4 to 5 plugin. Leave “Behaviour - Backward Compatibility 6” enabled.
Switch the update channel to Joomla Next in the Joomla Update options, and work through the Pre-Update Check’s required settings, recommended settings and extension list. If the server is below Joomla 6’s requirements, the upgrade option does not appear at all.
Upgrade, test, then set the channel back to Default. Leaving a site on Joomla Next is how it ends up on Joomla 7 by accident, and preventing accidental Joomla version jumps covers the channel settings.

After the upgrade, check whether the site still needs the Backward Compatibility 6 plugin. Every extension that still relies on it will break on the way to Joomla 7, so finding them now is cheaper than finding them in 2027. If disabling the old plugin before the upgrade throws an error such as Class “JPlugin” not found, our guide to fixing Class “JPlugin” not found shows how to find the extension and get the site back.

For the wider process of running core upgrades across many sites, including staging, backups and rollback, see our guide to managing CMS updates at scale. For a look at your own sites first, run a free audit, or compare the plans if you want the Joomla 6 readiness view across every site you manage.

Timeline

2023-08-17 Joomla 3 reaches end of life Free security support ends. A paid extended support programme runs until 17 February 2025, and then nothing.
2023-10-17 Joomla 5.0 and Joomla 4.4 released Joomla 4.4 becomes the bridge release for the Joomla 4 to 5 upgrade.
2025-10-14 Joomla 4.4 security support ends The last Joomla 4 release was 4.4.14 on 30 September 2025. Joomla 6.0 and Joomla 5.4 ship the same day.
2026-09-29 Joomla 5.4.9 and 6.1.4 released Sixteen core security fixes. The release announcement confirms the two Joomla 5.4 support dates.
2026-10-13 Joomla 5.4 bug fix support ends Joomla 5.4.10 and Joomla 6.2.0 were both released on this day, with no security fixes in either. 5.4.10 is the last planned 5.4 bug-fix release. From here, 5.4.x releases ship only when there is a security fix.
2026-12-31 PHP 8.2 security support ends Joomla 5.4 still runs on it, but PHP itself stops getting fixes ten months before Joomla 5 does.
2027-10-12 Joomla 5 end of life The last day of Joomla 5.4 security fixes. Joomla's release policy also puts Joomla 7.0 in October 2027, though no date has been published.
2029-10-16 Joomla 6 end of life Bug fixes for Joomla 6 end on 17 October 2028, security fixes a year later.

Joomla 6.2 Is Out: Requirements, Changes and Which Sites Can Take It

phil@mysites.guru (Phil Taylor) — Sat, 03 Oct 2026 12:10:26 GMT

The Joomla project released Joomla 6.2.0 on 13 October 2026, on the date it had planned. Joomla 5.4.10 came out the same day, with bug fixes only.

For anyone looking after a portfolio of client sites, 6.2 should be a straightforward update to apply. The server requirements are the same as 6.1, the official upgrade notes list no backward compatibility breaks, and the new features are mostly in the editor, content layout and mail. 6.2.0 has no security fixes, as the Joomla Security Strike Team told us before release, but the next Joomla 6 security release will be a 6.2.x, so your sites need to be on 6.2 before it arrives. The real question is which of your sites can take it, and the answer depends more on PHP versions and Joomla 5.4 stragglers than on anything in 6.2.

mySites.guru answers the server side of that question on one page. The Joomla 6 Compatibility Checker (press c then 6 anywhere in the dashboard) lists every connected Joomla 4, 5 and 6 site with its PHP version, database version, update channel and the state of the Backward Compatibility 6 plugin, each colour-coded against the Joomla 6 technical requirements. The figures below come from the same data, across all Joomla sites connected to mySites.guru that took a snapshot in the last 30 days.

When was Joomla 6.2 released?

Joomla 6.2.0 shipped on 13 October 2026, after three alphas, three betas and two release candidates. Feature freeze came with Beta 1 on 18 August and language freeze with RC1 on 29 September, and the schedule held all the way to the stable release.

Milestone	Date
Alpha 1	26 May 2026
Alpha 2	23 June 2026
Alpha 3	21 July 2026
Beta 1 (feature freeze)	18 August 2026
Beta 2	1 September 2026
Beta 3	15 September 2026
RC1 (language freeze)	29 September 2026
RC2	6 October 2026
Stable	13 October 2026

13 October was also a date for Joomla 5. The Joomla 5.4.9 announcement confirms that 5.4.x gets bug fixes until 13 October 2026 and security fixes until 12 October 2027. So on the day 6.2 arrived, every Joomla 5 site moved to security-only support.

Joomla 6.1 is also affected. The Joomla software release cycle says a minor release goes out of support when the next minor is published, so 6.1 went out of support on 13 October. The next 6.x security fix will ship as a 6.2.x release, not 6.1.5, so staying on 6.1 is not an option for long. 6.2.0 itself has no security fixes, but every 6.x security fix after it will ship for 6.2 only. Joomla 5.4 is still in its security support window, and 5.4.10 is its current release.

Joomla 6.2 technical requirements are unchanged from 6.1

Joomla 6.2 needs exactly what Joomla 6.1 needs. The official requirements page covers 6.1 and 6.2 in a single table:

Software	Minimum	Recommended
PHP	8.3.0	8.4
MySQL	8.0.13	8.4
MariaDB	10.4	12.0
PostgreSQL	12.0	17.6

A site that runs Joomla 6.1 today meets the 6.2 requirements by definition. In our data, every Joomla 6 site reports PHP 8.3 or newer, and 38.5% are on 8.3 exactly, the minimum, with 8.4 recommended. A small number run Joomla 6 on MySQL 5.7 or MariaDB 10.3, below the documented minimum. They work today, but Joomla does not test against those versions, and the MariaDB and MySQL picture across our sites explains why so many databases have drifted out of support.

What’s new in Joomla 6.2

Most of the 6.2 changes affect editors and site builders rather than hosting. These come from the release announcement, the merged pull requests and the project’s own Beta 1, Beta 2, Alpha 3 and Alpha 2 posts:

OAuth 2.0 for SMTP (#48290). Joomla can now authenticate to mail providers such as Microsoft 365 and Google with OAuth instead of a stored password. Microsoft has been retiring basic SMTP authentication, so this helps any site that sends mail through Microsoft 365.
Language fallback chains (#47933). A missing translation string can resolve through a configured fallback language, string by string, instead of showing a raw language constant.
Editor changes. TinyMCE moves from 8.6.0 to 8.9.1, gets a native Read More button (#48236), media manager integration (#48043) and a shared link picker for articles, contacts and menu items (#48138). By default TinyMCE now follows Joomla’s own text filter settings (#48041).
Content and layout options. Sub-category images in category lists (#48196), image and figure classes for articles (#47744), more mod_login options (#47946) and sub-levels below more than just the main menu item (#47909).
Web services. The content API now returns intro text and full text as separate fields (#44566), and category endpoints accept a state filter (#46887).
Smaller fixes. Clearer SVG upload errors, better installer error handling, a new backend help page and aria-disabled on toolbar buttons that need a selection.

The release candidates added little beyond Beta 3: wording that names “MariaDB or MySQL” rather than “MySQL” throughout (#48369), a com_contact SQL fix and test tooling updates.

One feature you may have read about did not ship. Article preview without a front-end login (#48030), which shared unpublished articles through signed, time-limited links, was merged for Beta 1 and then reverted in #48325 before Beta 2. It is not in 6.2.0, so do not promise it to clients who sign off content.

The security flag on Joomla extension updates

The 6.2 change with the most value for agencies has no visible interface of its own. Pull request #48127 lets an extension developer mark a release as a security release by adding one tag to their update XML:

<security>4</security>

The number is a severity from 0 (none) to 4 (critical). Joomla’s update manager then shows the severity next to the available update. A follow-up, #48190, makes Joomla report the highest severity of any release since the installed version. Without it, a critical fix in 1.0.1 would be hidden if 1.0.3 was an ordinary bug-fix release. The change was backported in #48233, so it already works on Joomla 5.4.9 and 6.1.4, and our developer guide to the security flag covers the XML, the edge cases and what admins see.

The flag only helps if vendors set it

A missing tag means “no information”, not “no security fix”. Many of the Joomla extension security releases we wrote about this year shipped with a changelog line saying “improved security” and nothing more. Until vendors start using the tag, an update without one can still be a security fix.

That is the real limitation. In a month of Joomla security disclosures, the hardest part for site owners was not applying fixes but knowing which updates were fixes at all. The tag is a step forward, but it depends on the same vendors who currently write “various improvements” in their changelogs. mySites.guru does not rely on that self-reporting: it matches installed extension versions against known vulnerability rules and alerts you when a site runs an affected version, whatever the vendor’s update XML says.

Will my extensions work on Joomla 6.2?

Almost certainly, if they already work on Joomla 6.1. Joomla’s release cycle forbids backward compatibility breaks in a minor release, and the 6.1 to 6.2 upgrade notes back that up. The deprecations page lists none, although the merged pull requests do deprecate the CMS Crypt package (#47443) and the static methods of MailTemplate (#47717). Deprecated code still runs in 6.2, so only extension developers need to act on these. The only new developer feature listed is a rebuilt asset build pipeline, which affects people building Joomla core, not people running it.

Two areas deserve a test on a copy before you roll out widely:

Editor extensions. Anything that adds TinyMCE buttons, plugins or its own link and media dialogs is running inside an editor that changed more than any other part of 6.2.
Anything touching the update system. The update tables get a new column for the security flag. Extensions that read or write those tables directly, such as custom update managers, are the ones to watch.

Vendor statements are starting to appear. Akeeba’s compatibility matrix already has a “Joomla 6.2” row for Akeeba Backup and its other Joomla extensions. Most vendors do not publish anything for a minor release, and with no breaking changes documented, a missing announcement is normal.

To check what each site actually runs, the extensions list in mySites.guru shows every installed extension and version across all your Joomla sites, so you can see which sites use the editor add-ons and update tools mentioned above.

Which of your Joomla sites can take 6.2

Joomla 6.2 is an update for Joomla 6.1 sites. Everything else is a different project. Here is how the Joomla sites connected to mySites.guru break down today:

29.2%

on Joomla 6.1

a normal minor update

37.1%

on Joomla 5.4

a major upgrade first

6.3%

on Joomla 4.x

two steps away

25.4%

on Joomla 3.x

a migration, not an update

Joomla sites connected to mySites.guru with a snapshot in the last 30 days, 3 October 2026. The rest run older or pre-release versions.

Joomla 6.1 sites are ready

On 3 October, 85.4% of Joomla 6 sites already ran 6.1.4, the last 6.1 release, and the rest were a patch or two behind. These sites are offered 6.2 on the Default update channel like any other update.

Joomla 5.4 sites need a major upgrade first

Many of them cannot do it yet. The 6.2 release notes repeat the rule that a site must be on 5.4 before moving to 6.x. In our data, 27.3% of Joomla 5.4 sites run PHP below 8.3, almost all of them on PHP 8.2, so Joomla 6 will not install there until the host or server moves to a newer PHP. That is the blocker worth finding first, because a PHP change on shared hosting can mean a support ticket or a client conversation.

27.3% of Joomla 5.4 sites cannot move to Joomla 6 until their PHP version changes.

Joomla 3 and 4 sites

These are outside the scope of a 6.2 update. Joomla 4 is fully end of life, and Joomla 3 sites need either a rebuild or the Joomla 3 patching route covered on joomla3security.com.

The Joomla 6 Compatibility Checker puts all of this on one screen. It flags PHP below 8.3 in red, 8.3 in amber and 8.4 or newer in green, applies the same three-colour logic to MySQL, MariaDB and PostgreSQL, and marks any site whose update channel is not “Default”. It does not test individual extensions against 6.2. Only an update on a copy of the site tells you that.

The compat6 plugin is a Joomla 7 problem, not a 6.2 one

One figure in our data matters more than anything in 6.2. 84% of Joomla 6 sites still have the “Behaviour - Backward Compatibility 6” plugin enabled. That plugin keeps old Joomla 4 and 5 code working on Joomla 6. Joomla 5.4 installs it enabled, and the upgrade documentation requires it to stay enabled for the move to 6.x, so almost every upgraded site still has it on. Fresh Joomla 6 installs start with it off.

It does no harm on 6.2. The compatibility plugin page for 6.2 is unchanged from 6.0. The problem comes later. Joomla releases a new major version every two years, in October of odd years, so Joomla 7 is due in October 2027. The 6.2 change in #47814 already adjusts the pre-update check so the CLI updater checks the compat6 and compat7 plugins before a major upgrade.

A site that only works because compat6 is on is running at least one extension that has not been updated for Joomla 6. We made the same argument for Joomla 5 in the compat plugin is a crutch. The 6.2 window, with no breaking changes and twelve months before the bridge release, is the cheapest time to switch the plugin off on a staging copy, see what breaks, and chase the vendor. What breaks usually shows up as Class “JPlugin” not found or a similar old class name. The Compatibility Checker shows the plugin state per site, so you can start with the sites where it is already off and work towards the ones where it is on.

How should I roll out Joomla 6.2 across many sites?

6.2.0 has no security fixes, but it is the release the next Joomla 6 security fixes will be built on. Do the preparation now, so that your sites are on 6.2 before that security release arrives:

Check update channels now. Any site on “Joomla Next” or “Testing” can be offered things you did not plan for. Our post on preventing accidental Joomla version jumps covers why Default is the only sensible production setting.
Find the 6.x sites below 6.1.4 first. They are missing the 16 security fixes in 6.1.4, covered in our 5.4.9 and 6.1.4 write-up. 6.2.0 includes those fixes, so these sites go to the front of the queue.
Update one representative site per stack first. Choose a site that uses your usual template, page builder and editor add-ons, update it, then check editing, the front end and mail delivery.
Roll out in batches with a backup first. The Mass Upgrade Sites tool (m then u) updates selected sites in one pass, and an Akeeba backup beforehand gives you a way back.
Plan the Joomla 5.4 sites separately. Find the ones on PHP 8.2 and fix PHP first. The Joomla 6 upgrade can follow, and there is no reason to tie it to the 6.2 release date.

Once the first 6.2.x security release is out, the fixed code is public, and anyone can compare it with 6.2.0 to work out what was vulnerable. A site still on 6.1 at that point has a major gap to close, not a patch to apply. That is why the gap between release and rollout should be short. The smoke test on one site per stack is still worth the hour: 5.4.9 shipped with a known issue that broke API edits, and a fault found on one site is far cheaper than one found on all of them. The Joomla Security Centre lists each core advisory on the day its fix is released.

Check every Joomla site against 6.2 in one view

The Joomla 6 Compatibility Checker is included in every mySites.guru subscription, with unlimited sites for a flat monthly price. Connect your sites and the PHP, database, update channel and compat6 columns fill in from the first snapshot. Start with a free audit.

1,000+ Days After Joomla 3's End of Life, Everything You Need Is on One Site

phil@mysites.guru (Phil Taylor) — Fri, 02 Oct 2026 12:36:01 GMT

Joomla 3 reached end of life on 17 August 2023. On 2 October 2026 that was 1,142 days ago. If you still look after a Joomla 3 site, the questions have not changed in three years: which security holes are open on it, which of its extensions still get fixes, and how long you can reasonably hold off the move to Joomla 5 or 6.

The answers have been scattered across Joomla’s own announcements, a few dozen vendor changelogs and forum threads, and the Joomla 3 posts on this blog. So we have put them on one site: joomla3security.com.

What joomla3security.com is

A free, public reference on where Joomla 3 stands after end of life: the support dates, 46 Joomla extension vendors’ positions, the core and extension vulnerabilities that still apply to Joomla 3, and your options. No account needed to read any of it.

What is on joomla3security.com

The site has six sections:

Timeline: the support dates, from Joomla 3.0 in September 2012 to the last paid eLTS release, 3.10.20, in January 2025, and the end of eLTS on 17 February 2025. Since that day there has been no official way to buy a patched Joomla 3 core at any price.
Vendors: what each Joomla extension vendor said about Joomla 3, when they said it, and what they did afterwards.
Core vulnerabilities: the 39 Joomla security advisories published since 3.10.12 whose flawed code is also in Joomla 3. Each one was fixed in a supported Joomla release, but none has an official Joomla 3 fix, because there are no more Joomla 3 releases.
Extension vulnerabilities: the 52 published Joomla extension vulnerabilities that apply to Joomla 3 builds.
Your options: stay and patch, migrate, or both, with the costs of each and the community rescue projects compared.
An FAQ and a reading list for the detail behind all of it.

The figures behind the site

Joomla 3 sites connected to mySites.guru are measurably worse off than everything else we monitor, and these are some of the best looked-after Joomla sites there are:

More likely to be hacked

4.90% of Joomla 3 sites vs 0.98% on Joomla 6

79%

Have unpatched core files

Of the Joomla 3 sites we can check

68.2%

Behind even 3.10.12

The final free Joomla 3 release

22.3%

Run a vulnerable extension

At least one with a known flaw

Measured across sites connected to mySites.guru on 28 August 2026.

The second and third figures are the fixable ones. The core fixes for most of those holes already exist and no one has applied them, and more than two thirds of Joomla 3 sites are missing years of fixes that Joomla did ship for free before end of life. The agency retainer post goes through what that means for anyone billing a client to keep a Joomla 3 site safe.

Read the vendor tracker first

The core is rarely what gets a Joomla 3 site hacked. The extensions are, and whether an extension still gets security fixes depends entirely on its vendor. The tracker sorts 46 of them into five groups:

Stopped

No more Joomla 3 releases

Still shipping

Joomla 3 fixes continue

Said stopped, kept shipping

Statement and releases disagree

A further 13 vendors have made no public statement and 4 are gone. Counts from joomla3security.com, 2 October 2026.

The seven who said they had stopped and kept shipping are why a written-down end date is worth so little. JoomShaper said its Joomla 3 products would get “no security patches, regardless of severity”, and then Helix Ultimate had its third Joomla 3 patch anyway, followed by an SP Page Builder patch. Thirteen more have never said anything at all. Each vendor has its own page with the quotes, dates and sources, so you can check the extensions you actually run rather than relying on the last announcement you remember.

How mySites.guru patches what Joomla no longer will

joomla3security.com links to the mySites.guru tools that close those gaps, all of them part of the subscription:

The one-click Joomla 3 core patch backports all 39 core advisories to Joomla 3.10.12. One toggle changes 85 core files, and switching it off restores the stock files. The October 2026 update added 14 more fixes, each reproduced on a real 3.10.12 site first.
JoomShaper’s own Joomla 3 security packages for Helix Ultimate, Helix3 and SP Page Builder deploy across every site in an account, checked against a pinned hash with a backup taken first.
Every connected site is checked against the mySites.guru Joomla extension vulnerability rules, so a newly disclosed hole in an extension you run gets flagged without you going looking.

See which of your sites are still on Joomla 3

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

Patch now, migrate one site at a time

Moving from Joomla 3 to Joomla 5 or 6 is closer to a rebuild than a version bump, because templates and plenty of extensions have no direct successor. That makes it a budget conversation with each site owner, and those take time. Most agencies we work with patch every Joomla 3 site now, then migrate them one by one in the order risk and budget allow. The options page sets out when each route makes sense.

Patching has a shelf life, because hosts will eventually drop the PHP versions Joomla 3 needs. It still beats leaving 39 known core holes open while the migration quote waits for sign-off. Start with the timeline and the vendor list, then connect a Joomla 3 site for a free audit to see what is open on yours. Keeping a whole portfolio patched is covered by a single mySites.guru subscription, from £5 a month for one site to £19.99 a month for unlimited.

What Is MariaDB and Why You Have Probably Never Heard of It - but Use It

phil@mysites.guru (Phil Taylor) — Fri, 02 Oct 2026 12:13:52 GMT

Robert from the MariaDB Foundation asked r/joomla a fair question this week: are you running Joomla on MariaDB, or something else, and why? The post links the Foundation’s yearly database survey, which takes under ten minutes, and the results go up at mariadb.org/survey.

We can answer the first half of that question with measurements. Every site connected to mySites.guru reports its database server and version in each snapshot, twice a day. Across the Joomla and WordPress sites we monitor, 68% run MariaDB and 32% run MySQL. The “why” is short: almost nobody chose their database, and almost nobody cares which one they got.

MariaDB vs MySQL on Joomla and WordPress sites

MariaDB runs 70.7% of the Joomla sites we monitor and 59.1% of the WordPress sites.

MySQL has the rest. These figures come from the version string each database server returns, read from connected sites that took a snapshot in the last 90 days. We publish percentages only, and site counts stay private.

Platform	MariaDB	MySQL
Joomla	70.7%	29.3%
WordPress	59.1%	40.9%
Other PHP sites	86.7%	13.3%
All sites	68.1%	31.9%

Both CMS projects publish their own numbers, and they point the same way. WordPress.org’s database statistics currently show about 60% MariaDB, within a point of ours, a crossover the MariaDB Foundation wrote up in 2025. Joomla’s usage statistics do not separate the two engines (both report as mysqli), but sorting the last 90 days by version number gives roughly 62% MariaDB.

Our Joomla figure is nine points higher than that. The likely reason is who is in the sample: Joomla’s statistics come from any install that opted in, while ours come from sites someone pays to manage, and those sit on hosting that gets updated more often. The “other PHP sites” row is the weakest of the four. Most custom PHP sites don’t report their database, so treat it as indicative.

What the **** is MariaDB?

That would be the reaction of most Joomla site owners to the Reddit question. Most of them have never heard of MariaDB, and they have certainly never sat down and compared its features with MySQL’s. They bought hosting, ran the Joomla installer, typed in the database details the control panel gave them, and moved on. As far as they are concerned, the site has “a database”, and that is the end of it.

For the record, MariaDB is a fork of MySQL started in 2009 by Michael “Monty” Widenius, one of MySQL’s original authors, after Oracle moved to buy Sun Microsystems and MySQL with it. It was built as a drop-in replacement: Joomla and WordPress talk to it through the same mysqli driver they use for MySQL, which is exactly why a site owner never needs to know which one is underneath. The two have drifted apart since, mostly in features a CMS does not touch.

The web host made the choice

So when 68% of sites run MariaDB, the site owners did not choose that. The host did, and the host’s choice is visible in the data.

The version strings show it. A database server reports the build it came from, and across Joomla sites alone we see over 700 distinct version strings. A sixth of the MariaDB servers behind Joomla sites report a cll-lve build, the CloudLinux packaging under much of cPanel shared hosting, and cPanel itself made MariaDB the default for new servers from version 122. Another 18% report a Debian or Ubuntu package, which is what a VPS gets when somebody types apt install and accepts the default. On Debian, the default MySQL-compatible server has been MariaDB for years.

The clearest evidence is in agency accounts. 58% of mySites.guru accounts with five or more sites have sites on MariaDB and MySQL at the same time. These are people who manage sites for a living, and their portfolios are still split, because each client arrived with hosting already in place. No agency gets to standardise the database across thirty clients’ hosting accounts.

The host picks the database

For a typical Joomla or WordPress site, the MariaDB vs MySQL question was settled the day someone chose a hosting plan.

That is why the “which is faster” comparisons filling the search results miss this audience. The decision a site owner controls is the host. The useful question to put to that host is which database version they run and when they plan to move off it, which matters more this year than it has for a while.

Half of all sites now run an end-of-life database

51% of the sites we monitor run a MySQL or MariaDB release that its developers no longer support.

Most of that happened in 2026. Oracle ended support for MySQL 8.0 on 30 April, and the MariaDB Foundation ended MariaDB 10.6 on 6 July. Those two versions alone run 36% of the sites we see, so a third of sites went end of life this year without anyone touching them.

Engine	Version	Share of all sites	Upstream support
MariaDB	10.11	28.1%	Until February 2028
MySQL	8.0	18.7%	Ended April 2026
MariaDB	10.6	17.4%	Ended July 2026
MariaDB	11.4	9.3%	Until May 2029
MySQL	8.4	7.8%	Until April 2029
MySQL	5.7	4.0%	Ended October 2023
MariaDB	10.5	3.8%	Ended June 2025
MariaDB	11.8	3.5%	Until June 2028
MariaDB	10.3	2.5%	Ended May 2023
MariaDB	10.4	2.1%	Ended June 2024
MySQL	5.5	1.0%	Ended December 2018
MySQL	5.6	0.4%	Ended February 2021
MariaDB	10.2	0.4%	Ended May 2022
MariaDB	12.x	0.3%	12.3 LTS until June 2029

The split by platform is close: 50.7% of Joomla sites and 52.1% of WordPress sites are on an end-of-life release.

The two platforms get there differently. On WordPress the larger part is MySQL (29.3% of sites, mostly 8.0 and 5.x), while on Joomla it is MariaDB (28.1%, mostly 10.6 plus a long tail of 10.3 to 10.5).

Why half of all sites are left on an old database

Websites are sold as a project. The build is paid for once, and what follows is a small monthly hosting fee and, if the client is lucky, a cheap maintenance plan. That recurring money is too thin to pay anyone to keep looking, so once a site goes live, nobody does. The site keeps working, the client is happy, and underneath it the PHP version, the database server and the extensions all age a little more each month. Sites are rarely abandoned in one go. They rot slowly.

The database is the clearest case, because it sits on the host’s side where neither the site owner nor most agencies ever look. Nothing on the site changes when MySQL 8.0 or MariaDB 10.6 goes out of support. No error appears, no email arrives, and the admin dashboard looks exactly as it did the day before. You only find out if something is watching.

That is the job mySites.guru does. Every connected site takes a snapshot twice a day, which records its CMS, PHP and database versions, and the dashboard flags end-of-life Joomla, WordPress and PHP versions across every site you manage. The compatibility pages below grade each site’s database too, so the slow rot shows up as a list of hosts to chase instead of a surprise during the next major upgrade. For an agency, that list is also the case for a maintenance plan worth paying for: you can show a client exactly what has aged on their site since launch. You can try it on your own sites or start with a free audit.

Some end-of-life servers still get patches

A server running the MySQL 8.0 or MariaDB 10.6 package from a supported Linux distribution may still get security fixes from that distribution, so those two need checking host by host. The 14.4% of sites on MySQL 5.x or MariaDB 10.5 and older have no such cover: those releases are years past any support.

There is one more catch for anyone hoping to move off MySQL 8.0 to MariaDB. A dump exported from MySQL 8 uses the utf8mb4_0900_ai_ci collation, which MariaDB only accepts from 11.4.5 onwards. Import it into anything older and the restore fails with “Unknown collation”.

Is your database ready for Joomla 6 and WordPress 7?

Joomla 6 enforces a database minimum of MySQL 8.0.13 or MariaDB 10.4, according to the Joomla technical requirements, and recommends MySQL 8.4 or MariaDB 12. 9.9% of the Joomla sites we monitor are below that minimum and cannot update to Joomla 6 until their host upgrades the database. Our Joomla 6 technical requirements post covers the full list.

WordPress is far more forgiving. The WordPress requirements page still accepts MySQL or MariaDB 5.5.5, and WordPress 7.0 left that floor alone while raising the PHP minimum. What WordPress recommends is a different matter: the hosting handbook for 7.0 lists MySQL 8.4 and MariaDB 10.11, 11.4 or 11.8, and its supported list stops at MySQL 8.4 and MariaDB 10.6. The WordPress 7 hosting check explains how we grade that.

See each site's database at once

The Joomla 6 and WordPress 7 compatibility pages in mySites.guru list every connected site with its PHP and database version, colour-coded against that release’s requirements. Filtering by database type or version shows which host each problem sits on.

If you manage multiple Joomla sites or multiple WordPress sites, that page is the shortest route to a list of hosts to email. We track end-of-life CMS and PHP versions the same way.

Newer sites lean further towards MariaDB

The newer the CMS version on a site, the more likely it sits on MariaDB. Joomla 3 sites run MariaDB about two thirds of the time, Joomla 6 sites more than three quarters of the time, and WordPress shows the same slope.

CMS version	On MariaDB
Joomla 3	66.9%
Joomla 5	72.4%
Joomla 6	76.5%
WordPress 6	51.3%
WordPress 7	60.3%

A site on the latest CMS release is usually on a host that has updated its stack recently, and hosts that update are mostly moving to MariaDB. We left Joomla 4 out of the table: one large account holds a fifth of the Joomla 4 sites we see, all on MySQL, which tips that row on its own. With the ten largest accounts removed, Joomla 4 sits at 56.5% MariaDB and the other rows move by a few points at most.

What about vector search in MariaDB 11.8?

The Reddit post also asked whether anyone has done anything with vectors. MariaDB Vector became generally available in MariaDB 11.8 LTS in June 2025, with a VECTOR column type, vector indexes and distance functions built into the server.

Why would Joomla users even be interested in vector search in MariaDB 11.8?

Vector search finds content by meaning rather than by matching words. Each article, product or support answer is turned into a list of numbers (an embedding) by an AI model, and the database stores those numbers in a VECTOR column. A visitor’s query gets the same treatment, and VEC_DISTANCE_COSINE() returns the rows whose meaning sits closest to it. Someone searching for “cancel my subscription” finds the article titled “Ending your membership”, which a keyword search such as Joomla’s Smart Search would usually miss.

On a Joomla site that could mean:

site search that understands synonyms and badly worded questions
“related articles” and “similar products” chosen by content, not by shared tags
a support chatbot that answers from the site’s own articles, with the content and its embeddings in the Joomla database instead of a separate vector service

For ordinary hosting, the last point is the big one. Until now, AI search features have meant paying for an external vector database and syncing content to it. With MariaDB 11.8 the vectors live in the same database as #__content, backed up with it and moved with it. You still need an AI model to create the embeddings, so it is not free, but it removes a whole extra service from the setup.

Only 3.9% of the sites we monitor are on MariaDB 11.8 or newer, so almost no Joomla or WordPress site can use it yet. We found no Joomla extension that uses it. On the WordPress side, Automattic has an experimental native vector database plugin on GitHub that supports MariaDB 11.7 and later, but it is not in the plugin directory. Vector search inside the CMS database is waiting on hosts, the same as everything else in this post.

How we counted

All figures here come from the database version reported by sites connected to mySites.guru that completed a snapshot in the last 90 days, read on 2 October 2026. Disabled sites and sites that report no database version are excluded.

Classifying the engine from a version string needs two corrections. MariaDB 10.x reports itself as 5.5.5-10.x.y, a prefix added so old MySQL clients would accept a version number starting with 10. MariaDB removed it in 11.0, so we strip it before reading the version. Some MariaDB 11 and 12 servers return a bare number with no “MariaDB” in it, so we count any major version of 10 or above as MariaDB. MySQL has never shipped a version 10.

Take the MariaDB survey

The MariaDB Foundation’s 2026 database survey is open until mid-October. Last year’s State of MariaDB report drew 275 responses, so each Joomla and WordPress developer who answers moves the result. If you run sites on MariaDB, or avoid it on purpose, they want to hear why.

“My host installed it” is a perfectly good answer to the survey’s “why”. Judging by the sites we monitor, it is probably the most common one.

14 More Joomla 3 Security Fixes, Each Tested on a Real 3.10.12 Site

phil@mysites.guru (Phil Taylor) — Fri, 02 Oct 2026 11:50:26 GMT

Joomla’s September 2026 release, Joomla 5.4.9 and 6.1.4, closed sixteen core security issues. If you run a Joomla 3 site, you will never be offered a single one of them. Joomla 3 reached end of life in August 2023 at version 3.10.12, and the project ships security fixes only for Joomla 5 and 6.

There used to be a paid way to keep getting them. Joomla’s Extended Long Term Support programme backported fixes to Joomla 3 for a subscription, but it ended on 17 February 2025 and has shipped nothing since. So as of 2025, there is no official source of new Joomla 3 core security fixes at all, paid or free.

That is the gap our one-click Joomla 3 patch tool fills, and this month it grew. We backported the nine September fixes that reach Joomla 3, found five more from the spring that had slipped past us, and shipped all fourteen. The tool went from 65 files to 85.

The short version

Fourteen more Joomla core security fixes are now in the mySites.guru one-click Joomla 3 patch tool, every one of them reproduced on a real Joomla 3.10.12 install before we shipped it. One toggle patches all 85 files. No eLTS subscription, and switch it off to revert.

What does the mySites.guru Joomla 3 patch tool do?

The tool is a toggle in each Joomla 3.10.12 site’s Snapshot. Flip it on and the mySites.guru connector compares the hash of every file that needs patching against the version we ship, replacing anything that does not match. Flip it off and the files revert to stock 3.10.12. There is nothing to upload, no eLTS licence, and no risk of being stranded on a half-applied patch.

The patch goes on top of official Joomla 3.10.12, nothing else

It patches the official Joomla 3.10.12 files. It is not a patch on top of an eLTS build, or a third-party fork such as JoomlaWorks’ unofficial Joomla 3.x “up to date” (which continues Joomla 3 under its own version numbering), or any other Joomla 3 series. If your site runs an eLTS release, a fork, or any version other than stock 3.10.12, upload the full fresh official Joomla 3.10.12 files over the site first, then run the tool to patch them. Straight from official 3.10.12 to the mySites.guru patch is the only supported path.

The tool lists every Joomla 3 site in your account with its own toggle, so you can patch one site or the whole list from one page.

Each Joomla 3 site also shows the same check as a row in its Snapshot. A green OK badge and an on toggle mean the site has every file in the current patch set. When the patch set grows, the badge turns red and shows how many files are now behind, so you know there is new protection to apply rather than having to go looking.

Patched: a green OK badge and the toggle on, meaning every file matches the current patch set.

Not patched: a red badge showing 85 files behind, after the October 2026 update grew the set. One toggle applies all of them.

Under the hood the patches come from the open-source Joomla 3.10.999 project, the same approach as the earlier Joomla 1.5.999 and Joomla 2.5.999 repositories. The how-to linked above has the full walkthrough of where the tool lives and how to patch sites in bulk. This post is about what went into it in October 2026, and how we decided.

What Joomla fixed in 5.4.9, and what reaches Joomla 3

Of the sixteen core issues in Joomla 5.4.9, nine reach the Joomla 3 code and are now patched. The other seven live in parts of Joomla that version 3 never had: the webservice API endpoints, the workflow engine, the HTML mail templates. There is no Joomla 3 equivalent to patch, so they are simply out of scope rather than ignored.

Four of the nine are worth describing, because they are the kind of flaw that sits unnoticed on an end-of-life site until someone goes looking:

A guest could create a user account (CVE-2026-90907). The profile.save controller never checked whether the person calling it was logged in, so a signed-out visitor could create a guest-level account even on a site with user registration turned off. The fix rejects a guest outright.
Arbitrary directory deletion through the cache (CVE-2026-90915). The file cache did not properly validate a cache group name, so a crafted name with ../ in it could walk out of the cache folder and delete directories elsewhere. The patched version resolves the path and rejects anything that escapes the cache root.
Server-side request forgery (CVE-2026-92222). Several URL fields accepted any scheme, so a URL meant to point at a feed could be pointed at an internal service instead. The fix restricts those fields to http and https.
Two XSS filter bypasses (CVE-2026-92231 and CVE-2026-92232). Joomla’s input filter could be tricked into keeping a javascript: URL by hiding it behind an HTML5 entity, or a data:text/html payload behind a tab character. Both are now decoded and stripped the way a browser would read them.

The full list, with every advisory link, is in the one-click how-to.

Why we don’t trust the “affected versions” field

This is where the real work is. A Joomla advisory lists the versions it affects, and the obvious thing to do is read that field and patch the versions it names. We don’t, because the field is written against the versions Joomla still supports, and the vulnerable code is often older than the oldest version listed.

Four of September’s advisories are rated “Joomla 4.0 and later”: the cache directory-deletion above, two improper-ACL checks on tagged items and the content-history comparison view, and an XSS in the module list. Read the field literally and you would skip all four on Joomla 3. Read the actual 3.10.12 source and the same flawed code is right there.

So we reproduce each candidate on a stock Joomla 3.10.12 install before it goes in. We stand up a real site, write a test that triggers the flaw, confirm it fires on the unpatched files, apply the backported fix, and confirm the test now fails to trigger it while the legitimate behaviour still works. The cache directory-deletion and both ACL checks earned their place in the Joomla 3 set that way, not because an advisory told us to add them.

The spring 2026 fixes came out of the same discipline. While checking the September batch against 3.10.12 we noticed five earlier ones that reach Joomla 3 and had never been added: an XSS in the feed modules, an XSS in com_contenthistory, a local file inclusion in a layout parameter, and two more input-filter hardening fixes. They are in now too.

The fix we left out on purpose

One September advisory did not make the cut, and that is the point of being precise. CVE-2026-21629 is an ACL hardening fix for com_ajax, and it is rated as affecting Joomla 3. But on Joomla 3 the administrator application sends every signed-out visitor to the login screen before com_ajax ever runs. The vulnerable path is not reachable, so there is nothing to patch.

We could have added the file anyway and claimed a bigger number. Inflating the count would make the tool look more thorough while doing nothing for a single site. A patch set is only worth trusting if every file in it is there for a reason, so a CVE that cannot fire on Joomla 3 stays out, and this post tells you which one and why.

How many files does the Joomla 3 patch tool change?

The tool now touches 85 files: 43 PHP files that hold the actual fixes, 37 XML form definitions that tighten input validation, three language files and two CA certificate bundles. Eighty-four are replaced with patched versions and one is a file Joomla 3 never shipped, created when you toggle on and deleted when you toggle off.

Because the patch set ships with the connector, it grows as new Joomla 3 CVEs are backported, and a site that was fully patched then reads as behind until you re-toggle. That is the mechanism doing its job, not a regression: the connector only counts a file as patched when it matches the exact version we ship today, so “fully patched” always means current, never current as of some fixed date.

What to do if you still run Joomla 3

Start planning the new site on a modern Joomla version. Patching Joomla 3 is a holding action, not a plan: the PHP it runs on, the extensions built for it, and the tooling around it are all aging out, and no amount of core patching saves you long term. A fresh build on Joomla 5 is the only real fix, so get it on the roadmap now rather than when something breaks.

For the sites you cannot, will not, or do not want to move yet, patch them. Switch the toggle on, and if you manage many Joomla 3 sites the bulk view patches them together. The case for keeping these sites covered while you plan their future is in Joomla 3 Didn’t Fail. Your Retainer Did..

This tool patches every known Joomla 3 core security issue

One toggle, 85 files, every Joomla core vulnerability we have confirmed reaches Joomla 3. No eLTS subscription, and reversible at any time.

Core is not the only thing aging on a Joomla 3 site. The extensions are going end of life alongside it, which is why we also patch JoomShaper’s Helix and SP Page Builder separately. Between the two, the known holes come off the table while you do the real work of migrating.

Snapshot vs Audit: Settings Check or Full File Scan?

phil@mysites.guru (Phil Taylor) — Fri, 02 Oct 2026 10:10:55 GMT

mySites.guru checks your WordPress and Joomla sites in two different ways, the snapshot and the audit. Both produce a list of pass/fail checks, and every one of those checks is documented, but they gather their data differently and catch different problems.

The snapshot reads your site’s configuration, users and extensions in milliseconds. The audit reads every file in your webspace looking for threats. They run independently on their own schedules, and the useful question is which one found a given problem, because a clean result from one says nothing about the other. If you manage more than a handful of sites, the multi-site dashboard shows both side by side for every connected site.

How does the mySites.guru snapshot work?

The snapshot is the quick health check. It looks up database settings, reads specific configuration files, checks HTTP response headers and counts things like user accounts and installed plugins. None of it needs a scan of the file system, so it finishes in milliseconds.

There are over 100 individual checks on each platform, grouped into categories like:

Platform configuration (debug mode, SSL, file editing, XML-RPC, auto-updates, and dozens more, including the WordPress debug constants that leak errors to visitors)
User accounts (inactive users, unactivated accounts, hashed passwords, admin count, rogue Super Admins)
Security headers (X-Frame-Options, Content-Security-Policy, HSTS, Referrer-Policy), covered in more detail here
Extensions and plugins (installed versions, available updates, deactivated plugins still on disk, known vulnerabilities)
Database integrity (table prefix, user permissions, pending migrations)
Hosting environment (PHP version against the Joomla technical requirements, disabled functions, error reporting, session configuration)
Search engine visibility (robots.txt reachability, blocked search and AI answer engines, sitemap declaration)
Targeted hack detection (a short list of specific compromises that live in the database or the server, covered below)

Snapshots run automatically about twice a day on every connected site, and you can trigger one on demand. Many checks include a one-click toggle, so debug mode left on or user registration accidentally enabled is fixed from the dashboard without logging into the site. You can see what that looks like on the screenshots page.

What does a snapshot set in motion?

A snapshot is also the trigger for several things you would not file under “checking”. Each time one finishes, mySites.guru gathers the full list of extensions and themes, compares each against its update feed, and checks the versions against the vulnerability database. A match raises an alert, which is why a new advisory can reach you within hours of a rule being added rather than at your next manual look.

Automatic extension updates work the same way. They do not run on a clock of their own: when a snapshot sees an update for an extension you have enabled for auto-update, the update goes out. Starting an audit also triggers a snapshot, so the two sets of results are never far apart on the day an audit runs.

Events between snapshots, such as a new admin login or a changed template file, come from near-real-time alerting instead. The snapshot is the twice-daily sweep, and the alerts cover the gaps.

How does the mySites.guru audit work?

The audit reads every file and every line of code in your webspace: PHP, JavaScript, images, archives, hidden files, everything. It matches them against a library of roughly 1,500 regex patterns and a database of known-bad file hashes to identify:

Malware and backdoors (suspect code patterns, obfuscated PHP, known malicious file hashes)
Mass mailers (scripts built to send spam from your server)
Modified core files (WordPress or Joomla core files that have been tampered with)
Impostor files (files sitting in a folder the CMS owns that the release never shipped)
Hidden files and folders (dot files tucked into directories you would never think to check)
Dangerous permissions (files or folders set to 777)
Suspicious file types (SQL dumps, renamed PHP files, upload scripts in unexpected places)

The audit also builds the file and folder listing that the investigation pages and the file manager’s audit view read from, so it does a second job beyond hack detection: a tool that needs to know what was on disk at the last scan is reading the audit’s output. The file-level checks and folder-level checks are documented one by one, and the guide to finding hacked files walks through reading the results.

How does an audit treat a shared host?

Because every file gets opened, an audit takes minutes where a snapshot takes milliseconds, and a large site takes longer. That is a real load on the server hosting the site, which is why the scheduler is built to go gently.

Only one audit runs at a time per server hostname and the rest queue behind it, so a host with fifty sites is never hit by fifty scans at once. The scan also slows itself down when a host struggles to keep up. A host that is fine at the first attempt runs at full speed, and one that keeps timing out gets a progressively slower scan until it completes. Scheduling is covered here, and you can start one manually whenever you need it.

That load falls on your hosting account, which is why the daily-versus-weekly question below matters.

How do they compare side by side?

	Snapshot	Audit
Speed	Milliseconds	Minutes, depending on site size
Frequency	About twice daily, plus on demand	Weekly by default, daily or monthly if you choose
Reads	Settings, headers, users, extension versions, known database hacks	Every file and line of code in the webspace
Checks per platform	100+	Around 30 inspection tools
Finds hacks	Rogue admins and known database-resident compromises	Backdoors, malware, modified core files, impostor files
One-click fixes	Yes, many checks have toggles	Investigation tools for reviewing findings

Joomla and WordPress in numbers

The two platforms do not have the same number of checks, because they do not have the same things to check. Counting the check library in October 2026 gives this:

	Snapshot checks	Audit tools
Joomla	129	33
WordPress	103	29
Other PHP sites	19	22

Joomla has more snapshot checks mostly because its configuration surface is larger, with around fifty configuration checks on their own. The audit counts sit much closer together, because a file scan looks much the same on either platform: a PHP file in the wrong place is a PHP file in the wrong place. If you run both, the Joomla and WordPress multi-site pages describe how each is managed day to day.

What each scan finds on a real site

The easiest way to hold the difference in your head is to ask where a problem physically lives. If it lives in the database or in a setting, the snapshot sees it. If it lives in a file on disk, only the audit does.

Problem	Found by
Debug mode on, registration open, missing security headers	Snapshot
An extension version with a known vulnerability	Snapshot
A rogue Super Admin account	Snapshot
Injected template or menu parameters, rogue JCE profiles, SP Page Builder assets	Snapshot
A PHP backdoor in an uploads folder or hidden behind an image extension	Audit
A modified or missing core file	Audit
A mass mailer script	Audit
An impostor file in a core folder	Audit
World-writable folders, SQL dumps left in the webroot	Audit

Two things follow from that table. A clean snapshot can still sit on a hacked site, because it cannot see a malicious file on disk. And the audit has company as a hack detector: the database-resident compromises that Joomla attackers favour are what the snapshot’s targeted checks look for. Those checks cover specific known compromises. A general scan of your database is still on the roadmap.

Four incidents, and the scan that caught each

Abstract tables only go so far, so here are four compromises we have written up, sorted by which scan is the one that sees them.

An attacker who creates their own Super Admin account is a snapshot finding. The rogue Super Admin check matches the account names and generated identities that known attacks use, and the walkthrough on finding rogue admin accounts shows what the result looks like on a live site.

A backdoor hidden in Joomla’s scheduler is also a snapshot finding. A scheduled-tasks row sits in the database and does nothing without a routine to run it, so the malicious scheduled task check reads the scheduler on every snapshot and judges each task by the routine it names. The same family includes locked scheduled tasks that stop legitimate jobs running.

Malware that survives its own deletion is the third. On Linux, deleting a file does not stop a process that is already running it, and the snapshot’s resident process check reports PHP processes whose code is no longer on disk. The post on malware you thought you deleted explains why reinfection within seconds of a cleanup points here.

The fourth is the one the audit exists for: a file that should not be there. Impostor files in core folders are PHP files sitting among a release’s files that the release never shipped, and only a scan that reads the folder against the release notices them.

Three of the four are snapshot findings. A daily audit would not have found any of the first three sooner, because the audit reads files and these problems are not in files.

Why a daily audit rarely earns its server load

We recently began writing to customers who had daily audits scheduled and asking them to switch most sites back to weekly or monthly. A hosting company that was about to connect around 700 sites asked whether it was an automated email, and then whether our servers could take that volume on a weekly or monthly schedule. They can, with room to spare. The reason for the email was the data: when we looked, about 99% of audits that run on a daily schedule were never opened by anyone.

Your server takes that load as much as ours does. Every audit reads every file on your host, and a scan whose results no one reads costs you that load for nothing.

Snapshots already run twice a day

Between audits, the snapshot is still watching your configuration, your extension versions, your user accounts and the known database hacks. The only extra thing a daily audit does over that is read your files line by line a few more times a week.

The published audit data shows what turns up when the file scan does run across a wide spread of sites, and the customer reviews describe how people use the dashboard day to day.

How often should each one run?

Leave the snapshot alone. It runs about twice a day by default, it costs your server almost nothing, and it is what powers update alerts and vulnerability warnings.

For audits, weekly suits most sites and is the default for new ones. Monthly suits dormant sites that no one edits. Daily is worth choosing for a site you are actively watching, for example in the days after a cleanup, where you want to know quickly whether anything came back. Switch it back once the site has been quiet for a couple of weeks.

If you manage a lot of sites, the bulk scheduler changes the period on many at once. Combined with a weekly default, it spreads the file-level work over the week while the snapshot keeps the daily watch. If a site does get hacked, the recovery walkthrough covers what to do next, and the Joomla and WordPress hacked-site pages cover the first hour.

Start with a free audit and see where your sites stand, or look at the pricing if you are managing more than a handful.

SP Page Builder's Joomla 3 Security Patch Was Incomplete. Version 1.0.3 Fixes It.

phil@mysites.guru (Phil Taylor) — Fri, 02 Oct 2026 09:06:56 GMT

JoomShaper has released version 1.0.3 of the Joomla 3 Security Patch for SP Page Builder, and it finishes a job the first release started. When SP Page Builder 6.9.1 fixed five security issues we reported, Joomla 3 sites were left out, because they cannot run the 6.x package at all. The Joomla 3 patch that shipped alongside it, version 1.0.2, was meant to back-port those fixes. It back-ported four of them, left the fifth live, and shipped a cross-site scripting fix that stopped one character short. Version 1.0.3 closes both gaps.

We found them while verifying the released packages on 14 September, proved each on a Joomla 3.10.12 test site with the patch files in place, and reported them to JoomShaper the same day. This post is what those two gaps were, how 1.0.3 addresses them, and the part that no patch version fixes: most Joomla 3 sites running SP Page Builder cannot install it.

What version 1.0.2 left open

The 6.9.1 round had five findings. Four of them are ordinary back-ports: the same corrected code, moved to the older files. The two that did not travel cleanly are the interesting ones, and both are the kind of gap that appears when a fix is applied to the exact place it was reported and not to the code sitting next to it.

The first was the captcha bypass. The second was an XSS fix that escaped one of two sinks on the same line. There was also a smaller observation about where the captcha type is read from, which 1.0.3 has now tidied up as well.

6.9CVSS 4.0

CVE-2026-79701Unauthenticated captcha bypass in the contact, form builder and opt-in form addons

MediumJoomla CNA, published 14 September 2026 and being extended to the Joomla 3 branch

An anonymous visitor gets past reCAPTCHA on any of the three Pro form addons by claiming the form sits inside a module. The 1.0.2 patch left this live on Joomla 3, and the opt-in form was not in the patch at all. Fixed in 1.0.3.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

No login neededExploitable over the internetCaptcha not verifiedFixed in 1.0.3

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

5.3CVSS 4.0

CVE-2026-102426CVE-2026-102426: reflected XSS in the dynamic content filter addon

MediumJoomla CNA, published 5 October 2026

A crafted link to a page using the dynamic content filter prints the attacker's HTML into the page, so their script runs in the visitor's browser as your site. It needs someone to click the link, and it is worse when that person is logged in as an administrator. Joomla 3 branch only. Fixed in 1.0.3.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

No login neededVictim must click a linkReflected XSSJoomla 3 onlyFixed in 1.0.3

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The captcha bypass that never reached Joomla 3

SP Page Builder’s Pro form addons verify their captcha in a public AJAX handler that anyone can call. The bypass, described in full in the 6.9.1 write-up, is that the handler reads a view_type value straight from the request, and when that value says the form is being rendered inside a module, the code throws away the real captcha result and replaces it with a test of whether the submitted token is merely non-empty. Declare view_type=module and the captcha is gone. It is published as CVE-2026-79701, with an affected range reaching back to 3.2.6, so every Joomla 3 build has been in scope the whole time. Rather than issue a new number for the Joomla 3 branch, the Joomla CNA is extending that same record, since it is one defect across two branches.

That override was still present, word for word, in the files the 1.0.2 patch shipped for the contact form and the form builder. The opt-in form, the third addon of the same family, was not in the patch at all, so a Joomla 3 site kept whatever it already had there. The one fix in the round that an anonymous attacker could reach without any account was the one the Joomla 3 patch did not apply.

We proved it the same way as on the modern branch: two submissions to the contact addon with the same invalid reCAPTCHA token, identical apart from one field. Without view_type, the response was “Invalid Recaptcha”. With view_type=module and a matching module id, the response was the mail stage, so the captcha gate had already been passed. One field, two outcomes, the same junk token.

Version 1.0.3 removes the module override from all three addons, the opt-in form now included, so the captcha plugin’s verdict is the one that counts in every render context.

An XSS fix that stopped one character short

The 1.0.2 patch also introduced a new file, the dynamic content filter addon, as its cross-site scripting fix, and added fifteen htmlspecialchars calls to it. Two sinks were missed, and they were on lines the patch itself had edited.

The addon renders a range slider whose minimum and maximum come from a request parameter. On the label line, the value was escaped inside the data-value attribute and then printed again, unescaped, as the element’s own text content a few characters later:

$output .= '<span class="slider-min-value" data-value="'.htmlspecialchars($minValue, ENT_QUOTES, 'UTF-8').'" data-field-id="' . $fieldId . '" >'.$minValue.'</span>';

The first $minValue is safe. The second, in the text node, was not, so a crafted value reflected straight into the page. The escaping had reached the attribute and stopped before the text a few characters to its right. Version 1.0.3 wraps both, matching the complete fix already present on the 6.x branch. The Joomla security team assigned it CVE-2026-102426.

The through-line across this vendor’s last several rounds is exactly this shape: the fix reaches the reported location and not the sibling running the same code. The 6.8.0 remote code execution sat in the method directly below the one hardened in 6.7.1. Here the correction reached one of two values on a single line, and skipped the opt-in form entirely.

Only 5.6.1 sites can install it

The harder limitation is unchanged from 1.0.2, and it is not about any one finding. The patch checks the installed version and will not run on anything except SP Page Builder 5.6.1 exactly. Across the Joomla 3 sites we monitor that run SP Page Builder, only about 3% are on 5.6.1. For the other 97%, this patch will not install, and neither will 6.9.1. The largest single group is on SP Page Builder 3.8.x, and it has no official fix at all.

There is a second, quieter problem, and it is one we had already raised with JoomShaper. The patch installs as a Joomla file package: it overwrites files in place and, once applied, the component still reports its own version as before. To any updater, and to any scanner that reads a version number, a patched Joomla 3 site looks identical to one that has never been touched. A security fix you cannot detect is one you cannot manage across more than a handful of sites.

Apply 1.0.3 in one click with mySites.guru

A version number cannot tell a patched Joomla 3 site from an unpatched one, so mySites.guru reads the files instead. The Unpatched JoomShaper Security Holes tool runs on each snapshot of a connected Joomla 3 site and looks inside the installed files for a string that exists only in a given release of JoomShaper’s patch. For Helix Ultimate, Helix3 and SP Page Builder it reports whether the extension is installed, whether any patch has been applied, and whether the applied patch is the current release. It now recognises 1.0.3, so a site still on 1.0.2 shows as needing the update rather than as a green tick it has not earned.

Applying the patch is one click on that site’s tool page. When you click it, mySites.guru:

backs up the files the vendor package is about to overwrite, and stops if the backup fails
downloads JoomShaper’s own 1.0.3 package from our CDN and checks it against a pinned SHA-256, so the site receives the exact file JoomShaper published
installs it through Joomla’s own extension installer, so the vendor’s version check runs and a site on the wrong SP Page Builder version is turned away, just as it would be if you installed the package by hand
reports the outcome per extension, so a failed backup, download or install shows up as a failure on the page instead of a success with nothing changed

Undoing it is one click too, restoring the backed-up originals. We install the whole vendor package because the patched files call methods that exist only in other patched files, so splicing them in one at a time would leave a site that fatals.

The tool also covers one hole that no JoomShaper package reaches: a local file include in the SP Page Builder 3.8.x addon loader. The vendor patch installs only onto 5.6.1, so for 3.8.x sites the tool applies a small guard to that one line, with its own backup and its own revert.

Why a monitoring service suits this kind of patch

Joomla’s updater, the Extensions manager and any scanner that compares version numbers all read a patched site and an unpatched one as the same, so confirming the fix means opening the files on each site. JoomShaper has also shipped four releases of the SP Page Builder package since July, and several of the Helix Ultimate one, and each new release turns a “patched” site back into an outdated one. mySites.guru repeats the file check on every snapshot of every connected site and flags the ones that fall behind, so you are not keeping a spreadsheet of which client site took which release.

We also read these packages closely ourselves. The two gaps that 1.0.3 fixes were found by us while checking 1.0.2, and the tool moved to 1.0.3 only after we had read the files JoomShaper released.

If you look after Joomla 3 sites that run SP Page Builder, Helix Ultimate or Helix3, connect them to mySites.guru and the tool will show you which ones are exposed, then patch them in a click. See pricing for plans.

Apart from that one guard, none of this helps the sites the vendor patch will not install onto. Joomla 3 reached end of life in August 2023, and the extensions built for it are following it out. The fix for those sites is the migration that has been waiting, not another patch. Until then, the findings that need a logged-in account are the ones to think hardest about: audit who holds Author and Editor, and turn off self-registration where nothing depends on it.

Timeline

14 September 2026 SP Page Builder 6.9.1 ships, with a separate Joomla 3 patch JoomShaper released 6.9.1 for the modern branch and, alongside it, the Joomla 3 Security Patch version 1.0.2 for sites that cannot run 6.x. The Joomla CNA published six CVE records for the 6.9.1 findings the same day, all crediting Phil Taylor of mySites.guru.
14 September 2026 We report two problems in the 1.0.2 Joomla 3 patch Verifying the released packages, we found the module-context captcha bypass (CVE-2026-79701) was still live in the files the Joomla 3 patch shipped, with the opt-in form addon not shipped at all, and the patch's cross-site scripting fix escaped only one of the two sinks on the lines it edited. Both proved live on a Joomla 3.10.12 test site, reported to JoomShaper with the Joomla security team copied in.
15 September 2026 JoomShaper acknowledges and starts work Support confirmed the report and said the development team would update the Joomla 3 patch.
30 September 2026 Version 1.0.3 ships, and we verify it JoomShaper released the corrected Joomla 3 Security Patch, version 1.0.3. We read the released files and confirmed the module-context captcha shortcut is gone from all three form addons, the opt-in form is now shipped, both dynamic content filter sinks are escaped, and the captcha type is read from the stored addon rather than the request.
30 September 2026 The Joomla CNA assigns the CVE numbers The Joomla security team assigned CVE-2026-102426 for the dynamic content filter XSS, and extended the existing CVE-2026-79701 to cover the Joomla 3 branch for the captcha bypass rather than issuing a new number, since it is the same defect on an older branch.

Phoca Cart 6.1.9 stops anyone downloading other customers' paid files

phil@mysites.guru (Phil Taylor) — Thu, 01 Oct 2026 18:24:48 GMT

On 1 October 2026 Phoca released Phoca Cart 6.1.9, a security release for the Joomla e-commerce extension. The announcement names the flaw in one line: “Authorisation bypass through user-controlled key (IDOR) in Order View”, with more detail promised in a CVE record. The Joomla CNA published it as CVE-2026-102775 on 5 October 2026.

We read the 6.1.9 package to work out what that means for a shop. It means anyone could download the digital products your other customers paid for, without an account. If your shop sells downloads, anyone could have taken your stock for free.

TL;DR

Phoca Cart before 6.1.9 checked that a download token and an order token had been sent with a download request, but never checked that they were correct
Any visitor, logged in or not, could fetch any purchased file by its sequential id, and each fetch counted against the real buyer’s download limit
6.1.8 is affected. Shops that installed the August security release need to update again
Only the Joomla 6 line is fixed. The current releases for Joomla 5 (5.2.4), Joomla 4 (4.0.13) and Joomla 3 (3.5.8) contain the same code and no fix
Joomla 5 sites will not be offered 6.1.9 by the updater. Install the package by hand
The flaw is CVE-2026-102775, CVSS 4.0 8.7 High, published by the Joomla CNA on 5 October 2026. This is Phoca’s fix; we analysed the release after it shipped

8.7CVSS 4.0

CVE-2026-102775CVE-2026-102775: unauthenticated download of other customers' purchased files

HighJoomla CNA

Any visitor can download every digital product sold through the shop, along with whatever else was attached to an order as a download. Nothing on the site is changed.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

No login neededPaid files exposedNo fix on Joomla 3, 4 or 5 lines

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

How the Phoca Cart download check failed

When a customer buys a downloadable product, Phoca Cart creates a row for the file against their order and gives it a download token. The order has its own token too. A guest buyer downloads the file by sending both tokens back, and a logged-in buyer is recognised as the owner of the order.

The download task in admin/libraries/phocacart/download/download.php loaded the file row from the numeric id in the request, then ran its ownership check. Here it is from 6.1.8:

// CHECK USER AND TOKEN
if ((int)$user->id < 1 && ($tokenDownload == '' || $tokenOrder == '')) {
    return false;
}
if (!isset($file->userid) && ($tokenDownload == '' || $tokenOrder == '')) {
    return false;
}
if ($user->id != $file->userid && ($tokenDownload == '' || $tokenOrder == '')) {
    return false;
}

Each condition ends in “the token is empty”. None of them compares the token sent with the token stored. So a visitor who is not the owner gets through by sending any two non-empty strings as d and o. The file ids are sequential integers, so finding the files takes nothing more than counting.

The only other gate in front of it is Joomla’s form token check in the download controller. That is a protection against cross-site request forgery, not a login, and any visitor receives one from a page with a form.

The download limits in Phoca Cart’s settings still applied, and that has a side effect a shop owner should know about. Each stolen download added to the file’s hit count, so a buyer whose shop limits the number of downloads may have found their allowance used up by someone else.

What changed in Phoca Cart 6.1.9

The fix is thirteen lines in the same function. The visitor now has to be the logged-in owner of the order, or send both tokens and have each match the stored value, compared with hash_equals():

$isOwner = ((int)$user->id > 0 && isset($file->userid) && (int)$user->id === (int)$file->userid);

if (!$isOwner) {
    if ($tokenDownload === '' || $tokenOrder === ''
        || !isset($file->download_token) || !isset($file->order_token)
        || !hash_equals((string)$file->download_token, (string)$tokenDownload)
        || !hash_equals((string)$file->order_token, (string)$tokenOrder)) {
        return false;
    }
}

That is the check the old code meant to perform. The only other code change in the release is a loose comparison in the order status handler, which is not security related. If you diff the GitHub tags rather than the packages, you will also see output escaping in the filter layouts. That belongs to 6.1.8: its tag was cut 43 seconds before the commit with the escaping, so the tag compare shows it under 6.1.9. We confirmed both points against the released ZIPs rather than the tags.

What we did and did not test

This is a reading of the released code, not an attack on anyone’s shop. We have not requested a file from any live site, and we are not publishing a working request.

Which Phoca Cart versions are affected?

All versions before 6.1.9, on all four branches. Phoca maintains one release line per Joomla version, and only the Joomla 6 line received the fix:

Joomla version	Newest Phoca Cart offered by the updater	Has the download fix?
Joomla 6	6.1.9	Yes
Joomla 5	5.2.4	No
Joomla 4	4.0.13	No
Joomla 3	3.5.8	No

We checked the download function in each of those packages. 5.2.4 and 4.0.13 are identical to 6.1.8, and 3.5.8 has the same empty-token checks. That table comes from Phoca’s update manifest as it stood on release day.

Look twice at the 6.1.8 row, because 6.1.8 was itself a security release. It fixed the price filter cross-site scripting issues (CVE-2026-76564 and CVE-2026-76565) in August, a few days after 6.1.7 fixed the product filter SQL injection. A shop that did everything right this summer is on 6.1.8 today, and it is exposed. Among the Phoca Cart installs we can see, roughly two in three of the affected ones are on 6.1.8.

Joomla 5 shops have to install Phoca Cart 6.1.9 by hand

This is the same distribution problem we described with the SQL injection in August. Phoca’s update feed offers each Joomla version one release, matched on a targetplatform regex, and Joomla discards any offered version that is not higher than the one installed.

On Joomla 5 that produces two different failures:

A Joomla 5 site on Phoca Cart 6.x is offered 5.2.4, which is lower than what it has. Joomla shows no update at all, and the site looks current while it runs 6.1.8.
A Joomla 5 site on Phoca Cart 5.x below 5.2.4 is offered 5.2.4. That release fixed the August SQL injection and does nothing for this flaw, so a site owner can apply the update in good faith and still be exposed.

Phoca Cart 6.x installs and runs on Joomla 5, so the fix for both is the same: download pkg_phocacart_v6.1.9.zip from the 6.1.9 release and install it through Joomla’s extension installer. Take a backup first, as with any jump across a major version.

Across the Joomla sites we manage, about half of the vulnerable Phoca Cart installs are on Joomla 3, 4 or 5, where the updater will not deliver this fix. Roughly one in ten is on Joomla 3 or 4, where no fixed release exists at all.

An empty update list is not proof you are patched

On Joomla 5, Phoca Cart can show no available update while running a vulnerable version. Check the installed version under System, Manage, Extensions and compare it with 6.1.9 by eye.

What to do about it on each Joomla version

Joomla 6: update Phoca Cart to 6.1.9 through the normal Joomla updater, then confirm the version number.
Joomla 5: install pkg_phocacart_v6.1.9.zip by hand from the GitHub release. Do not take the 5.2.4 the updater offers as a fix for this.
Joomla 3 and Joomla 4: there is no fixed Phoca Cart for your Joomla version, which fits a pattern we covered in the J2Store 3 end-of-life post: Joomla 3 shop extensions stop getting fixes long before their product pages say so. The lasting fix is to move the site to Joomla 5 or 6 and then to Phoca Cart 6.1.9. Until then, if the shop sells downloads, block requests whose task is download.download at your firewall or web server. That stops paying customers downloading too, so send purchased files to buyers another way while it is in place.
On any Joomla version: if the shop sells downloadable products, assume the files may have been copied. Look in your web server logs for download task requests in volume or from addresses that never bought anything, and expect buyers to report download limits already reached.

A shop that sells only physical goods has no order downloads for this flaw to hand out. Update anyway: the code is installed, and a downloadable product added next year would be exposed from the moment it went on sale.

See which of your sites are still on Joomla 3 or 4

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How mySites.guru flags vulnerable Phoca Cart installs

The awkward part of this release is that the Phoca Cart version alone does not tell you what to do. You need the Joomla version beside it, because that decides whether the updater will help, whether you need the package by hand, or whether there is no fix at all.

mySites.guru keeps both for each connected Joomla site. We added this flaw to our vulnerability database on release day, so every site running Phoca Cart below 6.1.9 is flagged on its dashboard now, with the Joomla version on the same screen. The Joomla 6 sites can then go out in one batch with the mass updater, which leaves a short list of Joomla 5 shops for the manual package. That works the same way across a portfolio of Joomla sites of any size, and is part of every subscription.

Why download checks keep failing in shop extensions

An IDOR happens when code checks the wrong thing. The code here knew it had to decide whether this visitor was allowed this file, and it had the right ingredients on hand: the stored tokens were loaded in the same query as the file. It tested whether the visitor had sent something, rather than whether what they sent was right.

It is the same shape as the Events Booking invoice flaw we covered in July, where anyone could download any registrant’s invoice by its id. Paid downloads are where this hurts most, because the file is the product. A leaked order number exposes an address; a leaked download hands over the thing the shop exists to sell, at no cost, as many times as the limits allow. When you review any Joomla shop extension, follow the download path first and look for the comparison against stored data. It is the line that most often turns out to be missing.

Phoca has been quick with fixes this year, with three security releases of Phoca Cart since August. The gap is on the older lines. Of those three, only the August SQL injection fix reached every branch from Joomla 4 up, and this one reached Joomla 6 only. A shop on an older Joomla version gets fewer fixes from each release, and the announcements do not say which lines were left out.

Quix Page Builder 6.3.4 Fixes Guest Access and Editor Code Execution Flaws

phil@mysites.guru (Phil Taylor) — Wed, 30 Sep 2026 16:58:09 GMT

ThemeXpert released Quix Page Builder 6.3.4 on 30 September 2026, and its changelog has a Security section with three entries. A visitor who was not logged in could change Quix settings and read pages restricted by access level. An editor could run code on the server. Text taken from Joomla articles could run scripts on Quix pages. Quix is a Joomla extension, not part of Joomla itself, so this affects only sites that have Quix installed.

This is the fifth Quix security release since the middle of July, and the numbers from the Quix sites mySites.guru monitors say that most of them have not installed any of the other four. If you run Quix anywhere, update to 6.3.4, and read on for why the sites furthest behind need more than one update.

TL;DR

Quix 6.3.4 fixes guest access to Quix settings and restricted pages, code execution by editors, and script injection from Joomla article text. It also hardens pasted images, image resizing and the bundled JMedia media manager
ThemeXpert gives no affected range, no severity and no CVE. Treat every version below 6.3.4 as affected
It is the fifth Quix security release in eleven weeks, after 6.2.1, 6.2.2, 6.2.4 and 6.2.7
Across the Quix sites mySites.guru monitors, more than half are still below 6.2.2, so they also miss the July fix for an unauthenticated SQL injection
mySites.guru flags every connected Joomla site below 6.3.4 from the day of the release

What the Quix 6.3.4 changelog says

The release notes on GitHub and the changelog.xml that Joomla’s update screen links to have the same three security entries, word for word:

“Pages: editors can no longer run code on the server, and guests can no longer change Quix settings or read access-restricted pages.”
“Joomla Content: text from articles, including titles and categories, can no longer run scripts on Quix pages.”
“Media: pasted images, image resizing and the bundled JMedia media manager are hardened.”

The rest of the release is ordinary maintenance: forms displaying on Joomla 4 again, builder errors when JCE is the default editor, and icons now stored on your own site instead of being fetched from getquix.net. One version ships for Joomla 3.10, 4, 5 and 6, so there is no second release line to track.

Read from the changelog, not the code

ThemeXpert’s public GitHub repository holds release notes and update metadata, not source code, and we have not diffed the 6.3.4 package. What follows reads the vendor’s wording for what it means on a site. We have not reproduced the flaws.

What each Quix 6.3.4 fix means for a Joomla site

Guests could change Quix settings and read restricted pages

In Joomla terms a guest is anyone who is not logged in, so this is the entry that matters most: it needed no account. Changing Quix settings from outside is an integrity problem with no obvious ceiling, because the settings decide how Quix loads and renders every page it builds. Reading “access-restricted pages” means a Quix page set to Registered, or to a custom access level for members or clients, could be read by an anonymous visitor.

If you use Joomla access levels to keep Quix pages private (a client area, a members’ price list, a staff page) assume their contents could have been read until the site was updated.

Editors could run code on the server

The changelog does not say which editors, but in a page builder that means an account allowed to build or edit Quix pages, which on most agency sites is more people than just the Super Users. Code execution on the server is the most serious class of flaw a Joomla extension can have, and editor accounts are the ones that get phished or reused.

It is also the second time. The 6.2.1 changelog in July fixed “a code-execution path via the Raw HTML element”, one of the issues we reported to ThemeXpert and tracked as CVE-2026-60026. Whether 6.3.4 closes a different path or a gap in that fix, ThemeXpert does not say.

Joomla article text could run scripts on Quix pages

Quix has elements that pull in Joomla articles, and the changelog says their titles, categories and text reached the Quix page without being escaped. That makes it stored cross-site scripting: whoever can write an article, including a front-end author on a site that allows one, could place a script that runs for every visitor to the Quix page showing that article, and for any administrator who views it while logged in.

Media handling was hardened

“Hardened” is vendor language for something that was not safe enough, with no detail given. It covers pasted images, image resizing and JMedia, the media manager Quix bundles. JMedia had three flaws of its own fixed in July, including a file upload that led to code execution (CVE-2026-60032), so this is another area that has needed work more than once.

Five Quix security releases in eleven weeks

ThemeXpert’s own changelog puts a Security section on five releases since mid-July. Quix 6.2.0, released just before our July report, described itself as a completed full security audit.

Release	Date	What the Security section fixed
6.2.1	15 July 2026	Unauthenticated SQL injection, Raw HTML code execution, form path traversal, icon XSS, media manager permission, JMedia upload and SSRF
6.2.2	16 July 2026	The unsanitised CSS ID and Class fields
6.2.4	26 July 2026	Unauthenticated page creation with a bare CSRF token, missing permission checks on collections, a guessable login cookie
6.2.7	18 August 2026	SQL injection in the Joomla Articles element, unauthorised session and cookie changes, bundled libraries
6.3.4	30 September 2026	Guest access to settings and restricted pages, editor code execution, article text XSS, media

ThemeXpert writes clearer changelogs than most Joomla vendors and names the flaw class in plain words. Read together, though, several of these releases fix the same kind of mistake: who is allowed to do what. Unauthenticated page creation in 6.2.4, unauthorised session changes in 6.2.7 and guest settings changes in 6.3.4 are all permission checks that were missing. A page builder exposes a lot of AJAX endpoints to the front end, and each one is a place to forget a permission check.

How far behind are Quix sites?

Among the Joomla sites in the mySites.guru database that run Quix and took a snapshot in the 30 days to 30 September 2026:

Installed Quix version	Share of sites
Below 6.2.2	52%
6.2.2 to 6.2.6	9%
6.2.7 to 6.3.3	39%

More than half have not installed 6.2.2, which means they still have the unauthenticated SQL injection we reported in July, which lets an anonymous visitor read the site’s database. About half of all Quix sites run Quix 5 or older, and Quix 2.x alone accounts for a third of all Quix sites. All the Security sections in ThemeXpert’s changelog belong to Quix 6 releases, so those sites have to get onto Quix 6 before 6.3.4 means anything to them. Try that on a copy of the site first: a jump of several major versions is not a routine update.

The 39% on 6.2.7 or later are the easy case: one update to 6.3.4 and they are current. The other 61% need 6.3.4 for this release and pick up the July and August fixes in the same step.

Which of your sites need Quix 6.3.4?

mySites.guru records the installed version of every extension on every connected Joomla site twice a day. The Quix rule for versions below 6.3.4 went live on the day of the release, so affected sites are flagged on their dashboards and in their audits, and the Quix page of our vulnerability list shows it alongside the two earlier Quix rules. A site below 6.2.7 is flagged by the older Quix rules instead, whose warnings describe the earlier flaws, and updating it to 6.3.4 clears all of them.

From there, update the flagged sites from one dashboard rather than logging into each administrator in turn, or let automatic extension updates install Quix releases as they come out, which with five security releases in eleven weeks is the setting that would have kept a site current without anyone watching. The vulnerable extension list puts Quix alongside the other flagged extensions on your sites.

What to check after updating Quix

Updating closes the holes. It does not remove anything that got in first. On a site that ran an affected version, work through these:

List the accounts that can build or edit Quix pages and remove any you do not recognise. An unfamiliar Super User is the clearest sign of a successful code execution.
Open Quix’s global options and check them against what you set, because guests could change them.
Look at the compiled page files. In the Quix code we audited in July, pages are compiled to PHP files under media/quixnxt/storage/. A file there that does not belong to one of your pages, or that contains more than template output, needs a closer look.
On a site with front-end authors, check recently edited articles that appear on Quix pages for <script> tags or event handlers in the title or text.

Find Super User accounts you did not create

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

The same audit checks for hacked files and backdoors and PHP files in folders that should only hold media, and real-time alerting tells you when a file changes or an unfamiliar administrator logs in. If you find something you did not put there, treat the site as compromised: our Joomla hacked-site guide sets out the order of work, and fix.mySites.guru will clean it up for a single fixed fee.

What we would like from ThemeXpert

A CVE with an affected range and a severity would let other scanners flag these sites too. Earlier Quix fixes got their CVEs from the Joomla CNA days after release, so these may follow, and we will add them to the rule when they do. Until then, the changelog is all anyone has, and the only safe reading of it is “all versions below 6.3.4”.

If you look after more than a handful of Joomla sites, the Quix history since July is the argument for checking installed versions continuously rather than when a vendor sends an email. See what mySites.guru costs for the number of sites you manage.

AcyMailing Shoots Itself in the Foot With a Vanishing Update Site

phil@mysites.guru (Phil Taylor) — Wed, 30 Sep 2026 16:18:22 GMT

AcyMailing 11.1.0 went out on 24 September 2026 with two security fixes, and two days later the Joomla CNA gave them CVE numbers: CVE-2026-94132, a 9.5 Critical file write through mailbox actions, and CVE-2026-94131, a file deletion rated 8.3 High. We covered both in our 11.1.0 post. Since then a proof-of-concept for the first one has been published on GitHub, so updating is no longer a job for next week.

Update, 7 October: AcyMailing 11.1.1 fixes it

Acyba released AcyMailing 11.1.1 on 5 October. We opened the Starter and Enterprise packages: both now declare the update server in pkg_acymailing.xml, and the install script adds the licence key to the update site Joomla creates instead of deleting and reinserting its own. Joomla’s Rebuild keeps that key, so on 11.1.1 a Rebuild leaves a working update site behind. Two smaller gaps remain, covered in what AcyMailing 11.1.1 changes. A site that has already lost its update site will not hear about 11.1.1, so it needs one last install over the top.

Update, 2 October: reported on Acyba's own forum since 2019

Acyba’s latest reply says the update mechanism “worked as expected for years” and that “until recently it had not been reported to us as a problem”. Its own forum says otherwise: users have reported missing AcyMailing updates and update sites there since July 2019, and in January 2023 two posts said Rebuild had removed every AcyMailing entry. The forum moderators’ answer each time was to reinstall. The threads are listed in reported on Acyba’s forum since 2019 below. Acyba also confirmed the fix will declare the update server in the manifest and ship in the coming days.

Update, 1 October: Acyba promises a fix in the next days

Acyba support has now replied twice. The first reply said its licence system needs to identify the user and that Joomla’s update system cannot do that. Joomla can: download keys and installer plugin events let an extension add licence data to the download request, and to the update request from Joomla 5.3. The second reply, after we pointed that out, says Acyba knew about the problem, has found the documentation, and will release a fixed version “in the next days”. The details are in what Acyba says and what Joomla does below. Until that version is out and installed, the reinstall steps in this post still apply.

A lot of Joomla sites running AcyMailing will not tell you there is anything to update, though. A Joomla developer pointed out on 30 September that a site on 10.11.1 reports itself up to date, and another found that the update sites were gone from every AcyMailing site they looked after. We traced it to a design choice in AcyMailing’s installer, and to the button almost every Joomla guide tells you to press when updates stop appearing.

TL;DR

AcyMailing’s Joomla package declares no update server in its XML manifest. Its install script inserts the update site into the database instead.
Joomla’s Rebuild button in Update Sites deletes every non-core update site and recreates only the ones manifests declare, so it removes AcyMailing’s and cannot put it back.
With no update site, Joomla reports AcyMailing as up to date on any version, including those below 11.1.0.
Across the AcyMailing sites mySites.guru monitors, one in four sites still below 11.1.0 has no AcyMailing update site. On 10.11 it is more than half.
Installing the current package over the top brings the update site back, but every Rebuild deletes it again, over and over, until AcyMailing puts the missing <updateservers> values in its XML manifest.
Acyba confirmed on 1 October that it knows. It says its licence system cannot work through Joomla’s update system and that Rebuild changed recently. Joomla’s source shows both are wrong: the licensing features exist and Acyba has not implemented them, and Rebuild has behaved the same way since 3.6. A second reply the same afternoon promises a fixed version “in the next days”.
On 2 October Acyba said the problem had not been reported until recently. Its own forum has threads about missing AcyMailing update sites going back to July 2019, answered by forum moderators with “reinstall it”.
AcyMailing 11.1.1, released on 5 October, fixes it: the update server is in the manifest and Rebuild keeps the licence key. Sites that already lost their update site still need one reinstall to get there.

Where AcyMailing keeps its Joomla update site

A Joomla extension normally tells Joomla where to look for updates in its XML manifest, in an <updateservers> block. When the extension is installed, Joomla’s own “Extension - Joomla” plugin reads that block and writes the row into #__update_sites. The manifest stays on disk, so Joomla can always rebuild the row from it.

AcyMailing does not do that. We opened all the AcyMailing Joomla packages we could get hold of, from 10.10.2 to 11.1.0, in the Starter, Essential and Enterprise editions, and not one pkg_acymailing.xml or acym.xml contains an <updateservers> element. Instead, the package’s install script, pkg_acymailing.php, does the job itself after every install or update:

// 1 - Clear existing updates on AcyMailing extensions
acym_query('DELETE FROM #__updates WHERE extension_id IN (...)');
// ...deletes every update site linked to AcyMailing's extensions...

// 2 - Add the new update XML
$updateSiteDefinition->location = ACYM_UPDATEME_API_URL
    .'public/updatexml/component?extension=acymailing'
    .'&cms=joomla&version=latest&level=starter&type=package';
$updateSiteId = acym_insertObject('#__update_sites', $updateSiteDefinition);

The paid editions use level=essential or level=enterprise and add the site’s own URL, which is how Acyba ties the download to a licence. The method is the same, apart from the edition name, in all the packages we checked from 10.10.2 to 11.1.0.

The feed itself works: on 30 September 2026 it answered 11.1.0 for all three editions. The weak point is that the only record of where the feed lives is a database row, and no file on disk can recreate it.

How AcyMailing’s update site has changed since 2020

The design is older than 10.10.2. Acyba publishes the AcyMailing component on GitHub, with tags from 6.13.1 in July 2020 onwards, and we diffed the update-site code at each of the 145 tags, then the packages we hold from 10.10.2 to 11.1.0. The address has moved several times. How it is registered has stayed the same: a row inserted from PHP, with no <updateservers> in acym.xml or pkg_acymailing.xml.

AcyMailing version	What changed in the update site
6.13.1 (July 2020)	`addUpdateSite()` in the component’s update helper inserts the row on install, pointing at `acyba.com/index.php?option=com_updateme&ctrl=updatexml` with the edition and version in the query string
6.14.1 (August 2020)	A `nocache` timestamp is added to the address
7.6.2 (November 2021)	Edition and version are fixed when the package is built. Each AcyMailing add-on module and plugin gets its own update site, also inserted from PHP
8.7.0 (August 2023)	The feed moves to `api.acymailing.com/public/updatexml/component?extension=acymailing&cms=joomla&version=latest&level=<edition>`
9.11.0 (December 2024)	The update-site code leaves the component for the package install script, `pkg_acymailing.php`, which is not in the public repository
10.10.2 to 11.1.0 (2026)	One update site, linked to the package, with `&type=package`. Essential and Enterprise add `&website=` and the site’s address

The update address has not included a licence key at any point. The only value that differs from one site to the next is the &website= parameter on the paid editions, and the Starter address is identical on every site, so it could sit in the manifest as it is. We cannot say when &website= arrived: the packages from 9.11.0 to 10.10.1 are not in the repository, and Acyba’s download server returns “The version was not provided or is incorrect” for any version other than the latest.

What Joomla’s Rebuild button does to AcyMailing

Joomla has a Rebuild button in the toolbar of System, Update Sites. It was added in 2016 in joomla-cms #9744, described as rebuilding the update sites “from the manifest files”, and the code in UpdatesitesModel::rebuild() does exactly that on Joomla 4, 5 and 6. It deletes every row from #__update_sites, #__update_sites_extensions and #__updates except Joomla’s own core sites, then walks every extension manifest on disk and recreates an update site for each one that has an <updateservers> block. It never runs an extension’s install script.

For most extensions that is harmless, and it is the standard advice when updates go missing. Admin Tools’ documentation sends you to it, Akeeba’s support desk has recommended it since at least 2017, and our post on Joomla update expiry errors suggests a rebuild and re-check too. For AcyMailing it is the one click that removes the update site for good. The row is deleted, there is no manifest to rebuild it from, and from then on Joomla has no feed to ask about AcyMailing. When Joomla has nothing to ask, the Extensions: Update screen shows no AcyMailing update, and the site looks up to date.

Rebuild is not the only way to lose it: deleting the row by hand in the Update Sites view does the same. What makes Rebuild the common cause is timing: it is the step people take when updates look broken, so it tends to happen on the sites that most need an update.

An update site that exists only in the database is one click from gone

If an extension cannot be rebuilt from its manifest, Joomla’s standard repair is what breaks it.

How many AcyMailing sites have lost their update site?

Across the Joomla sites mySites.guru monitors that ran a snapshot in the 14 days to 30 September 2026, one in eight sites running AcyMailing has no AcyMailing update site at all. The sites to worry about are the ones that need 11.1.0 and cannot see it. About 40% of those AcyMailing sites were still below 11.1.0, and among them one in four had no update site. For those sites the Joomla updater is silent about a 9.5 Critical fix.

Broken down by the installed version, the pattern is hard to miss:

AcyMailing version	Sites with no AcyMailing update site
11.1	5%
11.0	18%
10.11	58%
9.10	6%

The 10.11 figure looks like a bug in that release, but the update-site code in its installer is the same as in 11.1.0. What it shows is a selection effect. Sites that could see updates moved on to 11.0 and 11.1 over the summer. The sites still sitting on 10.11 are, more often than not, the ones whose Joomla stopped hearing about new versions. The older a version looks in your list, the more likely it is that nobody was ever told about the newer one.

How do I get the AcyMailing update site back in Joomla?

Install the current AcyMailing package over the top of the existing install. The package’s install script runs again, clears out any AcyMailing update sites it finds, and inserts a fresh one. Your lists, subscribers, campaigns and settings are untouched, because this is the same process as any normal AcyMailing update, and AcyMailing’s own update guide gives it as the fallback when the updater fails.

Download the edition the site already runs. Starter is free from acymailing.com; Essential and Enterprise packages are in your AcyMailing account under the licence.
In the Joomla administrator, go to System, Install, Extensions and upload the package. Do not uninstall AcyMailing first; an install over the top is all it needs.
Open System, Update Sites and search for AcyMailing. There should be one enabled entry pointing at api.acymailing.com.
If the site is on 11.1.1 or later, you are done and Rebuild is safe again. On anything older, treat Rebuild as off limits. If you have to use it for another extension, reinstall AcyMailing straight afterwards, every time.

Up to 11.1.0, every Rebuild deletes it again

On 11.1.0 and older, reinstalling restores the database row and nothing else. The XML manifest in those versions has no <updateservers> values, so the next Rebuild deletes the update site again, and so will every Rebuild after that. Installing 11.1.1 is the way out: its manifest declares the update server.

Installing 11.1.0 this way also closes the two CVEs, so on a site below 11.1.0 one upload does both jobs. Check any AcyMailing add-ons afterwards: 11.1.0 breaks some older ones with a PHP fatal error.

What mySites.guru sees when Joomla sees nothing

mySites.guru records the installed version of every extension on every connected Joomla site, and compares it with our Joomla vulnerability rules. The AcyMailing rule for versions below 11.1.0 went live on release day. That comparison uses the version number, not Joomla’s update data, so a site with no AcyMailing update site is still flagged as vulnerable on its dashboard and in its audit, even while its own Joomla administrator says there is nothing to do.

What we cannot do for such a site is update it for you. mySites.guru’s one-click updates, bulk updates and automatic extension updates all start from the update Joomla reports, so they need an update site to work from. On a site that has lost it, the vulnerability flag is your warning and the reinstall above is the fix. Once the update site is back, those tools pick AcyMailing up again from the next snapshot.

If you are a subscriber, the AcyMailing extension search lists all your installs grouped by version. A site still showing 10.11 or 11.0 there after this week is worth a closer look. The vulnerable extension list puts it together with every other flagged extension across your sites.

This is the second update-channel failure we have written up today. OrdaSoft fixed a SQL injection and a CVSS 10.0 upload flaw in OS CCK 8.3.16 while its update server kept offering 8.3.14. The two failures differ, and the lesson is the same: a patch that exists does not mean a patch is reaching anyone, so check the installed version, not the update screen.

What Acyba says, and what Joomla does

We wrote to Acyba support on 30 September, copying the Joomla Security Strike Team, and had an answer the next morning. It confirms the cause above and explains the reason. Acyba’s licence system has to identify the customer before it can return a download URL or an expired-licence message, and a manifest URL is the same for everyone. So Acyba has never declared update servers in its XML manifest and writes the update site row, with the licence information in its URL, from the install script. It says Rebuild “recently changed”, or that AcyMailing stopped being compatible with it, and that it is working on a workaround that has to cover Joomla 3 to 6. It asked whether Joomla can add dynamic parameters to the update server URL when it is called.

Joomla already supports what Acyba asked for. We checked the 3.10 and current source trees:

Joomla feature	Since	What it does
`extra_query` on an update site	present in 3.10	Joomla appends it to the package download URL
`<dlid prefix="" suffix=""/>` in the manifest, and the Download Key field	4.0.0	Declares that an extension takes a key and stores it in `extra_query`
`onInstallerBeforePackageDownload`	3.2.3	An installer plugin can change the download URL and headers
`onInstallerBeforeUpdateSiteDownload`	5.3.0	The same, for the request that fetches the update XML
Rebuild preserving `extra_query`	3.9.26	Rebuild backs up each site’s `extra_query` and restores it

That is how other commercial Joomla extensions license their updates: the update feed is declared in the manifest, the customer’s key travels with the download, and the vendor’s server accepts it or refuses it with a message. One limit applies. Before Joomla 5.3 there is no hook on the XML request, so a vendor on older versions cannot change which version is offered per licence, only whether the download is allowed.

Rebuild has not changed in the way Acyba describes. UpdatesitesModel::rebuild() has been marked @since 3.6, it deletes every non-core update site and recreates them from manifests, and the 3.10 code does the same. The only behavioural change to it since is the 3.9.26 one that preserves extra_query; the commits after 4.0 are refactoring, such as database injection and the PSR-12 conversion. The one recent change nearby, joomla-cms #45388 in Joomla 5.3.1, is in the extension plugin rather than Rebuild: it updates an existing row when an extension’s manifest moves its update server, and it only runs for manifests that declare one, so AcyMailing is unaffected. A row that an install script inserts with its own location has always been deleted by a Rebuild, on every Joomla version, which is why AcyMailing sites lose it.

Our reply to Acyba included a short installer plugin that adds a licence key to both requests. We have not run it against a live AcyMailing licence server, so treat it as a sketch of the mechanism.

Acyba answered again that afternoon, and the tone had changed. It thanked us for “the reminder and the explanation”, said it already knew about the problem and had found the documentation, and that it was already working on it. It also said that because AI tools now let anyone produce security reports, more and more of them are being published, which leaves less time for features and bugs that are not security issues. It closed by promising a new version of the plugin “in the next days” with the fix.

We welcome the commitment. The two replies are hard to square, though. The first asked whether Joomla could add the very capability the second says Acyba had already found documented, and a rising number of security reports does not explain an update channel that has relied on a database row since at least 6.13.1 in July 2020. We also do not see a missing update site as competing with “features and bugs” for time. On a site that has lost it, no AcyMailing update reaches the administrator at all, security releases included, and that is a security problem in its own right.

Reported on Acyba’s forum since 2019

Acyba’s third reply, on the morning of 2 October, explained that support relays messages for the developers, and that the development team had settled on declaring the update server in the manifest. It also said this:

Our update mechanism worked as expected for years, and until recently it had not been reported to us as a problem.

Acyba’s own forum at forum.acymailing.com has threads about missing AcyMailing updates and update sites going back more than seven years. We sent six of them back to Acyba on 2 October. A search of all 18,206 posts on the forum then found thirteen more, and all nineteen are below:

Date	Thread	What the user reported	Answer on the forum
22 Jul 2019	Not prompting for me to update my acymailing	AcyMailing Starter 4.4.1 on Joomla 3.9.10: Joomla does not say there is a new version	A forum moderator: answered privately in a support ticket
22 Aug 2019	Update to 6.2.0 doesn’t work	AcyMailing 6.1.4: Find Updates shows no AcyMailing update, and clearing the cache does not help	A forum admin: “Strange that you don’t have any update available”, then download it and install it over the top
12 Nov 2019	acymailing missing from joomla Update Sites	AcyMailing 5.10.4 is missing from Update Sites, with a valid subscription; rebuilding the list did not bring it back	A forum moderator: download the latest version and install it again
11 May 2020	AcyMailing 5 download	AcyMailing 5.8.0: “I have rebuilt the Updates site list and cleared the Extension Manager cache”, still no update	A forum moderator: raise a support ticket
4 Dec 2020	Squeeze page registration takes too long	Starter 5.10.4: no update appears in Joomla, although the AcyMailing update site is enabled	A forum moderator: migrate to AcyMailing 6
9 Feb 2021	Why does AcyMailing not find my license on updates	Licensed sites repeatedly fail to update	A forum moderator: remove the AcyMailing entry from Update Sites and install the package again, which “will properly add new entry”. In 2022, on the same thread: “Joomla Update sites is a feature of Joomla, and we can’t provide support for that part”
29 Mar 2021	How to upgrade from 5.10.19 to 5.10.20	Joomla’s Extension Manager does not show 5.10.20. Told to Rebuild, the user reports “After rebuilding, clear cache and find updates the update did not show up”	A forum moderator: Rebuild, then download the package and install it
26 Apr 2021	Click map	“I was on 7.4 and there was no update notification”	No reply on that point
31 Aug 2021	Mise à jour en boucle du plugin AcyMailing - JCE integration chez Watchful	AcyMailing 7.5.12’s JCE integration plugin “does not contain the line indicating the URL of the update server”, so the site shows no update and Watchful loops; a second and third user see the same	A forum admin: cannot reproduce, open a ticket
6 Jan 2022	Updates not showing up in Joomla updates	Essential, valid licence: updates show neither in Joomla nor in mySites.guru after updating the update sites. A second user: “I think this is a continuing problem. I have that for years already on several Joomla sites”	A forum moderator: open a support ticket
9 Jun 2022	Not getting Joomla update notifications for ACYMailing	No update notifications, no AcyMailing entry in Update Sites, rebuilding changed nothing	A forum moderator: install the latest version manually, or raise a support ticket
17 Jun 2022	Migration of AcyMail failed to Joomla 4	After moving a site to its live domain, the AcyMailing update fails with a licence error naming the old domain	A forum moderator: remove the AcyMailing update sites, “rebuild update sites”, then install the same package again by hand
14 Dec 2022	Bad website URL in licence check	The update URL still names the local domain the site was built on	A forum moderator: “This is not a bug”. The installation “created update sites” which Joomla does not change, so remove them and reinstall
11 Jan 2023	Update Sites Entries	“Tried REBUILD and ALL Acymailing entries have gone - including plugin entries !”	A forum moderator: install AcyMailing again
11 Jan 2023	5 time the Acymailing update site in the Update site list ?	The same user, on AcyMailing 7: Rebuild “worked but removed ALL Acymailing entries”	A forum moderator: install AcyMailing again
7 Jun 2023	Update site missing	Enterprise 8.4: there is no update site for AcyMailing	A forum moderator: update through the Joomla installer
22 Aug 2024	Can we stop with manual updates please	“The JED states that Acymailing uses the Joomla update system however for the last several updates you have required that we download the update”	A forum moderator: “We have made changes to the way the updates are processed”, so 9.7.x and 9.8.0 had to be installed by hand
27 Jan 2025	Unsubscribe link	Enterprise 9.11.1: “I received no update notification in the backend”, with 10.0.0 already released	No reply on that point
27 Dec 2025	Disappearing update site - does anyone else have this issue?	On Joomla 5, “the update site disappears from the update sites list” within 24 hours of a reinstall, and the only solution support offered was to reinstall	No reply

The 2019 and 2020 threads are mostly about AcyMailing 4 and 5, an older product line, so they show the same symptom rather than the same code. From 2021 they are about the current product: 7.4 with no update notification, a 7.5 plugin whose manifest names no update server, licensed 7 and 8 sites, 9.11.1, and the January 2023 threads that name Rebuild as the cause. In 2022 a moderator twice told users to remove the AcyMailing update sites and reinstall, and once to rebuild and then reinstall, which only makes sense if Rebuild cannot restore the entry on its own. The December 2025 post was written by a paying customer who had already been through Acyba’s support desk. Over seven years the answer stayed the same: reinstall, which restores the database row until the next Rebuild deletes it again.

Most answers come from two accounts with the forum’s moderator role, and two more answers come from accounts in its admin group. The forum does not say whether any of them work for Acyba, so we have not described them as staff, although one moderator writes of “our developers” and “our update server”. Either way, the reports were made on Acyba’s own forum, and the 2025 post records the same advice coming from Acyba’s support desk.

The fix belongs in AcyMailing’s Joomla manifest

A <updateservers> block in pkg_acymailing.xml pointing at the Starter feed would let Joomla rebuild a working update site, and the install script could go on replacing it with the licensed URL as it does now. Declaring a download key with <dlid> is the standard way to attach a licence to an update feed without writing to the database by hand. Either change is a few lines, and either would mean Rebuild repairs AcyMailing instead of breaking it.

We wrote that on 30 September. Five days later Acyba shipped the first of those two changes.

What AcyMailing 11.1.1 changes

AcyMailing 11.1.1 came out on 5 October 2026. Its changelog says: “The update system has been changed to better match the Joomla updater intended usage. Information on expired licenses can no longer be displayed in the Joomla updater but rebuilding the update site is now possible.” On 7 October we opened the free Starter package and the Enterprise package and checked them against Joomla 6.1’s source:

pkg_acymailing.xml now has an <updateservers> block pointing at api.acymailing.com/public/updatexml/component?extension=acymailing&cms=joomla&level=<edition>&type=package. The address no longer has version=latest or the site’s own URL in it, so it is the same on every site running that edition.
The delete-then-insert code in the install script is gone. A new function, acym_syncUpdateSite(), finds the update site Joomla created from the manifest by that exact address and writes licenseKey=<your key> into its extra_query. It runs after every install or update and again whenever a licence key is saved in AcyMailing’s configuration, and it removes the old-style AcyMailing update sites left behind by earlier versions.
Joomla appends extra_query to the package download URL, and Acyba’s download server reads it. With no key it answers “The license key was not provided”, and with a made-up one “The license was not found”.
Rebuild backs up each update site’s extra_query by address and restores it when a manifest declares the same address. The address in Acyba’s PHP and the one in its XML are identical, so a Rebuild on 11.1.1 recreates the AcyMailing update site with the licence key still attached.

That is the manifest fix described above, done the way Joomla intends, and it ends the reinstall-after-every-Rebuild routine. Two smaller gaps remain.

There is still no <dlid> element. Joomla only treats an update site as taking a download key when the manifest declares one. Without it, Joomla removes the Download Key field from AcyMailing’s entry in System, Update Sites, and its warning about extensions missing a download key skips AcyMailing. The key can only be entered in AcyMailing’s own configuration. One line, <dlid prefix="licenseKey=" suffix=""/>, matches the format Acyba already writes and would switch both on.
Licence errors come back as HTTP 200. When the key is missing, wrong or expired, the download server answers with status 200 and a line of text where the zip should be. Joomla only rejects a download whose status is not 200, so it saves that text as the package and fails later when it cannot unpack it, and the administrator never sees why. That is presumably what the changelog means by expired-licence information no longer showing in the Joomla updater. With a 401 or 403, Joomla would stop at the download step with “Error connecting to the server: 403”, which at least points at the licence.

Neither gap stops an update reaching a correctly licensed site.

What to do now depends on what the site can see. If Joomla offers 11.1.1, update as normal, and Rebuild is safe from then on. If Joomla says AcyMailing is up to date on anything below 11.1.1, its update site is already gone and it will not hear about this release either, so install 11.1.1 over the top one last time. On Essential and Enterprise, check the licence key is saved on the License tab of AcyMailing’s configuration afterwards, because that is where the update site now gets it from. Check the version number yourself, or let mySites.guru check it for every site you look after.

Timeline

2026-09-24 Acyba releases AcyMailing 11.1.0 Two security fixes are listed under Bug fixes, with no advisory. mySites.guru flags every connected Joomla site below 11.1.0 the same day.
2026-09-26 The Joomla CNA publishes CVE-2026-94132 and CVE-2026-94131 A public proof-of-concept for CVE-2026-94132 appears on GitHub the same evening.
2026-09-30 Joomla developers notice sites that cannot see the update Sites on older AcyMailing versions report themselves up to date. We trace it to update sites that exist only in the database.
2026-09-30 We publish this post and write to Acyba and the Joomla Security Strike Team The email to Acyba support, copied to security@joomla.org, goes out at 17:24 UTC and asks whether Acyba knows about the missing update sites.
2026-10-01 Acyba confirms it knows, and blames Rebuild At 09:42 UTC Acyba support replies that its licence system needs to identify the user, that it therefore inserts update site rows from PHP instead of declaring them in the manifest, and that Rebuild "recently changed". It asks whether Joomla can add dynamic parameters to the update server URL.
2026-10-01 We answer with the Joomla code that already does it Our reply, copied to the Joomla Security Strike Team, points at download keys, the installer plugin events and the Rebuild history, with a plugin example.
2026-10-01 Acyba promises a fix "in the next days" At 13:42 UTC Acyba support replies that it knew about the problem, has found the Joomla documentation and is already working on it. It says AI-assisted security reports are taking time away from other work, and that a new AcyMailing version with the fix will follow in the next days.
2026-10-02 Acyba says the problem had not been reported until recently At 07:51 UTC Acyba support confirms the fix will declare the update server in the manifest and ship in the coming days. It says the update mechanism worked as expected for years and "until recently it had not been reported to us as a problem".
2026-10-02 We send Acyba six of its own forum threads, from 2019 to 2025 Our reply at 08:52 UTC links forum threads reporting missing AcyMailing update sites, two of them saying Rebuild removed the entries, together with the Joomla and AcyMailing version histories in this post.
2026-10-05 Acyba releases AcyMailing 11.1.1 with the update server in the manifest The changelog says the update system now matches "the Joomla updater intended usage" and that "rebuilding the update site is now possible".
2026-10-07 We check the 11.1.1 packages against Joomla's source Starter and Enterprise both declare the update server, and Rebuild keeps the licence key. No download key element yet, and licence errors still come back as HTTP 200.

OS CCK 8.3.16 for Joomla Fixes a No-Login PHP Upload and an SQL Injection, but the Updater Still Offers 8.3.14

phil@mysites.guru (Phil Taylor) — Wed, 30 Sep 2026 15:47:57 GMT

OrdaSoft has released OS CCK 8.3.16, and it fixes two security flaws in the Joomla extension, both reachable with no login. The worse one is CVE-2026-102427, which the Joomla CNA scores at the maximum CVSS 10.0: any visitor could upload a file to a site running OS CCK below 8.3.16 and have the server run it as PHP. The other is an SQL injection in the public listing pages, fixed in the same release with no advisory. It got its own record, CVE-2026-102428 (CVSS 9.3 Critical), on 5 October.

The bigger problem is that neither fix will reach most of the sites that need it. OrdaSoft’s own update server still tells Joomla that the current version is the older, vulnerable 8.3.14, so no affected site is offered 8.3.16. It has to be installed by hand.

How mySites.guru flags OS CCK on your Joomla sites

mySites.guru records the exact version of every extension on every connected Joomla site in each snapshot, twice a day. We added both flaws to our Joomla vulnerability database, CVE-2026-102427 the same afternoon its record was published, so any site running OS CCK below 8.3.16 now shows them on its site card and in its audit, with 8.3.16 as the version that resolves them. The flag works from the installed version, so it does not rely on Joomla’s updater, which is the part that is broken here.

The Pro edition installs under the same element, com_os_cck, but numbers its versions differently from the free Light line. A Pro install inside the affected range is flagged. OrdaSoft publishes no Pro changelog, so we cannot tell you which Pro build includes the fixes, and we would rather flag it than guess it safe.

How the OS CCK upload handler let anyone write PHP to a Joomla site

OS CCK lets site owners build custom content types, and those types can have image fields that visitors fill in from the front end. The upload behind those fields is a file called site/uploader.php, reached through the component’s normal routing with task=getContent. The dispatcher just includes the file. There is no login check and no permission check anywhere on that path, so the request works from an anonymous browser.

The handler did try to make sure the upload was an image. It read the file’s first bytes with mime_content_type() and compared the result against the image types in OS CCK’s own MIME table. That is a real content check, better than trusting the browser’s Content-Type header. The problem was the other half. According to the CVE record, the list of allowed file extensions was in the source but commented out, and the saved file’s extension came straight from the filename the attacker sent.

10.0CVSS 4.0

CriticalJoomla CNA · CVE-2026-102427

Anyone can upload a PHP file and run it, with no account on the site.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

No login neededSingle request

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

Put those two facts together and you have the exploit. A polyglot file, one that opens with real GIF or PNG header bytes and has PHP source appended after them, satisfies the content check because its first bytes really are an image. Saved as shell.php, it then goes into a folder under the site’s images directory, and PHP executes anything ending in .php in that folder when a browser asks for it. The CNA’s own summary names that exact technique.

What OrdaSoft changed in the OS CCK 8.3.16 upload handler

We read the 8.3.16 Light package. The upload handler now defines an extension allow-list of jpg, jpeg, png, gif and webp, and rejects any upload whose lower-cased extension is not on it before the file is saved. The magic-byte check is still there, so an upload now has to pass both: look like an image, and be named like one. That pairing is what the OWASP file upload guidance asks for, because each check alone has a known bypass.

One thing did not change. In 8.3.16 the getContent task is still reached with no login and no permission check, and uploads still go to images/com_os_cck<n>/original/ under the web root. That is by design for a front-end form, and with the allow-list back in place it no longer gives an attacker code execution. It does mean anonymous visitors can still put image files on the server, which is relevant if disk space or content moderation is a concern on the site.

The second flaw: a no-login SQL injection in record sorting

A content construction kit exists to show lists of things, and a list needs to be sortable. OS CCK takes the name of the sort column from the request and uses it to build the ORDER BY clause of the query behind the listing. In the releases before 8.3.16 that value went into the query through a filter whose real job is a keyword blacklist, not a column allow-list, which is not enough to stop an ORDER BY injection.

In 8.3.16 the listing code compares the requested sort field against the actual columns of the content type, plus a short list of known sort keys, and falls back to a safe default when it matches none of them. The previous, unrestricted line is still in the file, commented out, one line above its replacement. That is the same fix OrdaSoft shipped days earlier for three other extensions that did get CVEs.

9.3CVSS 4.0

CVE-2026-102428: SQL injection in record sorting

CriticalJoomla CNA

Anyone can read from and write to the site's database through the sort column of a public listing page.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

No login needed1.0.0 to 8.3.15

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The SQL injection had no CVE until 5 October

When 8.3.16 shipped, CVE-2026-102427 covered the upload flaw only, and the sort-order SQL injection had no record, no severity score and no advisory, so trackers keyed on CVE identifiers did not show it. The Joomla CNA published CVE-2026-102428 for it on 5 October 2026. Updating to 8.3.16 fixes both.

Why the fix will not reach most Joomla sites

Joomla extensions update through an update server: the vendor publishes a small XML manifest that names the current version and links to the download, and every site checks it. OrdaSoft’s OS CCK manifest still names version 8.3.14.

Joomla’s updater compares the version in that manifest against the version installed on the site. A site already on 8.3.14 or 8.3.15 is therefore told it is up to date, and 8.3.16 is never offered, even though the download link inside that same manifest now serves the fixed 8.3.16 file. The patch is sitting on OrdaSoft’s server, wired to the update system, and labelled as older than it is. Only a site that happens to be on something below 8.3.14, or an owner who reinstalls by hand, ends up on the fixed release.

So the fix shipped, and the update system that is supposed to deliver it will not. That gap, between a patch existing and a patch arriving, is the reason a version flag across a whole portfolio beats trusting each vendor’s updater to do its job.

Why a content check alone is not enough for Joomla extension uploads

Checking the bytes of an upload answers one question: does the start of this file look like an image? It says nothing about what the server will do with the file once it is saved. On almost every Joomla host, that decision comes from the file’s extension. A .php file under the web root goes to PHP, whatever its first bytes are. PHP ignores leading binary junk and runs the first <?php block it finds.

So the extension is the control that decides whether an upload becomes code, and the content check is a second layer on top. Commenting out the allow-list removed the layer that mattered. OS CCK is the fifth OrdaSoft extension to get a security fix in September after OS Gallery and the Real Estate Manager, Vehicle Manager and Book Library batch, and CVE-2026-102427 credits the same researcher, Ala Arfaoui. OS Gallery’s worst finding was also an upload that trusted the attacker’s filename.

A web server rule that blocks PHP execution inside images would have stopped this class of flaw on any site that had one. Joomla does not ship that rule by default, and most hosts do not add it.

Why a sort parameter keeps becoming an SQL injection in Joomla extensions

Escaping and parameter binding protect a value, the kind of thing that sits inside quotes in a query, like a search term or an ID. They work by making sure an attacker cannot break out of those quotes. A column name in an ORDER BY clause is part of the query’s structure instead: it sits there with no quotes around it, and a prepared statement cannot bind it. There is no quote to escape, so whatever the attacker sends is read as SQL from the first character. A filter that strips or blacklists a few keywords does not change that.

The fix is always the same, and it is the one OS CCK 8.3.16 now applies: compare the requested sort column against a fixed allow-list of the columns the listing is allowed to sort by, and fall back to a default when it matches none. Joomla’s own list models do exactly this with their filter_fields allow-list. The sort direction gets the same treatment, reduced to ASC or DESC and nothing else.

How rare is OS CCK across the sites we monitor?

Rarely used. Only a handful of connected sites in the mySites.guru database run OS CCK at all. That is good news for Joomla sites in general and bad news for the few that run it, because a rarely used extension with no advisory and a broken update path gets little attention. No mailing list will warn its owners, and the Joomla updater tells them they are up to date.

Is CVE-2026-102427 being exploited?

There is no public report of exploitation yet. The CVE is not on CISA’s Known Exploited Vulnerabilities catalogue, and CISA’s assessment attached to the record says exploitation none, automatable yes, technical impact total. The record’s own E:A (attacked) value is the Joomla CNA’s default on every record it publishes, so it should not be read as evidence either way.

Automatable is the part to take seriously. The attack is a single unauthenticated POST to a predictable URL, with a file anyone can build in a text editor. It needs no human in the loop, which is the kind of flaw mass scanners add once a record is public.

Find PHP files hiding in the images folder

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected Joomla site.

Check your site for free

What to do if you run OS CCK on a Joomla site

Install 8.3.16 or later by hand. Download the current package from ordasoft.com, install it over the top in the Joomla extension manager, and check the installed version afterwards. Do not wait for the updater.
If you cannot update today, disable the component in the extension manager. Unpublishing a menu item does not help, because the upload task and the listing pages answer on the component’s own URL.
Search the images folder, and especially any images/com_os_cck*/original/ folders, for .php, .phtml or .phar files. Nothing in a Joomla images folder should be code. If you find one, treat the site as compromised and work through our Joomla hacked-site guide.
Treat the database as potentially read on any site that sat on an affected version: check the Super User and Administrator groups for accounts your team did not create, reset Super User passwords, and rotate the Joomla secret and any API keys or mail credentials stored on the site.

Find Super User accounts you did not create

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

If a site is already showing signs of a break-in and you would rather hand it over, we can fix it for you. If you manage Joomla sites for clients, the free audit shows what mySites.guru finds on your own sites first, and a subscription keeps every connected site checked against flaws like these the day they are published, whether or not the vendor’s updater is working.

Timeline

2026-09-20 The OrdaSoft wave starts with OS Gallery The Joomla CNA publishes four CVEs against OrdaSoft's OS Gallery, including an unauthenticated SQL injection, all fixed in 6.2.7 with no vendor advisory.
2026-09-28 Three more OrdaSoft extensions get six CVEs Real Estate Manager, Vehicle Manager and Book Library each get an unauthenticated SQL injection in their listing sort order, plus a reflected XSS. Same finder, same class of flaw.
2026-09-29 OrdaSoft releases OS CCK 8.3.16 The 8.3.16 Light package restores the upload handler's file-extension allow-list and rewrites the listing sort handling to validate the sort column. There is no advisory.
2026-09-30 The Joomla CNA publishes CVE-2026-102427 The record covers the upload flaw, scores it CVSS 4.0 10.0 Critical and credits Ala Arfaoui. OrdaSoft's update stream still advertises 8.3.14, and mySites.guru flags every connected site running OS CCK below 8.3.16.
2026-10-05 The SQL injection gets CVE-2026-102428 The Joomla CNA publishes a second OS CCK record for the no-login sort-order SQL injection, CVSS 4.0 9.3 Critical, versions 1.0.0 to 8.3.15. Both flaws are fixed in 8.3.16.

JCTables for Joomla: Unauthenticated SQL Injection Fixed in 1.21.1

phil@mysites.guru (Phil Taylor) — Wed, 30 Sep 2026 15:23:29 GMT

TL;DR

CVE-2026-76570 is an unauthenticated SQL injection in JCTables, JoomCode’s datatables component for Joomla. The Joomla CNA published it on 30 September 2026 and scored it 10.0 Critical, the top of the scale. Every version before 1.21.1 is affected, and the fix is 1.21.1.

No login is needed, and the injection works in write queries as well as reads, so an anonymous visitor can change rows in the database as well as copy them. VulnCheck’s write-up takes that as far as running code on the server. Update to 1.21.1.

10.0CVSS 4.0

CVE-2026-76570Unauthenticated SQL injection in read and write queries

CriticalJoomla CNA

Any visitor can read any table in the Joomla database and change any row, which is enough to take over an administrator account.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A/AU:Y

No login neededRead and writeAll versions before 1.21.1

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

What went wrong in the JCTables front-end controller

JCTables lets a site show database tables to visitors and, if the site owner allows it, lets them edit cells inline. That editing runs through a front-end controller reached at index.php?option=com_jctables&task=.... Before 1.21.1, that controller checked neither who the visitor was nor Joomla’s form token, on any of its tasks. The CVE record describes it as a “CRUD API controller” that “performs no Joomla token validation and no authentication check on any task.”

The queries behind those tasks made it worse. According to VulnCheck’s analysis, the tasks that update cells, delete rows, insert and update records, save forms and fetch rows took table names, column names and values straight from the request. And the helper meant to escape those values, ladb_escape(), returned anything already wrapped in quote marks unchanged, on the theory that it must be escaped already.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

The write half is what earns the 10.0. A read-only SQL injection gives an attacker a copy of your data. This one also lets them change it, including the administrator account’s password hash. VulnCheck showed the full chain in a lab: rewrite an administrator’s credentials, log in to the back end, install an extension, and run code as the web server.

That last step needs the Joomla administrator login page to be reachable, which it is on most sites. Changing the database needs no login at all.

What changed in JCTables 1.21.1

VulnCheck lists what JoomCode changed:

Each write task now checks Joomla’s form token with Session::checkToken(), so the component rejects a request that did not come from the site’s own form.
ladb_escape() now quotes the value through the database driver instead of trusting input that arrives already quoted. That is the pattern OWASP recommends: escape or bind each value instead of guessing which ones are already safe.
Row reads are limited to tables the administrator has configured, instead of whatever table the request names.

JoomCode shipped the fix eight days after the report: VulnCheck reported it on 28 July 2026 and 1.21.1 was released on 5 August. That is a fast turnaround by any vendor’s standard.

The JCTables fix was out for eight weeks before the CVE

The CVE arrived on 30 September, eight weeks after 1.21.1. For most site owners the CVE is the signal, because it is what scanners, alerts and news feeds pick up. So the eight weeks in between were a window in which the fix existed and few site owners had a reason to install it.

Our data shows how that played out. On the day the CVE was published, roughly seven in eight JCTables installs across the Joomla sites we monitor were still on an affected version. Only about one in eight had moved to 1.21.1. Of the affected installs, more than two in three are on the older 1.10.x builds, not the 1.20.0 release just before the fix.

We see this pattern with most extension disclosures. The same thing happened with YouTube Gallery on 26 September 2026, where the fix sat in a public repository for two months before its CVE. When an extension update ships, the safest assumption is that it might be a security fix, whether or not anyone has said so yet.

Is my Joomla site affected by CVE-2026-76570?

If a Joomla site has JCTables installed at any version below 1.21.1, yes. That covers the 1.20.0 release, every 1.10.x build, and anything older. In Joomla it appears as “JCTables” or “JC Tables”, with the element com_jctables and the author JoomCode.

A rarely used extension

JCTables is a niche component. Only a handful of the Joomla sites connected to mySites.guru have it installed, so most site owners reading this will not be affected. If yours is one of them, the steps below still apply today.

The flaw is in the component. JoomCode also ships a “Content - JCTables” plugin that embeds tables in articles; the CVE does not name it, and the fix is in the component package. JoomCode’s free download is com_jctables_1.21.1_free.zip. Pro subscribers get their package from the same page after logging in.

Pro users: check the version number after updating

The CVE and VulnCheck’s analysis describe the free edition, and the CNA’s affected range does not split the editions. Rather than assume the Pro build is different, check that the JCTables component on each site reads 1.21.1 or later after you update.

What you should do right now

Update JCTables to 1.21.1 on every Joomla site that has it, from JoomCode’s download page or through Joomla’s updater.
Check the version afterwards. In System, Manage, Extensions, the JCTables component should read 1.21.1.
If you cannot update today, disable the JCTables component until you can. That removes the vulnerable controller.
Assume the database may have been read or changed if an affected version was live. Change every administrator password, and our guide to checking Joomla database security covers what else to review.
Look for administrator accounts you did not create, or existing ones that changed. This flaw can write to the users table, so a new or altered super user is the first thing to rule out. Our walkthrough on finding rogue admin accounts in Joomla shows what to look for.
If the component is no longer used, uninstall it. An extension no one uses still answers requests from anyone who finds it.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How mySites.guru finds every JCTables install

The hard part of any extension vulnerability is knowing which of your sites run it, and at what version. mySites.guru keeps a live inventory of the extensions on each connected Joomla site, so one search for JCTables lists the sites that have it installed and the version each one runs.

We added CVE-2026-76570 to our vulnerability database on the day it was published, so every connected site below 1.21.1 is flagged on its dashboard now, without anyone having to go looking. The mass updater then pushes the update to all of them from one screen. That is part of the subscription, and it works the same way across a portfolio of Joomla sites of any size.

Why Joomla data-table extensions are a high-value target

A datatables component exists to put database rows on a web page, and JCTables goes further than most: its own listing promises master-detail tables, inline editing and connections to external databases. That is a component whose job is building queries from what the page asks for. When that path is open to anonymous visitors, the distance from “a page with a table on it” to “the whole database” is very short.

It is the same class of problem we keep finding in front-end endpoints across Joomla extensions: code written on the assumption that only the extension’s own JavaScript will ever call it. An attacker does not use the extension’s JavaScript. They call the endpoint directly. Listing and table components keep turning up for this reason: the three OrdaSoft extensions with SQL injections in their sort order, published on 28 September 2026, built part of their queries from the request in much the same way.

If a site has already been hit, or you would rather someone else cleaned it up, fix.mySites.guru patches the site, audits it for backdoors and returns it to you for a single fixed fee. Our Joomla hacked guide covers what to check yourself.

Disclosure and credit

We did not find this flaw, and it is one of a long run of Joomla extension security issues this year, several of them from researchers auditing the same extensions we are. The CVE record credits Valentin Lobstein (Chocapikk) as the finder, and VulnCheck published the technical write-up the same day the Joomla CNA published the record, 30 September 2026. VulnCheck reports no evidence of exploitation in the wild, and the flaw is not on CISA’s Known Exploited Vulnerabilities list as of the date of this post. The fix is JCTables 1.21.1.

Joomla 5.4.9 and 6.1.4 Fix 16 Security Issues, Two Rated High

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 16:26:03 GMT

The Joomla project released Joomla 5.4.9 and 6.1.4 on 29 September 2026, and both fix the same sixteen core security issues, CVE-2026-90906 to CVE-2026-92232. Two are rated High by the Joomla Security Strike Team: a cache purge that can delete any directory the web server can write to, and server-side request forgery through URL fields in several core extensions. The rest are seven cross-site scripting fixes, six access control fixes and an MFA bypass through Remember Me cookies.

The advisories give a title, a severity and a version range, and not much else. Who can actually reach each flaw decides the order you patch in far more than the severity label does, so we traced every fix back to its entry point. The two High issues both need a backend login. One of the Moderate ones needs nothing at all.

What to do now

Update Joomla 5 sites to 5.4.9 and Joomla 6 sites to 6.1.4. Joomla 4 sites must go to 4.4 before 5.4.9, and 5.x sites must be on 5.4 before 6.1.4. Five of these flaws reach back to Joomla 1.5 or 3.0, and Joomla 3 gets no fix from the Joomla project. The 6.2.0 betas did not have the fixes at release time.

TL;DR

16 core fixes in one release, all credited to outside researchers, none to us
High: arbitrary directory deletion through System, Clear Cache (CVE-2026-90915) and SSRF through feed and request URLs (CVE-2026-92222). Both need a backend account
Reachable anonymously on every site: CVE-2026-90907 lets a visitor create a Guest account with registration switched off, back to Joomla 1.5
MFA bypass (CVE-2026-92227) needs the password, then uses a Remember Me cookie to skip the second factor on later front-end logins
Five issues reach Joomla 3, where about one in four of the Joomla sites in the mySites.guru database still run
The Template Manager bug from 5.4.8 and 6.1.3 is fixed in this release too
Known issue on 5.4.9: editing items through the Joomla API fails with a fatal error. A one-line workaround is below, and 6.1.4 is not affected

All Sixteen Joomla Security Issues in One Table

The Joomla Security Centre published all sixteen advisories about an hour after the release. Every one is fixed in 5.4.9 and 6.1.4. The “Who can reach it” column is our reading of the code, not something the advisories state, and it assumes Joomla’s default permissions.

CVE	Severity	Issue	Affected from	Who can reach it	Reported by
CVE-2026-90915	High	Arbitrary directory deletion via cache purge	4.0.0	Administrator	Aria Akhavan
CVE-2026-92222	High	SSRF in several core extensions	3.0.0	Manager and up	Aria Akhavan
CVE-2026-90907	Moderate	Account creation via profile.save	1.5.0	Anyone	Adithyan P
CVE-2026-92227	Moderate	MFA bypass through Remember Me cookies	4.0.0	Password holder	Google and Ada Logics, Mukul Goyal
CVE-2026-90917	Moderate	Tagged items shown from restricted categories	4.0.0	Anyone	Sabuhi Mammadov
CVE-2026-90918	Moderate	XSS in HTML mail templates	4.0.0	Anyone, if HTML mail is on	Joe Grey
CVE-2026-92231	Moderate	InputFilter bypass via HTML5 entities	1.5.0	Filtered content authors	Netanel Stern
CVE-2026-92232	Moderate	InputFilter bypass via whitespace in data URIs	1.5.0	Filtered content authors	not stated
CVE-2026-90906	Moderate	XSS in `HTMLHelper::link`	1.5.0	Depends on the caller	Demyanchuk V.
CVE-2026-90914	Moderate	XSS in audio and video layouts	4.0.0	Content editors	Aria Akhavan
CVE-2026-92224	Moderate	XSS in link toolbar layout	4.0.0	Depends on the caller	Google and Ada Logics
CVE-2026-92225	Moderate	XSS in the module list	4.0.0	Module editors	Google and Ada Logics
CVE-2026-92223	Moderate	Workflow stage change without permission	5.0.0	Backend editors, if Workflows are on	Faceless
CVE-2026-90913	Moderate	Access level changes through the API	4.0.0	API users below Super User	sec-reex
CVE-2026-92226	Moderate	API edits ignoring item permissions	4.0.0	API users below Super User	Google and Ada Logics
CVE-2026-90916	Low	Content history compare shows other items	4.0.0	Anyone who edits content	Arkadiusz

The CVE records themselves had not been published at cve.org when this was written, so the advisories are the authoritative source for now.

Patching Joomla 5.4.9 and 6.1.4 Across a Client Portfolio

On one site this is a single click. Across a portfolio, the first job is working out which sites need which path, and the numbers from the Joomla sites in the mySites.guru database, taken minutes after the release, show where the work is.

73.1%

of Joomla sites run a version this release fixes

every 4.x, 5.x below 5.4.9, 6.x below 6.1.4

26.0%

are on Joomla 3

five of the sixteen flaws reach them, with no fix

90.6%

of Joomla 5 and 6 sites reached the previous release

six weeks after 5.4.8 and 6.1.3 shipped

Joomla sites in the mySites.guru database that reported in during the 30 days to 29 September 2026.

That last figure is the encouraging one. Nine in ten Joomla 5 and 6 sites in the mySites.guru database were on the latest release six weeks after it came out, so most people managing them do update. The remaining one in ten is where incidents come from, and those sites are rarely left behind on purpose: the site on a different host, the one whose update stalled during download, the client who has their own admin login and clicked “later”.

mySites.guru’s Joomla version check flags each connected site behind the latest release in its branch, so all your 5.4.8 and 6.1.3 sites are now flagged. You can manage multiple Joomla sites from that one list and run the core update on all of them in one pass. The guide on mass upgrading Joomla and WordPress sites from one dashboard shows the click path, and the opt-in update queue runs one update at a time per server so a shared host is not hit by thirty at once.

Joomla CMS Version Must Be Up-to-date

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

Some sites will update themselves. Joomla 5.4 and later can take automated core updates from the Joomla project’s own free update service, which is on by default for new 5.4 and 6.x installs and off for sites upgraded from older versions. That is a Joomla feature rather than a mySites.guru one, and a site where it is off, or which cannot reach the update server, stays where it is. Check the version each site actually reports rather than assuming.

Two upgrade-path rules from the release notes catch people out. Joomla 5.4.9 needs 4.4 as its starting point, so a Joomla 4.3 site goes to 4.4 first. Joomla 6.1.4 needs 5.4, so a 5.3 site goes to 5.4.9 before it goes anywhere near 6. Both releases also add one database column (#__updates.security, explained below), so take a backup first. A site that fails at the database step is much easier to put back from a backup than to repair.

The Joomla Flaw That Reaches Every Site: Account Creation With Registration Off

We would patch for CVE-2026-90907, first, ahead of both High issues. It is rated Moderate, but it needs no login and no special configuration, and it reaches back to Joomla 1.5.

The front-end profile form saves through a profile.save task in com_users. Before this release, that task checked the form token and nothing else. A visitor who was not logged in has a user id of zero, so the save ran against a new, empty user: Joomla bound the posted name, username, email and password, put the account in the configured guest group (Guest, by default), and saved it. The Allow User Registration setting is never consulted on that path. The fix is three lines in ProfileController::save() that refuse the request if the user is a guest.

On a default site, what an attacker gets is limited:

The account is in the Guest group, which has no front-end login permission by default, so it cannot sign in
It is not blocked, and the attacker chose its password, so it becomes a working login the moment someone grants Guest more rights or points the guest group somewhere else
It exists. It can hold an email address or username so the real person cannot register with it
User plugins run for it. A CRM sync, a newsletter auto-subscribe or a community profile plugin that acts on onUserAfterSave fires for every account created this way

The practical clean-up is to sort Users by registration date on sites where registration is switched off and look at anything in the Guest group you do not recognise. mySites.guru’s user registration check tells you which sites have registration on, and managing users across every site makes the review a single search rather than an admin login per site. For accounts with real rights, the rogue administrator detection is the check to run.

The Two High-Severity Joomla Issues

Both High issues need a backend account, which is why the JSST rates their probability Low. The impact is what earns them High.

Deleting directories through the cache purge (CVE-2026-90915)

System, Clear Cache sends the names of the cache groups to delete, and the file cache handler joined each name onto the cache folder path and deleted the result. Its safety check only confirmed the path started with the cache folder. It never resolved .., so a group name like ../../images passed the check and deleted the images folder, and so on up to anything the web server user can write to.

The request has a CSRF token, so it cannot be triggered by a link. The people who can send it are those with access to Clear Cache, which by default is the Administrator and Super User groups. The concern is an Administrator, or anyone a site builder has given cache access, being able to destroy the whole site’s files, which is far beyond what that role should allow. It only applies with the file cache handler, which is Joomla’s default. The fix routes every cache path through Path::check(), which resolves the path and refuses anything outside the cache folder.

Server-side request forgery through URL fields (CVE-2026-92222)

Joomla’s URL validation rule accepts over twenty schemes when a form field does not name its own list: file, gopher, ldap, ftp and more alongside http and https. Most URL fields only store a link, but four make the server fetch whatever URL they hold:

News Feeds items, reachable by Manager and up, the lowest-privileged route
The Feed Display module, site and administrator versions, reachable by anyone who can create modules
The scheduled GET Request task, which also writes the response into the task output, so whoever set it up can read what came back
The custom update source in Joomla Update, Super User only

The fix limits those fields to http and https (plus ftp and ftps for the update source). Our reading of the feed code is that it opened the URL with PHP’s XMLReader before anything else, which would also make local XML files readable through file://; the advisory does not go into that detail. This one reaches back to Joomla 3.0.0, and the Regular Labs Modules Anywhere fix two days earlier used the same Feed module as its route to the server’s files.

The Joomla MFA Bypass Through Remember Me

CVE-2026-92227 is the fourth MFA bypass Joomla has fixed this year, and it needs the password first. Joomla issued the Remember Me cookie the moment the password was accepted, before the MFA prompt appeared. By default, Joomla also skips MFA for logins made by cookie. Put together, someone with a user’s password could tick Remember Me, abandon the MFA screen, and return later in a fresh browser session to be logged in by the cookie without ever entering a second factor.

The fix holds the cookie back until MFA has been passed. It affects front-end logins only, because the administrator login has no Remember Me, and both plugins involved (Authentication - Cookie and System - Remember Me) are enabled by default. The same release also switches the TOTP code comparison to hash_equals() (#48056), so variants like +123456 no longer pass for the real code.

If you are forcing MFA on Super Users across a portfolio, patch first. That post also explains why cookie logins skip MFA by default and how to change that setting, which is sensible with or without this fix.

Force Multi-Factor Authentication For Super Users

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

The Joomla Cross-Site Scripting Fixes

Seven of the sixteen are cross-site scripting, where a value ends up in a page or email without being escaped. How much each one matters depends almost entirely on who can supply the value:

InputFilter, two bypasses (CVE-2026-92231, CVE-2026-92232). This is the filter that cleans HTML from users who are not on No Filtering, which by default includes Authors and Editors. One bypass hid javascript: behind HTML5 entities such as &NewLine;; the other hid a data:text/html link behind a tab character that browsers drop. Both date back to 1.5.0 and follow the two InputFilter fixes in 5.4.6 and 6.1.1. If you let people you do not fully trust write content, these are the XSS fixes that matter
HTML mail templates (CVE-2026-90918). Joomla already marked values like the contact form’s name and message as unsafe, but on sites sending HTML mail they were inserted raw anyway. Visitors could put markup into mail sent to the site owner. The default is plain text, so most sites were not exposed
Audio and video output (CVE-2026-90914). Only the src attribute of the media field’s audio and video output was escaped. The advisory’s range starts at 4.0.0, but the layouts it fixes only exist on Joomla 6, and 5.4.9 changes nothing for it
The module list (CVE-2026-92225). A module position string was printed unescaped into the backend Modules list, so someone who can edit modules could plant script for a Super User who opens the list
HTMLHelper::link and the link toolbar (CVE-2026-90906, CVE-2026-92224). Library helpers that printed URLs unescaped. Whether a site is exploitable depends on some caller, core or third-party, passing a user-influenced URL to them, which is why both are rated Low probability

The Joomla Access Control Fixes

The other six are places where Joomla checked the wrong permission, or checked one and forgot another:

Tagged items (CVE-2026-90917). Tag lists, Popular Tags and Similar Tags checked an article’s own access level but not its category’s. An article left Public inside a Registered-only category showed up for anonymous visitors
Content history compare (CVE-2026-90916, Low). The compare view checked the first version id and not the second, so anyone who can edit one item with history could read old versions of items they cannot open
Workflow stage changes (CVE-2026-92223). The batch stage change set an error when the user lacked permission and then made the change anyway. Workflows are off by default, so only sites that turned them on for Joomla 5 and 6 publishing workflows are affected
The Joomla API (CVE-2026-90913, CVE-2026-92226). API users could create and edit viewing access levels with ordinary user-management rights where the backend requires full admin, and API edits ignored item-level permissions. By default only Super Users can log in to the API, so these matter on sites that have given API access to a lower group for an integration

If nothing on a site uses the API, switching the Joomla API off removes that whole class of problem, and the API tokens you have issued are worth a review whether or not you do.

Disable The Joomla API (Web Services)

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

Joomla 3 Sites Get No Fix

Five of the sixteen reach back to Joomla 1.5.0 or 3.0.0: the anonymous account creation, the SSRF, both InputFilter bypasses and the HTMLHelper::link escaping. Joomla 3 has been end of life since August 2023, so the Joomla project will not patch any of them there.

In the mySites.guru database, 26.0% of Joomla sites that reported in over the last 30 days are still on Joomla 3, roughly one in four. Each of them now has a publicly documented way for an anonymous visitor to create accounts, with the exact file and the three missing lines named in a public diff. The Joomla 3 end-of-life check lists those sites, and what Joomla 3 end of life means for agency retainers covers the options for them.

An unsupported CMS collects known flaws

Each Joomla release like this one adds to the list of documented, unfixed problems on every Joomla 3 site. Nothing about those sites changed today, yet they are less safe than they were yesterday.

Known Issue: Joomla 5.4.9 Breaks API Edits

A few hours after the release, Joomla published a known issues page for 5.4.9. Updating an item through the Joomla API, with a PATCH request to change a banner, a user or an article, now stops with a fatal error.

The cause is the new item permission check in ApiController::allowEdit(), part of the fix for API edits ignoring item permissions. It calls InflectorFactory, but the use statement that imports the class was lost when the fixes were ported to the 5.x branch, so PHP cannot find it. The 6.1.4 copy of the file has the import, which is why only 5.4.9 is affected. The fix is #48527, merged the same evening and due in 5.4.10.

If an integration writes to a 5.4.9 site through the API, add this line with the other use statements near the top of libraries/src/MVC/Controller/ApiController.php:

use Doctrine\Inflector\InflectorFactory;

That is exactly what #48527 adds, so 5.4.10 will overwrite the file with the same fix. Reading items through the API still works, and a site where nothing uses the API never touches this code, so neither is a reason to hold back 5.4.9 and its sixteen security fixes. If the API on a site is switched on but nothing uses it, this is a good moment to switch it off.

Other Changes in Joomla 5.4.9 and 6.1.4

The Template Manager is fixed

The Template Manager bug that 5.4.8 and 6.1.3 introduced, where creating an override or a new template folder failed with “Snooping out of bounds”, is fixed in both releases by #48274. Two other Template Manager fixes in the same release also changed TemplateModel.php, so the file that ships is not identical to the replacement Joomla published as a known issue, or to the one our fix tool installed. The update overwrites either, which is what you want.

Extensions can now mark a security release

#48233 lets an extension’s update feed flag an update with a <security> level from 0 (None) to 4 (Critical). Joomla stores the highest level among all updates newer than the installed version in the new #__updates.security column, and System, Update, Extensions shows a “Security release level” badge. That is the database change in this release. It only helps once extension developers start sending the flag, but it is the first time core Joomla has had a way to tell you an extension update is a security fix rather than a feature release. Extension developers can find the XML, the edge cases and screenshots in our developer guide to the security flag.

Smaller changes in this release

POWCaptcha no longer uses a CSRF token for its challenge on 6.1 (#48304), because page caching served one visitor’s token to the next and broke the captcha
Banner tracks CSV export escapes names that start with =, +, - or @ (#48047), closing a spreadsheet formula injection
Tagged articles stop creating a duplicate #__ucm_content row on every save (#48221)
Bundled libraries: joomla/filter is updated for the InputFilter fixes, joomla/filesystem moves to a public release containing the SHTML upload fix from 5.4.8, and joomla/registry and paragonie/sodium_compat get point releases

Joomla 6.2 beta sites

The 6.2.0 betas and the 6.2 development branch did not have these fixes when 5.4.9 and 6.1.4 shipped. If you run a 6.2 beta anywhere public, it is exposed until the next beta.

What We Would Do Tonight

Patch sites with front-end logins, MFA users, restricted categories or HTML mail first. Those are the sites where an anonymous visitor or a stolen password can reach something
Patch everything else on Joomla 4, 5 and 6 in one bulk run
Check each site reports 5.4.9 or 6.1.4 from its own files, and chase the ones that did not move
On 5.4.9 sites where an integration edits content through the API, apply the one-line workaround until 5.4.10
On sites with registration off, look for Guest accounts created before the update
Put a date on the Joomla 3 sites. They will not get this fix or the next one

Previous releases in this series: 5.4.6 and 6.1.1 fixed ten issues including two MFA bypasses, and 5.4.7 and 6.1.2 shipped the regression that ignored article options. If you are not yet managing your Joomla sites from one place, the free audit runs the version check on your own sites, and pricing covers everything else the subscription does.

Timeline

2026-07-15 The earliest of the sixteen reports reaches the JSST The content history comparison view issue, CVE-2026-90916. The rest arrive between late July and 10 September.
2026-09-10 Google and Ada Logics report four issues in one day The link toolbar and module list XSS, the webservice edit check and, jointly with Mukul Goyal, the Remember Me MFA bypass.
2026-09-17 Release candidates ship without the security fixes 5.4.9-rc1 and 6.1.4-rc1 contain only the public bug fixes. The security changes went into the final release commits.
2026-09-29 Joomla 5.4.9 and 6.1.4 are released Both at 16:00 UTC, each described as a security release to install as soon as possible.
2026-09-29 All sixteen advisories go up on the Security Centre About an hour after the release, with CVE ids, version ranges and credits.
2026-09-29 API edits found broken on 5.4.9 About an hour after the release, pull request #48527 is opened: a use statement lost while porting the security fixes to 5.x makes every API PATCH request fatal. 6.1.4 is not affected.
2026-09-29 Joomla publishes the 5.4.9 known issue The known issues page goes up at 19:07 UTC with a one-line workaround for libraries/src/MVC/Controller/ApiController.php.
2026-09-29 The fix is merged for 5.4.10 #48527 is merged into the 5.4 branch at 19:36 UTC. It adds the same line as the workaround, so 5.4.10 overwrites a patched file with identical code.

How to Disable the Joomla API (and What Breaks When You Do)

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 12:45:05 GMT

Every Joomla site since 4.0 ships with a second application sitting beside the website and the administrator: the Joomla API, which Joomla’s own screens call Web Services. It lives at /api/, it is switched on by default, and on a fresh Joomla 6.1 install it is eighteen enabled plugins exposing articles, users, configuration, extensions, media and more to anyone who can authenticate. Most Joomla sites have no use for it at all, and still take on the security risk of an interface their owners never asked for.

This guide covers switching the Joomla API off completely, step by step with screenshots from a Joomla 6.1.3 site, and then the harder part: what stops working when you do. The biggest casualty is Joomla’s own Automated Core Updates, which since 5.4 depend on the API to work at all. After that come the nuclear option of deleting the api folder, and the .htaccess, nginx and Cloudflare rules that block /api/ before PHP ever sees the request.

Disabling the API stops Joomla automated core updates

Automated Core Updates are a free service the Joomla project runs for sites on Joomla 5.4 and later: Joomla’s update server calls back to your site on /api/index.php/v1/joomlaupdate/ and installs new core releases without anyone logging in. Disabling the Web Services - Joomlaupdate plugin, blocking /api/ or deleting the api folder all stop that service. Two things are not affected and should not be confused with it: updating Joomla yourself from System, then Joomla under Update in the administrator, and core updates you run from mySites.guru. Neither uses the Joomla API. If you rely on the Joomla project’s service, keep that one plugin and path open, as described below.

What the Joomla API is, and when it arrived

The Joomla API is a separate entry point, api/index.php, that answers requests with JSON:API documents instead of HTML pages. It has no routes of its own. Each route comes from a plugin in the webservices group, so Web Services - Content registers the article endpoints, Web Services - Users registers the user endpoints, and so on. Requests authenticate through a second plugin group, api-authentication, and a user can only log in through it if their group holds the Web Services Login permission (core.login.api).

It was built for Joomla 4. George Wilson’s pull request #23424 merged the first version into the 4.0 branch on 7 March 2019, building on Google Summer of Code webservices work. Token authentication followed in pull request #27021 in March 2020, and Joomla 4.0.0 shipped on 17 August 2021 with sixteen webservices plugins, all enabled.

The plugin count has grown since. Joomla 4.1 added Web Services - Media, and Joomla 5.4 added Web Services - Joomlaupdate for automated updates, which is how a Joomla 6.1 site ends up with eighteen. Plugins added by a core update are installed enabled, and that includes sites where the owner had already switched every other webservices plugin off. The 5.4 update SQL inserted the Joomlaupdate plugin with enabled = 1 regardless, so a site that was fully locked down on 5.3 came out of the 5.4 update with its API partly back on.

Default states on a fresh Joomla 6.1 install, taken from Joomla’s installation SQL:

18 x Web Services plugins: Enabled. Banners, Config, Contact, Content, Installer, Joomlaupdate, Languages, Media, Menus, Messages, Modules, Newsfeeds, Plugins, Privacy, Redirect, Tags, Templates and Users. They are locked core extensions, so they can be disabled but not uninstalled.
API Authentication - Web Services Joomla Token: Enabled. Lets a request log in with an X-Joomla-Token header.
API Authentication - Web Services Basic Auth: Disabled. Would let a request log in with a username and password.
User - Joomla API Token: Enabled. Adds the Joomla API Token tab to user profiles, where tokens are created. Super Users only by default.
Web Services Login permission: Granted to Super Users only in the root permissions.

There is no master switch. The Web Services section of Global Configuration holds only CORS settings, and nothing in ApiApplication checks a global on/off flag. Switching the API off means switching off its plugins.

The Joomla API’s security record so far

For its first eighteen months the Joomla API was quiet. Then came CVE-2023-23752, fixed in Joomla 4.2.8 on 16 February 2023. The API router merged the request’s query string into the route’s own settings, so adding ?public=true to a request told Joomla the route needed no login. /api/index.php/v1/config/application?public=true returned the site’s configuration, including the database username and password in plain text, and the users endpoint returned every username and email address. Every Joomla 4 site from 4.0.0 to 4.2.7 was affected.

It was exploited in the wild within weeks. VulnCheck showed how the leaked credentials turned into code execution, Rapid7 shipped a Metasploit module in April 2023, and CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 8 January 2024. Anyone who had switched off the Web Services plugins was safe, because a disabled plugin has no route to attack.

After that the API was quiet again until 2026, when the Joomla Security Strike Team published thirteen more advisories for core webservice endpoints between March and September:

Joomla core API advisories

Since the API shipped in August 2021

Of them published in 2026

Across five releases, March to September

Fixed for Joomla 4

Every 2026 advisory lists Joomla 4 as affected

Counted from the Joomla Security Centre. Joomla 4 reached end of life on 14 October 2025.

CVE	What was wrong	Fixed in
CVE-2026-21630	SQL injection in the articles endpoint’s ordering	5.4.4 / 6.0.4
CVE-2026-23899	Improper access check in webservice endpoints	5.4.4 / 6.0.4
CVE-2026-35223	Improper access check in the com_config endpoints	5.4.6 / 6.1.1
CVE-2026-40384	Path traversal in the com_media endpoint	5.4.6 / 6.1.1
CVE-2026-48904	Privilege escalation through the com_users endpoints	5.4.6 / 6.1.1
CVE-2026-48947	Media files overwritten without edit permission	5.4.7 / 6.1.2
CVE-2026-48957	Incorrect access control in the com_privacy endpoints	5.4.7 / 6.1.2
CVE-2026-48958	Custom fields created without permission	5.4.7 / 6.1.2
CVE-2026-71574	The API allowed changes the administrator screens block	5.4.8 / 6.1.3
CVE-2026-72531	Fields reachable for components the user cannot access	5.4.8 / 6.1.3
CVE-2026-72532	Categories reachable for components the user cannot access	5.4.8 / 6.1.3
CVE-2026-90913	Access level changes through the API by users below Super User	5.4.9 / 6.1.4
CVE-2026-92226	API edit tasks ignoring item permissions	5.4.9 / 6.1.4

Most of these are permission checks that were missing or weaker than the matching check in the administrator, which is the pattern to expect from a second front door written years after the first. The API reimplements access control for every component it exposes, and each reimplementation is a fresh chance to get it wrong. The two newest are covered in the Joomla 5.4.9 and 6.1.4 security release, and we cover a few of the older ones individually in the Joomla 5.4.6 and 6.1.1 security release and in our look at AJAX and API endpoints as a CMS blind spot.

For a site owner, a site with its webservices plugins disabled was not reachable through any of these fourteen, because a disabled plugin registers no route and the request stops with a 404 before any component code runs. A Joomla 4 site will not receive fixes for the thirteen 2026 flaws, so for the Joomla 4 sites still out there, switching the API off is the only mitigation available short of upgrading off an end-of-life version.

Not yet public.

Does your Joomla site actually use the API?

Almost certainly not. The Joomla API is used by software outside the site, never by the site itself: the administrator, the frontend, the media manager and the Joomla Update screen do not make a single call to /api/. Unless something external was set up on purpose to talk to the site with an API token, the API sits unused, as it does on most brochure sites, club sites and small shops.

The extension ecosystem has been slow to build on it. Five years after Joomla 4.0, the one major vendor we know of that depends on the core API is Akeeba:

Akeeba Backup’s JSON API v3 authenticates with a Joomla API token. Akeeba deprecated the older v2 API and its Secret Word authentication on 26 August 2026 and plans to remove both in Akeeba Backup 11 in October 2027, so remote backup tools that talk to Akeeba Backup will move onto the Joomla API over the next year.
Akeeba Panopticon, the self-hosted site monitor, connects through the Joomla API with a Super User’s token and needs the Web Services - Installer plugin, the token plugins and its own connector plugin enabled.

Beyond Akeeba, a search of public code turns up a handful of extensions shipping their own webservices plugin, among them JoomGallery 4, Phoca Cart, J2Commerce and BwPostman, plus custom work: a mobile app, a headless frontend, or an agency’s integration with a CRM. If you did not build or buy one of those, you do not need the API.

mySites.guru is not on the list. The mySites.guru connector does not use the Joomla API, so everything in this guide can be applied to a connected site without affecting audits, snapshots, backups or updates.

What stops working when you disable the Joomla API?

The site keeps working. Pages render, users log in, editors edit and the administrator behaves as before, because none of it goes near /api/. Four things do stop:

Automated Core Updates on Joomla 5.4 and later. When they are on, your site registers with autoupdate.joomla.org, and Joomla’s update server then calls back into six routes under /api/index.php/v1/joomlaupdate/ to check health, prepare, run and finish an update. Those routes are registered by the Web Services - Joomlaupdate plugin and authenticated by an X-JUpdate-Token header rather than a user login. New 5.4 and 6.x installs have Automated Update switched on; sites upgraded from earlier versions have it off.
Akeeba Backup’s JSON API v3 and Akeeba Panopticon, which both need the API, and Panopticon needs specific plugins enabled. Backups you run through mySites.guru are not on this list: mySites.guru works with every version of Akeeba’s JSON API, so switching the Joomla API off does not break mySites.guru’s backups through Akeeba Backup. Other services that use Akeeba’s JSON API lose that option when Akeeba Backup 11 removes the older API, as explained below.
Any extension that ships its own webservices plugin, if you rely on its remote features.
Anything custom that holds an API token for the site.

The manual update in the administrator (System, then Joomla under Update) is not affected by any of this. It runs in the administrator and does not touch the API.

Keeping automated updates while switching everything else off

The Joomlaupdate routes are declared public and check their own update token, so they do not need the token authentication plugin or any user’s Web Services Login permission. You can disable the other seventeen core webservices plugins and both API authentication plugins, leave Web Services - Joomlaupdate enabled, and automated updates keep working. Every other endpoint answers 404. The firewall rules later in this guide include the matching exception.

If you decide automated updates are not wanted anyway, our guide to disabling Joomla automated upgrades explains the reasons agencies usually give, and how mySites.guru switches the setting off across every connected site.

What changes when Akeeba Backup drops its old JSON API?

Today you can switch the Joomla API off completely and still let outside services drive Akeeba Backup, because Akeeba’s older JSON API v2 and its Secret Word authentication work without Joomla’s API layer. That window is closing. Akeeba deprecated both on 26 August 2026 and plans to remove them in Akeeba Backup 11, scheduled for October 2027. From that release on, the only way for a third party to talk to Akeeba Backup is JSON API v3, and v3 runs through the Joomla API with a Joomla API token.

For a site that uses Akeeba Backup with an outside service that relies on Akeeba’s JSON API, such as a remote backup tool or Akeeba Panopticon, switching the Joomla API off completely will stop being an option once that site is on Akeeba Backup 11. The narrower lockdown in this guide still applies: keep Web Services - Akeeba Backup, the token authentication plugin and the account that holds the token, disable every other webservices plugin, and restrict /api/ at the edge to the addresses of the service that needs it.

mySites.guru works with every version of Akeeba’s JSON API, so nothing changes for mySites.guru backups today. We have also built a new connection layer that lets mySites.guru reach Akeeba Backup without going through Joomla’s API at all, so mySites.guru customers can keep the Joomla API switched off after Akeeba Backup 11 as well.

How to disable the Joomla API step by step

These steps are the same on Joomla 4, 5 and 6. The screenshots are from a Joomla 6.1.3 test site that also has Akeeba Backup installed, which is why a nineteenth webservices plugin appears in the list.

1. Disable every Web Services plugin

Log in to the administrator and go to System, then Plugins under Manage. Click Filter Options and set the type filter (the second dropdown) to webservices. Set the list limit to 50 or All so nothing is hidden on a second page, tick the select-all box in the table header, and click Disable in the toolbar.

Read the confirmation message before moving on. It should say the same number of plugins as the list shows. Joomla skips any plugin that another user has checked out, so on our test site the first attempt reported “18 plugins disabled” out of 19 and left the Akeeba Backup plugin running, with only a small padlock beside its name to explain why. Check it in (System, then Global Check-in) and disable it again.

This is the step that matters most. With the webservices plugins disabled, the API registers no routes, and every request to /api/ stops at the router with 404 Resource not found before any component code runs. It covers third-party webservices plugins too, including ones that register public routes and handle their own authentication (Akeeba’s does, so it can accept its Secret Word).

If you want to keep automated updates, re-enable Web Services - Joomlaupdate alone after this step.

2. Disable the API authentication plugins

Clear the type filter and search the plugin list for API Token. Disable both results: API Authentication - Web Services Joomla Token, which accepts tokens on API requests, and User - Joomla API Token, which adds the token tab to user profiles. Then filter by the api-authentication type and confirm API Authentication - Web Services Basic Auth is disabled, as it is by default.

With step 1 done this is belt and braces, but it means any API token that has ever been issued on the site stops working immediately. That matters if a plugin is re-enabled later by a person, an extension installer or a core update.

3. Turn off Automated Update

Go to System, then Joomla under Update, click Options, open the Automated Updates tab and set Automated Update to No. On a site where it was on, this is the right setting once the API is off: the feature cannot reach the site any more, so core updates are now your job, and the setting should say so. Skip this step if you kept the Joomlaupdate plugin enabled.

4. Check the Web Services Login permission

Go to System, then Global Configuration, and open the Permissions tab. Work through each group and make sure Web Services Login is not Allowed for anything other than Super Users. Joomla only grants it to Super Users by default, but tutorials for setting up integration accounts tell people to grant it to other groups, and it tends to stay granted after the integration is gone.

5. Test it from outside

Request an endpoint from a machine that is not logged in to the site:

curl -s -H 'Accept: application/vnd.api+json' https://example.com/api/index.php/v1/content/articles

A site with the API switched off answers with a 404:

{"errors":[{"title":"Resource not found","code":404}]}

A site with the API still on answers 401 with {"errors":[{"title":"Forbidden"}]}, meaning the route exists and wants a login. A 401 is not a pass.

6. Re-check after every Joomla update

Core updates can add webservices plugins, and new ones are installed enabled. Joomla 4.1 did it with Media, and Joomla 5.4 did it with Joomlaupdate, reopening part of the API on sites that had closed it, with no notice. Filter the plugin list by webservices after each update and disable anything new, or put one of the edge rules below in front of the site so a returning plugin cannot be reached anyway.

Deleting the Joomla api folder: the nuclear option

The blunt alternative is to delete the api folder from the site root. With it gone there is no api/index.php to run, and requests to /api/ fail with a not-found response from the web server. It feels decisive, and for a site that must be closed right now and has no one available to work through the plugin list, it is a reasonable emergency measure. It has four problems as a long-term fix:

Every Joomla update puts it back. The api folder is part of the full update package, and Joomla’s build forces api/index.php into every package as well, so the next core update restores the whole application with no message saying so.
Automated Core Updates stop, exactly as with the plugins, because the callback routes live in the deleted folder.
The System, Discover screen throws an error, because the installer’s discover scan lists api/components and fails when the folder is missing.
Installing a language pack or any component with an API section writes files back into api/, partially restoring the folder with the plugins still enabled.

Nothing in Joomla checks for the folder or warns when it is missing, which cuts both ways: deleting it breaks nothing loudly, and its return goes equally unnoticed. If you use this option, disable the plugins as well, so the folder is harmless when it comes back.

Blocking /api/ with .htaccess or nginx

A server rule stops API requests before Joomla or PHP starts, and core updates leave it in place because Joomla does not overwrite your live .htaccess. It is the right companion to disabling the plugins: the plugins close the API inside Joomla, and the rule means a plugin re-enabled by an update is still unreachable.

On Apache, put the rule in the ## Begin - Custom redirects section of Joomla’s .htaccess, which sits above the core SEF section that rewrites /api/ requests to api/index.php:

## Begin - Custom redirects
#
# Block the Joomla API (Web Services)
RewriteRule ^api/ - [F]
#
## End - Custom redirects

[F] answers 403 Forbidden and stops rewriting. The pattern must match api/ rather than a specific route, because the API is reachable both through the rewrite (/api/v1/...) and directly through /api/index.php/v1/.... If Joomla is installed in a subfolder, the same rule goes in that subfolder’s .htaccess and matches relative to it.

To keep automated updates working, exempt the Joomlaupdate routes:

RewriteCond %{REQUEST_URI} !/v1/joomlaupdate/
RewriteRule ^api/ - [F]

To allow an integration from a known address, add an IP condition:

RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteRule ^api/ - [F]

Behind Cloudflare or another proxy, REMOTE_ADDR is the proxy’s address unless the server restores the visitor’s IP with mod_remoteip, so an IP allowlist in .htaccess needs that set up first. On a server without mod_rewrite, RedirectMatch 403 ^/api/ does the same job through mod_alias.

On nginx, a prefix location with ^~ wins over the usual ~ \.php$ block, so PHP never runs for these requests:

location ^~ /api/ {
    # allow 203.0.113.10;
    deny all;
}

A rule in .htaccess is one layer, and we have argued at length that .htaccess will not stop a Joomla hack on its own. Here it is closing a door you have already locked, which is the job it is good at.

A Cloudflare WAF rule for the Joomla API

If the site sits behind Cloudflare, a custom WAF rule blocks /api/ at the edge, before the request reaches your server at all. Create a new custom rule in the zone’s WAF settings, switch the rule builder to the expression editor, and use:

(starts_with(http.request.uri.path, "/api/"))

Set the action to Block and deploy it. To keep automated updates, exempt the Joomlaupdate routes:

(starts_with(http.request.uri.path, "/api/") and not http.request.uri.path contains "/v1/joomlaupdate/")

To let one integration through, add its addresses to the expression, separated by spaces rather than commas:

(starts_with(http.request.uri.path, "/api/") and not ip.src in {203.0.113.10 198.51.100.0/24})

The free plan allows five custom rules per zone, so one of them spent on /api/ is well spent. starts_with is case-sensitive, which is fine here because Joomla’s API paths are lower case. For a site in a subfolder, change /api/ to /subfolder/api/.

An edge rule only covers traffic that goes through Cloudflare. Anyone who finds the origin server’s real IP address can go around it, which is one more reason the plugins should be off as well.

Which Joomla API lockdown should you use?

Use more than one. Our order of preference, for a site that does not need the API:

Disable the plugins: Always. It is the only method that works inside Joomla, needs no server access and removes every route. Re-check it after each core update.
Cloudflare rule: If the site is on Cloudflare. It stops requests before they cost you anything and cannot be undone by a Joomla update.
.htaccess or nginx rule: If the site is not on Cloudflare, or as well as it. Joomla updates leave it alone, and it blocks anything the plugin list misses.
Delete the api folder: Only as an emergency stopgap, paired with disabled plugins. It lasts until the next core update.

For a site that uses the API for one integration, keep only the plugins that integration needs, restrict /api/ to its IP addresses at the edge, give its token to a dedicated account rather than a person’s, and revoke the token when the integration is retired. For a site that wants automated core updates and nothing else, keep Web Services - Joomlaupdate, disable the rest, and exempt /v1/joomlaupdate/ in your rules.

Where mySites.guru fits

Everything above is a manual job, repeated on every Joomla site you look after, and repeated again after every core update that re-enables a plugin with no warning. mySites.guru turns steps 1 to 4 into one tool: Joomla API (Web Services) Enabled is a read-only check that runs on each connected Joomla 4, 5 or 6 site’s snapshot, and Disable The Joomla 4+ API (Web Services) Layer is the toggle next to it that acts on what the check finds.

The check counts enabled plugins across both the webservices and api-authentication folders (leaving out Joomlaupdate, which is reported on its own), and reads CVE the moment a site is both API-enabled and still on Joomla 4.0.0 to 4.2.7, the versions exposed to CVE-2023-23752. It reads Basic when the weaker Basic Authentication plugin is on, since that accepts a username and password with no MFA step in front of it.
Its Investigate page lists each webservices and api-authentication plugin with a core-or-third-party flag, and the users who currently hold an enabled API token, by id, username and name. It never reads or transmits the token itself, so this is the list you check before assuming no one still has access. If a hack is the reason you are looking, revoking every one of those tokens in a single click is a separate, purpose-built tool, because a password reset does not touch them.
The toggle disables all of those plugins in one click, core and third-party alike, while leaving Web Services - Joomlaupdate running on purpose so automated core updates keep working, then re-counts and reports an error if anything is still on. Flipping it back restores Joomla’s own defaults, the core webservices plugins and Token authentication, not Basic auth or a third-party plugin that happened to be on before. A per-plugin switch on the same page handles the one case the bulk toggle does not, keeping only Joomlaupdate enabled and everything else off.
Run it one site at a time, or from Tools across every Joomla site in the account, so a portfolio-wide lockdown is one click instead of an afternoon in each site’s Plugins manager.

Pair it with the rest of what a mySites.guru subscription does around this:

With automated updates off, patching is back in your hands. mySites.guru shows which sites are behind the current Joomla release and lets you upgrade many Joomla sites from one screen, with a backup taken first. When a release like Joomla 5.4.6 and 6.1.1 fixes a webservice flaw, that view is the list of sites still exposed.
Every snapshot checks whether Joomla’s Automated Update is on, and one toggle switches it off remotely across the sites you choose.
Installed extensions are matched against our Joomla vulnerability database, including the third-party extensions that ship their own webservices plugins.
Privilege escalation flaws such as CVE-2026-48904 end with an extra administrator. mySites.guru flags admin accounts that should not be there, and forced MFA for Super Users protects the logins that do belong.
Sites still on Joomla 4 are flagged as end of life, and those are the ones where switching the API off matters most.

The connector does not use the Joomla API, so none of this depends on /api/ being open. See the plans, or run a free audit on one site to see what it finds.

Timeline

2019-03-07 Web Services merged into the Joomla 4.0 branch George Wilson's pull request #23424 adds api/index.php, the JSON:API output and routes registered by plugins.
2020-03-23 Token authentication added Pull request #27021 brings the Joomla API Token that most integrations now use.
2021-08-17 Joomla 4.0.0 ships with the API switched on The release includes sixteen webservices plugins, all enabled by default.
2023-02-16 Joomla 4.2.8 fixes CVE-2023-23752 Adding ?public=true to an API request skipped authentication and exposed the site configuration, including the database password. JSST advisory.
2023-03-23 CVE-2023-23752 exploited in the wild VulnCheck reports exploitation seen by SANS ISC and GreyNoise, and a Metasploit module follows in April.
2024-01-08 CISA adds CVE-2023-23752 to its Known Exploited Vulnerabilities catalogue Catalogue entry.
2025-10-14 Joomla 5.4 adds Automated Core Updates, built on the API A new Web Services - Joomlaupdate plugin, from pull request #45143, is installed enabled, including on sites that had switched every other webservices plugin off. How it works.
2026-03-31 Two webservice fixes in Joomla 5.4.4 and 6.0.4 An SQL injection in the articles endpoint and an improper access check across webservice endpoints.
2026-08-18 Eleven webservice fixes in five months By Joomla 5.4.8 and 6.1.3 the count for 2026 alone reaches eleven, none of them released for Joomla 4. Every advisory is linked in the table above and listed in the Joomla Security Centre.
2026-09-29 Two more webservice fixes in Joomla 5.4.9 and 6.1.4 CVE-2026-90913 and CVE-2026-92226 bring the count for 2026 to thirteen, both rated Moderate and both listing Joomla 4 as affected.
Not yet public Not yet public
Not yet public Not yet public

How to Revoke Every Joomla API Token After a Hack

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 12:45:05 GMT

You clean up a Joomla hack the right way. Patch the extension that let the attacker in, delete the webshells, force every password to reset, force every session out. A week later the site is hacked again, through a route that makes no sense, because the hole is patched and every password is new.

A Joomla API Token is not a password, so a password reset never touches it. If the attacker created one before you cleaned up, it authenticates against /api/ exactly as it did the day it was issued, and it keeps working until someone specifically revokes it. Joomla has no page listing every token on a site and no button that clears them all, so on a site with more than a handful of users, revoking one specifically almost never happens.

Revoke Every Joomla API Token From mySites.guru in One Click

mySites.guru’s Revoke Every API Token After a Hack tool does in one click what Joomla makes you do one profile at a time. It reads every issued token across every user, the joomlatoken.* rows in #__user_profiles, shows you who holds one, and removes all of them in a single action. Three options sit alongside it:

Revoke every token: Deletes every issued Joomla API Token on the site, across every user, in one action.
Rotate the update key: For sites on Joomla 5.4+ with Automated Core Updates on: writes a new update_token and re-registers the site with autoupdate.joomla.org, so a stolen key stops working.
Switch the API off: Disables the webservices and api-authentication plugins in the same pass, so there is nothing left to authenticate against.
Log everyone out: Ends every #__session row and every remember-me row in #__user_keys, on top of the tokens. Off by default, because it also ends your own session if you reached the site through mySites.guru.

It is a manual tool you run when you need it, not a background check: find it from the tool finder (press Cmd-K, or Ctrl-K on Windows) or from the link on a hacked site’s card, run it once, and every token on that site is gone. It clears a Super User’s token in the same click as an editor’s, because a hack does not care which of them the attacker actually used.

Joomla issues a new token on the user's next save

Revoking deletes the token, and the deleted one never works again. Joomla’s User - Joomla API Token plugin then treats that user as one who never had a token, so the next time the account is saved, from its profile, from Users: Manage or by an extension, Joomla generates a fresh token and switches it on. Every new user in the plugin’s Allowed User Groups (Super Users unless someone changed it) gets one when the account is created, too. Whoever stole the old token cannot use the new one, but it is a working credential again. To keep a user without a working token, save their account once so the Active switch appears on the Joomla API Token tab, set it to No and save again. To stop tokens being issued to a whole group, take it out of Allowed User Groups.

One count is worth knowing before you run it. The token total is read straight from #__user_profiles, so a token belonging to a user account that has since been deleted still counts and still gets removed, but it cannot be named in the holder list, because that list has to join against #__users to show a username. If the two numbers disagree by one or two, that is why, not a bug.

What Is a Joomla API Token?

A Joomla API Token is a per-user credential for Joomla’s REST API, which Joomla’s own screens call Web Services. It is created from that user’s own profile, on a Joomla API Token tab that only appears when the API Authentication - Web Services Joomla Token plugin is enabled and the user is in the Allowed User Groups of the User - Joomla API Token plugin, which is Super Users unless someone changed it. Using the token also needs the Web Services Login permission. A request authenticates with an Authorization: Bearer header, or X-Joomla-Token on servers that strip the Authorization header before PHP sees it.

Nicholas Dionysopoulos built token authentication in pull request #27021 in March 2020, and it shipped live with Joomla 4.0.0 on 17 August 2021.

Joomla never stores the raw token. What sits in #__user_profiles is a seed, and a request is verified with HMAC-SHA256 against the site’s own secret value in configuration.php. That detail is the whole reason a password reset changes nothing: the token is not derived from the user’s password at all. It is a second, independent credential, checked against a site-wide secret rather than anything about the user holding it.

Why Cleanup Usually Skips This Step

Every hack-cleanup checklist says roughly the same thing: change every password, rotate every credential, force every session out. Joomla’s own Security Checklist says it, and so does our own guide to finding rogue admin accounts. None of that is wrong, but “rotate every credential” rarely gets broken down far enough to name a credential that lives outside the password system entirely, which is exactly the shape of gap that leaves a token still working.

The reason is not carelessness. Joomla gives you nowhere to look. There is no screen that lists who holds a token, so checking for one is not a step anyone can act on without opening every profile in turn, and on a site with real editorial staff that is dozens of profiles for a check most people have never heard needs doing at all.

The checklist stops at the technical fix in every case we have seen, too. Whether anyone outside your own team now has to be told what that token could reach is a separate question, and it is the one covered last in this post, not because it matters least.

How Do You Revoke a Joomla API Token by Hand?

Without mySites.guru, revoking a token means working through the user list one profile at a time:

In the administrator, go to Users, then Manage, and open the profile you want to check.
Open the Joomla API Token tab. It only appears for a user in the plugin’s Allowed User Groups, so most ordinary accounts will not show it at all.
Set Active to No to switch the token off, or set Reset to Yes to issue a fresh token and invalidate the old one in the same save. Click Save & Close.
Repeat for every user in the Allowed User Groups. There is no list of who currently holds a token, so working through those accounts one by one is the only way to be sure you have not missed one.
Confirm from outside with the old token:

curl -H "Authorization: Bearer OLDTOKEN" https://example.com/api/index.php/v1/users

A revoked token answers 401. On a site with five editors this is ten minutes. On a client site with forty accounts built up over a decade, it is the step that gets deferred, and then forgotten.

Rotating the site secret is a last resort, not a shortcut

Every token verifies against configuration.php’s secret value, so changing it invalidates every token on the site in one move, without touching a single profile. It is real, and it is not designed as a revocation feature. Joomla core uses the same secret to sign sessions and to encrypt some stored values, but core is not the only thing that might be using it: any third-party extension is free to read secret out of configuration.php for its own encryption, licensing checks or anything else a developer decided to key off it, and there is no registry of which ones do. You cannot know what changing it will break on a given site without auditing every installed extension first, so it can just as easily make things worse as make them better. Reach for it only on a site you are already rebuilding from scratch, never as a routine way to clear tokens.

Is There a Known Vulnerability in the Joomla API Worth Checking For?

Yes, if the site has not been updated recently. CyStack’s research, published in April 2026, found two flaws in Joomla’s core REST API: an SQL injection in the articles endpoint’s ordering parameters (CVE-2026-21630) and a missing access check on the com_config endpoints (CVE-2026-23899) that let an authenticated caller read the site’s secret, the same value every token is checked against. Both affected Joomla 4.0.0 to 5.4.3 and 6.0.0 to 6.0.3, and both were fixed on 31 March 2026, part of the record we keep on the Joomla API’s security history.

If a site was on an affected version when it was hacked, treat every token issued since as suspect. A leaked secret can be used to forge a valid token without ever touching a user’s profile, which is one more reason a revoke has to cover every token rather than just the ones that look unfamiliar.

Not yet public.

Should You Also Switch the Joomla API Off?

If nothing on the site needs it, yes, and it is worth doing alongside a token revoke rather than instead of it. Revoking tokens clears the credential. Switching the API off removes the whole surface those credentials authenticate against, including Basic authentication if it is enabled and any third-party webservices plugin. mySites.guru’s revoke tool has a switch for exactly this, right next to the token revoke, so both happen in the same pass.

What Automated Core Updates Change About This

If the site runs Joomla 5.4 or later with Automated Core Updates switched on, there is a second credential worth handling at the same time: the update_token that authenticates Joomla’s own update server calling back into /api/index.php/v1/joomlaupdate/. It is a different mechanism to a user’s API token, registered with autoupdate.joomla.org rather than issued from a profile, but it lives on the same API surface, and mySites.guru’s revoke tool can rotate it and re-register the site in the same action that clears the tokens. Joomla 4 and Joomla 5.0 to 5.3 have no automated updates, so this step does not apply to them.

Does Revoking Tokens Stop the Site From Being Hacked Again?

No, and nothing here replaces working out how the attacker got in. Removing tokens closes one specific door, a credential a password reset never touches. It does not remove a rogue admin account, a webshell, or the vulnerable extension that let someone in to begin with. Pair it with finding rogue admin accounts across every Joomla site you manage and, for the file side of the cleanup, our guide to cleaning a hacked Joomla or WordPress site. If you would rather hand the whole thing to someone, fix.mysites.guru is a single fixed fee of £120 per incident, usually same day, and non-subscribers get a free month included.

The Step After the Technical Cleanup: Do You Need to Report a Breach?

Every checklist covered so far, ours included until this post, stops at the technical fix: patch the hole, remove the malware, revoke the credentials. None of it asks the other question a hack can raise, which is whether someone outside your team now has to be told.

If there is a reasonable chance an attacker used a live API token to read personal data, usernames, email addresses, order records, anything that identifies a real person, that is very likely a personal data breach under UK GDPR, or the equivalent under the EU GDPR for an EU-established controller, or your own jurisdiction’s data protection law elsewhere. The law does not care how the data was read. An API token pulling the users endpoint for three weeks and a defaced homepage are both a breach if personal data was exposed, and only the second one looks like an incident.

Two duties then run on their own clock, alongside the technical cleanup rather than after it:

Tell your supervisory authority. In the UK that is the Information Commissioner’s Office, and the rule is 72 hours from when you become aware of the breach, not from when the token was first created, unless the breach is unlikely to put anyone’s rights and freedoms at risk.
Tell the people affected, without undue delay, if the breach is likely to result in a high risk to them, for example because what leaked could be used for fraud or identity theft.

Working out whether either duty applies takes evidence the cleanup already produces: when the token was issued, what endpoints it could reach, and how long it went unnoticed. That is one more reason to revoke it and write down what you found in the same sitting, rather than treating the technical fix as the end of the incident. This is not legal advice, and the thresholds differ by jurisdiction, so involve whoever handles data protection for the business, or a solicitor, rather than deciding it alone from a blog post.

Where mySites.guru Fits

Token revocation is a five-minute job on one site and a real, recurring cost across a portfolio, especially since it is the step every generic checklist leaves out. A mySites.guru subscription covers the rest of what a hack response needs from one dashboard:

Rogue Super Admin accounts are flagged on every connected Joomla site automatically, with a one-click delete.
Installed extensions are matched against our Joomla vulnerability database, so the extension that let the attacker in the first time gets flagged before it happens again.
Backups run before every mass change, so a revoke, a Joomla update, or an extension update on a whole portfolio is never a one-way action.
Sites still on an end-of-life Joomla version, where the API’s known flaws have no fix available, are flagged so you know where the risk actually sits.

See the plans, or run a free audit on one site to see what it finds.

How to Revoke Every WordPress Application Password After a Hack

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 12:45:05 GMT

You clean up a hacked WordPress site the right way. Remove the malware, patch the plugin that let it in, change every password, force everyone to log back in. Weeks later something is still pulling data through the REST API, using a credential no one remembers issuing.

Application Passwords are not your login password. They are a separate credential, stored in their own place, and a password reset does not touch them. One created during a compromise keeps authenticating REST API requests exactly as before, right through a cleanup that changed every password on the site and never looked at it.

Revoke Every Application Password From mySites.guru in One Click

mySites.guru’s Revoke Every Application Password After a Hack tool clears every Application Password on a site, across every user, in a single action. It is a manual tool you run when you need it rather than a background check, reached from the tool finder (Cmd-K, or Ctrl-K on Windows) or the link on a hacked site’s card.

Revoke every password: Deletes every user's Application Passwords on the site in one action, not one profile at a time.
The core method runs first: It calls WordPress's own delete_all_application_passwords() for each user, so the standard wp_delete_application_password action still fires and any security plugin still logs it.
Then it checks the raw data: It re-reads each user's usermeta afterwards. If a filter on a compromised site blocked the delete without saying so, it writes an empty value directly and tells you it had to.
Log everyone out: A separate, optional step that ends every session token as well. Off by default, because it also ends your own session if you reached the site through mySites.guru.

That second check matters more here than it would on a clean site. A site that is actively compromised can have a malicious filter on update_user_metadata that reports success while writing nothing, which is exactly the failure mode a normal admin-screen click cannot see. Calling the real WordPress function first means the usual hooks and logging still fire; reading the raw row afterwards means a lie from a compromised filter does not end the story.

The same double-check runs for the logout step: WordPress’s own WP_Session_Tokens::destroy_all() for each user, a raw re-count, and a direct delete of anything still sitting in the sessions table.

What Are WordPress Application Passwords?

Application Passwords are per-user credentials for the WordPress REST API, XML-RPC and WP-CLI, authenticated over standard HTTP Basic Auth without exposing the account’s real login password. WordPress core added them in version 5.6, announced on Make WordPress Core in November 2020 and released that December.

Each one is stored under _application_passwords in that user’s usermeta, as a bcrypt hash alongside a name, a created date, a last-used timestamp and the last IP address that used it, per WordPress’s own documentation. WordPress hashes the password the same way it hashes a login password, but that is where the resemblance to your login credential ends: the two are unrelated values, generated independently, and changing one has no effect on the other.

Why a Password Reset Does Not Touch Them

A password change updates the user_pass column. An Application Password lives entirely in usermeta and is never read or written when user_pass changes, so the two operations simply never meet. Recovery guidance from TrustedLogin makes the same point: reviewing and revoking Application Passwords is a distinct step from a password reset, not a side effect of one.

Most general hack-recovery checklists still lead with “change every password” and leave it there, because that instruction covers the credential people think about first. Application Passwords were built specifically so that automated tools, mobile apps and integrations would not need the account’s real password at all, which is exactly why revoking the real password leaves them completely unaffected.

Those same checklists also stop at the technical fix, every one we have found. Whether anyone outside your own team now has to be told what an Application Password could reach is a separate question, and it gets its own section near the end of this post, not because it matters least.

How Do You Revoke Application Passwords by Hand?

WordPress core already has a revoke button, and it is worth knowing exactly what it covers before assuming it solves this for a whole site:

In wp-admin, go to Users, then All Users, and click Edit on the account you want to check.
Scroll to the Application Passwords section of that user’s profile.
Click Revoke next to a single password to remove just that one, or Revoke All Application Passwords at the bottom of the list to clear every password that user holds.
Repeat for every user on the site. The button only ever acts on the profile you are currently viewing, so there is no way to reach every user’s passwords from one screen.
Confirm from outside with the old credential:

curl -u "username:revoked-app-password" https://example.com/wp-json/wp/v2/users/me

A revoked password answers 401. If you manage sites from the command line, WP-CLI has a per-user equivalent, wp user application-password delete <id> --all, which is faster to run in a loop than clicking through wp-admin but is still a per-user command, not a site-wide one.

Core's Revoke All button is real, and it is scoped to one profile

It is not a missing feature so much as a design choice: Application Passwords live under each user’s own profile because that is where a person manages their own credentials. Nothing in WordPress core was ever built to act on every user’s passwords from a single screen, so a site-wide clean-up step means visiting every profile in turn.

Is There a Site-Wide Revoke in Any Security Plugin?

Not one that revokes every user’s existing Application Passwords in a single click, as far as we have found. Wordfence can disable Application Passwords entirely, which blocks new ones and stops existing ones from authenticating, but that is a different action from clearing them out, and it stays in effect as a standing restriction rather than a one-time cleanup step. If a plugin you use does offer a real site-wide revoke, treat that as a reason to check it works the way this post describes: calling WordPress’s real deletion function first, then verifying the raw data, not just clearing a list on screen.

What About WooCommerce REST API Keys?

Left alone, on purpose. WooCommerce API keys are a separate credential system with their own storage and their own revoke screen under WooCommerce’s settings, distinct from core Application Passwords. mySites.guru’s tool does not touch them, so if a hacked site also runs a WooCommerce store with API keys issued to an integration, revoke those separately, one at a time, from WooCommerce’s own API keys list.

Does Revoking Application Passwords Stop the Site Being Hacked Again?

No. It closes one specific door, a REST API credential that a password reset and a file cleanup both leave standing. It does not remove malware, patch the plugin that let someone in, or clean up an account an attacker planted. Pair it with cleaning up a hacked WordPress or Joomla site and our guide to checking whether your WordPress site is actually hacked if you are still confirming what happened. If you would rather hand the whole thing to someone, fix.mysites.guru is a single fixed fee of £120 per incident, usually same day, and non-subscribers get a free month included.

The Step After the Technical Cleanup: Do You Need to Report a Breach?

Every checklist covered so far, ours included until this post, stops at the technical fix: remove the malware, patch the plugin, revoke the credentials. None of it asks the other question a hack can raise, which is whether someone outside your team now has to be told.

If there is a reasonable chance an attacker used a live Application Password to read personal data through the REST API, customer names, email addresses, order records from a WooCommerce store, anything that identifies a real person, that is very likely a personal data breach under UK GDPR, or the equivalent under the EU GDPR for an EU-established controller, or your own jurisdiction’s data protection law elsewhere. The law does not care that the credential looked legitimate. An Application Password pulling the orders endpoint unnoticed for a month and a defaced homepage are both a breach if personal data was exposed, and only the second one looks like an incident.

Two duties then run on their own clock, alongside the technical cleanup rather than after it:

Tell your supervisory authority. In the UK that is the Information Commissioner’s Office, and the rule is 72 hours from when you become aware of the breach, not from when the password was first created, unless the breach is unlikely to put anyone’s rights and freedoms at risk.
Tell the people affected, without undue delay, if the breach is likely to result in a high risk to them, for example because what leaked could be used for fraud or identity theft.

Working out whether either duty applies takes evidence the cleanup already produces: when the password was created, what it could reach through the REST API, and how long it went unnoticed. That is one more reason to revoke it and write down what you found in the same sitting, rather than treating the technical fix as the end of the incident. This is not legal advice, and the thresholds differ by jurisdiction, so involve whoever handles data protection for the business, or a solicitor, rather than deciding it alone from a blog post.

Where mySites.guru Fits

Checking every user’s Application Passwords by hand does not scale past one or two sites, which is exactly when it stops happening. A mySites.guru subscription covers the rest of a hack response from one dashboard:

The WordPress checks covered in five new checks for WordPress hacks a file scan cannot see find rogue and hidden administrator accounts on every connected site automatically.
Installed plugins and themes are matched against known vulnerabilities, so the entry point that led to the compromise gets flagged before it happens again.
Backups run before any mass change, so revoking credentials or updating a whole portfolio at once is never a one-way action.
Every connected site gets the same post-hack tools, so a response that would mean visiting every user’s profile on every site becomes one action per site instead.

See the plans, or run a free audit on one site to see what it finds.

How to Delete a Site From mySites.guru

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 12:00:50 GMT

You retire a client site, an agency contract ends, or a test install has outlived its purpose, and now it’s sitting in your mySites.guru Sites list doing nothing but taking up a row. Removing it is a short job, but the confirmation screen is built to slow you down first, and most people get a couple of things wrong about what deleting a site does.

Step by step: deleting a site

1. Open the site’s Manage page

From your Sites list, click into the site you want to remove. That takes you to its Manage page, with the row of tabs (Important, Health, Manage, Alert, Activity, Notes) across the top.

2. Open Config, then Advanced

In the top right of that tab bar is a small pill labelled Config, with a gear icon. Click it, then open the Advanced sub-tab (alongside Site Basics and Connection & Security).

3. Find the Danger Zone

On the Advanced sub-tab is a red-bordered Danger Zone section with one option in it: Delete This Site. Click Delete Site.

4. Type the hostname to confirm

This opens a confirmation screen that spells out what’s about to happen: the site, its alerts, monitors, audit history and backups are all removed, permanently. Underneath, it also states what it will not do (more on that below). Type the site’s exact hostname into the field. The red Delete site button stays disabled, greyed out, until what you’ve typed matches.

Once it matches, a checkmark appears and the button goes live.

5. Click Delete site

Click it, and the site is gone immediately. You’re returned to your Sites list with a confirmation that it’s been removed.

What deleting a site does not do

Deleting a site doesn't remove the connector plugin or cancel your subscription

Two assumptions catch people out. First, the connector plugin stays installed on your CMS: removing it is your responsibility, done through your site’s own plugin manager, same as any other plugin. Second, deleting a site has no effect on billing. If you’re on a paid plan, your subscription keeps running exactly as it was.

If you’re closing an account down rather than tidying up one site, delete the sites you want gone first, then cancel your subscription separately. Sites left on your account when you cancel just sit there, disconnected but intact, and that’s on purpose: a lot of customers come back after a break, and leaving sites attached means they don’t have to reconnect everything from scratch. It also stops anyone else claiming that domain on their own account in the meantime.

What actually happens when you click delete

This isn’t a soft delete or a status flag. Every site connected to mySites.guru has its own unique encryption key pair, split between our side and the connector plugin on your server. Deleting the site destroys our half of that pair immediately, so we can’t reach your site again even if we wanted to. Add the same domain back later and it arrives as a brand new site with a brand new connector, with no history, because there’s nothing left on our end to link the two.

On the data side, everything specific to that site (alerts, monitors, audit history and backups) comes off the live service straight away. We keep a one-way cryptographic hash of the domain name, which can’t be reversed back into the domain, purely so we can recognise a previously connected domain if fraud or a legal request ever requires it.

Site won’t connect? There’s a shortcut

If mySites.guru currently can’t reach a site at all, you don’t need to go through Config first. The Sites list itself shows a Delete button directly on that row, right next to Reconnect, and both jump straight to the same confirmation screen. That’s worth knowing if you’re working through a disconnected sites count on your dashboard.

It’s also mySites.guru’s own recommended fix when a connector is permanently dead rather than just misconfigured: the reconnect wizard’s diagnosis leads with Delete this site & install a fresh connector, because a dead connector can’t be fixed by retrying. That’s the same delete-then-reconnect pattern used when migrating a site to a newer connector for Joomla 4, and it comes with the same reminder: delete the site in mySites.guru, then go and remove the old plugin from the site too. One without the other leaves half the job done.

Do I need to remove the connector plugin too?

If you want the site completely clear of mySites.guru, yes. Deleting the site here never touches your server, so the plugin (bfnetwork inside a Joomla plugin, or bundled inside the mywpguru plugin on WordPress) is still sitting in your plugins folder afterwards. It’s inert once the site is deleted, since the encryption key it relies on no longer works, but inert isn’t the same as gone. Remove it the same way you’d remove any other plugin: through Joomla’s Extensions manager or WordPress’s Plugins screen.

If you skip this step, nothing breaks. The plugin just sits there doing nothing until your next spring clean.

Balbooa Forms 2.4.3.4 Fixes Five Security Issues

phil@mysites.guru (Phil Taylor) — Tue, 29 Sep 2026 10:26:24 GMT

Balbooa released Forms 2.4.3.4 on 29 September 2026 and asked every customer to install it as soon as possible. The release note lists five security fixes in the Joomla form builder (com_baforms), and the Joomla CNA published a CVE for each of them the same afternoon. All five are reachable by an anonymous visitor through a public form. The worst, scored CVSS 9.5, is remote code execution through the post-submission PHP action, the same feature behind a CVSS 10.0 CVE in August.

The CVE records put every Balbooa Forms release from 1.0.0 to 2.4.3.3 in range. If your sites run 2.4.3.3, as a large share of Balbooa Forms sites in the mySites.guru database still did on release day, they need this update. So does 2.4.3.2, the version everyone was told to install seven weeks ago.

TL;DR

Update every Balbooa Forms install to 2.4.3.4, then confirm the component reports 2.4.3.4. The flaws were reported by Sergiy Tryzhychynskyi and Łukasz Rybak, and David Jardin of the Joomla Security Strike Team coordinated the disclosure. The Joomla CNA scores the five CVEs from 6.9 to 9.5 and gives the affected range as every version below 2.4.3.4, which is what mySites.guru now flags.

What Balbooa Forms 2.4.3.4 fixes

Balbooa’s release note is a short table. The CVE records the Joomla CNA published later the same day describe each flaw in more detail, and everything below comes from those two sources. We have not diffed 2.4.3.3 against 2.4.3.4 ourselves.

CVE	Severity	What it is	Login needed?
CVE-2026-102425	Critical 9.5	Code injection through field shortcodes in the post-submission PHP action	No, if the form uses a PHP action
CVE-2026-102424	High 8.9	Path traversal that emails server files out through auto-reply attachments	No, if auto-replies attach uploads
CVE-2026-101127	High 8.6	Stored XSS through the uploaded filename, shown to administrators	No
CVE-2026-101112	Medium 6.9	Deletion of any visitor’s attachment via `removeTmpAttachment`	No
CVE-2026-101126	Medium 6.9	Tampering with attachment filenames and references on submission	No

Remote code execution through the PHP action

9.5CVSS 4.0

CVE-2026-102425Unauthenticated RCE via field shortcode injection

Criticalthe Joomla CNA

An anonymous visitor who submits a form set up with a PHP action can run their own PHP on the server. The attack requirement is the form configuration: no PHP action, or no visitor-supplied shortcode inside a double-quoted string, and there is nothing to exploit.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

No login neededForms with a PHP actionFixed in 2.4.3.4

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

Balbooa Forms lets an administrator attach custom PHP to run after a form is submitted, and lets that PHP include field values through shortcodes. According to the CVE record, the component swaps each shortcode for the raw value the visitor typed and then passes the result to eval(). A form whose PHP puts a field shortcode inside a double-quoted string therefore runs whatever a visitor submits in that field.

In August, CVE-2026-67364 showed that a shortcode fed from a URL parameter could inject code into the same PHP, scored 10.0 and fixed in 2.4.3.2. This record is the same feature reached through ordinary form fields, and it puts 2.4.3.2 and 2.4.3.3 in range, so the August fix did not cover it. It only matters on forms where an administrator has set up a PHP action, which is a minority, but on those forms it is a complete takeover.

A path traversal into auto-reply emails

Balbooa Forms can send the person who filled in a form an automatic reply, and those emails can attach the files they uploaded. The CVE record confirms what the vendor’s “LFI protection” wording suggested. The final submission accepts the upload-field state as JSON from the visitor, trusts the filename in it, and joins it to the upload folder without checking the file exists, belongs to them or stays inside that folder. A visitor can submit ../../../../configuration.php as a filename and receive the site’s configuration file, database password included, at the address they typed into the form.

That only applies where a form has auto-reply switched on with uploaded files attached, so many sites are not exposed to it. You cannot tell which forms are set up that way without opening each one, and updating takes less time.

Other visitors’ attachments

Two fixes, CVE-2026-101112 and CVE-2026-101126, concern the files a visitor uploads while filling in a form. Before 2.4.3.4, removeTmpAttachment did not check that the attachment belonged to the person asking to delete it, so anyone could delete temporary or stored attachments from other people’s sessions. The final submission step had the same gap: the attachment references sent with a form were not tied to the session that uploaded them, so an attacker could point a submission at someone else’s file. The session token the form checks stops cross-site requests, but any guest can get a token for their own session, so it authorises nothing. Neither runs code. On a form that collects CVs, ID documents or signed paperwork, though, an attacker could delete or swap what a real applicant sent, and you would find out only when the file you needed was missing or wrong.

Stored XSS through a filename

In CVE-2026-101127, the upload endpoint checks a file’s extension and MIME type but stores the original filename exactly as sent. When an administrator opens the submission, the component’s JavaScript writes that name into the page through innerHTML. A filename is whatever the uploader says it is, so an anonymous visitor can plant script that runs when an administrator opens the submission. Script running in a Super User’s browser can do anything that Super User can, including installing extensions.

Which Balbooa Forms sites are affected?

All five CVE records give the same range: every release from 1.0.0 to 2.4.3.3. mySites.guru flags every Balbooa Forms version below 2.4.3.4 for these five CVEs. Releases below 2.4.3.2 are also flagged for earlier flaws, including CVE-2026-65880 and CVE-2026-67364, both unauthenticated remote code execution scored 10.0, so they are the most exposed. All of them need the same update.

6 in 10

Balbooa Forms installs on 2.4.3.2 or 2.4.3.3

Only this release affects them

1 in 6

Already on 2.4.3.4

The release is hours old

1 in 5

Still below 2.4.3.2

Exposed to the CVSS 10.0 flaws

Share of Balbooa Forms component installs in the mySites.guru database, 29 September 2026.

Most sites that were two or three releases behind in August are now on 2.4.3.3, so their owners do update when told. The worry is the other end: one Balbooa Forms site in five is still on a version with a known unauthenticated remote code execution flaw, several releases after the fix and well after the July zero-day was being exploited.

What to do now

Update Balbooa Forms to 2.4.3.4 on every Joomla site that runs it, through Joomla’s update manager or the mySites.guru mass updater.
Check the version afterwards. Open System, Manage, Extensions and confirm the Balbooa Forms component, not only the package, reads 2.4.3.4.
Look at your forms’ auto-replies. If a form sends attachments in its auto-reply and a site stayed on an older version for a while, consider changing the database password in configuration.php and your hosting control panel, because that is the file a path traversal would go after.
Check for administrator accounts you did not create, since the stored XSS and the older flaws both lead to admin access.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

Still below 2.4.3.2?

Those sites are exposed to the two unauthenticated remote code execution flaws from July and August, not only to this release. Update them first, then check them for PHP files in images/baforms/ and anything else under images/ you do not recognise. The original Balbooa Forms post covers what to look for.

Six Balbooa Forms security releases since July

This is the sixth security-related Balbooa Forms release in under three months:

Version	Date	What it fixed
2.4.1	9 July	Unauthenticated file upload to RCE, CVE-2026-56291, which we found being exploited
2.4.3	28 July	Unauthenticated RCE through the Signature field, CVE-2026-65880
2.4.3.1	31 July	Administrator-area hardening
2.4.3.2	18 August	Released as hardening, then published as CVE-2026-67364 (PHP code injection, 10.0) and CVE-2026-67363 (payment amount tampering)
2.4.3.3	not stated	Balbooa published no security note for this release
2.4.3.4	29 September	The five fixes above

There are two ways to read that list. The pessimistic reading is that a form builder that takes file uploads, runs PHP and handles payments from anonymous visitors has a lot of attack surface, and outside researchers keep finding more of it. The fairer one is that Balbooa ships fixes quickly, credits its reporters, emails its customers and coordinates with the Joomla Security Strike Team. For a site owner both lead to the same place: Balbooa Forms is an extension you keep on the current release all the time, not once a quarter.

Sergiy Tryzhychynskyi was also credited on the August hardening release, and Łukasz Rybak reported the Sourcerer PHP execution flaw in Regular Labs’ extension, so Balbooa Forms now has experienced researchers looking at it.

How do I find every Balbooa Forms site I manage?

The hard part of an extension release is rarely the update. It is knowing which of your sites run the extension and which version each one is on. Past a dozen sites, logging in to each Joomla admin to check is how an install gets missed, and a missed install is how one site in five ends up still exposed to a July flaw at the end of September.

mySites.guru keeps a live inventory of the extensions on each connected Joomla and WordPress site. Search for Balbooa Forms once and you get each site running it with its installed version. The 2.4.3.4 rule is already in our vulnerability database, so every connected site below 2.4.3.4 is flagged on your dashboard now, and the mass updater pushes the update to all of them from one screen.

The same subscription covers the checks that matter after a flaw like this: the audit looks for PHP files in upload folders, new administrator accounts and modified core files on every site, and flags them before a customer notices. It is all part of the subscription, with no add-ons.

If a Balbooa Forms site has already been hit, fix.mySites.guru cleans it, updates it and audits it for backdoors for a single fixed fee, usually the same day.

Severity and CVE status

The Joomla CNA published all five CVE records on 29 September 2026 with CVSS 4.0 scores, and mySites.guru uses them as published: Critical overall, from the 9.5 remote code execution flaw. The two most serious flaws have an attack requirement in their vector (AT:P), because each only works on a form set up a particular way, with a PHP action or with auto-replies that attach uploads. The other three need nothing but a public form with an upload field. The affected range, 1.0.0 to 2.4.3.3, is the one the rule flags.

Credit for the findings goes to Sergiy Tryzhychynskyi and Łukasz Rybak, and to David Jardin of the Joomla Security Strike Team for coordinating, per Balbooa’s release note. We did not find these issues.

Three OrdaSoft Joomla Extensions Have Unauthenticated SQL Injections in Their Sort Order

phil@mysites.guru (Phil Taylor) — Mon, 28 Sep 2026 19:49:04 GMT

Six CVEs published today by the Joomla CNA cover three Joomla extensions from OrdaSoft: Real Estate Manager, Vehicle Manager and Book Library. Each extension has the same pair of flaws. The worse of the two is an SQL injection on the public listing pages that needs no login and scores CVSS 4.0 9.3 Critical, and the other is a reflected cross-site scripting flaw at 5.3 Medium.

If a Joomla site you manage runs any of the three, it needs updating today. Real Estate Manager is fixed in 6.7.9 and Vehicle Manager in 6.5.8. Book Library’s record is less clear about its fix, which the section on versions below explains.

How mySites.guru flags these three extensions

mySites.guru records the exact version of every extension on every connected Joomla site twice a day. When the six records were published we added them to our Joomla vulnerability database, so any connected site running Real Estate Manager below 6.7.9, Vehicle Manager below 6.5.8 or Book Library below 6.4.6 is now flagged on its own site card and in its audit, with the version that resolves it. There is nothing to search for. If the extension is on the site, the flag is already there.

The records name the Free editions of each extension. OrdaSoft’s Pro and ShopPro editions install under the same Joomla element and use the same version numbers, so the flag cannot tell them apart, and a Pro site below the fixed version is flagged too. Updating a Pro install that turns out to have been safe costs you a few minutes. Missing one that was not could cost you the database.

Three extensions let a visitor choose the sort column

All three extensions show lists of things: properties, vehicles, books. All three let the visitor sort those lists, and all three take the name of the sort column from the request and put it into the ORDER BY clause of the query that builds the page. That is the whole flaw, repeated three times with small variations.

Real Estate Manager, CVE-2026-100752

In Real Estate Manager, site/realestatemanager.php builds the ORDER BY clause for three separate front-end queries (category browsing, search results and the full property listing) from the order_field request parameter. The value is concatenated straight into the SQL with no allow-list of real column names and no cast.

9.3CVSS 4.0

CriticalJoomla CNA · CVE-2026-100752

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Vehicle Manager, CVE-2026-101108

Vehicle Manager reads order_field and order_direction at three public entry points in site/vehiclemanager.php: the category listing, search, and the all-vehicles listing. The difference here is that the code does try. It runs both values through a sanitising function that applies real escaping. Escaping does nothing for a value that ends up in an unquoted ORDER BY clause, which the next section explains, so the injection works anyway.

9.3CVSS 4.0

CriticalJoomla CNA · CVE-2026-101108

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Book Library, CVE-2026-101110

Book Library’s books() function in site/booklibrary.php reads the field and direction parameters and passes each through a function called protectInjectionWithoutQuote(). Despite the name, its only real protection is a keyword blacklist, and when it spots the word select it wraps the value in $db->quote() instead of rejecting it. The value then goes into an unquoted ORDER BY clause, where quoting is as useless as escaping.

The record notes two conditions for reaching the vulnerable path: a first request to prime the sort defaults stored in the session, and a trailing SQL comment containing the word select that satisfies the blacklist without changing what the payload does. Neither needs a login, so neither slows an attacker down much.

9.3CVSS 4.0

CriticalJoomla CNA · CVE-2026-101110

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

All three records score the same way: reachable over the network, no privileges, no user interaction, and high impact on the confidentiality, integrity and availability of the data.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

Why escaping cannot protect an ORDER BY clause

If you write Joomla code, or pay someone who does, this mistake turns up in extension after extension.

SQL escaping and parameter binding both protect a value, something the database treats as data, like the text in a search box or the number in an ID. Escaping works by making sure the attacker cannot close the quotes the value sits inside. A column name in ORDER BY is part of the query’s structure rather than a value: it sits in the query with no quotes around it, and a prepared statement cannot bind it as a parameter. There is no quote for the attacker to close, so anything they send is read as SQL from the first character.

That is why Vehicle Manager’s properly escaped sort value and Book Library’s quoted one are both still injectable. The fix for a sort parameter is to compare it against a fixed list of the columns the listing is allowed to sort by, and to fall back to a default when it matches none of them. Joomla’s own list models do exactly this with their filter_fields allow-list. The direction parameter gets the same treatment, reduced to ASC or DESC and nothing else.

The reflected cross-site scripting flaws

The second CVE on each extension is less severe but has the same shape across all three: a title request parameter written back into the page inside a double-quoted HTML attribute with no escaping. A double quote in the parameter closes the attribute, and whatever follows, including a <script> tag, runs in the browser of anyone who opens the crafted link.

In Real Estate Manager (CVE-2026-100753), the “leave a review” form on the public property page fills its title field straight from the request. The comment field next to it gets partial tag-stripping, the title field gets none.
In Vehicle Manager (CVE-2026-101109), the public vehicle page (task=view) echoes the title parameter into an attribute with no output encoding.
In Book Library (CVE-2026-101111), the book page template, site/views/view_book/tmpl/default.php, runs echo $_REQUEST["title"]; inside an attribute.

5.3CVSS 4.0

MediumJoomla CNA · CVE-2026-100753

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

5.3CVSS 4.0

MediumJoomla CNA · CVE-2026-101109

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

5.3CVSS 4.0

MediumJoomla CNA · CVE-2026-101111

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The scores are lower because the victim has to open a link someone sent them. The link points at your own domain, though, which is what makes a phishing email convincing, and if the person who clicks it is logged in to the Joomla administrator, the script runs with their session.

Which versions fix each extension

Extension	Joomla element	Affected	Fixed in
Real Estate Manager	`com_realestatemanager`	1.0.0 to 6.7.8	6.7.9
Vehicle Manager	`com_vehiclemanager`	1.0.0 to 6.5.7	6.5.8
Book Library	`com_booklibrary`	1.0.0 to 6.4.5 or 6.4.6	6.4.6 or the release after it

Real Estate Manager and Vehicle Manager are straightforward: the title and the affected range in each record agree. Book Library’s records do not. Their titles give the fix as ”< 6.4.6”, while their structured affected range runs from 1.0.0 up to and including 6.4.6. One of the two is a typing slip, and there is no vendor changelog to say which.

Book Library: take the newest release

mySites.guru flags Book Library below 6.4.6, which is what the record titles say. If OrdaSoft offers anything newer than 6.4.6, install that instead, so the question of which half of the record is right stops mattering.

What OrdaSoft has published

As far as we can find, OrdaSoft has published no advisory. Its site has no changelog entry, no security page and no mention of any of the six CVE numbers. The only reference in each record is the OrdaSoft home page, and the product pages’ own release lists stop well short of the versions now in circulation. The fixed version numbers in this post come from the CVE records alone.

That matches what happened eight days ago with OS Gallery, another OrdaSoft extension, whose four CVEs also named a fixed release that the vendor did not announce. All six of today’s records credit the same finder as the OS Gallery ones, Ala Arfaoui, and between the two batches the same kind of flaw keeps turning up. If you run other OrdaSoft components, keep a close eye on them.

Update, 30 September 2026: a fourth OrdaSoft extension

OrdaSoft has now shipped the same sort-order fix in OS CCK, a content construction kit for Joomla. This one has no CVE and no advisory at all, and OrdaSoft’s update server still advertises the older, vulnerable version, so affected sites are never offered the fix automatically. The same 8.3.16 release also closed a worse flaw that did get a CVE: CVE-2026-102427, an unauthenticated file upload that runs PHP, scored CVSS 10.0.

What the mySites.guru database shows

These are not common extensions. Only a small number of sites in the mySites.guru database run each one, and on the day the records were published, every install we can see with a readable version number is on an affected release. That is normal on day one of a disclosure, and it is also why a CVE record alone does not get anyone to update, which is why we flag affected sites on the day rather than waiting for owners to notice.

What to do today

Update Real Estate Manager to 6.7.9 or later, Vehicle Manager to 6.5.8 or later, and Book Library to the newest release OrdaSoft offers.
If you cannot update today, disable the component in the Joomla extension manager. The injection is on public pages that answer whether or not a menu item links to them, so unpublishing a menu item does not close it.
Treat the database as read on any site that sat on an affected version: reset Super User passwords, rotate the Joomla secret, and replace any stored API keys or mail credentials.
Check the Super User and Administrator groups for accounts your team did not create.

Find Super User accounts you did not create

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

What to check after the flag

The version flag tells you a site is exposed. It does not tell you whether anyone got there first, and an SQL injection that needs no login is the kind that gets scripted and sprayed at any site that answers the right URL. The useful checks come after the flag.

mySites.guru runs them as part of the subscription, unattended, on every connected site. The rogue admin check lists Super Users added outside the normal flow across your whole account in one view. The malware and file scanners look for code dropped on the server once an attacker has a password. And the vulnerable extension list explains how version flags like these three work for every Joomla and WordPress extension we track. Doing the same by hand means logging in to every site, one at a time, every time a vendor like OrdaSoft has a bad week.

If one of your sites already shows signs of compromise, work through our Joomla hacked-site guide or have us fix it for you.

If you manage Joomla sites for clients, mySites.guru flags every connected site the day a fix like this is published, and the free audit shows what it finds on your own sites first.

Send Downtime Alerts to Teams, Google Chat, Discord or Your Own Code

phil@mysites.guru (Phil Taylor) — Mon, 28 Sep 2026 14:33:21 GMT

mySites.guru runs an Uptime Monitor against the sites you have connected, and when it detects that one is down, it notifies you. It notifies you again when the site comes back. By default that notification is an email, which is fine if you read email the moment it arrives, and most of us do not, least of all at three in the morning. The uptime monitoring page covers the rest of the feature.

Until now the only other option was the mySites.guru Slack app. We looked at every account that runs uptime monitors, and just over 1.5% had it connected. The other 98% or so heard about downtime from their inbox, which is how an uptime alert turns into something you read at breakfast.

Those down and up notifications can now also go to any webhook URL you paste in. There are five formats: one for Slack and the tools that read Slack’s format (Mattermost and Rocket.Chat), one each for Discord, Microsoft Teams and Google Chat, and signed JSON for n8n, Zapier, Make or your own code. The down and up emails keep arriving as before.

Five formats behind one URL box

The setting is a card called “Webhook: send Uptime Monitor alerts to any URL” on the Integrations tab of your notification settings. Paste the incoming webhook URL your chat app gave you and the format picks itself from the address: a hooks.slack.com URL selects Slack, a Teams Workflows URL selects Teams, a discord.com/api/webhooks/ URL selects Discord, a chat.googleapis.com URL selects Google Chat, and anything else falls back to JSON. You can change it by hand if the guess is wrong.

The Test button posts a test message using whatever is in the boxes right now, so you can check a URL before you save it. “Show an example message” displays the exact body we will send in the selected format, which saves guessing what will turn up in the channel.

Slack-compatible: For Slack, Mattermost and Rocket.Chat. A colour-coded attachment with the site, the server and the time we checked.
Discord: An embed, red for down and green for back up, with mentions switched off.
Microsoft Teams (Workflows): An Adaptive Card for the Workflows webhook trigger that replaced Office 365 connectors.
Google Chat: A text message with a bold headline, the site details and a Manage site link.
JSON: A documented body with a signature header, for n8n, Zapier, Make and your own code.

The URL has to be https:// on port 443 or 8443, with no username or password in it. We also check where the host resolves on every save, every test and every delivery, and we will not post to private or internal network addresses, because a webhook is a URL you choose that our servers then call.

Microsoft Teams after the Office 365 connector shutdown

Microsoft retired Office 365 connectors in Teams, including the old Incoming Webhook connector. The deadline moved several times after the first announcement in July 2024, and the final switch-off was scheduled for 18 to 22 May 2026. If an old tool of yours still posts to a webhook.office.com connector URL, that is the kind of URL the shutdown was aimed at.

The replacement is Workflows. In Teams, add the Send webhook alerts to a channel template, choose the team and channel, and copy the URL it gives you. That URL goes into the mySites.guru card, and we post an Adaptive Card to it in the shape Microsoft’s Workflows webhook documentation expects: a bold title coloured by event, a line of detail, and the site, server and check time as facts.

A Workflows webhook cannot set its own bot name or icon, so the alert appears in the channel as a Workflows post. There is no setting for it on our side or Microsoft’s.

Why does Google Chat get plain text?

Google Chat’s incoming webhook accepts only the fields in its own message format, and in our testing it answered anything else with an HTTP 400 error. None of the Slack, Discord or Teams shapes get through, so the Google Chat format is a {"text": "..."} message written in Chat’s own formatting markup: the headline in *bold*, a line of detail, the site, server and check time, and a <url|Manage site> link straight to the site in mySites.guru.

That text value, with its line breaks shown as real lines, reads:

*Example site is down*
https://example.com is not responding to our Uptime Monitor.

Site: https://example.com
Checked: 2026-09-28 14:18 UTC
<https://manage.mysites.guru/en/sites/manage/example|Manage site>

To create the URL, open the space in Google Chat, then the space menu, Apps & integrations, Add webhooks, as described in Google’s webhook quickstart. The URL includes a key and a token, so treat it like a password: anyone holding it can post into that space.

Google allows one message per second per space, shared by every webhook in it. The limit shows up when a whole server goes down and takes twenty client sites with it: the alerts arrive in a burst and Google slows some of them with a 429 response. We treat a 429 as temporary and retry it, so the later alerts in a burst usually arrive a little late instead of going missing.

Site names are text we did not write, so we also break up any *, _, ~, backtick, < or > in them before they reach Chat. A site called <https://example.com|Click here> stays visible as text and never becomes a link someone else chose.

Slack, Mattermost, Rocket.Chat and Discord

The Slack-compatible format uses Slack’s older message attachments rather than Block Kit. Slack still supports attachments and calls them legacy, but Mattermost’s incoming webhooks ignore Block Kit and read attachments, and Rocket.Chat accepts the same Slack-style attachment fields. One payload works in all three. The attachment is red for down, green for back up and blue for a test.

If you already use the mySites.guru Slack app, which you connect from the same Integrations tab, you do not need a webhook for Slack. The webhook is for a second destination, or for a team that lives somewhere else.

Discord gets an embed with the same colours, and we set Discord’s allowed mentions to an empty list, so a site named @everyone cannot ping everyone on your server. The Slack family gets the same protection a different way, with an invisible zero-width space after each @, so @channel or @here in a site name stays as plain text.

How do I verify a signed alert in n8n or my own code?

Each request we send has an X-MySites-Signature header containing sha256= followed by the hex HMAC-SHA256 of the X-MySites-Timestamp value, a full stop, and the raw request body, keyed with your signing secret. Compute the same value on your side, compare the two with a constant-time function, and reject a timestamp more than five minutes old so a captured request cannot be replayed later.

The scheme is close to how Stripe signs its webhooks, and the sha256= prefix matches GitHub’s X-Hub-Signature-256. GitHub signs the body only; putting the timestamp inside the signed string is what makes the five-minute window enforceable.

Each request also has an X-MySites-Event header, which is monitor.down, monitor.up or test. X-MySites-Delivery holds a UUID that stays the same across retries, so a receiver can drop a duplicate. User-Agent is mySites.guru-Webhook/1.0.

The JSON format sends this body:

{
    "event": "monitor.down",
    "delivery_id": "4f03fa9d-26a1-4590-83cc-332e25e986ac",
    "occurred_at": "2026-09-28T14:18:00+00:00",
    "source": "mySites.guru",
    "site": {
        "id": "example",
        "name": "Example site",
        "url": "https://example.com",
        "server_hostname": null,
        "manage_url": "https://manage.mysites.guru/en/sites/manage/example"
    }
}

server_hostname is always present and is null when we do not know the server, so your code does not need to treat the key as optional. Checking the signature in PHP is short:

$expected = 'sha256=' . hash_hmac('sha256', $timestamp . '.' . $rawBody, $secret);

$tooOld   = abs(time() - (int) $timestamp) > 300;

if ($tooOld || ! hash_equals($expected, $signatureHeader)) {
    http_response_code(401);
    exit;
}

And in Node, for example inside an n8n Code node:

const crypto = require('crypto');

const expected = 'sha256=' + crypto
  .createHmac('sha256', secret)
  .update(`${timestamp}.${rawBody}`)
  .digest('hex');

const ok = expected.length === signatureHeader.length
  && crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signatureHeader));

if (!ok || Math.abs(Date.now() / 1000 - Number(timestamp)) > 300) {
  throw new Error('Rejected: bad signature or old timestamp');
}

The signature has to be computed over the bytes we sent, not over JSON your tool has already parsed and re-encoded. In n8n, turn on the Raw Body option on the Webhook node. In Zapier, use Catch Raw Hook rather than Catch Hook, because only the raw version keeps the headers and the unchanged body. Make’s Custom webhook receives the alert with no extra setup.

The signing secret is created on your first save and appears on the card whenever the JSON format is selected, with Show, Copy and Regenerate buttons. All five formats are signed, but chat apps ignore the header, so the secret only matters to code you write. Regenerating it breaks any receiver still checking against the old one, and the card asks you to confirm first.

What happens when the webhook stops answering?

A delivery that fails for a temporary reason (a network error, a timeout, or an HTTP 408, 429 or any 5xx) is retried after 30 seconds, then 60, then 120: four attempts in all. Any other 4xx response is treated as final. So is a redirect, which we never follow, because following one would send your alert to an address we have not checked.

After 10 failed deliveries in a row, the webhook pauses itself. The card then shows it as paused with a Resume button, and a “Last sent” line under the buttons shows when the most recent delivery went out and what came back.

We do not email you when a webhook pauses. An alerting feature that sends email because its own alerting has broken is how an inbox fills with noise on a bad night. Your down and up emails are separate and keep arriving whatever the webhook is doing, so pausing a webhook never leaves you blind.

Team accounts and who gets which alert

Each user has one webhook, and the people who receive an alert are the same people the Slack app notifies: the account owner, plus any team members who have access to that site. A team member limited to a handful of client sites only gets alerts for those sites, so a freelancer on your team can point their own Discord at just the sites they look after.

If three people on the same account paste the same Slack channel URL, the alert is posted once. You can save a webhook on any account, but alerts are only sent, and Test only works, while the account has an active subscription.

For everything else about how the monitor decides a site is down, and why an alert sometimes fires for a site that looks fine to you, read why you’re getting downtime alerts. If you want to pull data rather than have it pushed, the mySites.guru API and its one-call site summary cover that side.

Modules Anywhere 10.0.0 and Tabs & Accordions 3.2.0 Close Two Content Author Security Holes

phil@mysites.guru (Phil Taylor) — Sun, 27 Sep 2026 17:27:19 GMT

Regular Labs released Modules Anywhere 10.0.0 and Tabs & Accordions 3.2.0 for Joomla on 27 September 2026, and each has a [SECURITY FIX] entry in its changelog. Both close a way for someone with permission to write content to reach further than their role should allow: in Modules Anywhere, by changing the settings of any module they embed; in Tabs & Accordions, by placing JavaScript in a tab that runs in a visitor’s browser.

These are Joomla extension fixes, not Joomla core. Regular Labs found and fixed them; we did not report them, and the vendor credits no one.

What to do now

Update Modules Anywhere to 10.0.0 and Tabs & Accordions to 3.2.0, Free or Pro, on every Joomla 4, 5 and 6 site that runs them. If you updated Tabs & Accordions to 3.1.0 in September, that release does not include this fix. Modules Anywhere 10.0.0 is a breaking change, so check any page that overrides module settings in a tag after you update. On Joomla 3 there is no fixed Modules Anywhere: limit who can author content, or remove the extension.

Update, 28 September 2026: CVE-2026-100750 and CVE-2026-100751

The Joomla CNA has published both issues, and the records are wider than the changelog suggested.

8.5CVSS 4.0

CVE-2026-100750Modules Anywhere: file read and server-side request forgery through module overrides

Highthe Joomla CNA

A content author could override any setting of a module they embedded. Joomla's Feed module fetches its URL on the server and accepts local file: URLs, so the override reads files from the server or reaches addresses only the server can see. Affects the Pro edition, 1.5.0 to 9.0.5.

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:H

Content author account neededPro edition

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:H: High: Data and files can be altered at will
VA:N: None: The site stays up

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

7.5CVSS 4.0

CVE-2026-100751Tabs & Accordions: stored XSS through data-rlta-url

Highthe Joomla CNA

A javascript: URL in a tab or accordion's url option was passed to window.open() when a visitor opened the item, so script from a content author ran in the visitor's browser, including a logged-in administrator's. Affects Free and Pro, 2.3.0 to 3.1.0.

CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/S:N/AU:N

Content author account neededFree and Pro

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

	Modules Anywhere	Tabs & Accordions
Weakness	Server-side request forgery (CWE-918)	Stored cross-site scripting (CWE-79)
Affected	Pro, 1.5.0 to 9.0.5	Free and Pro, 2.3.0 to 3.1.0
Fixed in	10.0.0	3.2.0

This changes what we wrote on release day. The Modules Anywhere issue reaches the server itself: Joomla’s own Feed module opens its feed URL server-side and accepts local file: URLs, so an author who can override that setting can read files from the site’s server or make it request other addresses. Every Modules Anywhere Pro release back to 1.5.0 is affected, so the 7.x Joomla 3 branch and the 8.x releases are in range alongside 9.x. Tabs & Accordions Free is affected as well as Pro.

We have widened our flags to match. A day after release, 41% of the Tabs & Accordions installs we monitor and 72% of Modules Anywhere installs are still on an affected build.

TL;DR

Modules Anywhere 10.0.0 fixes CVE-2026-100750 (High, 8.5): before it, a content author could override the settings of any module they embedded, and through Joomla’s Feed module read files from the server. Pro 1.5.0 to 9.0.5 is affected
Tabs & Accordions 3.2.0 fixes CVE-2026-100751 (High, 7.5): data-rlta-url attributes accepted executable JavaScript URLs, so a content author could plant script that ran for visitors. Free and Pro 2.3.0 to 3.1.0 are affected
Free and Pro share one version number, so mySites.guru flags both editions of both extensions
87% of the affected Tabs & Accordions installs we monitor are on 3.1.0, the release that fixed a different Tabs & Accordions issue two weeks ago
Modules Anywhere 10.0.0 is marked BC BREAK, and moves several settings into a new Process Tags section
No Joomla 3 fix: the Modules Anywhere Joomla 3 branch stopped at 7.18.0 and is affected, and Tabs & Accordions has no Joomla 3 version
mySites.guru flags every connected Joomla site running Modules Anywhere below 10.0.0 or Tabs & Accordions 2.3.0 to 3.1.x

What changed in Modules Anywhere 10.0.0

Modules Anywhere lets you place any Joomla module inside an article with a tag. The Pro edition lets that tag override the module’s own settings, so one module can be shown with different options in different places. Before 10.0.0, any content author could use those overrides on any module they could embed.

The changelog is specific about the consequence: the fix “restricts module parameter overrides to trusted sources by default, preventing content authors from changing feed URLs and other module settings”. An author who can embed a feed module can point it at a feed they control, and the site will display whatever that feed contains, under the site’s own name.

The CVE record goes further. Joomla’s core Feed module fetches its URL on the server, and it accepts local file: URLs as well as network addresses. So the same override lets an author read files the web server can see, or make the server request internal addresses it can reach and outsiders cannot. That is server-side request forgery (CWE-918), and it is why CVE-2026-100750 scores 8.5 despite needing a logged-in author. The Feed module is the documented example, and any other module setting is open to the same override.

10.0.0 adds settings for trusted component and module sources, and only accepts overrides from those by default. A related Pro entry fixes module and title tag overrides accepting unsafe HTML element names.

10.0.0 changes behaviour on update

Regular Labs marks this release BC BREAK. Parameter overrides from sources that are not trusted stop working after the update, and the previous area, tag-removal and Sourcerer settings are migrated into the new Process Tags settings. If your articles override module settings in a tag, test them on a staging copy first and allow the sources you trust, rather than switching the restriction off.

What changed in Tabs & Accordions 3.2.0

The second issue scores lower. Tabs & Accordions turns simple tags in an article into tabs and accordion panels. Each panel can have a data-rlta-url attribute, and before 3.2.0 the extension accepted a javascript: URL there. The changelog entry reads, in full: “Fixes data-rlta-url attributes accepting executable JavaScript URLs”.

In practice, anyone allowed to write or edit an article could put script into a tab that ran in the browser of anyone who opened it: the browser code hands the value to window.open() when the item is activated. Joomla’s text filters see only ordinary plugin syntax when the article is saved, because the dangerous attribute is created later, when the page is rendered. That is a stored cross-site scripting issue (CWE-79), and on most Joomla sites the people who read articles include logged-in editors and administrators, so the script can run with their rights. It needs an account that can author content, which keeps it away from anonymous visitors on sites that only give authoring rights to staff.

The same release fixes title-tag attributes accepting unsafe HTML element names, and adds the new Process Tags security controls in both editions. It also moves the administrator tag-processing option into the Security settings, which is worth checking after the update if you changed it.

This is the second Tabs & Accordions fix in two weeks

On 13 September Regular Labs shipped Tabs & Accordions 3.1.0 to fix crafted data-rlta-alias attributes running JavaScript when a matching link was clicked. That was a different attribute. 3.1.0 did not touch data-rlta-url, so a site that updated promptly in September is still exposed to this one.

We can see the installed version of Tabs & Accordions on every Joomla site connected to mySites.guru, and the September update did its job: most sites moved to 3.1.0. That is exactly why so many need to move again.

93%

on a 3.x build

all inside the range the 3.2.0 fix covers

87%

of those on 3.1.0

updated in September, need to update again

32%

Free edition

of the affected installs, also covered by the CVE

Share of Tabs & Accordions installs on Joomla sites connected to mySites.guru, measured on 27 September 2026.

This is a pattern we see with Regular Labs more than most vendors: they fix a class of problem one attribute or one feature at a time, over several releases. Sourcerer needed three releases to close one issue in August. Being fully up to date with a Regular Labs extension means you have the fixes shipped so far, and the next one may be a fortnight away.

Which Joomla sites can take these updates?

Only Joomla 4, 5 and 6 sites. Regular Labs’ own update feed was already offering Modules Anywhere 10.0.0 and Tabs & Accordions 3.2.0 to Joomla 4 to 6 by the evening of release day, unlike the September batch, where the feed lagged the changelog for part of the day.

Joomla 3 is a different story. Across the Joomla sites connected to mySites.guru, 31% of Modules Anywhere installs are on the 7.x branch, and 98% of those sites run Joomla 3. That branch has been frozen at 7.18.0 since Regular Labs stopped building for Joomla 3, and it will not get this fix. The CVE record covers every Pro release from 1.5.0, so 7.x is affected, and we now flag it for this issue on top of the July fixes it never received. Tabs & Accordions has no Joomla 3 version at all.

For those sites the answer is the one it has been since 2023: plan the move off Joomla 3. On Joomla 4 and later, 57% of Modules Anywhere installs were on 9.x on release day, most of them on 9.0.5, and a smaller group is still on 8.x. Both need 10.0.0.

How mySites.guru flags these Regular Labs releases

mySites.guru records the exact version of every extension on every connected Joomla site twice a day. On release day we added entries to our Joomla vulnerability database, and when the CVE records were published we widened them to Modules Anywhere 1.5.0 to below 10.0.0 and Tabs & Accordions 2.3.0 to below 3.2.0, so every connected site running an affected build is flagged on its dashboard and in its audit, with the version that resolves it.

Because Regular Labs ships Free and Pro under one version number, the flag cannot tell the two editions apart, so a Free Modules Anywhere site on 9.0.5 is flagged too, even though that CVE covers only Pro. That is the right way round: updating a Free install is quick and free, and a missed Pro site is not. The vulnerable extension list explains how these flags work for every extension we track.

When a whole family of extensions moves on the same day, updating them one site at a time is the part that gets skipped. mySites.guru can update Joomla extensions across every connected site from one screen, and if you would rather not babysit the next Regular Labs wave, enable extension auto-updates for the extensions you trust.

Who can author content on your Joomla sites?

Both issues start with an account that can write articles, so the size of the risk on a given site is the number of those accounts and how carefully they were given out. On a brochure site where only two staff members write content, it is small. On a membership site, a school, or anything that lets people register and contribute articles, the author role is exactly where an attacker would start.

Until every site is updated:

Check whether front-end registration is switched on, and whether new users can reach a group with authoring rights
Remove authoring rights from accounts that no longer need them, and delete accounts that have never logged in
Keep Joomla’s text filters strict for Registered and Author groups, so raw HTML and script are stripped on save
Review recently edited articles that use Tabs & Accordions or Modules Anywhere tags if you do not trust every author

Disable User Registration Unless Required

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

If you find script or module settings you did not put there, treat the site as compromised and work through our Joomla hacked-site guide, or have us fix it for you.

If you run Regular Labs extensions on more than a few sites, mySites.guru flags every connected site the day a Regular Labs fix is published, and the free audit shows what it finds on your own sites first.

UP 6.1.0 fixes file read and code execution in the UP plugin for Joomla

phil@mysites.guru (Phil Taylor) — Sat, 26 Sep 2026 17:04:10 GMT

UP, the Universal Plugin, is a Joomla content plugin that reads {up ...} shortcodes out of article text and acts on them while the page renders. About 160 actions ship with it. Most are harmless: embed a video or a map, make a table responsive, list articles by tag. A handful do far more, running PHP, querying the database, reading files, and fetching code from GitHub. Its maintainer released UP 6.1.0 on 26 September 2026, and it fixes a set of flaws we found in 6.0.29 and reported privately in August.

The worst of them needed nothing but a web browser. UP answers requests on Joomla’s anonymous AJAX endpoint, and in 6.0.29 one of those requests returned any file the server could read, configuration.php and the database password inside it included.

Update UP now

UP 6.1.0 (Joomla 5.2 to 6.x) and UP 5.2.1 (Joomla 3.10 to 5.1) are the fixed releases. The maintainer lists every version from 5.0 to 6.0.29 as affected. This post describes the mechanisms and leaves the working requests out.

TL;DR

Update UP to 6.1.0 on Joomla 5.2 to 6.x, or 5.2.1 on Joomla 3.10 to 5.1. Every version from 5.0 to 6.0.29 is affected
In 6.0.29 an anonymous request could make the site download action code from GitHub with certificate checks switched off, the route to running someone else’s code
A second anonymous request read any file the web server could read, configuration.php included
Anyone who could write an article could run PHP and query the whole database, and it ran for every visitor to that page
A third anonymous request could create files outside the folder they were meant for
Tracked as CVE-2026-97160 to CVE-2026-97163, scored up to 10.0 Critical by the Joomla CNA
It took fifteen release candidates over four weeks to close every route, and we retested each one, because more than once a changelog said “fixed” over code that was not
mySites.guru flags every connected site on an affected version, so you do not have to check each one by hand

The findings, by who could exploit them

Whether a flaw needs a login decides how urgent it is, so here they are grouped that way. Three needed no login at all.

#	Flaw in 6.0.29	Who can exploit it	What it exposes	CVE
1	Anonymous trigger to install action code from GitHub	Anyone, no login	Code execution, if the download can be steered	CVE-2026-97163
2	Arbitrary file read on the AJAX endpoint	Anyone, no login	`configuration.php`, and any other file the server can read	CVE-2026-97161
3	PHP and SQL actions open to article authors	Anyone who can write an article	PHP execution and the whole database, for every visitor	CVE-2026-97160, CVE-2026-97162
4	File creation outside the intended folder	Anyone, no login	Stray files written where they should not be	CVE-2026-97161

Our original report listed a fourth anonymous flaw, a file move and delete endpoint. When the maintainer replied, he pointed out that the file had a PHP syntax error and never ran, which we confirmed. It is tidied up in 6.1.0, but it was never exploitable, so it is not in the table.

1. An anonymous request could install code from GitHub

UP has a “mini” mode. Rather than ship all its actions, it downloads the one a page needs from the maintainer’s GitHub repository the first time it is used, and unpacks it into the plugin’s own folder, where Joomla runs it.

In 6.0.29 an anonymous visitor could set that download in motion, and the fetch ran with its TLS certificate checks switched off. On its own the request only chose which file name to ask for inside a fixed repository, so it is not a one-shot takeover. But with the certificate checks off, anyone positioned between the server and GitHub could answer with a different archive, and whatever arrived was unpacked into a folder of PHP that UP includes on demand. Our own provisional score was lower because of that second condition; the Joomla CNA scored it 10.0 Critical. We proved the anonymous trigger on our test site and stopped there, because the next step would have meant serving a payload through the maintainer’s own infrastructure. 6.1.0 restricts the download and turns the certificate checks back on.

2. Any file on the server, for anyone who asked

One action existed to show a text or CSV file in a popup. The file name came straight from the request, and the endpoint checked neither who was asking nor where the file sat on disk. The file-type limits lived in the code that draws the button, and never in the code that answered the request.

On our test site, one anonymous request returned a canary file we had placed outside the web root, and configuration.php came back the same way. That file holds the database username and password, so reading it is close to handing over the database. 6.1.0 restricts this action to the file types it was meant for and keeps it inside the site.

3. What an article author could reach, and how the gate kept failing

The most drawn-out part of this was not an anonymous flaw. It was the boundary between an ordinary content author and the actions that run code.

UP keeps a list of action names reserved for administrators, and when an article is saved it scans the text and blocks the save if a non-administrator used one. That check read the action name exactly as it was typed. The renderer did not. Before deciding which action to run, it rewrote the name several times: stripping editor markup, changing the case, swapping punctuation, and applying a dictionary of alternative names the plugin accepts for convenience.

Each rewrite was a way in. Typed in a form the check did not recognise but the renderer did, a shortcode saved cleanly and still ran. The clearest demonstration was a matched pair: one spelling of an action blocked, another spelling of the same action, by the same user on the same build, saved and ran. Behind that gate sat an action that runs PHP and an action that reads the database directly, so a low-privilege author could reach code execution and the users table on a page any anonymous visitor could then open.

Closing this took several tries. One release worked out the real name once, in a single function used by both the save check and the renderer, which shut all four routes at once. The next release dropped one lookup from that function and reopened one of them, which we proved live and reported the same morning; the release after restored it. The version that shipped reserves the risky actions to administrators, checks at save time and again at render time, and matches the name the same way in both places.

The PHP and SQL actions still exist for administrators, by design. So on a site running UP, an administrator writing an article can read almost any table in the database. Keep that in mind when you decide who holds administrator access. It is also a reason to be wary of any flaw elsewhere that could forge an administrator’s request.

A permission check that took the site down

One release added a missing permission check to an AJAX handler. It was the right check, written in a way that could not run: it referred to the current object inside a static function, which PHP does not allow. The moment an unauthorised visitor triggered it, PHP raised a fatal error.

On the increasingly common FrankenPHP setup that was not a tidy error page. The failure produced a response the web server could not send, and the server process fell over. In our lab, one anonymous request took the whole site down until it was restarted by hand. It was corrected in the next candidate and stayed corrected through release, but it is a neat illustration of why a fix has to be run, not just read: the code looked right.

How to update UP safely

Take a backup first. If you use mySites.guru, take a snapshot or run a full backup before you touch a live site.
Update to 6.1.0 or 5.2.1. On one site, use Joomla’s System, Update, Extensions screen. Across several, use the mySites.guru mass updater to push it to every site at once.
Confirm the version. Check each site’s extension list shows UP 6.1.0 (or 5.2.1 on older Joomla) or later.
Look for files you did not put there. The GitHub-install flaw wrote into the plugin’s own folder, so check for action directories and PHP files under it that you do not recognise.
Review who can write articles, and who is an administrator. The author-level route ran for years of installs, and the admin-only actions are powerful by design.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How to find every site running UP

The first question after a disclosure like this is which of your sites run the thing. mySites.guru keeps a live inventory of the extensions, plugins and templates on each connected Joomla and WordPress site. Search for UP once and you see each site running it and the version each one is on.

We added the ranges from the CVE records, 5.0.0 to 5.2.0 on the older branch and every 6.x version below 6.1.0, to the mySites.guru vulnerability database, so every connected site still on a vulnerable UP is flagged on its dashboard without anyone searching. The same database lists the Joomla extension vulnerabilities we track, with the affected versions for each.

What else mySites.guru checks on a Joomla site

UP is one plugin. A typical Joomla site runs dozens of extensions, each with its own release notes and its own idea of what counts as a security release. No single check covers that. It takes several running together:

Vulnerable extension detection compares installed extensions against the known-vulnerable ranges and flags a site as soon as one matches. That is how the UP rule reaches every connected site at once.
Rogue administrator detection lists super users you did not create, which is where an abused admin-only action tends to leave its mark.
File scanning checks every file against a pattern library of roughly 1,500 malware signatures and looks for files that can accept uploads, the kind a GitHub-install flaw could drop.

All of it runs unattended across every connected site, and all of it is part of the subscription. Doing the same by hand means logging into each Joomla admin, reading the extensions list and comparing it against changelogs, then doing it again the next time a vendor ships.

If a site has already been hit, fix.mySites.guru cleans it, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day. Non-subscribers get a free month with it.

Start with a free audit on one site to see what it finds, or see the plans and connect every site you manage.

Fifteen candidates, and why we retested every one

Every build in this sequence arrived with a changelog saying the issues were fixed. Each time, part of it was true, part was not, and twice a build introduced something that had not been wrong before. One release normalised the action name in one place and closed four routes at once; the next dropped a line and reopened one. A permission check that read correctly crashed the site the first time an anonymous visitor reached it.

The maintainer, who had taken UP on after its author died and was not being paid for any of this, answered every report within hours and kept going through fifteen candidates until there was nothing left an author could reach. That is the outcome you want. It is also the reason the fix took four weeks: a vendor’s changelog is a claim, not evidence, and the only way to know a security fix holds is to run the fixed build and try the attack again. We retested every candidate, and read the released 6.1.0 code against the last regressions before publishing this.

Disclosure and severity

We found these flaws reading UP 6.0.29’s code and confirmed the anonymous file read and the author-level code execution live on our own test install. They were reported privately on 23 August 2026, to the vendor address and the Joomla Security Strike Team, and nothing was published until a fixed release existed.

The Joomla CNA published four CVE records on 26 September 2026, one per weakness type, each crediting mySites.guru as the finder: CVE-2026-97163 for the remote code installation, CVE-2026-97160 for PHP command injection, CVE-2026-97161 for the path traversal and file access routes, and CVE-2026-97162 for the SQL injection routes. The weakness classes named in the records are path traversal (CWE-22) and improper access control (CWE-284), code injection (CWE-94) and SQL injection (CWE-89).

The scores below are the CNA’s, worst first.

10.0CVSS 4.0

CVE-2026-97163Remote code installation from GitHub, no login needed

Criticalthe Joomla CNA

An anonymous request set an on-demand code download in motion over a connection with certificate checks disabled, and whatever arrived was unpacked into a folder of PHP that UP runs.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

No login needed

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

9.4CVSS 4.0

CVE-2026-97160PHP command injection through the php action

Criticalthe Joomla CNA

The php action runs PHP from article text and is meant for administrators, which is why the CNA scores it as needing high privileges. Before 6.1.0 an article author could reach it by spelling the action name in a way the save check did not recognise, and the code ran for every visitor to the page.

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Administrator actionAuthor-reachable before 6.1.0

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

9.2CVSS 4.0

CVE-2026-97161Arbitrary file read and file creation through path traversal

Criticalthe Joomla CNA

One anonymous request to the AJAX endpoint returned any file the web server could read, including configuration.php and the database credentials it holds. Another wrote files through a path built from request input, outside the folder they belonged in.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

No login neededExploitable over the internet

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

8.3CVSS 4.0

CVE-2026-97162SQL injection vectors

Highthe Joomla CNA

The sql action and actions that build queries from shortcode options passed attacker-controlled text into database queries. In one release candidate a subquery read password hashes from the users table.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Several routes

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Field	Detail
Component	UP, the “Universal Plugin” for Joomla (`plg_content_up`, plus the packaged action set)
Vendor	Originally Lomart, who died September 2025; maintained since by Pascal Le Conte (conseilgouz)
Type	Path traversal (CWE-22) and improper access control (CWE-284) for the GitHub install and file access routes; code injection (CWE-94) for the PHP action; SQL injection (CWE-89)
Affected versions	5.0 to 6.0.29 (per the maintainer)
Fixed in	UP 6.1.0 (Joomla 5.2 to 6.x) and UP 5.2.1 (Joomla 3.10 to 5.1), released 26 September 2026
CVE	CVE-2026-97163 (remote code installation), CVE-2026-97160 (PHP command injection), CVE-2026-97161 (path traversal and file access), CVE-2026-97162 (SQL injection)
CVSS 4.0	Joomla CNA: 10.0 Critical (CVE-2026-97163), 9.4 Critical (CVE-2026-97160), 9.2 Critical (CVE-2026-97161), 8.3 High (CVE-2026-97162)
Finder	Phil Taylor, mySites.guru
Reported	23 August 2026, privately to the vendor and the Joomla Security Strike Team
Acknowledged	24 August 2026
Release reviewed	26 September 2026, code review of the released 6.1.0 build

Timeline

2025-09 UP's original author dies Lomart, who wrote and maintained UP, died in September 2025. Pascal Le Conte took over maintenance. It was not announced anywhere we could find, and the contact page on the UP website returned a 404, which is why our report a year later went to an address no one was reading.
2026-08-23 mySites.guru audits UP 6.0.29 and reports four unauthenticated flaws Arbitrary file read, file creation through path traversal, a file move and delete endpoint, and remote code installation. Reported the same night to the vendor address and the Joomla Security Strike Team, with CVE assignment requested through the Joomla CNA. The email also flagged that article authors could run PHP and SQL, without detail. All public detail withheld.
2026-08-24 The maintainer replies within ten hours Pascal Le Conte acknowledged the report and committed to fixing it, and told us he now maintains the plugin. He also showed that the file move and delete endpoint never ran in 6.0.29 because of a PHP syntax error, which we confirmed, so three of the four were live and one was inert.
2026-08-25 First release candidate, and our first retest A build arrived with a new setting reserving the risky actions to administrators. Retested the same day: one finding properly closed, two still exploitable, and the new setting could be walked around. We sent the author-level PHP and SQL findings in full.
2026-08-29 A build for the Joomla 3.10 to 5.1 branch joins in Candidates for both the 6.1.0 and the 5.2.1 branch. Our retest found three of the original findings still reachable by the same route, and the changelog's claim to have fixed the SQL action did not hold up against the running code.
2026-09-01 The maintainer asks the Joomla CNA for CVE IDs The SQL action was removed, and a different file-reading action, absent from the restricted list, gave an author the same read. Pascal asked the Joomla Security Strike Team to assign CVE identifiers and credit mySites.guru.
2026-09-07 The administrator-only list can be walked around four ways The check reserving the risky actions compared the action name before the renderer rewrote it, and there were four rewrites, so there were four ways past it. Five further actions needed no trick at all, because they were never on the list.
2026-09-09 The structural fix arrives in RC11 A single normalisation function now works out the real action name for both the save check and the renderer, closing all four bypasses at once. An inverted file check and a denial-of-service crash are fixed too.
2026-09-11 RC12 regresses, and RC13 fixes it the same day RC12 dropped the alternative-name lookup from that function and reopened one route, which we proved live and reported that morning. RC13 restored the lookup and tightened the anonymous AJAX session check.
2026-09-14 The SQL action becomes administrator-only for good After we set out the remaining SQL injection paths, the SQL action was reserved to administrators, with queries touching password and token columns blocked.
2026-09-17 Our review of the last candidate finds nothing an author can reach Two small gaps remained in the save-time scan, both still blocked by the render-time check. The maintainer closed them in the final build.
2026-09-26 Four CVE IDs assigned The Joomla CNA assigned CVE-2026-97160 to CVE-2026-97163, grouping the vectors into one identifier per weakness type because each type shares a root cause and a fix.
2026-09-26 UP 6.1.0 and UP 5.2.1 released 6.1.0 for Joomla 5.2 to 6.x, 5.2.1 for Joomla 3.10 to 5.1, held back until the CVE IDs were assigned. Every version from 5.0 to 6.0.29 is affected.
2026-09-26 Released build reviewed, affected sites flagged and this post published We read the released 6.1.0 code against the last regressions: the alternative-name lookup is back in the shared check, and the anonymous AJAX session check only accepts keys the plugin issued itself. The CVE records published the same afternoon, and every connected site on an affected UP version is flagged in mySites.guru.

Event Gallery 6.5.0 Hides Eight Security Fixes in 46 Bug Fixes

phil@mysites.guru (Phil Taylor) — Sat, 26 Sep 2026 14:35:16 GMT

Sven Bluege released Event Gallery 6.5.0 for Joomla on 26 September 2026, and it is a security release. Before 6.5.0, a page on another website could make a logged-in editor upload images into a gallery event and replace existing ones, a crafted link could run script in an editor’s session, and the identifiers of carts and orders in the image shop could be worked out from the time they were created.

The release page does not put it that way. The notes sit behind a collapsed More information button, run to 8,673 words, and file the security fixes among 46 bug fixes in the same even tone as a PayPal option and a German mail template. Nothing on the page tells a site owner to update today.

What to do now

Update Event Gallery to 6.5.0 on every Joomla site that runs it, Core and Extended alike. 6.5.0 needs Joomla 5.4 or later, so a site still on Joomla 3 or 4 has to upgrade Joomla first. If the site overrides the upload layout in its template, update the override too, or every upload will be rejected with an invalid token message.

Update, 4 October 2026: update to Event Gallery 6.6.0 instead

Sven Bluege released Event Gallery 6.6.0 on 4 October 2026 with three more security fixes: a CSRF in eight backend list buttons (CVE-2026-102776), a Google Photos picker that could be made to send its access token to any address (CVE-2026-102777), and an XSS on the shared image page (CVE-2026-102778). All three are present in 6.5.0, so the advice in this post to update to 6.5.0 is now out of date: update every site to 6.6.0, including sites already on 6.5.0. It has the same Joomla 5.4 and Joomla 6 requirement. The details are in our Event Gallery 6.6.0 post.

Update, 27 September 2026: all five advisories now have CVEs

The Joomla CNA published a CVE for each of the vendor’s five advisories the day after the release. Every record lists Event Gallery 1.0.0 to 6.0.0 as affected and 6.5.0 as the fix, and the CVSS 4.0 scores are the CNA’s own, so two of them differ from the vendor’s:

CVE-2026-97164 (EGSA-2026-01), path traversal in Clear Cache: 7.0 High, against the vendor’s 6.5. The images parameter of the cache task could recursively delete any folder the web server can write to
CVE-2026-97165 (EGSA-2026-02), reflected XSS and open redirect through the Back link: 5.3 Medium
CVE-2026-100747 (EGSA-2026-03), CSRF in the image upload: 5.1 Medium
CVE-2026-100748 (EGSA-2026-04), CSRF in the cart actions: 6.9 Medium, against the vendor’s 4.3, because the CNA scores it as needing no privileges at all
CVE-2026-100749 (EGSA-2026-05), CSRF in the backend clean-up: 5.1 Medium. The record notes that only orphaned file entries and carts older than 30 days can be deleted this way

The guessable order identifiers have no CVE, consistent with the vendor now listing them as hardening. The mySites.guru Event Gallery rule lists all five CVE ids and is now rated High, following the Clear Cache score. The advice is unchanged: update every site to 6.5.0.

Update, 26 September 2026: the release notes now lead with security

Following the first publication of this blog post, in response, Sven Bluege rewrote the 6.5.0 release notes the same afternoon. They now open with “This is a security release. Update every site to 6.5.0.”, say that every earlier version is affected and that 6.5.0 needs Joomla 5.4 or Joomla 6, and send sites on older Joomla to a Security Advisories chapter in the manual. A new Security Fixes section lists five vulnerabilities, each with its own advisory ID and severity:

EGSA-2026-01, path traversal in Clear Cache (severity 6.5). A backend user allowed to manage Event Gallery, which in Joomla’s default permissions is every Administrator and not only Super Users, could make Clear Cache delete any folder the web server can write to, up to the whole site. Our original post did not cover this one
EGSA-2026-02, cross-site scripting and open redirect on the frontend upload page (6.1), affecting 3.11.4 to 6.0.0
EGSA-2026-03, forged uploads (5.4)
EGSA-2026-04, forged cart changes (4.3). Adding an image to the cart and removing it needed no token, so a page on another site could change a visitor’s cart
EGSA-2026-05, forged clean-up in the backend (4.3)

The guessable order identifiers, the test mail button, the backend picker requests and the unescaped folder name are now listed separately as hardening without a known vulnerability, which is why the vendor counts five where we counted eight. This is the change we asked for in the last section of this post, made within hours. The sections below describe the notes as they stood when 6.5.0 came out. The advice has not changed: update every site to 6.5.0.

The Joomla CNA has since published a CVE for each of the five advisories, listed in the 27 September update above.

TL;DR

Event Gallery 6.5.0 fixes eight security issues, five of them now with CVEs (CVE-2026-97164, CVE-2026-97165, CVE-2026-100747, CVE-2026-100748 and CVE-2026-100749)
Clear Cache path traversal (CVE-2026-97164, 7.0 High): a backend user allowed to manage Event Gallery could delete any folder the web server can write to. We missed this one in our first version of this post
The upload CSRF is present in both earlier releases we checked, 5.7.8 and 6.0.0
Image upload CSRF: neither the backend nor the frontend upload checked Joomla’s form token, so a malicious page could upload or replace images in an event through a logged-in editor. Uploads are still limited to images and mp4 video, so there is no route to running code
Reflected XSS: the Back link on the frontend upload page printed a URL parameter as it came, so a crafted link could redirect an editor or run script in their session
Guessable order IDs: cart and order identifiers were derived from the creation time. Orders created before the update keep their old identifiers
Several backend actions, from clean-up links to test mails, were missing token or permission checks
As first released: no CVE and no Security heading. The fixes were in the Bug Fixes list, and the only highlight that mentioned them was one word: “Safer.” The vendor added a Security Fixes section the same afternoon, and the CVEs followed a day later
About a third of the affected sites we monitor are on Joomla 3, where 6.5.0 will not install
mySites.guru flags every connected Joomla site running Event Gallery below 6.5.0

The Event Gallery 6.5.0 release notes run to 8,673 words

Open the 6.5.0 release page and you see a version number, a release date, two download links and a small button labelled More information. Press it and the notes unfold: eight highlights, ten migration hints, 21 new features, 15 minor changes and 46 bug fixes, 8,673 words in all. It is well written, too. Every entry says what used to happen, what happens now and what, if anything, you need to change.

What it never does is sort the entries by how much they matter. There is no Security heading. The word “vulnerability” does not appear. The eight highlights lead with buying several images at once, a new cart, PayPal Checkout and new mails for buyers, and the security work comes last, as a single bullet that starts with the word “Safer.” In the Bug Fixes list the first security entry is number 8, and the upload CSRF, the fix with the widest reach, is number 39 of 46, between a fix for the upload page of Flickr and Google Photos events and the fix for the test mail button.

The entries are accurate. The one for the Back link says, in plain words, that a prepared link could “run a script in the session of the editor who clicked it”. But you only read that sentence if you expand a collapsed panel and scroll past more than 8,000 words to reach the upload fix, and at no point does the page connect any of it to an action.

“Safer. The upload, the test mail, the clean-up links and the background requests of the backend check the form token now, and new carts and orders get identifiers which can no longer be guessed.”

Read as hardening. Updated with the next batch.

“Security release. Before 6.5.0 a malicious page could upload or replace images through a logged-in editor, and a crafted link could run script in their session. Update every site now.”

Updated today.

The line on the left is the vendor's, word for word from the Event Gallery 6.5.0 highlights. The line on the right is ours, written from the vendor's own Bug Fixes entries and our reading of the code. They describe the same release.

Most people looking after more than a handful of Joomla sites triage extension updates by skimming the top of the notes. A release led by shop features reads as a feature release, and a feature release on a live photo shop is the kind of update that gets scheduled for a quiet week, not applied the same morning. We made the same point about Helix3 shipping a critical fix as “Security Update”, T4 Page Builder calling an open mail relay “Safer recipients” and AcyMailing filing two security fixes under Bug fixes. The Joomla project’s own guidance for extension developers handling a security report asks for the security content to be separated out and named. The fix here is small: move the eight entries under their own heading at the top, and add one sentence saying which versions are affected and that sites should update.

What the Event Gallery 6.5.0 security fixes close

Our reading, not our discovery

Sven Bluege found and fixed these issues himself; we did not report them. We confirmed the upload, Back link and identifier findings by comparing the 5.7.8, 6.0.0 and 6.5.0 packages. The severity here was our own assessment at the time of writing; the CNA’s scores are in the 27 September update above. We are not publishing request shapes, because most installs have not updated yet.

The Joomla image upload had no CSRF token

In 6.0.0 and 5.7.8, the upload task in both the backend and the frontend controller passed the request straight to the model. The model checked that the user had Joomla’s edit permission for Event Gallery and nothing else. It never checked the form token, the value Joomla puts in every form so the server can tell a request the user made from one another website made on their behalf.

That makes the upload a classic cross-site request forgery. An editor, or a frontend publisher who uploads from the site, visits a page that posts a file to their own site’s upload task in the background, and their browser sends their session cookie with it. The file goes into the named event, and if an image of the same name is already there, it is replaced. On a photo shop that sells prints of an event, that lets an attacker swap the pictures customers are paying for.

There is a limit to the damage. Event Gallery checks the extension against an allow-list of jpg, gif, png, jpeg, webp and mp4, checks the file’s actual content type as well, and cleans the file name. We found no route from this upload to running code on the server. 6.5.0 adds the token check to both controllers, and a site with a template override of the upload layout has to update that override, because the page now passes the token to the uploader script.

The Back link on the upload page was a reflected XSS

The frontend upload page offers a Back link, and before 6.5.0 its target came from a return parameter in the address, base64-decoded and printed into the page without escaping or checking. A crafted link could point Back at another website, or break out of the link and run script in the page, in the session of whoever opened it. The people who use that page are the site’s editors and publishers, so the script runs with their rights.

6.5.0 only accepts a target on the site’s own domain and leaves the link out otherwise. The same page also printed an event’s folder name unescaped. Folder names saved through the backend are cleaned, so that one only matters if a name reached the database another way, and 6.5.0 escapes it too.

Cart and order identifiers could be worked out

Event Gallery built cart identifiers from PHP’s uniqid(), which is derived from the current time, and turned the result into a 28-digit number. The vendor’s notes spell out the consequence: anyone who knew roughly when an order was placed could work out its identifier. They also note that the number was too large for PHP to hold as an integer, so a single careless cast anywhere could collapse every identifier into one value and show one customer another’s order.

The vendor says order download links were never exposed, because they use a separate random token. From 6.5.0 new carts and orders get a short prefix followed by 16 random bytes. Carts and orders that already exist keep their old identifier, so updating does not make historic orders harder to guess.

Backend actions skipped their token and permission checks

The remaining fixes are backend actions that trusted any logged-in administrator request. The two clean-up links on the overview page, which delete orphaned files and old carts, had no form token, so a prepared link on another website could trigger them. The test mail button on email templates had no token and no edit permission check. Sync Database, Thumbnail Creator and Clear Cache carried on after the token had expired or for users who could not manage the component, and three small backend requests that fill the content plugin’s pickers and count missing thumbnails answered anyone logged into the backend. 6.5.0 checks the token and the permission on all of them.

Which Joomla sites can install Event Gallery 6.5.0?

Only sites on Joomla 5.4 or later, or Joomla 6. Event Gallery 6.5.0 is published for those versions alone, and there is no 5.x or 4.x maintenance release with the fixes, so a site on an older Joomla core has no Event Gallery version it can update to that closes these issues. That makes the release a bigger job than it looks for a large share of the sites that need it.

Across the Joomla sites connected to mySites.guru, 91% of Event Gallery installs were below 6.5.0 on the morning it came out, and 42% were on 6.0.0, the release before. Split the affected sites by Joomla core and the picture changes: 59% run Joomla 5.4 or later and can update in a couple of minutes, but about a third are on Joomla 3 and a further 7% on Joomla 4. The single most common version among those older sites is Event Gallery 4.3.2, from January 2023, the last release published for Joomla 3.10.

For those sites, the extension update is the easy half. The real work is getting off Joomla 3, which has been end of life since August 2023, and any gallery and shop extension that stopped receiving fixes at the same time is one more reason to schedule it.

How mySites.guru flags Event Gallery below 6.5.0

mySites.guru records the exact version of every extension on every connected Joomla site twice a day. Our Joomla vulnerability database had an entry for Event Gallery below 6.5.0 on the day the release came out, so each connected site running an older component is flagged on its dashboard and in its audit, whether it runs Core or Extended. The Event Gallery page of our vulnerability list shows the rule, and the vulnerable extension list explains how the flags work across every extension we track.

The same audit checks the Joomla core version, which is the part that decides how much work each flagged site needs. A site on Joomla 5.4 or later can be updated in bulk from one dashboard. A site on Joomla 3 or 4 goes on the upgrade list instead.

Joomla CMS Version Must Be Up-to-date

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

What should I do if I cannot update Event Gallery yet?

Reduce the number of people who can be used against the site until you can. Every issue except the order identifiers needs a logged-in editor or administrator to open a page or link that an attacker prepared, so the exposure is the set of accounts with edit rights to Event Gallery and what those people browse while they are logged in.

Review who has edit permission for Event Gallery and remove it from accounts that do not need it
If no one uploads from the frontend, unpublish the frontend upload menu item
Ask editors to log out of the site before browsing elsewhere, and not to open unexpected links to the upload page
Compare the images in your shop events against your originals if anything looks different, and run a full site audit
Plan the Joomla upgrade that 6.5.0 needs, because none of this replaces the update

If you find images you did not upload, or anything else on the site you cannot account for, our Joomla hacked-site guide covers the order of work.

What we would like from Event Gallery’s release notes

The fixes are good ones. A form token on the upload, an allow-list for the Back link target, random identifiers from random_bytes() and permission checks on every backend action are the textbook answers, and the notes explain each change more clearly than most vendors manage. What is missing is a heading and a sentence.

Put the security entries under their own heading, above the features. Say which versions are affected, what an attacker could do in one line each, and that sites should update now. A CVE would put the release in front of every scanner at no cost to the vendor. None of that means publishing how to exploit anything. Until then, the safest way to read an Event Gallery release is to expand More information and search the page for “token”. If you look after more than a few Joomla sites, mySites.guru will tell you which ones need the update the morning it goes out.

YouTube Gallery for Joomla: Unauthenticated SQL Injection Fixed in 5.7.3

phil@mysites.guru (Phil Taylor) — Sat, 26 Sep 2026 14:16:55 GMT

TL;DR

CVE-2026-94130 is an unauthenticated SQL injection in YouTube Gallery, JoomlaBoat’s video gallery extension for Joomla. The Joomla CNA published it on 26 September 2026 and scored it 9.3 Critical. Every version from 1.0.0 to 5.7.2 is affected, and the fix is 5.7.3.

No login is needed. The flaw sits in the public video search and in the router that maps friendly video URLs to database rows, so anyone who can load a page with a gallery on it can reach it. Update to 5.7.3. If you are on one of the old 4.x builds, there is no 4.x patch: 5.7.3 is the fix for you too.

9.3CVSS 4.0

CVE-2026-94130Unauthenticated SQL injection in video search and routing

CriticalJoomla CNA

Any visitor can inject SQL into the queries behind YouTube Gallery's front-end search and video URLs, and read data from the Joomla database.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

No login neededPublic front endVersions 1.0.0 to 5.7.2

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

What went wrong in YouTube Gallery’s queries

The CVE describes an injection in “video search functionality and sorting” that lets an attacker inject SQL into read queries. The two fix commits in JoomlaBoat’s public repository show where. Both are cases of request input being pasted into a query string between quote marks, rather than being escaped or bound.

The search builds a WHERE clause from the ygsearchquery request parameter. Before 5.7.3 it wrapped each search term in double quotes after deleting any double quotes the visitor had typed. Stripping one character is not escaping, and SQL has more than one way to break out of a string. The 5.7.3 fix passes each term through Joomla’s $db->quote() and each column name through $db->quoteName() against an allowlist, which is the correct pattern.

The router made the simpler version of the same mistake. Its fix is two lines:

// Before: the alias from the URL is concatenated straight into the query
$db->setQuery('SELECT videoid FROM #__youtubegallery_videos WHERE alias="' . $alias . '" LIMIT 1');

// After (5.7.3): the value is quoted and escaped by the database driver
$db->setQuery('SELECT videoid FROM #__youtubegallery_videos WHERE alias=' . $db->quote($alias) . ' LIMIT 1');

A router runs on every request that uses a search-engine-friendly URL for the component, which is about as public as a Joomla code path gets. It is the same class of problem we keep finding in front-end endpoints across Joomla extensions: code written on the assumption that only the extension itself will ever call it.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

If a vulnerable version was live on a site, our guide to checking Joomla database security covers what to review afterwards.

The fix was public two months before the CVE

JoomlaBoat committed the search fix on 26 July 2026 and the router fix on 27 July, both with commit messages that say “Security: Fixed SQL injection vulnerability”. The repository is public. Anyone watching it, or diffing 5.7.2 against 5.7.3, had a map of the vulnerable code from late July. The CVE, which is what most scanners and most site owners react to, arrived on 26 September.

There is one wrinkle in that history. The search fix bumped the version to 5.7.3, and the router fix went in a day later without a second bump. So a 5.7.3 package built between those two commits would include the search fix and not the router fix. We downloaded the package JoomlaBoat serves now, dated September 2026, and it contains both. If you installed a 5.7.3 in late July, reinstall from the current download to be sure.

A gap like that between fix and CVE is normal: vendors fix first and the paperwork follows. It does mean that “there was no CVE yet” was never the same as “no one knew”. When a vendor’s changelog or commit history says “security”, treat the update as a security update on the day it ships.

Here is where the sites we monitor stand on the day the CVE was published: not one connected Joomla site runs YouTube Gallery 5.7.3 yet. Every install we can read a version from is on an affected build.

Is my Joomla site affected by CVE-2026-94130?

If a Joomla site has YouTube Gallery installed at any version below 5.7.3, yes. That includes the 5.x releases up to 5.7.2, the old 4.x free builds, and anything older. The installed component shows up in Joomla as “YouTube Gallery” or “Youtube Gallery”, with the element com_youtubegallery, and its author may read JoomlaBoat.com, Ivan Komlev or Design Compass corp depending on its age. They are all the same extension.

The extension ships with a content plugin, a module and an editor button, but the vulnerable queries live in the component. Updating the package to 5.7.3 fixes it. The same gallery pattern, an unauthenticated injection through a public search, is behind the OS Gallery flaws we disclosed earlier in September.

Most affected installs are on the old 4.x line

Across the Joomla sites we monitor, about three in four affected YouTube Gallery installs are on a version older than 5.0, and most of those sites run Joomla 3. There is no 4.x security release. The fix for those sites is the same 5.7.3 as everyone else, and in our data 5.x builds already run on Joomla 3.10 sites. JoomlaBoat lists PHP 7.4 as the minimum.

What you should do right now

Update YouTube Gallery to 5.7.3 on every Joomla site that has it, from JoomlaBoat’s download page or through Joomla’s updater.
Check the version afterwards. In System, Manage, Extensions, the YouTube Gallery component should read 5.7.3.
If you cannot update today, disable the component, its content plugin and its module until you can. That removes the public search and the routed video URLs.
Look for administrator accounts you did not create. A SQL injection that can read the users table is a route to account takeover through password hashes and session data. Our walkthrough on finding rogue admin accounts in Joomla shows what to look for.
If the gallery is no longer used, uninstall it. An extension no one uses still answers requests from anyone who finds it.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How mySites.guru finds every YouTube Gallery install

The hard part of any extension vulnerability is knowing which of your sites run the thing, and at what version. mySites.guru keeps a live inventory of every extension on every connected Joomla site, so one search for YouTube Gallery returns every site with it installed and the version each one runs.

We added CVE-2026-94130 to our vulnerability database on the day it was published, so every connected site below 5.7.3 is flagged on its dashboard now, without anyone having to go looking. The mass updater then pushes the update to all of them from one screen. That is part of the subscription, and it works the same way across a portfolio of Joomla sites of any size.

Why old video galleries keep turning up in security advisories

Video and gallery extensions tend to be installed once, when the site is built, and then forgotten. They keep working, so no one opens the extension manager to look, and the version falls further behind every year. The version spread we see for YouTube Gallery shows it clearly: installs dating back to the 1.x and 2.x releases, and a big block of sites still running a 4.x build that has not changed in years.

It has happened to this component before. CVE-2014-4960, published in July 2014, was an unauthenticated SQL injection in the same component, through its listid and themeid parameters, affecting 4.x through 4.1.7. Twelve years on, we still see a handful of connected sites running builds older than that.

Those old installs are what an attacker scanning for a newly published CVE finds first. An unauthenticated front-end SQL injection needs nothing but the URL of a page that shows a gallery. If you manage client sites, this is the kind of extension worth auditing for, whether or not anyone remembers adding it.

If a site has already been hit, or you would rather someone else clean it up, fix.mySites.guru patches the site, audits it for backdoors and returns it to you for a single fixed fee. Our Joomla hacked guide covers what to check yourself.

Disclosure and credit

We did not find this flaw, and it is one of a long run of Joomla extension security issues this year. The CVE record credits Osman Hussein, Krzysztof Zając of CERT Polska, and Dick Snel of onvio.nl as finders, and was published by the Joomla CNA on 26 September 2026. We have seen no report of this flaw being exploited in the wild, and it is not on CISA’s Known Exploited Vulnerabilities list as of the date of this post. The fix is YouTube Gallery 5.7.3.

Timeline

2026-07-26 Search query fix committed to JoomlaBoat's public repository The commit is titled "Security: Fixed SQL injection vulnerability in search functionality" and bumps the version to 5.7.3.
2026-07-27 Router fix committed "Security: Fixed SQL injection vulnerability in router." Both fixes are visible to anyone reading the repository.
2026-09-26 CVE-2026-94130 published by the Joomla CNA CVSS 4.0 9.3 Critical, versions 1.0.0 to 5.7.2 affected.
2026-09-26 mySites.guru flags every affected site The range is in our vulnerability database, so connected sites below 5.7.3 are flagged automatically.

Every Site in Your Account From One API or MCP Call

phil@mysites.guru (Phil Taylor) — Thu, 24 Sep 2026 21:21:36 GMT

Since we published the mySites.guru API and the MCP server that lets Claude manage your sites, many hundreds of digital agencies have created clients that read from their mySites.guru accounts. Some feed an internal dashboard, some post a morning report into Slack, and a lot of them are Claude conversations asking which sites need work today.

Most of those integrations are well behaved. A few are not. We give every access token a generous 1,000 requests an hour, and some clients spend it by walking through every site in the account, one request per site, every minute, around the clock, and getting back the same answer each time because nothing has changed since the last lap.

So today we are adding a site summary endpoint to the API, and the matching list_site_summaries tool to the MCP server. One call returns a complete summary of every site in your account. Where an integration used to make thousands of calls, it now makes one.

Why polling every site every minute tells you nothing new

The data behind the API does not change every minute. mySites.guru collects it on a schedule: each connected site is snapshotted twice a day, audits run daily, weekly or monthly depending on how you have set them up, and backups run on whatever backup schedules you have created. Between those points, asking again returns what you already have.

Take an agency with 200 sites that loops through them every minute. That is 12,000 requests an hour against a 1,000 an hour allowance, so the loop hits the limit about five minutes into each hour, starts collecting 429 Too Many Requests responses, and spends the next 55 minutes locked out, including for the requests that would have done something useful, such as triggering a backup. Slow the loop to every fifteen minutes and it fits, just, at 800 requests an hour, with almost nothing left for anything else. Either way it asks about each site somewhere between 96 and 1,440 times a day, for data that a snapshot refreshes twice.

Those requests are not free on our side either. Every one of them is authenticated, checked against your team permissions and served from the same database the dashboard uses, for every mySites.guru customer at once.

Snapshots run twice a day. Poll accordingly.

One summary call every few hours sees every change a per-site loop would, for a fraction of the requests.

What the site summary endpoint returns

GET /api/v1/sites/summary returns one row per site, built entirely from data mySites.guru already holds. It makes no live call to any of your sites, so it is quick even on the largest accounts, and it costs one request from your hourly allowance whether you manage five sites or five hundred.

Each row answers the questions agencies were making one request per site to ask:

Identity: The site hash_id, URL, friendly name, platform, your tags, and a manage_url that opens the site in the mySites.guru dashboard.
Versions: The CMS, PHP and database versions, and the mySites.guru connector version, as recorded at the last snapshot.
State: Whether the site is connected, paused or flagged as hacked.
Snapshot: When the site was last snapshotted, how many days ago that was, and a handful of facts from that snapshot: debug mode, caching, user registration, offline mode, super admin count, admins without two-factor authentication, and malicious cron jobs.
Audit: When the last audit ran, its id (ready to pass to the audit endpoint for the full result), and whether you have looked at it yet.
Backups: When the most recent backup started and, separately, when the most recent backup finished.
Updates: How many updates are waiting and whether a core update is available.
Vulnerabilities: How many installed extensions or plugins have known vulnerabilities, and how many known vulnerabilities affect the core version.
SSL: The certificate expiry date and the days remaining, which goes negative once it has lapsed.
Attention: A needs_attention flag and the list of reasons behind it.

There are two backup times because the start time is written when a backup begins, so on its own it cannot tell you whether the backup finished. last_backup_completed comes from the backup records themselves and is the one to trust when a client asks whether last night’s backup worked.

Sites that are not WordPress or Joomla, the ones connected as general websites, return null for updates, vulnerable extensions and snapshot facts, because there is no CMS to count them on.

A request and a response

GET https://manage.mysites.guru/api/v1/sites/summary?needs_attention=true
Authorization: Bearer eyJ...

{
  "data": [
    {
      "hash_id": "aB3xY9",
      "url": "https://acme.example.com",
      "friendly_name": "Acme Corp",
      "platform": "Joomla",
      "manage_url": "https://manage.mysites.guru/en/sites/manage/aB3xY9",
      "tags": [{ "slug": "retainer", "name": "Retainer", "color": "#0e1116" }],
      "version": "5.3.3",
      "php_version": "8.3.24",
      "db_version": "8.0.43",
      "connector_version": "2026.09.1",
      "is_connected": true,
      "is_paused": false,
      "is_hacked": false,
      "last_snapshot": "2026-09-24T06:12:40+00:00",
      "snapshot_age_days": 0,
      "last_audit": "2026-09-21T02:03:11+00:00",
      "last_audit_id": "k9Qm2T",
      "audit_unread": true,
      "last_backup_started": "2026-09-24T01:00:02+00:00",
      "last_backup_completed": "2026-09-23T01:04:57+00:00",
      "updates_available": 4,
      "core_update_available": false,
      "vulnerable_extensions": 1,
      "core_vulnerability_count": 0,
      "ssl_expiration": "2026-11-02T23:59:59+00:00",
      "ssl_days_remaining": 39,
      "needs_attention": true,
      "attention_reasons": ["updates_available", "vulnerable_extensions"],
      "snapshot": {
        "id": "Zp7Lr4",
        "debug_enabled": false,
        "cache_enabled": true,
        "user_registration_enabled": false,
        "offline_mode": false,
        "super_admin_count": 2,
        "non_2fa_admins": 1,
        "malicious_cron_jobs": 0
      }
    }
  ],
  "meta": {
    "total": 1,
    "scope_total": 87,
    "generated_at": "2026-09-24T09:30:00+00:00",
    "stale_snapshot_days": 2,
    "counts": {
      "hacked": 0,
      "updates_available": 1,
      "core_update_available": 0,
      "vulnerable_extensions": 1,
      "core_vulnerabilities": 0,
      "disconnected": 0,
      "stale_snapshot": 0,
      "paused": 3,
      "needs_attention": 1
    },
    "summary": "1 of 87 sites need attention: 1 with updates, 1 with vulnerable extensions."
  }
}

Look at the meta block before the rows. counts totals every reason across the whole account, and summary puts it in a sentence you can post straight into a Slack channel or a morning email. The acme row also shows why the two backup times are separate: last night’s backup started but has not finished, so the last completed one is from the night before.

How do I narrow the summary down?

Every parameter is optional, and with none of them the summary returns every site in your account, paused ones included. They work the same way on the REST endpoint and on the MCP tool.

needs_attention: Set to true to return only the sites that need attention. The meta counts still cover the whole account, so you still get "4 of 120 sites need attention".
platform: Joomla, Wordpress or Generic.
tag: One of your tag slugs, for example a client or a retainer tier.
hash_ids: A comma-separated list of up to 100 site hash_ids, for when you only care about a handful of sites.
include_paused: Defaults to true. Set it to false to leave paused sites out altogether.
sort: name (the default), last_snapshot or last_backup_completed (oldest first, with never-run sites at the top), or updates (most first).

sort=last_backup_completed puts the sites with the oldest completed backup, and any that have never completed one, at the top. That is the list to read before a client asks about their backups.

What counts as needing attention?

A site needs attention when it is not paused and at least one of seven things is true. Each row lists the reasons that applied in attention_reasons, so you can route them differently: a hacked site pages someone, four pending updates can wait for the Tuesday maintenance window.

hacked: mySites.guru has flagged the site as hacked.
updates_available: At least one extension, plugin or theme update is waiting.
core_update_available: A newer WordPress or Joomla release is available.
vulnerable_extensions: An installed extension or plugin has a known vulnerability.
core_vulnerabilities: The installed WordPress or Joomla version has known vulnerabilities.
disconnected: mySites.guru cannot currently reach the site through its connector.
stale_snapshot: The site has never been snapshotted, or its last snapshot is more than two days old.

Paused sites never count as needing attention. You paused them on purpose, usually because the client has left or the site is mid-rebuild, and a report that shouts about them every morning trains everyone to ignore the report. They still appear in the list unless you pass include_paused=false, and meta.counts.paused tells you how many there are.

Using the summary from Claude and other MCP clients

The MCP server exposes the same thing as the list_site_summaries tool, so any AI client connected to your mySites.guru account can call it. Nothing needs setting up: the next time your client lists the server’s tools, it is there.

AI clients gain the most from it. Ask Claude “which of my sites need attention?” with only list_sites and get_site available, and it does what the looping scripts do: fetch the list, then open each site in turn. On a large account that is hundreds of tool calls, a long wait, a rate limit that runs out halfway through, and a conversation stuffed with detail it did not need. With list_site_summaries it is one call.

The tool’s own description tells the client to start with needs_attention=true on accounts with a lot of sites and then narrow down by platform, tag or specific sites. Questions like these now take a single call:

“Which of my sites need attention, and why?”
“Which client sites tagged retainer have not completed a backup this week?”
“List every Joomla site with a vulnerable extension.”
“Which sites have an SSL certificate expiring in the next 30 days?”

From there the client can open the full audit for any site that looks wrong, or trigger the backups and updates it finds are missing, and it still has almost all of its hourly allowance left to do it.

A polling pattern that fits inside the rate limit

If you are running one of the loops described above, here is the replacement. It uses a fraction of the allowance and tells you more.

Call GET /api/v1/sites/summary?needs_attention=true on a schedule. Every two to four hours is plenty, given snapshots run twice a day.
Read meta.summary and meta.counts for the headline, and post it wherever your team looks. It is the API version of the morning routine we recommend for checking sites.
For each row that needs attention, act on the reason: open the audit with last_audit_id, send a person to manage_url, or trigger the update or backup through the API.
Only fetch full site detail for the handful of sites you are acting on.

In a shell, the whole morning report is two commands:

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://manage.mysites.guru/api/v1/sites/summary?needs_attention=true&sort=updates" \
  | jq -r '.meta.summary, (.data[] | "\(.friendly_name): \(.attention_reasons | join(", "))")'

That is one request, where the same report built from per-site calls would cost one request per site. Each response also has generated_at, so if you cache the result in your own dashboard you can show your team how old the numbers are.

The rate limit has not changed

Each access token still gets 1,000 requests an hour, and a summary call costs one of them. Go over and the API returns 429 Too Many Requests with a Retry-After header telling you how many seconds to wait. Well-behaved clients read that header and back off rather than retrying straight away.

What the site summary leaves out

The summary only returns what mySites.guru already has on file, and that shapes what is not in it.

Live data. Every value is as fresh as the last snapshot, audit or backup, and no less. If you need to know what a site looks like this second, trigger a snapshot and read the result when it finishes.
Uptime status. Whether a site is up right now comes from uptime monitoring, which lives outside the data the summary reads, so it would need a live lookup per site, the cost this endpoint exists to avoid.
Paging. You always get the full filtered set, with meta.total telling you how many rows came back. The filters are how you keep a response small.
Any change to list_sites. GET /api/v1/sites and the list_sites tool behave as they did yesterday, so integrations you have already built keep working.

The summary follows the same permissions as everything else in the API. A token only sees the sites its user can see in the dashboard, and a team member restricted to certain sites gets a summary of those sites and nothing else, as described in our post on managing sites with your whole team.

The API is still in beta

We reserve the right to make changes to the API while it is still in beta, and we may increase or decrease API rate limits as we see different traffic patterns. Any client that is constantly maxed out or abusing its permissions will be terminated instantly.

The dashboard already knows all of this

Every field in the summary is something mySites.guru collects for you anyway, unattended, on each connected site, and the API returns it in one piece. If you are weighing up building your own monitoring, the loop that asks for the data is the easy part. Collecting it in the first place is where the work is.

That work is all part of the subscription. The twice-daily snapshots record every version, setting and extension. The vulnerable extension list turns those versions into a warning the morning a flaw is published. Scheduled audits scan for hacked files and backdoors, real-time alerting tells you when a file changes or an unfamiliar admin logs in, and scheduled backups run whether anyone remembers them or not. The site summary is the one call that reads all of it back.

If you already have an API client, the endpoint is live on your account today. If you do not have an account yet, run a free audit on one of your sites, or see the plans and connect all of them.

AcyMailing 11.1.0 Fixes Two Security Flaws

phil@mysites.guru (Phil Taylor) — Thu, 24 Sep 2026 19:31:43 GMT

Acyba released AcyMailing 11.1.0 for Joomla and WordPress on 24 September 2026, and it is a security release. Two lines in the AcyMailing changelog say so, if you know where to look. Our reading of the code diff between 11.0.5 and 11.1.0 puts both fixes at the serious end: one let anyone able to email a monitored mailbox write a file of any type, PHP included, into the web root, and the other let a subscriber delete files outside the upload folder, configuration.php included.

The release came with no CVE, no blog post, no advisory and no announcement. The two fixes are one-line entries filed under Bug fixes, between a List-Unsubscribe header fix and a translation fix, and the only sign that they concern the Enterprise edition is a small coloured dot at the end of each line whose meaning appears only when you hover over it.

Update, 26 September 2026: both flaws now have CVEs

The Joomla CNA published a CVE for each fix two days after the release. CVE-2026-94132 covers the mailbox actions file write and is scored CVSS 4.0 9.5 Critical, a little above our provisional 9.2 because the CNA also rates the impact on systems beyond the vulnerable one as high. CVE-2026-94131 covers the custom field file deletion at 8.3 High, the score we gave it. Both records list every AcyMailing version up to 11.0.5 as affected and 11.1.0 as the fix, which matches our reading of the diff. The records name the Enterprise edition, and our advice for Starter installs does not change: update them too. mySites.guru’s AcyMailing rule now lists both CVE ids.

What to do now

Update AcyMailing to 11.1.0 on every Joomla and WordPress site that runs it, Starter installs included. If you cannot update today, remove file-type custom fields from public forms, switch mailbox actions and bounce handling to IMAP, and stop PHP executing in media/com_acym/upload/. Then update. If the site uses AcyMailing add-ons, check them after updating: one is already known to cause a fatal error.

TL;DR

AcyMailing 11.1.0 fixes two security flaws that affect every earlier version with the features enabled
Mailbox actions in POP3 mode (CVE-2026-94132): MIME parts of incoming emails were saved to media/com_acym/upload/ with no extension check, so anyone who could email the monitored mailbox could write a PHP file into the web root. CVSS 4.0 9.5 Critical
File-type custom fields (CVE-2026-94131): the stored value went unchecked, and clearing the field later deleted whatever path it named, so a subscriber could delete configuration.php. CVSS 4.0 8.3 High
The technical detail below is our reading of the code diff, not reproduced on a test site, and neither flaw is our discovery
The CVEs arrived two days after the release. Before that there was no advisory and no vendor post, just two lines under Bug fixes, marked Enterprise-only by a dot you have to hover over
mySites.guru flags every connected Joomla site running AcyMailing below 11.1.0
11.1.0 changed method signatures in its add-on base class, and an older Easy Profile add-on stops the site with a fatal error. Check add-ons after updating

What the AcyMailing 11.1.0 changelog says

Here is the whole of the 11.1.0 Bug fixes list as it appears on the vendor’s site. The two security fixes are the fourth and fifth lines.

The AcyMailing 11.1.0 Bug fixes list, captured on 24 September 2026. The dots after the fourth, fifth and tenth lines are the only Enterprise marker.

Read as a site owner would, both lines sound optional. “Security for some custom fields has been enhanced” sounds like hardening. “A very specific scenario” leaves you to guess which scenario, whether it applies to you, and what happens if it does. The page does not say which versions are affected, whether a login is needed, or that one of the fixes closes a route to running code on the server.

“A security issue related to a very specific scenario has been fixed in the mailbox actions.”

Updated when someone gets round to it.

“If your mailbox actions use POP3, anyone who can email that mailbox could write a PHP file into your web root. Update now.”

Updated today.

The line on the left is Acyba's, verbatim from the AcyMailing 11.1.0 changelog. The line on the right is ours, from our reading of the code diff. They describe the same fix.

The Enterprise dot is a hover tooltip

The dot at the end of each security line is an 8-pixel circle in dark pink. It has no text next to it and there is no legend anywhere on the changelog page. Its meaning sits in an HTML title attribute, “Only in the Enterprise version”, which a desktop browser shows after you rest the mouse on it for a second or so. On a phone or tablet there is no hover, so there is no tooltip. A screen reader will not reliably announce it either.

So to learn from the changelog that 11.1.0 fixes two Enterprise security flaws, you have to notice two security lines hidden under Bug fixes, spot a dot the size of a full stop, guess it means something, and hover over it. The same changelog text is copied into the free plugin’s wordpress.org listing, where there is no dot at all.

The dot also tells you less than it seems to. It describes which features are licensed, not where the vulnerable code lives. The public AcyMailing Starter source on GitHub, which is what the free wordpress.org plugin ships, contains the mailbox helper, the POP3 library and the file-field handling at the v11.1.0 tag. The previous release makes the point better than we can. AcyMailing 11.0.5 listed “Security has been improved on image embedding in sent emails” with the same Enterprise dot, and a week later Wordfence published CVE-2026-77807, an unauthenticated arbitrary file read rated 7.5 High, against the free WordPress plugin. The dot said Enterprise, and the CVE was filed against Starter.

Our reading is that a Starter install cannot switch either feature on, but we have not tested that, and the code is there. Update Starter anyway. It is free, and the dot was wrong about 11.0.5.

How AcyMailing’s security notes changed this year

This vendor has written better security notes, and recently. In 2023 Acyba published standalone posts for its security releases, one titled Critical security patch v8.5.0: check your websites now. In March 2026, AcyMailing 10.8.2 went out with a heading of its own, Vulnerability, naming the affected range, 9.11.0 to 10.8.1, and promising details once users had time to patch. That flaw became CVE-2026-3614.

In July we reported an unauthenticated SQL injection in AcyMailing, which became CVE-2026-56292, rated 9.2 Critical by the Joomla CNA. AcyMailing 10.11.1 fixed it with one line, “A vulnerability allowing SQL injection has been patched. Updating is strongly recommended.” We screenshotted that entry on 9 July, and it sat under a Vulnerability heading. On 24 September the same line sits under Bug fixes. The only Vulnerability heading left on the whole changelog is the one for 10.8.2.

Then came 11.0.5, with an image-embedding line that became a CVE, and now 11.1.0, with two security fixes under Bug fixes and a dot. Each release has said less than the one before. Most people with more than a few sites triage updates by reading changelogs, and for them the trend is worse than any one entry, because the heading was what got a release read at all.

We made the same complaint when Helix3 shipped a critical fix as “Security Update” and when T4 Page Builder called an open mail relay “Safer recipients”. The Joomla project’s own guidance for extension developers handling a security report asks for a dedicated advisory separate from the changelog, the affected and fixed versions, and the class of flaw named in plain words. AcyMailing 11.1.0 gives the fixed version and stops there.

What the two AcyMailing 11.1.0 fixes close

Read from the code, not reproduced

Everything in this section comes from reading the differences between the AcyMailing 11.0.5 and 11.1.0 packages. We have not reproduced either flaw on a test site, and we did not find or report them: Acyba fixed them itself. The scores below are the Joomla CNA’s, from the CVE records published on 26 September. We are not publishing request shapes, because most installs have not updated.

Mailbox actions saved email attachments of any type to the web root

9.5CVSS 4.0

CVE-2026-94132Arbitrary file write through mailbox actions (POP3 mode)

Criticalthe Joomla CNA

Anyone able to email a mailbox that AcyMailing monitors over POP3 could have a file of any type, PHP included, saved into media/com_acym/upload/, inside the web root.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

No login neededNeeds POP3 without IMAPEnterprise feature

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

Mailbox actions are an Enterprise feature that connects to a mailbox and acts on what arrives: forward a message to an address or a list, subscribe the sender, unsubscribe the sender. They share the connection settings used for bounce handling, where the connection method can be IMAP, POP3, or “POP3 without IMAP extension”. The last is for hosts where PHP’s IMAP extension is not installed, and AcyMailing then parses mail with a bundled PEAR POP3 library instead.

That fallback parser is where the flaw was. Its test for “is this MIME part an image” compared the result of preg_match() with !== false. preg_match() returns 1 or 0, and false only on an error, so the test was true for every part, and every named part went down the image branch. That branch cleaned up the name before the dot but kept the extension, and never checked it against AcyMailing’s allowed file types. A part named x.php was written to disk as x.php, in media/com_acym/upload/.

The attachment path runs when the Forward action decodes a message, and an inline path needed nothing more than a Content-ID header, so the only thing an attacker needed was the mailbox’s email address. A mailbox set up to receive email and act on it is rarely a secret: it is usually a published list, reply or contact address. The IMAP code path already checked extensions, which is why the vendor calls this “a very specific scenario”. Specific it is, and on a site that meets it, the result is someone else’s code running on your server.

Whether a PHP file in that folder executes depends on the server. Some hosts and hardening extensions block PHP in media folders, and many do not. We have written about why an .htaccess rule will not save a Joomla site on its own, and a file-write flaw is a good example: the rule only helps if it exists, applies to that folder, and the server honours it.

AcyMailing 11.1.0 changes the comparison to === 1, checks the allowed-extensions list on both the attachment and inline paths, and adds a new check that rejects PHP, HTML, Perl, Python, JSP and similar extensions whatever the allowed list says.

File-type custom fields let a subscriber delete files

8.3CVSS 4.0

CVE-2026-94131Arbitrary file deletion through file-type custom fields

Highthe Joomla CNA

A subscriber could store a path in a file-type custom field and have AcyMailing delete that file when the field was cleared, including files outside the upload folder such as configuration.php.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Subscription formNeeds a file custom fieldEnterprise feature

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Custom fields let an Enterprise site collect extra data on its subscription and profile forms, and one of the field types is File. In 11.0.5 and earlier, a file field accepted any string as its value, whether or not an upload had happened, so a subscriber submitting a normal subscription or profile form could set it to a relative path that climbed out of the upload folder.

When that field was later saved empty, AcyMailing deleted the old file. It built the path from the per-user upload folder plus the stored value, and the path helper it used only tidies up slashes, so ../ segments passed straight through to a plain PHP unlink(). The upload side had a smaller problem too: the stored name came from the raw uploaded filename, not its basename(). One thing we have not confirmed is whether an anonymous visitor can send the second request, the one that clears the field, against their own subscriber record, or whether that needs the profile link AcyMailing emails to subscribers. Either way, no site login is involved.

On Joomla the obvious target is configuration.php, and what deleting it does is often overstated. Joomla checks for the file on every request. If it is missing and the /installation/ folder is still on disk, Joomla sends visitors to the installer, and whoever completes it controls the site. If /installation/ was removed after setup, as it normally is, Joomla prints “No configuration file found and no installation code available. Exiting…” and the site is down until someone restores the file. So the reliable outcome is an outage, and a takeover on any site that kept its installation folder. On WordPress the equivalent file is wp-config.php, and deleting it reopens the setup wizard on any install, the route we covered in the Avada Builder file deletion post. AcyMailing Enterprise is sold for both platforms.

AcyMailing 11.1.0 only lets a file field’s value come from a real upload, runs filenames through basename() and its own filename validation, and checks that the resolved path is inside the upload directory before both writing and deleting.

AcyMailing 11.1.0 went two days without a CVE

There was none on release day. We checked the CVE list, NVD, Patchstack, WPScan, CIRCL’s vulnerability lookup and the vendor’s own site and feed on 24 September 2026 and found nothing for either fix. The Joomla CNA published CVE-2026-94132 and CVE-2026-94131 on 26 September. The wordpress.org plugin page and the Joomla Extensions Directory both list 11.1.0, with the same changelog text and no warning.

These are not our findings: we did not report them, Acyba fixed them itself, and we wrote about them because our customers run AcyMailing and the changelog did not tell them enough to act. On release day we called the missing number paperwork that had not caught up, and two days later it caught up.

For those two days, every tool that relies on CVE feeds said nothing about either flaw. A WordPress security plugin fed from a vulnerability database had no entry to warn you about, and a scanner matching versions against the CVE list had none either. On WordPress that gap is still open as we write: the vulnerability feed we import has no entry for 11.1.0 yet, because both CVEs were filed against the Joomla extension.

AcyMailing 11.1.0 can crash sites with older add-ons

Within hours of the release, Dr. Jordan Weinstein reported on X that updating to 11.1.0 took his site down with a PHP fatal error on PHP 8.4, thrown while AcyMailing loaded its Easy Profile add-on. He also traced the cause and posted the fix.

Dr. Jordan Weinstein's report and fix, posted on X on 24 September 2026.

We checked his diagnosis against the public source. In 11.0.5 the AcymPlugin base class that every AcyMailing add-on extends did not declare onAcymDeclareConditions() or onAcymDeclareFilters() at all. In 11.1.0 it declares both, along with onAcymDeclareActions(), with a typed signature: (array &$conditions): void and so on. PHP requires a child class that overrides a method to stay compatible with the parent’s declaration, and a missing : void return type is not compatible. An add-on still written the old way, onAcymDeclareConditions(&$conditions) with no types, was fine in 11.0.5 because there was nothing to clash with, and is a fatal error in 11.1.0 as soon as PHP loads the file.

Jordan saw it with Easy Profile. The same break applies to any AcyMailing add-on, from Acyba or anyone else, that overrides one of those three methods without the new types, so Easy Profile is the one we know about, not necessarily the only one.

If you hit it, the fix is in the add-on, not in AcyMailing. In EasyprofileAutomationConditions.php the declaration becomes:

public function onAcymDeclareConditions(array &$conditions): void

and in EasyprofileAutomationFilters.php:

public function onAcymDeclareFilters(array &$filters): void
{
    $this->filtersFromConditions($filters);
}

A hand edit like that is overwritten the next time the add-on updates, so check for a fixed add-on release first, and treat the edit as a stopgap until there is one. If you cannot edit files, disabling the add-on brings the site back. Do not roll AcyMailing back to 11.0.5 to get round it: that reopens both security flaws to fix a compatibility problem.

Which of your sites need AcyMailing 11.1.0?

This is the question that a changelog one-liner leaves you to answer by hand, and past a handful of sites, answering it by hand is how old versions stay installed for years.

mySites.guru records the exact version of every extension on every connected Joomla and WordPress site twice a day. Our Joomla vulnerability database has an entry for AcyMailing below 11.1.0, published the day the release came out, so every connected Joomla site running an older version is flagged on its dashboard and in its audit, and the AcyMailing page of our vulnerability list shows the rule alongside the earlier ones. We flag every edition, because from outside the site a Starter install and an Enterprise install look the same.

If you are a subscriber, the AcyMailing extension search lists every install across your account grouped by version. On WordPress the automatic flag arrives when the vulnerability feed we import catches up, which for 11.1.0 has not happened yet, so use the search to find WordPress installs today. Then update them all from one dashboard instead of one admin panel at a time. If a site shows below 11.1.0 there while its own Joomla administrator says AcyMailing is up to date, its AcyMailing update site has probably been deleted.

Finding the sites is one check. Knowing whether anything got in before you updated takes several more. The vulnerable extension list tells you which sites run a flawed version. The file scanners tell you whether anything arrived before you updated: hacked files and backdoors, suspect content, and new PHP files in folders that should only hold media. Real-time alerting tells you when a file changes or an unfamiliar admin logs in. All of it is part of the subscription and runs unattended on every connected site, which beats a checklist of logins per server forever.

Find files that match known hacks

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

If you ran AcyMailing Enterprise below 11.1.0

Updating closes both routes. It does not undo anything that already happened, so if you ran Enterprise with either feature enabled, spend ten minutes checking.

Mailbox actions in “POP3 without IMAP extension” mode: list the files in media/com_acym/upload/. Anything that is not an image or a document you recognise, and any file ending in .php, .phtml, .phar or .htm, needs a closer look. Then switch the connection method to IMAP if your host supports it, which the vendor’s own documentation recommends anyway.
File-type custom fields on a public form: check that configuration.php is present and unchanged, that /installation/ is not on the server, and that the per-user upload folders hold only files your subscribers uploaded themselves. If you do not need file fields on public forms, remove them.
Either feature: block PHP execution in media/com_acym/upload/ at the web server level as a second layer, and run a full site audit to catch anything that is not where it should be.

If you find a file you did not put there, treat the site as compromised rather than deleting the one file and moving on. Our Joomla hacked-site guide covers the order of work, and if you would rather hand it over, fix.mySites.guru cleans up a hacked site for a single fixed fee.

What we would like from AcyMailing

Acyba fixed both flaws, and from our reading of the diff the fixes are the right ones: allow-lists rather than block-lists, a path check on both write and delete, and the broken comparison corrected rather than worked around. The engineering is fine. What is missing is a sentence telling people to act on it.

A separate Security heading on the changelog, as 10.8.2 had, would do most of the work. Naming the affected versions and the conditions, “sites using mailbox actions over POP3” and “sites with file custom fields on public forms”, would let administrators decide in seconds whether a release is urgent for them. Putting the edition in visible text, not in a tooltip, would help everyone who reads changelogs on a phone. Requesting the CVEs before release, not two days after it, would have put both fixes in front of every scanner from the first morning, at no cost to the vendor. None of that requires publishing how to exploit anything.

Until then, the safest reading of any AcyMailing changelog is to ignore the headings and the dots and update. If you look after more than a few sites, mySites.guru will tell you which ones need it, the morning the release goes out.

Timeline

2026-03-13 AcyMailing 10.8.2 ships under a Vulnerability heading The changelog entry names the affected range, 9.11.0 to 10.8.1, and promises details later. The flaw was reported through Wordfence and became CVE-2026-3614.
2026-07-09 AcyMailing 10.11.1 ships under a Vulnerability heading Our unauthenticated SQL injection, CVE-2026-56292. One line, 'Updating is strongly recommended', but under its own heading. We screenshotted it that afternoon.
2026-09-03 AcyMailing 11.0.5 adds an Enterprise dot to a security line 'Security has been improved on image embedding in sent emails' is filed under Bug fixes with the Enterprise-only dot.
2026-09-11 CVE-2026-77807 is published against the free WordPress plugin Wordfence records the image-embedding fix as an unauthenticated arbitrary file read, CVSS 3.1 7.5, in the wordpress.org plugin up to 11.0.4. The line with the Enterprise dot described a flaw in the free build.
2026-09-24 AcyMailing 11.1.0 ships with two security one-liners under Bug fixes Both have the Enterprise dot. No CVE, no advisory, no blog post. On the same day the 10.11.1 SQL injection line is listed under Bug fixes too, not under the Vulnerability heading it had in July.
2026-09-24 mySites.guru flags every connected Joomla site below 11.1.0 Every AcyMailing install below 11.1.0 is flagged, whatever the edition, because Starter and Enterprise look the same from outside.
2026-09-26 The Joomla CNA publishes CVE-2026-94132 and CVE-2026-94131 The mailbox file write is scored 9.5 Critical and the file deletion 8.3 High, both for every version up to 11.0.5. mySites.guru adds both ids to its AcyMailing rule the same afternoon.

EasyStore 3.0.1 Fixes Seven Security Flaws mySites.guru Found in 3.0.0 on Release Day

phil@mysites.guru (Phil Taylor) — Wed, 23 Sep 2026 11:39:43 GMT

EasyStore is JoomShaper’s ecommerce extension for Joomla: products, cart, checkout, orders and coupons. JoomShaper released EasyStore 3.0.0 on 10 September 2026, and within hours of it going out we had found seven security flaws in it during a code audit for mySites.guru customers. We reported them privately that day. EasyStore 3.0.1, released on 23 September, fixes all seven.

The one that matters most to a shop owner needs no login. EasyStore’s guest checkout could be asked for any guest customer’s saved shipping address by email address, and it answered: name, street address, city, postcode, country and phone number, to anyone.

TL;DR

Update EasyStore to 3.0.1 now. Every version below it is affected, Free and Pro: we reported the flaws against 3.0.0 and the same code is in 2.0.1, so older 2.x shops are exposed too
The worst needs no login at all: the guest checkout lookup returned a guest customer’s full shipping address and phone number to any visitor who supplied their email address
Five are in the administrator side: two SQL injections, no CSRF protection across the admin API, a configuration update that rewrote the site’s mail sender with no token check, and an edit permission check that always returned yes
The seventh affects logged-in customers, whose reviews a hostile page could post because the CSRF check was commented out
JoomShaper handled this one well, sending us a build to verify before release and shipping 3.0.1 with a Security section listing seven reserved CVE IDs
mySites.guru flags every connected site on an affected version, so you do not have to check each shop by hand

The seven flaws, and who can reach them

Whether a flaw needs a login decides how urgent it is, so here they are grouped that way, worst first.

#	Flaw	Who can exploit it	What it exposes
1	Guest checkout customer lookup (IDOR)	Anyone, no login	A guest customer’s name, address and phone number
2	SQL injection in media image deletion	An administrator session	The database
3	SQL injection in coupon bulk update	An administrator session	The database
4	No CSRF check on the admin API	A logged-in admin who opens a hostile page	Product, order, customer and settings changes
5	Configuration update with no CSRF or access check	A logged-in admin who opens a hostile page	The site’s mail sender name and address
6	`allowEdit()` always returns true	Any administrator	Edits Joomla’s permissions should block
7	CSRF check commented out on reviews	A logged-in customer who opens a hostile page	Reviews posted in their name

The Joomla CNA’s CVSS 4.0 scores put the media SQL injection and the allowEdit() bypass highest at 8.6 High, then the customer lookup and the coupon SQL injection at 8.2 High, the admin API and configuration CSRF at 7.2 High, and the review CSRF at 5.3 Medium. We still rank the customer lookup first because it is the only one an anonymous visitor can use. The cards under Disclosure and severity show each vector.

1. Any visitor could look up a customer’s address by email

EasyStore’s checkout has a helper that fills in the shipping form for a returning guest. When a guest types their email address, the browser sends it to task=checkout.searchGuestUser and gets the saved address back.

The controller took the email from the request, looked up the matching row in the guest customers table and returned its stored shipping address as JSON. There was no login check, no session check and no token, and nothing tied the request to the person who owned the address. Anyone could send the same request, from anywhere, with any email address.

So a customer’s name, street address, city, postcode, country and phone number were one request away for anybody who knew or guessed their email. Email addresses are not secrets: they leak in breaches, sit on business cards and can be bought in bulk. An attacker with a list could test every address on it against a shop and keep the ones that returned a home address, which is also a reliable way to learn who shops there. We confirmed this live on our own test install.

In 3.0.1 the endpoint returns nothing at all and is marked as deprecated, with a code comment giving the personal data exposure as the reason. That is the right fix: the feature cannot be made safe without proving who is asking, and proving that is what logging in is for.

A lookup like this leaves no trace

Reading customer data writes nothing: no file changes, no new admin account, nothing a file scan would catch. If a shop with real guest customers ran EasyStore below 3.0.1, treat guest shipping details as potentially read, and check with whoever handles data protection for the business whether it has to be reported.

2 and 3. SQL injection in media deletion and coupon bulk update

Two admin endpoints built a SQL IN() list by gluing request values straight into the query. Media image deletion took an ids string, split it on commas and put the pieces into WHERE id IN (...) unchanged. Coupon bulk update did the same with a cid[] array.

Both need an administrator session. That sounds like a high bar, but administrator accounts are the ones that get phished, reused across sites and shared with contractors, and a SQL injection turns “can manage the shop” into “can read or change anything in the database”, including tables that have nothing to do with EasyStore. In 3.0.1 both paths convert every id to an integer and pass them through Joomla’s parameterised whereIn(), which is the correct, complete fix.

4 and 5. Admin changes a hostile page could trigger

Cross-site request forgery (CSRF) is the attack where a page on another site makes the victim’s browser send a request to yours without them knowing. The browser attaches the victim’s session cookie, so the request arrives logged in. Joomla’s defence is a form token that another site cannot know, and every state-changing request is supposed to check it.

EasyStore’s admin API controller did not check the token globally. Only its products() method did. Every other admin AJAX endpoint (media, coupons, customers, orders, tags, brands, categories, reviews, settings and collections) accepted state-changing requests without one. The configuration endpoint was a separate case of the same problem: it wrote the site’s sender name and email address into Joomla’s configuration.php with no token check and no access check.

This is why “needs an administrator” undersells these two. The attacker does not need an admin account. They need an administrator who is logged in to open a link, which is an easier thing to arrange. A changed mail sender tends to go unnoticed until password reset emails start behaving strangely.

In 3.0.1 the admin API checks the token for every POST, PUT, PATCH and DELETE request, and the configuration update now requires the right request method, admin permission and a valid token.

6. A permission check that always said yes

Joomla lets a site owner restrict who can edit what, down to individual records. Controllers ask for that decision through allowEdit(). EasyStore’s admin API overrode it like this:

protected function allowEdit($data = [], $key = 'id')
{
    return true;
}

So every edit routed through that controller skipped Joomla’s asset permissions entirely. A shop manager the owner had restricted could edit anything the API could reach. In 3.0.1 the method asks EasyStore’s access control class instead.

7. Reviews posted in a customer’s name

The storefront review endpoint already had the right CSRF check written, and it was commented out:

// Note: Uncomment CSRF check if frontend explicitly attaches standard Joomla token to requests
// if (!\Joomla\CMS\Session\Session::checkToken('request')) {
//     $this->sendResponse(['status' => 'error', 'message' => Text::_('JINVALID_TOKEN')], 403);
//     return;
// }

A hostile page could post reviews under any logged-in customer who visited it. It is the least serious of the seven, but fake reviews under real customer names are a reputational problem for a shop, and the fix was already sitting in the file. 3.0.1 enables the check and restricts the request method.

What JoomShaper got right this time

In July we reported three flaws in EasyStore 2.0.1. JoomShaper fixed them quickly, but shipped 2.0.2 with the fixes worded as routine changelog lines, with no security wording at all. This release was handled differently.

JoomShaper sent us the fixed build, Free and Pro, and asked us to confirm it before releasing. We did, against the code, and all seven were closed. Then 3.0.1 went out with a separate Security section that names each flaw by type and cites a CVE ID for each one:

A shop owner reading that knows it is a security release. The word “unauthenticated” is right there on the first line. Compare it with July, when the only hint that 2.0.2 closed a database-wide SQL injection was a line about “strict allowlist sanitization for product list sorting options”.

The changelog itself credits no one for finding the flaws. The CVE records do: all seven, published by the Joomla CNA the same evening, name Phil Taylor of mySites.guru as the finder, and they confirm the pairing of CVE IDs to fixes shown above.

Is 3.0.1 the end of it?

For the seven flaws in this post, yes: every one is fixed in 3.0.1’s code. Reading 3.0.1 to confirm those fixes, we also found further issues that this release does not address. We are not publishing any detail about them.

That should not stop anyone updating. 3.0.1 closes everything described above, including the one any visitor could exploit, and staying on 3.0.0 or 2.x leaves all seven open. When there is more to say, we will say it here.

How do you update EasyStore safely?

Take a backup first. If you use mySites.guru, take a snapshot or run a full backup before touching a live shop.
Update to 3.0.1. On one site, use Joomla’s System, Update, Extensions screen. Across several, use the mySites.guru mass updater to push it to every shop at once.
Confirm the version. Check the site’s extension list shows EasyStore 3.0.1 or later.
Check the mail settings. In Joomla’s Global Configuration, confirm the From Email and From Name are what you set, since the configuration flaw could change them.
Review your administrator accounts. Several of these flaws were reachable through an administrator’s session, so look for accounts and changes you do not recognise.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How do I find every EasyStore shop I manage?

On release day, every EasyStore install in the mySites.guru database with a readable version number was on an affected version. Well over half were already on 3.0.0, less than two weeks after it came out, which says something good about how quickly EasyStore shops update. It also means the flaws reached most shops almost as soon as they shipped.

The first question after a release like this is which of your sites run the thing. mySites.guru keeps a live inventory of the extensions, plugins and templates on each connected Joomla and WordPress site. Search for EasyStore once and you see each shop running it and the version each one is on.

We added the affected range, every version below 3.0.1, to the mySites.guru vulnerability database today, so every connected site still on a vulnerable EasyStore is flagged on its dashboard without anyone searching. The same database lists the Joomla extension vulnerabilities we track, with the affected versions for each.

What else mySites.guru checks on a Joomla shop

EasyStore is one extension. A typical Joomla shop runs dozens, and each has its own release notes, its own version numbering and its own idea of what counts as a security release. No single check covers that. It takes several running together:

Vulnerable extension detection compares installed extensions against the known-vulnerable ranges and flags the site as soon as one matches. That is how today’s EasyStore rule reaches every connected shop at once.
Rogue administrator detection lists super users you did not create, which is where admin-side flaws tend to leave their mark.
File scanning checks every file against a pattern library of roughly 1,500 malware signatures and looks for files that can accept uploads.
The mass updater pushes the fixed version to every affected site from one screen once you know which ones they are.

If a shop has already been hit, fix.mySites.guru cleans it, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day. Non-subscribers get a free month with it.

Start with a free audit on one site to see what it finds, or see the plans and connect every site you manage.

Disclosure and severity

We found all seven flaws reading EasyStore 3.0.0’s code and confirmed the unauthenticated customer lookup live on our own test install. They were reported privately to JoomShaper on 10 September 2026, with the Joomla Security Strike Team copied, and nothing was published until the fix shipped.

The weakness classes are an insecure direct object reference (CWE-639) for the customer lookup, cross-site request forgery (CWE-352) for the review, admin API and configuration flaws, SQL injection (CWE-89) for the media and coupon endpoints, and incorrect authorization (CWE-863) for allowEdit().

These are the Joomla CNA’s CVSS 4.0 scores from the published records, which replace the provisional scores we gave when this post first went up. Worst first:

8.6CVSS 4.0

CVE-2026-90901Authenticated SQL injection in media image deletion

HighJoomla CNA record, published 23 September 2026

SQL injection in media image deletion. An administrator session can read or change anything in the site database.

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

8.6CVSS 4.0

CVE-2026-90904ACL bypass in administrator API record editing

HighJoomla CNA record, published 23 September 2026

allowEdit() always returns true. Any administrator can edit records that Joomla's asset permissions should stop them editing.

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

8.2CVSS 4.0

CVE-2026-90899Unauthenticated guest checkout IDOR exposing customer PII

HighJoomla CNA record, published 23 September 2026

Guest checkout customer lookup. Any visitor who supplies a guest customer's email address gets back their name, street address, city, postcode, country and phone number.

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

No login neededExploitable over the internetCustomer personal data

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:H: High: The attacker has to defeat a mitigation first
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

8.2CVSS 4.0

CVE-2026-90902Authenticated SQL injection in coupon bulk update

HighJoomla CNA record, published 23 September 2026

SQL injection in coupon bulk update. The same flaw as the media endpoint, reached through the coupon ids. The published vector says no login is needed (PR:N), which does not match the flaw: the task is only reachable from an administrator session. We will update this card if the record is corrected.

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:H: High: The attacker has to defeat a mitigation first
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

7.2CVSS 4.0

CVE-2026-90903Missing CSRF token verification across the administrator AJAX API

HighJoomla CNA record, published 23 September 2026

No CSRF check across the admin API. A logged-in administrator who opens a hostile page can be made to change products, orders, customers and settings.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N

Needs an admin to open a link

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

7.2CVSS 4.0

CVE-2026-90905Missing CSRF and access control checks in site configuration updates

HighJoomla CNA record, published 23 September 2026

Configuration update with no CSRF or access check. A hostile page can rewrite the site's mail sender name and address in configuration.php.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N

Needs an admin to open a link

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:L: Low: Some data can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

5.3CVSS 4.0

CVE-2026-90900Missing CSRF token verification on storefront product reviews

MediumJoomla CNA record, published 23 September 2026

CSRF on storefront reviews. A hostile page can post reviews in the name of any logged-in customer who visits it.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Needs a customer to open a link

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:P: Passive: Someone has to visit a page

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Field	Detail
Extension	EasyStore for Joomla (`com_easystore`), Free and Pro
Vendor	JoomShaper (joomshaper.com)
Affected versions	Everything below 3.0.1 (reported against 3.0.0, also present in 2.0.1)
Fixed in	EasyStore 3.0.1, released 23 September 2026
CVE	CVE-2026-90899, CVE-2026-90900, CVE-2026-90901, CVE-2026-90902, CVE-2026-90903, CVE-2026-90904, CVE-2026-90905, published by the Joomla CNA on 23 September 2026
CVSS 4.0	Joomla CNA: 8.6 High (media SQL injection, allowEdit), 8.2 High (customer lookup, coupon SQL injection), 7.2 High (admin API CSRF, configuration CSRF), 5.3 Medium (review CSRF)
Finder	Phil Taylor, mySites.guru
Reported	10 September 2026, to JoomShaper, with the Joomla Security Strike Team copied
Acknowledged	10 September 2026
Fix verified	22 September 2026, against a pre-release build JoomShaper sent us
Credit	Phil Taylor, mySites.guru, in all seven CVE records. None in the 3.0.1 changelog

Timeline

2026-09-10 JoomShaper releases EasyStore 3.0.0 A major release of the Joomla ecommerce extension, Free and Pro.
2026-09-10 mySites.guru reports seven flaws the same day Sent privately to JoomShaper, with the Joomla Security Strike Team copied. No public detail.
2026-09-10 JoomShaper acknowledges the report Support thanks us and passes the findings to the developers to verify.
2026-09-22 JoomShaper sends a fixed build for checking Free and Pro, with a request to confirm before release.
2026-09-22 mySites.guru confirms all seven are fixed Checked against the code of the build JoomShaper sent.
2026-09-23 EasyStore 3.0.1 ships with a Security section Seven fixes, each citing a reserved CVE ID. No reporter credit.
2026-09-23 Affected sites flagged and this post published Every connected site below 3.0.1 is flagged in mySites.guru.
2026-09-23 Joomla CNA publishes all seven CVE records Each record credits Phil Taylor of mySites.guru as the finder.

mySites.guru is shortlisted in Joomla's first J!Awards

phil@mysites.guru (Phil Taylor) — Mon, 21 Sep 2026 16:22:32 GMT

We won

mySites.guru won Your Favourite Tool in Your Joomla Workflow, announced at the Joomla World Conference in Potsdam on 16 October 2026. Thank you to everyone who voted. Read the announcement.

mySites.guru is one of five nominees for Your Favourite Tool in Your Joomla Workflow in the J!Awards 2026, the first community choice awards the Joomla project has run. The shortlist came from public nominations between 17 August and 13 September, and the five tools with the most nominations in each category went through to the vote, so if you put our name forward, thank you.

Voting closed on 11 October 2026, and the winners were announced at the Joomla World Conference in Potsdam on 16 October. Thank you to everyone who voted for us.

What are the Joomla J!Awards?

The J!Awards are the Joomla project’s community choice awards, and 2026 is the first year. In the project’s own words, they “celebrate the people, projects, extensions, and businesses helping make Joomla better”. There are eight categories in two groups. Creators and Contributors covers the favourite new feature of Joomla 6, the favourite Joomla Community Magazine article, the favourite website design built with Joomla and the Joomla influencer of the year. Tools and Services covers the favourite extension, template, hosting platform and tool in a Joomla workflow.

There is no jury. The public nominated, the most-nominated entries became the shortlist, and the nominee with the most votes in each category wins. The Joomla press release that launched the awards names its inspiration as the J!OSCARs, the awards created in 2010 at the J and Beyond conference, and that is where our history with Joomla awards starts.

mySites.guru is no stranger to winning awards - the Joomla J!OSCARs

We have been here before, under the name the service traded as until it was renamed mySites.guru in 2024. J and Beyond, the community Joomla conference that ran the J!OSCARs, gave the service four of them between 2013 and 2017:

2013: Noordwijkerhout. The J!OSCAR jury gave its Joomla! Innovation of the Year award to monitoring services, mySites.guru among them.
2014: Königstein. The J!OSCAR for Joomla Services, decided by the attendees.
2015: Prague. Joomla Services again, and again decided by the attendees.
2017: Kraków. Joomla Services for a third time, after a year off.

Each year links to the conference’s own winners page as the Internet Archive kept it, and the Joomla Community Magazine’s report from Kraków records the 2017 win. The J!OSCARs were decided at the conference, by a jury or by the people in the room. The J!Awards are the first Joomla awards where the whole community votes online, so the result depended on who took a minute to vote, wherever they were. The full awards record is on its own page.

What mySites.guru did for Joomla sites in 2026

A vote for a workflow tool should rest on what the tool does. Here is this year, in numbers from our own records:

100+

Joomla extension vulnerabilities we found and reported to their developers this year

314

Joomla extension vulnerability rules matched against connected sites

across 193 extensions

years since we started as the Joomla Health Checker

in 2012, inside the Joomla community

Counts as of 21 September 2026.

Most of the year went into security. We found and privately reported more than a hundred vulnerabilities in Joomla extensions, nineteen of them in a single month, and the responsible disclosure archive lists them. When a vendor ships the fix, it protects all the sites running that extension, whether or not their owners have heard of us. Our subscribers get the other half: the Joomla vulnerability database is matched against the extension versions on their connected sites, so “which of my sites run the vulnerable version?” is answered on the dashboard rather than by logging into each site to check.

The rest of the year went on the kind of work a workflow category is about:

A tool to find and fix the JCE profiles hack on all your sites at once.
Every known Joomla 3 security issue fixed in one click, part of the subscription, with no separate eLTS licence needed.
One-click patches for abandoned JoomShaper extensions on Joomla 3, for the sites that cannot move yet.
Forcing MFA on Super Users across the Joomla 6.1 sites you manage.
Release Radar, a free public log of new Joomla and WordPress extension releases, including commercial releases that no directory lists.

Over the summer alone we added 38 new tools and improved 40 more.

Why mySites.guru belongs in a Joomla workflow

A tool in your Joomla workflow is the one you open without thinking about it, and for the agencies who use mySites.guru that is the dashboard they check first thing. It shows all your Joomla and WordPress sites on one screen: which have updates waiting, which have failed a security check and which have gone down. From there you can update extensions in bulk and run security audits on a daily, weekly or monthly schedule, without logging into each site’s administrator one at a time.

That is the job we have done since 2012, and the Joomla multi-site dashboard and the full feature list show the rest. If you use it every day, Your Favourite Tool in Your Joomla Workflow is a fair description, and that is the case we made for the vote.

Not using mySites.guru yet?

Seeing what we would find on your own sites costs nothing. A free site audit runs the full set of checks on one WordPress or Joomla site with no card needed.

mySites.guru itself is a paid subscription: £19.99 a month for unlimited sites, with all features included, and the price has not changed since 2012. The vulnerability matching, the bulk updates and the security tools above are all part of the subscription.

The winners were announced at the Joomla World Conference on 16 October 2026, and mySites.guru won the category. Here is the announcement, and our thanks to everyone who voted.

Timeline

2026-08-17 Nominations open The Joomla project launches the first J!Awards, eight categories chosen by the community.
2026-09-13 Nominations close The five most-nominated entries in each category go through to a public vote.
2026-09-21 Voting opens at 00:01 UTC Open to everyone, no account needed, one submission per person.
2026-10-11 Voting closes at 23:59 UTC The nominee with the most votes in each category wins.
2026-10-16 Winners announced at the Joomla World Conference Potsdam, near Berlin, 16 to 18 October.

Blind SQL Injection in Gridbox's Blog Author

phil@mysites.guru (Phil Taylor) — Mon, 21 Sep 2026 09:21:19 GMT

TL;DR

Balbooa shipped Gridbox 2.20.3.1 on 21 September 2026. It fixes a time-based blind SQL injection in the blog author parameter, which lives on the public front end of any Gridbox blog and needs no login. An attacker can read your database one answer at a time, which is slow but reaches everything in it.

Every version below 2.20.3.1 is affected, which is nearly every Gridbox site in the mySites.guru database. There is no CVE and no CVSS score yet, and the vendor filed it as “security hardening”. Update to 2.20.3.1 now. If you are still below 2.20.2, you have a bigger problem than this one, covered in our two earlier Gridbox posts.

Update, 8 October 2026: Gridbox 2.20.4.0 is now the version to install

Balbooa released Gridbox 2.20.4.0 with two more security fixes: a Cross-Site Request Forgery flaw in the language installation process and a tighter path check in the image preview, reported by Sergiy Tryzhychynskyi. Both affect 2.20.3.1, so the advice below to update to 2.20.3.1 is now out of date. Update straight to 2.20.4.0. The details are in Gridbox 2.20.4.0 Fixes a Language Install CSRF and an Image Path Check.

What the flaw is

Gridbox blogs let a visitor filter posts by author, with a URL like index.php?option=com_gridbox&view=blog&author=5. That author value went straight into a database query without being turned into a number or quoted first. When user input reaches a query as raw text, an attacker can stop describing an author and start writing SQL, and the database runs it.

The fix, visible by comparing the 2.20.3.1 release against 2.20.3, is a single change in the component’s router. The parameter is now cast to an integer before it reaches the query:

// Before (vulnerable): the author value is concatenated in as-is
->where('`id` = '.$query['author']);

// After (2.20.3.1): cast to an integer first, so only a number survives
->where('`id` = ' . (int) $query['author']);

The same casting was added to the neighbouring tag, app and id parameters in the router. Casting to an integer is the correct, complete fix for a numeric identifier: after it, author=5 AND SLEEP(10) becomes the number 5 and nothing else.

Why a blind injection still reads everything

This is a blind injection, so it does not print database rows back on the page. It is time-based, which is the patient variant. The attacker phrases each question so a true answer makes the database pause and a false answer does not, then reads the answer from the response time. “Is the first character of the admin password hash an a?” Wait and see. Then the second character, and the next account, and the next table.

It is slower than an injection that dumps rows in one response, but it is not weaker. Given time, a time-based blind injection reads usernames, email addresses, password hashes, session tokens and site configuration, and it does all of it without a single valid login.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

Is my Gridbox site affected?

If any Joomla site you run has Gridbox below 2.20.3.1, yes. The current 2.20.3 build and the 2.20.2.3 build before it are both affected, and so is every older release. The fix is 2.20.3.1 and nothing lower.

Below 2.20.2 is a different, worse conversation

Sites still running a Gridbox below 2.20.2 are exposed to the July 2026 set of flaws, several of which were being exploited in the wild, including a pre-auth remote code execution and an authentication bypass that handed out Super User access. Updating to 2.20.3.1 fixes all of it at once, but treat those sites as urgent and read the 23-vulnerability write-up and the authentication bypass post for what to check.

What you should do right now

Update Gridbox to 2.20.3.1 on every Joomla site that runs it, through Joomla’s Update tab or the mySites.guru mass updater.
Confirm the version afterwards. Open System, Manage, Extensions on the site and check Gridbox reads 2.20.3.1, so a half-applied update does not leave you exposed.
Check your administrator accounts and users. A flaw that can read password hashes and session tokens is a route to account takeover, so look for accounts you did not create and sessions you do not recognise.
If you cannot update immediately, unpublish any front-end Gridbox blog view that exposes the author filter until you can, which removes the reachable path.

Find administrator accounts you never created

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit on every connected site.

Check your site for free

How do I find every Gridbox site I manage?

The awkward question after any extension flaw is which of your sites actually run the thing. Past a handful of sites, logging into each Joomla admin to read the extensions list is not realistic, and that is exactly how old versions survive.

mySites.guru keeps a live inventory of every extension, template and framework on every connected Joomla and WordPress site. Search for Gridbox once and get back every site running it, the version each is on and whether an update is waiting. Across the Joomla sites we manage, several hundred run Gridbox, which is a lot of sites to reach one at a time.

We have added the affected range, every version below 2.20.3.1, to our vulnerability database, so every connected site still on a vulnerable Gridbox is flagged automatically, and the mass updater pushes 2.20.3.1 to all of them from one screen. Finding and fixing the whole set is part of the subscription, not a separate purchase.

The third Gridbox security story in two months

This is the third security release for Gridbox since July. The authentication bypass came first, fixed in 2.20.1. Then Balbooa asked us to audit the extension and we reported twenty-three vulnerabilities, fixed in 2.20.2, several of which were already being exploited. Now an outside researcher, Studio Przy Lesie, has brought this SQL injection to Balbooa, with Cert.pl identifying it, fixed in 2.20.3.1.

Read that sequence the right way. An extension getting fixes is a sign of attention, not neglect, and the same Media Manager code has been hardened across Balbooa’s Forms and Gallery products in the same window. The lesson for a site owner is not “drop Gridbox”, it is that a popular page builder is a large attack surface, and staying current on it is not optional. The sites that get hurt are always the ones a version or two behind when the next one arrives.

No CVE, no CVSS, no advisory with a range

We did not find this flaw, so this is not our timeline to narrate. What we can say is what the disclosure does and does not tell a site owner. Balbooa’s note names the vulnerability type and thanks the reporters, which is more than the July authentication bypass changelog managed. It still ships with no CVE, no CVSS score and no statement of which versions are affected or whether the flaw is reachable without a login. A site owner reading it cannot tell how urgent it is or which of their sites are in scope.

That gap is why our own severity call and our own version range matter here. We confirmed the vulnerable parameter and the fix, and set the affected range ourselves so the sites we manage are flagged correctly today rather than whenever a CVE catches up. Cert.pl is a CNA, so a record may follow; if it does, we will map it.

Stay ahead of the next one

Extension flaws are not rare events you can respond to one at a time. There has been one for Gridbox roughly every three weeks since July, and that is one extension among the dozens on a typical Joomla site. mySites.guru watches the whole set, flags a site the moment a version it runs becomes known-vulnerable, and lets you update everything from one place.

If a site has already been hit, or you would rather someone else make sure, fix.mySites.guru patches the site, audits it for backdoors and hands it back secure for a single fixed fee, usually the same day. Non-subscribers get a free month with it.

Disclosure and severity

There is no CVE and no published CVSS score for this flaw as of 21 September 2026. Our own assessment is High: the injection is unauthenticated, reachable on the public front end of any Gridbox blog, and can read the entire database, which is limited only by an attacker’s patience rather than by any access control. We are treating it with the same urgency as an equivalent scored flaw because “no number yet” is not the same as “not serious”.

Credit for the finding goes to Studio Przy Lesie for reporting it and Cert.pl for identifying it, per Balbooa’s release note. The fix is Gridbox 2.20.3.1.

Timeline

2026-07-20 Gridbox 2.20.1 fixes an unauthenticated authentication bypass CVE-2026-61425. One cookie made any visitor a Super User.
2026-07-29 Gridbox 2.20.2 fixes 23 vulnerabilities from a mySites.guru audit Eleven CVEs, several already being exploited.
2026-09-21 Gridbox 2.20.3.1 fixes the blog author SQL injection Reported by Studio Przy Lesie, identified by Cert.pl. No CVE, no CVSS, no advisory range published.
2026-09-21 mySites.guru flags every affected site and alerts customers The affected range is in our vulnerability database, so connected sites below 2.20.3.1 are flagged automatically.

OS Gallery 6.2.7 Fixes an Unauthenticated SQL Injection and Two Authenticated RCEs

phil@mysites.guru (Phil Taylor) — Sun, 20 Sep 2026 18:48:44 GMT

OrdaSoft’s OS Gallery, a gallery extension for Joomla, has four new vulnerabilities published today by the Joomla CNA, and between them they cover the two attacker starting points that matter most in any CMS extension: an unauthenticated route straight into the database, and two separate routes from an ordinary gallery-manager account to running code on the server. If you manage a Joomla site with OS Gallery installed on any version up to 6.2.6, it needs updating regardless of who logs in or how the gallery is used.

The four split into two groups: one needs no login at all, and three need an account holding a specific permission on the gallery component. Which group a flaw falls into changes how urgently it matters to you.

How mySites.guru flags this automatically

You do not need to read the rest of this post to find out whether you are affected. mySites.guru’s extension inventory tracks OS Gallery’s installed version on every connected Joomla site, and any site on 6.2.6 or below, Light edition included, is already flagged on its own site card, no searching required. If you manage sites outside mySites.guru too, the breakdown below tells you what to check for.

Two ways from a gallery-manager account to running code on the server

The highest CVSS score of the four is a tie: CVE-2026-88857 and CVE-2026-88856 both score 9.4 Critical, and both need an account holding core.manage on the OS Gallery component, the permission Joomla grants to a gallery manager rather than a site administrator.

CVE-2026-88857 is a file upload flaw in saveWatermark(). The function copies an uploaded file into a web-accessible directory using the filename exactly as the client sent it, with no check on the file’s extension and no check on its actual content, only the Content-Type header the client claims. A gallery manager, or an attacker who has taken over one, can name the upload shell.php, set the Content-Type to image/jpeg, and the server stores it under its real name and later runs it when requested directly.

9.4CVSS 4.0

CriticalJoomla CNA · CVE-2026-88857

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

CVE-2026-88856 does not even need a file upload. The updateOSGallery() function, reached through task=update_osgallery, reads a JSON request body and takes the value of a method field, then calls it as a live PHP function using a package field from the same request as its argument. There is no allow-list of permitted function names, so anything callable with one argument is reachable, including system, exec, shell_exec and passthru.

9.4CVSS 4.0

CriticalJoomla CNA · CVE-2026-88856

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

Either one gives an attacker who already holds gallery-manager access the same shell your hosting provider has.

The search box needs no login at all

One step down by CVSS, and the only one of the four that needs no account whatsoever, is CVE-2026-88854. OS Gallery’s front-end search, delivered through the mod_osgallery_search module that ships with the extension, reads the textsearch and searchText request parameters with Joomla’s getVar(), which despite the name is not one of Joomla’s real input filters and does not touch quotes or SQL syntax, only HTML tags. The value goes straight into a LIKE clause with no escaping.

9.3CVSS 4.0

CriticalJoomla CNA · CVE-2026-88854

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

mod_osgallery_search is the kind of module that ends up on a page and gets forgotten about: a small search box next to a gallery, doing what a search box does. Anyone who can reach that page, which is anyone who can reach the site, can send a crafted search term and pull data straight out of the database with a UNION SELECT, administrator password hashes included. No login, no CSRF token, no gallery-manager account required.

A malicious actor could extract your whole database: usernames, emails, password hashes, session IDs, shopping orders, invoices, and everything else it holds. Gulp.

A second SQL injection at the same permission level

The fourth CVE, CVE-2026-88855, scores lowest of the four at 8.6 High. saveGallery() passes form data through a hand-rolled parser into Joomla’s Input object, then reads it back with filter types that do not sanitise SQL content. Values from category_names[], catOrderIds and the image-ordering fields go straight into SQL with no quoting and no integer cast, and an account with core.manage on the gallery can use it to read and write the whole database, including a UNION-based pull of the #__users password hashes.

8.6CVSS 4.0

HighJoomla CNA · CVE-2026-88855

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Who found this, and what OrdaSoft has said

All four CVEs credit the same finder, Ala Arfaoui, a security researcher whose public disclosure history up to now is entirely WordPress: more than a dozen credited CVEs, mostly cross-site request forgery and SQL injection in smaller WordPress plugins, going back several years. As far as the CVE records show, these four OS Gallery findings are the first time that work has crossed over into Joomla. Eight days later, six more records crediting the same finder covered three more OrdaSoft extensions, Real Estate Manager, Vehicle Manager and Book Library, each with an SQL injection that needs no login. On 30 September 2026 OrdaSoft shipped the same sort-order fix in a fourth extension, OS CCK, with an update server that still offers the vulnerable version. The same release fixed an unauthenticated upload flaw in OS CCK that runs PHP, CVE-2026-102427, again credited to Ala Arfaoui.

OrdaSoft’s own site has no changelog entry, no security page and no mention of any of the four CVE numbers as of publication. We could not find a public advisory, a release announcement, or any acknowledgement of the finder. The only place 6.2.7 is named as the fix is inside the four CVE records themselves. That is not unusual for a small extension vendor, most of the vendor self-fixes we cover here say considerably more than this, but it does mean the version number in this post is the only public confirmation of the fix available right now.

OS Gallery does not currently appear on the Joomla Vulnerable Extensions List, and these four CVEs are the first ever published against com_osgallery. There is no earlier history to compare the fix against.

How to check every OS Gallery site you manage

By hand, checking one site means logging in, opening the extension manager, filtering for OS Gallery, reading the version, and updating anything on 6.2.6 or below. On one site that is a few minutes. Across forty sites it is most of an afternoon, and it is the kind of afternoon where site thirty-one gets less attention than site three.

In mySites.guru, search the extension inventory once for OS Gallery and get back every connected site running it with its current version, and any site below 6.2.7 is flagged on its own site card without you searching for anything.

If a gallery-manager account on any of your sites was compromised through either RCE route, the practical next step is finding whatever was left behind. A planted PHP file does not have to look like a webshell to behave like one.

Find files capable of accepting an upload

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit.

Check your site for free

What the numbers look like across the sites we manage

As of today, the large majority of the OS Gallery installs we can see across the Joomla sites on mySites.guru are on a version below 6.2.7, which is what you would expect on the day four new CVEs are published against an extension that had none before. That is not a criticism of anyone running it. A fix released today has not had time to reach anyone, which is why we flag affected sites and email their owners rather than assuming a CVE record alone gets the word out.

OS Gallery ships a free “Light” edition alongside the paid one, and a site running it reports a version string like “6.2.5 Light” rather than a bare number. mySites.guru’s matcher strips the edition tag before comparing, so a Light install is judged on its version number the same way a Pro one is.

Timeline

2026-09-10 The four CVE identifiers are reserved The Joomla CNA reserves CVE-2026-88854 through CVE-2026-88857 for OS Gallery, ten days before any record is published.
2026-09-20 All four CVEs are published The Joomla CNA publishes all four records the same day, crediting Ala Arfaoui as the finder of all four. This is the extension's first published CVE history; no earlier CVE exists against com_osgallery.
2026-09-20 OS Gallery 6.2.7 is named as the fix All four published records name 6.2.7 as the version that resolves the flaw described in it. We could not find a public vendor advisory or changelog entry announcing the release independently of the CVE records.
2026-09-20 mySites.guru flags every affected site The detection rule covering OS Gallery 1.0.0 to 6.2.6 goes live, and every connected site running an affected version is flagged automatically on its site card.

JoomGallery 4.4.2 Fixes an Unauthenticated File Upload

phil@mysites.guru (Phil Taylor) — Sat, 19 Sep 2026 10:35:14 GMT

Install JoomGallery 4.4.2. Every 4.x release before it, from 4.0.0 up to and including 4.4.1, ships an upload service that accepts files from anyone on the internet with no login at all.

That is the short version, and if you only read one line it should be that one. For four days after publication the CVE record itself would have sent you to the wrong release; it has since been corrected, but always confirm the version reads 4.4.2 on the site itself rather than trusting a feed.

6.3CVSS 4.0

Mediumthe Joomla CNA · CVE-2026-84048

An anonymous visitor can write files into the site's temp directory, and read back or delete anyone else's upload in progress. Neither the file name nor the extension is under their control, which is what keeps this short of straightforward remote code execution on a normal server.

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N

No login neededJoomla 4, 5 and 6Fixed in 4.4.2

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:N: None: The site stays up

If you manage Joomla sites through mySites.guru, the work is already done for you. The vulnerability rule covering JoomGallery 4.0.0 to 4.4.1 is live, so every connected site running an affected version is flagged on its site card, and searching the mySites.guru extension inventory for JoomGallery gives you every site that has it with the installed version beside each one. We have also emailed the owner of every affected site directly, with their own sites listed.

For four days, the advisory named the wrong version

Here is the trap that existed between 15 and 19 September, and it is a good example of why a machine-readable security record is not the same thing as security advice.

CVE-2026-84048 was published titled Joomla Extension - joomgalleryfriends.net - Unauthenticated arbitrary file upload via the TUS endpoint in JoomGallery < 4.4.1. Read that the way everybody reads a CVE title and you would have concluded the flaw was fixed in 4.4.1.

The record’s structured affected list said something different from the start:

"versions": [ { "status": "affected", "version": "4.0.0-4.4.1" } ]

That range included 4.4.1. The two parts of one record disagreed, and the version list was the accurate one. JoomGallery 4.4.1 was released on 8 September 2026 as an ordinary bugfix release with ten non-security changes in it, and the upload service it shipped was unchanged from 4.4.0. The fix arrived ten days later in 4.4.2.

The vendor’s own advisory had it right from the start: affected 4.0.0 up to and including 4.4.1, fixed in 4.4.2. But the CVE record carried no remediation field, so anything downstream that wanted to tell you what to install had to derive it from the title. On 19 September, the day after 4.4.2 shipped, one widely-read vulnerability database was still rendering the record as “any release below 4.4.1 is considered affected”, adding “no vendor fix or workaround currently provided”, and recommending you “upgrade the JoomGallery extension to version 4.4.1 or later” - on the same page whose affected table listed 4.4.1 as vulnerable.

We reported the title mismatch to the Joomla Security Strike Team the same day. They corrected the title to < 4.4.2, and the downstream database has since re-derived its remediation advice from the fixed title too. If you are reading the CVE record today, it names the right version. The trap only ever caught whoever acted on it during that four-day window.

One artifact still reads the old way and always will: the vendor’s own GitHub release notes for 4.4.2 quote the original CVE description verbatim, so the release that contains the fix describes the flaw as affecting versions ”< 4.4.1”. Release notes don’t get revised after publication the way a CVE record does.

If you actioned this between 15 and 19 September, check what you installed

An automated feed or a scanner that derived its advice from the CVE title in that window would have told you to install 4.4.1. That version is affected. Open one of the sites you updated and confirm the JoomGallery version reads 4.4.2 before you consider this closed.

What the JoomGallery upload service actually did

JoomGallery 4.x ships a drag-and-drop multi-upload widget for the gallery, and behind it an implementation of tus, an open protocol for resumable uploads. Resumable means the upload is split across several requests on purpose: one to create the upload and get back a handle, more to append bytes at an offset, another to check how far it got. A dropped connection resumes instead of starting over, which is the right thing to want when someone is uploading five hundred photographs over hotel wifi.

The implementation is a vendored fork of an open-source tus server, wired into the component and dispatched before anything else happens in the controller. In 4.4.1 the entire precondition on creating an upload is a check that the client sent the right protocol version header:

case 'POST':
  if(!$this->checkTusVersion())
  {
    throw new Request('The requested protocol version is not supported', 405);
  }
  $this->buildUuid();
  $this->processPost();
    break;

There is no session token, no permission check and no check of who is asking. Search the whole request path at that release for checkToken, getFormToken, authorise, checkACL or getIdentity and you get nothing back, which is an unusually clean answer to the question “what was missing”.

What an anonymous visitor could do on a stock Joomla server

This is where the reporting on this flaw splits in two, and each side overstates in the opposite direction. The vendor’s page calls it critical. The record scores it 6.3 Medium. The useful answer is the list of what the endpoint permitted on a default install:

Write arbitrary bytes: Create an upload and append any content to it. The bytes are entirely attacker-chosen; only the file's name is not.
Read back someone else's upload: The server's GET handler streams an upload back to anyone who names its handle, and it is enabled by default in both releases.
Delete someone else's upload: The DELETE handler has the same absence of an ownership check as everything else.
Fill the disk: The 250MB cap was enforced against a header rather than against what was stored, and both guards in the write loop were skipped entirely by a chunked request that sends no Content-Length.

None of that needs an unusual server. It needs JoomGallery 4.3.0 or later installed and enabled.

What the endpoint would not do is give an attacker a file they could run. On creating an upload, JoomGallery generates the filename itself, as 32 hexadecimal characters with no extension and nothing appended from the request. The attacker-supplied filename in the upload metadata is only read much later, at the point the gallery finalises an image into the library, and that step runs the component’s normal permission and file-type checks that an anonymous visitor cannot pass. So the artefact left on disk is a pair of files in the Joomla temp directory:

tmp/aabbccddeeff00112233445566778899
tmp/aabbccddeeff00112233445566778899.info

The first holds whatever was uploaded. The second is a small JSON record of the upload’s state.

Why code execution needs an unusual server

Both the vendor and the CVE say code execution requires a non-standard server configuration, and that holds up.

A default Joomla tmp directory is web-readable and ships only an index.html. The bundled htaccess.txt has no rules covering it. So one of those files will happily be served to a browser. It will not be executed, because it has no extension, and both Apache with a .php handler and nginx with a location ~ \.php$ block decide what to execute by extension.

Getting one to run needs the server to have been told to execute things by something other than extension: a SetHandler bound to a directory rather than a suffix, an nginx location that passes everything to PHP-FPM, a temp path pointed somewhere a second stack executes, or a separate file-inclusion bug elsewhere on the site that will include a path the attacker can name. That last one is the realistic chain, and it needs a second vulnerability to exist first. The attacker does know the exact path, because the server hands the handle back in the response to the request that created the upload.

So: not a webshell drop on a normal LAMP stack, and the 6.3 is honest. Also not nothing, because everything in the table above happens on a completely ordinary install.

The front-end route opened in 4.3.0, not 4.0.0

The CVE and the vendor both date this to the beginning of the 4.x branch. The vendor’s wording is that the flaw “has existed since the introduction of JoomGallery 4.x”. We read the released packages for 4.0.0, 4.1.1, 4.2.0, 4.3.0, 4.4.1 and 4.4.2 to work out what changed and when, and the picture is slightly more specific than that.

The upload service has been unprotected since 4.0.0, which is what the vendor is describing. But reaching it without logging in is a separate question, and the answer changed partway through the branch:

4.0.0 to 4.2.0

Administrator only

The upload service exists with no access checks, but the only route to it is inside the Joomla administrator, behind the core.manage permission on the component.

4.3.0 to 4.4.1

Reachable by anyone

A site-side controller inherits the upload dispatch for the first time, so the same unprotected service answers requests from the public front end.

Read from the released packages at each tag. We did not exploit a running 4.2.0 install to confirm the negative, so treat the earlier band as the code's account rather than a tested one.

From 4.3.0, released in February 2026, a controller in the site half of the component extends the administrator controller that dispatches the upload service, and Joomla’s own access gate does not help, because it only checks permissions when the request is for the administrator application. That gives three front-end routes into it, all reachable without a login.

This distinction is worth having if you are triaging a backlog of Joomla sites rather than updating one. A site sitting on 4.1.1 is in better shape than one on 4.4.1, because the unprotected endpoint there needs an administrator session to reach at all. It still wants updating, and mySites.guru still flags it, both because the vendor and the CNA describe the whole branch as affected and because an endpoint with no token check is reachable through a logged-in administrator’s browser whatever else is true.

What JoomGallery 4.4.2 changed

The fix rewrites the upload service rather than patching one check into it, which is the right shape of response. Four things were added.

A session token is now required on every request that writes. The server reads an X-CSRF-Token header and compares it against Joomla’s form token with hash_equals, rejecting anything that does not match with a 403. On its own that stops a third-party page driving a logged-in administrator’s browser, though it does not stop anonymous abuse, because a guest has a session and a valid token too.

Each upload is now owned. On creation the server records an owner derived from the logged-in user id, or from a hash of the session id for a guest, and every later request comparing that owner with hash_equals before it will touch the upload. That is what stops one visitor reading, resuming or deleting another visitor’s upload.

Every upload must now name a target the requester is allowed to write to. A new authorisation step loads the gallery category or image being uploaded into and runs the component’s own permission check against it, and rejects the request when no target is given. This is the control that actually shuts the anonymous attacker out, because an anonymous visitor has no permission to add an image to a category.

The size limit is now enforced against what is being stored rather than against a header the client supplied, and the write loop’s bound no longer depends on a Content-Length that a chunked request simply omits.

One change in the same release that is easy to misread

The upload handle also changed, from an MD5 of uniqid() seeded with mt_rand() and the machine name, to bin2hex(random_bytes(16)). That looks like a weak-randomness fix and it is worth understanding as the opposite. In 4.4.1 the handle protected nothing, because anyone could create uploads freely and no request checked ownership, so a perfectly random value would have changed nothing. The patch gives the handle a security job for the first time, by pairing it with the owner check, and a predictable value would have been a real weakness under the new design. The fix is correct for what the code became, not a repair of what it was.

Three CVEs in one Joomla extension branch in under a month

This is the third CVE against the JoomGallery 4.x branch in four weeks, and the second of the three classified as improper access control.

CVE	Published	What it was	Fixed in
CVE-2026-66916	22 Aug 2026	Password-protected categories readable through the JSON view, which skipped the gate the HTML view enforced	4.4.0
CVE-2026-66917	22 Aug 2026	Stored cross-site scripting through image records, executing for every later visitor	4.4.0
CVE-2026-84048	15 Sep 2026	The unauthenticated upload service described here	4.4.2

Two different external researchers found them, which is a reasonable sign that people are now looking at this extension properly. If you updated in August and considered the matter closed, note that 4.4.0 fixed the first pair and is affected by this one.

The gap that stands out in the sequence is the three days between CVE-2026-84048 being published on 15 September and 4.4.2 shipping on 18 September. For those three days the flaw was public, complete with the endpoint’s name, and no fixed release existed. That is not the vendor being slow, six days from report to release is a good turnaround for a volunteer project, but it is a reminder that a CVE appearing in your feed does not mean a patch is waiting for you.

How to check the Joomla sites you manage

By hand, the loop per site is: log in, open the extension manager, filter for JoomGallery, read the version, update if it is below 4.4.2, then open the temp directory over FTP or SSH and look for the file pair. On one site that is five minutes. On forty it is most of a day, and it is the kind of day where site thirty-one gets a less careful look than site three.

The version part of that is what an extension inventory is for. In mySites.guru you search the inventory once for JoomGallery and get back every connected site with it installed and the version on each, and any site below 4.4.2 is flagged as vulnerable on its own site card without you searching for anything at all.

The temp directory part is the check below, which looks for exactly the kind of leftover this flaw produces.

Find files left behind in your Joomla temp directory

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs as part of the full audit, which most sites schedule weekly.

Check your site for free

One caveat worth knowing about, because it affects a small number of sites. A handful of JoomGallery installs report an empty version string in their manifest. A version that cannot be ordered against a range cannot be judged against one, so mySites.guru declines to flag those sites rather than guessing, which is the right way round but leaves you to check them yourself. If such a site runs Joomla 4, 5 or 6 then it is on the 4.x branch by definition, because 3.x does not run there, and it needs a manual look. The alert emails we sent name those sites explicitly.

What the numbers look like across the sites we manage

Two days after 4.4.2 shipped, 94% of the JoomGallery 4.x installs we can see across the Joomla sites on mySites.guru are still on an affected version. That is not a criticism of anyone: a release from two days ago that was announced on a project news page and a GitHub tag has not reached most people yet, which is the entire reason we send the emails.

The larger population is more interesting. The clear majority of JoomGallery installs we can see are still on the 3.x branch for Joomla 3, and those are not affected by this flaw, because 3.x has no resumable-upload server in it at all. Those sites have a different and larger problem, which is that they are on Joomla 3.

Updating extensions across a lot of sites

The honest lesson of this one is about the distance between a fix existing and a fix being installed, which for most agencies is measured in weeks and for some sites is measured in never. JoomGallery is incidental to it.

mySites.guru exists to close that distance. It tracks the installed version of every extension on every connected Joomla and WordPress site, matches those against a curated vulnerability database for Joomla extensions and the Wordfence feed for WordPress, and flags affected sites without anyone reading a mailing list. You can update extensions across many sites from one screen instead of logging into each, and set safe automatic updates for the extensions you trust to update themselves.

Some related reading, if this post found you because a site is already in trouble rather than because you are keeping ahead of it:

Finding hacked files and backdoors, which is where to start if you found something in that temp directory you cannot account for
Why your .htaccess will not stop a Joomla hack, which covers this exact class of problem and why server hardening is not a substitute for patching
AJAX endpoints and the CMS security blind spot, the root-cause pattern this flaw is one more instance of
How to clean up dangerous files on a Joomla server, including what accumulates in tmp and why Joomla does not always clear it

Monthly

£19.99per month

Unlimited sites, every check, no per-site pricing.

Yearly

£199.99per year

The same thing with two months off.

See the full pricing Unlimited sites on every plan, so a JoomGallery sweep across forty Joomla sites costs the same as across four.

If you would rather see it work before deciding, connect one site and run a free audit on it. It will tell you whether that site is running an affected JoomGallery, and a good deal else besides.

And if you have already found something you cannot explain in a temp directory, that is a different conversation. fix.mySites.guru is a flat £120 per incident: the site gets cleaned, audited for backdoors and handed back, usually the same day, and we screen it first so you are not charged in the rare case it cannot be fixed.

Timeline

2026-02-08 JoomGallery 4.3.0 opens the upload service to the front end A site-side controller inherits the resumable-upload dispatch for the first time. Before this release the same endpoint exists but only inside the Joomla administrator.
2026-09-12 Yugorin of Samar Group reports the flaw to the vendor The vendor's advisory credits Yugorin of Samar Group with a responsible disclosure on this date. The fix branch opens the same day.
2026-09-15 CVE-2026-84048 is published with no patch available The Joomla CNA publishes the record, scored CVSS 4.0 6.3 Medium. The title names 4.4.1 as the boundary. No fixed release exists yet, and none would for another three days.
2026-09-18 JoomGallery 4.4.2 ships the fix The release adds a token check, an ownership check and per-category permission checks to the upload service, and enforces the upload size limit it previously ignored.
2026-09-19 mySites.guru flags every affected site and emails the owners The vulnerability rule covering JoomGallery 4.0.0 to 4.4.1 goes live, and the owner of every connected site running an affected version gets a direct alert listing their sites.
2026-09-19 The Joomla Security Strike Team corrects the CVE title After we reported the title/version mismatch, the record is updated to read "< 4.4.2", and the downstream database that had been recommending 4.4.1 re-derives its advice from the corrected title.

The Malware You Thought You Deleted - Is Still Running!

phil@mysites.guru (Phil Taylor) — Wed, 16 Sep 2026 14:04:01 GMT

You fix the hacked website. You delete the webshell. You refresh the page. It is already back.

So you delete it again, watch the file disappear, and refresh once more. Back again. At this point most people start doubting the delete, then the FTP client, then the malware scanner that told them the file was there in the first place. We have watched capable developers go round that loop for an entire afternoon.

Nothing they did was wrong. The file really was deleted, every single time. The problem is that on Linux, deleting a file does not stop a program that has already been started from it, and something was still running.

This is the fourth post in a short series on where the thing rebuilding a hacked site hides. The earlier three cover the crontabs your hosting panel never shows you, Joomla’s own scheduled tasks table and five WordPress hiding places a file scan cannot reach. They are all answers to one question, which is what put the malware back. This one answers the case where nothing put it back, because the process writing the files had been running the whole time.

Why does deleting the file not stop the malware?

Deleting a file on Linux does not destroy its contents. It removes the name. The unlink system call takes the directory entry away, and the data behind it stays as long as anything still refers to it, which includes any process that already has it open or is executing it. The file is unreachable by name and entirely intact in use.

A PHP process that was started from /home/site/public_html/tmp/x.php does not re-read that script on every loop. It was parsed once, at startup, and the compiled program is held in the process’s own memory. Remove the script and the running process neither notices nor cares. It keeps running the code it already has, and if that code contains a loop that writes index.php, it keeps writing index.php.

That is the entire technique, and it is why the timing of a reinfection tells you what you are dealing with:

Back within the hour: A scheduled task is putting it back. Something on a timer woke up, ran, and rewrote the files. The crontab, the CMS scheduler or a systemd timer is the place to look.
Back on the next page load: A database-resident hook is putting it back. WP-Cron fires on visitor traffic rather than on a timer, so a busy site rebuilds the malware almost immediately.
Back within seconds, every time: Nothing is being triggered at all, because the process behind it was running the whole time. It sits in memory rewriting the file as fast as you remove it.

The third case is the one that reads as a failure of your tooling rather than a property of the attack, which is exactly why it wastes so much of an afternoon.

A self-deleting dropper leaves nothing to scan

A dropper is a small piece of malware whose only job is to deliver other malware. It does not deface your site or steal anything itself. It arrives through whatever hole was open, writes the payload that does the real work, and then gets out of the way. The name is literal: it drops something and leaves.

The malware side of this is not sophisticated, which is part of why it is common. A dropper that reaches the site starts a detached PHP process in the background, then removes its own script and the directory it was started in. From that point the attacker has a program running on your server with no file behind it. There is no file on the hard disk, there is nothing to see when you FTP and look.

The dropper does not have to be the one that removes the file, and in practice it often is not. Most people meet this the other way round: you find the webshell during a clean-up and delete it yourself, and the process it started an hour earlier keeps running from the file you have just removed. Your own tidy-up produces exactly the state the malware would otherwise have engineered for itself. That is the version in the opening of this post, and it is why the symptom reads as a failed deletion rather than as an attack.

Sucuri published the clearest public example back in 2020, in The Hidden PHP Malware that Reinfects Cleaned Files. Their sample runs itself through nohup so it outlives the request timeout, calls unlink() on its own source file, then sits in a loop hashing a target file once a second and rewriting it the instant the hash changes. It even backdates the file it restores by four hundred days and sets it read-only, so the timestamp gives nothing away. Their conclusion is the argument for this whole check: once the dropper has deleted itself, “the only way to detect this malware reinfector would be to view the running processes.”

The technique is six years old and still works, because nothing in a normal clean-up routine looks at the server’s running processes.

Every instrument you would normally reach for now reads clean, and each one is working correctly:

A file scanner reads files. There is no file.
A crontab audit reads crontabs. Nothing is scheduled, because the attacker had no need to schedule anything.
A core-file integrity diff compares what shipped against what is there, which is how an impostor file in a core folder gets caught. The process is not a file, so it does not appear in the comparison.
A malware signature database matches patterns in content. There is no content on disk to match against.

This is the same shape of problem as a backdoor that lives in a database row or the Helix3 defacement that never touches a file. The difference is that a database row can at least be read back later. A process exists only while it is running, so the evidence is gone the moment the server reboots, and so is the malware. That makes it simultaneously the easiest persistence to destroy and the hardest to find.

There is no tidy name to look this up under, which is part of why it stays obscure. MITRE ATT&CK’s closest entry, T1070.004 File Deletion, covers an attacker removing their own files but says nothing about the process that keeps running afterwards, and its detection guidance only watches for the deletion itself. “Process ghosting” is a real named technique but a Windows one, exploiting how that kernel loads an executable image, and borrowing the term here would describe the wrong mechanism. “Fileless malware” is the usual loose umbrella, though it normally means something that never touched disk in the first place rather than something that touched disk, started, and then deleted itself behind it.

What mySites.guru reads, and where it stops

Every other check we ship reads your files or your database. This one reads the server’s own running processes, because that is the only place the evidence exists.

If you have never looked at one, a process list is the server’s live inventory of what is actually executing at this instant, as opposed to the filesystem, which only tells you what is stored. Every running program has an entry, and each entry records who owns it, what started it, when it started, and which file it was launched from. Under your own hosting account that is normally the web server’s PHP workers, anything cron has started, and any background job you set up yourself.

The last of those fields is the one that matters here. The operating system records where each process was launched from, and it keeps that record after the file goes: delete the file and the entry stays, now marked (deleted). So the running process list is the one place that still remembers a file the filesystem has already forgotten.

It is one check out of 228, and on its own it will not tell you whether a site is hacked. Nor will any of the other 227. Somebody arriving here after a bad afternoon wants a single instrument that answers the question, and no such instrument exists for this problem.

On every snapshot, twice a day (snapshot vs audit explains how that differs from an audit), the connector walks the running processes under your own hosting account and reports any PHP process whose code is no longer on disk. It runs on Joomla, WordPress and generic PHP sites.

Before anything else about it, the limitation, because it is a large one.

This check is best effort, and your host decides whether it works

Reading the list of running processes needs a permission a lot of shared hosts simply do not grant to PHP. Where the host says no, mySites.guru cannot answer the question at all. On the sites reporting today that is roughly four in ten, which is not a rounding error, and it is why this check is marked BETA in the app. Those sites are told in plain words that we could not look, and why. A result here is only ever a statement about the processes running under your own account, on a server that let us read them, at the moment we looked.

We see what an attacker sees, and nothing more

That limit is a design decision rather than a gap we have not got round to yet. mySites.guru runs on your site as an ordinary PHP process, under your own hosting account. Not as root, not as a privileged user, and not as an agent you install on the server. What we can read is therefore close to exactly what an attacker who has got into your site can read, and no more than that.

That cuts both ways, and both directions matter here.

It is why the malicious process is visible to us at all. It was started by PHP through your web server, so it runs as the same user we do, and we can read its /proc entry for precisely the same reason the attacker could read ours. Same privilege level, same view.

It is also why a host that hides the process list from PHP hides it from us too. open_basedir does not apply to root, and a server administrator running ps sees everything. We are confined because we are unprivileged, which is the trade: the alternative is asking you to hand a third party root on your server, and no security check is worth that. Where we cannot look, the honest answer is to say so and point you at the two parties who do have the privilege, which is you over SSH or your host.

The same boundary is why we stop reading a process the moment we can see it is not yours. On a shared server with no per-vhost user separation, every site on the box runs as one account, so anything outside your own site’s root is reported and never offered for stopping. Other customers’ processes are none of our business, and reading them would make us the thing we are looking for.

There are three things that count as proof, and they are separate because they fail differently:

Its script has been deleted: The process was started from a PHP file, and that file is gone. This is the classic self-deleting dropper and the strongest single signal on the list.
Its working directory has been deleted: The directory the process was started in no longer exists. Malware that removes the folder it unpacked itself into shows up here, and so does a queue worker that was running while you replaced a release directory.
Its PHP binary has been deleted: The interpreter itself has been replaced. This is reported and never offered for stopping, because a host does exactly this to every running process each time it patches PHP. On its own it almost always means the server was updated.

Two further observations get attached once a process is already proven by one of those three, never on their own: that it is detached from any parent, and that its script sits in a temp directory. Both are suggestive rather than evidence, so neither can flag a process by itself.

The check is fussy about what counts as PHP, on purpose. It judges the interpreter on the binary the kernel reports, never on the command-line string, because this family of malware names its script after an ordinary server configuration file. A substring test over the command line reads that as the web server and skips straight past it.

There is a stronger reason to distrust the command line, and the Linux manual says it out loud. A process can rewrite its own arguments after it starts, so /proc/PID/cmdline is, in the manual’s words, “the command line that the process wants you to see”. The binary behind /proc/PID/exe is a kernel fact. The argument string is whatever the process typed there.

The bottom row is the check, on a server that would not let us read its process list. A grey No Data badge is not a pass, and it is not coloured like one.

What we found once we started looking

The check has been running in production since mid-September 2026. These are the figures as of 16 September, measured over the most recent snapshot for every site audited in the previous thirty days.

1 in 360

sites had a PHP process running code that is no longer on disk

Found on both Joomla and WordPress

Twice a day

every connected site has its running processes read

Joomla, WordPress and generic PHP

6 years

this technique has been publicly documented and still works

Because a normal clean-up never looks at running processes

Measured 16 September 2026 across every connected site with a snapshot in the previous thirty days, latest snapshot per site, among those whose server allowed the read.

Almost every flagged site had exactly one such process. A handful had three or four, which is what an automated reinfection loop that has been restarted a few times looks like. We found them on both Joomla and WordPress sites; the WordPress sample is far too small to draw a comparison from, so we are not going to draw one.

That hit rate is low per site and high per account. An agency looking after three hundred sites should expect to find one, and it will be the site somebody has already cleaned twice.

On roughly four sites in ten we cannot answer the question at all, because the server will not let PHP read its own process list. Around three in ten block the read entirely, almost always because open_basedir confines PHP’s filesystem functions to the site’s own directory, and /proc is not in it. About one in ten will not tell us which account we are running as, which we treat as a no rather than guessing and reading another customer’s processes.

If you are diagnosing your own server, open_basedir is not the only thing that gets in the way. CloudLinux’s CageFS, which a great deal of cPanel hosting runs, gives each account a filtered /proc showing only its own processes, which is exactly the right behaviour and does not block this check. A host that mounts /proc with hidepid=2 is doing something stricter, and a host that disables the exec family closes the last remaining route.

The other four sites in ten. This is what the check reports when the host will not let it look, and it is not a pass.

Grey is not green

A check that cannot run has to look different from a check that ran and found nothing. Those sites report that we could not look and say why, rather than showing an unearned OK badge. It is the third answer most security tooling skips, and skipping it is how a scanner ends up reporting a clean bill of health for a question it never asked.

Why this check never says HACKED

It would be easy to make this one red, and it would be wrong. A deleted working directory has a completely ordinary cause: deploy a new release by swapping a directory while a queue worker is running, and that worker is now running from a directory that no longer exists. From outside the process, that is indistinguishable from malware.

So the check reports rather than accuses. It does not feed the hacked-site flag, it ships marked BETA, and every row shows the raw evidence: the full command line, how long the process has been running, its parent, and which of the three signals fired. Something you set up is usually recognisable from its command line within about two seconds. Something you did not set up usually is not.

The command line is attacker-controlled text

A command line is arbitrary bytes chosen by whoever started the process, which makes printing it back to you a small security problem of its own. It can contain bidirectional formatting characters that reorder what you see on screen: a U+202E override can make evil.php draw as php.live, the same trick played on filenames for twenty years. Those characters are replaced with a visible marker rather than escaped, because escaping does not help when the characters are not markup.

Where a row is safely actionable there is a Stop it button, and the conditions for showing it are narrow. The process has to be detached, running under your account, traceable to this specific site, and proven by a deleted script or working directory rather than a deleted interpreter. Anything outside this site’s own root is reported and never offered for stopping, for the shared-account reason above.

Pressing the button re-checks all of it on your server at the moment you press, rather than trusting the page you are looking at. Process IDs get recycled, so the request sends back the start time and a hash of the command line it was shown, and the server will not act if either has changed. The honest failure messages are part of the design: “That process now has a parent, so something is managing it”, or “We cannot tie that process to this site, so we will not stop it”.

How do I find this across every site I manage?

Two ways, and the second is the one worth knowing if you look after more than a handful of sites.

On a single site, the check sits in the Hacked panel of that site’s audit page in mySites.guru, under the name Processes Running Deleted Code, with a BETA label next to it. The badge is the summary: a green OK, a count of processes to review, or a grey No Data if the server would not let us look. Investigate on that row reads the process list live rather than replaying the stored snapshot, because a process list is out of date the moment it is written down. You get one row per candidate with its full command line, how long it has been running, its parent, and which signals fired.

An actual finding on a connected site, pulled while writing this post. The account path is redacted and everything else is exactly as the tool reported it. The working directory is the giveaway: it is not in this site at all.

That single row contains everything this post describes, on one real site.

Three tags on that row, and only the red one is proof. The other two are the supporting observations from earlier, which is why they are grey.

The script is /tmp/httpd.conf. That is the naming trick, in the wild: a PHP script named after the Apache configuration file, so anything matching on the command line string reads “httpd” and moves on. It sits in /tmp, which is why the row also says running from a temp directory. And it is gone, which is the tag that matters, its script has been deleted.

It has been running for 182,581 seconds, which is a little over two days, and it is detached from any parent. No ordinary web request lives for two days. Whatever started it exited long ago and this outlived it.

Then the line that turned out to matter most, and it took a second look to see it. The working directory is not in this site at all. It is a second document root in the same hosting account: the development copy of the same site, sitting next door. The folder itself is components/com_finder/models/models, a doubled folder name inside a Joomla core component, which is not a path Joomla ships.

The abandoned dev copy is the way in

Put those two facts together and the incident rearranges itself. The live site is connected to mySites.guru and gets audited. The dev copy beside it is connected to nothing, gets no audits, no update alerts and no hack checks, and has been sitting there being forgotten. That is the copy that was compromised, and the process is running out of its document root.

Sharing a cPanel account means sharing a Unix user, and a Unix user that can write to one document root can write to the other. So a development copy forgotten for a year becomes a fully privileged foothold in the live site, and none of the hardening on the live site applies to it. The attacker did not need to get past anything on production. They went around it.

This is the most common version of the story, and the one worth taking away even if you never see a resident process. A staging or development copy on the same hosting account is production, in every sense that matters to an attacker. Either connect it and patch it like the real thing, or delete it.

The final line on the row is the privilege boundary from earlier, working exactly as intended: we cannot tie the process to this site’s own directory, so no Stop button is offered. That is the right call. The process belongs to a different document root, and a tool that stops processes outside the site it was pointed at is a tool that eventually stops the wrong one. Acting on this needs somebody with a view of the whole account, which means SSH or the host.

One last thing about this site, and it is the argument of this whole post in a single row. A completely separate check, on the same site and the same snapshot, found two rogue SP Page Builder icon-font assets, which is the database residue left by the unauthenticated upload exploit we traced in June. Neither check knows the other exists. Whether the two are connected is a question for the clean-up rather than something either one can answer on its own, but a site showing both is not a site where one instrument would have been enough.

Across an account, the all-sites view answers it on one page: every Joomla site reporting a resident process, and the same view for WordPress. This is the version that matters after an extension vulnerability goes public, when the question is not “is this site affected” but “which of my sites are”. It is also reachable from the command palette by searching for resident processes or reinfection.

Either route hands you the same thing, which is evidence rather than a verdict. Stopping the process is only the first of four steps, and the order they go in is the part people get wrong.

If the badge is grey, the honest next step is SSH

On a server that blocks the process list there is nothing mySites.guru can tell you here, and the section below is how you answer the same question yourself in about ten seconds with shell access. If you have no shell access either, your host can run it for you, and the question to ask them is whether any process is running from a deleted file under your account.

Find the process that is rewriting your site

mySites.guru checks every connected site for this automatically and flags it the moment it appears. It runs twice a day on every connected Joomla, WordPress and generic PHP site.

Check your site for free

Investigating a hack takes the whole toolkit

A resident process is one persistence route out of several, and an attacker who bothered to set one up has usually set up two. Investigating a compromised site is elimination across instruments, not a single lookup: you are asking the same question of the filesystem, the database, the schedulers, the user table and the server’s own running processes, and the answer only means something once all of them have answered.

That is the real argument for a toolkit rather than a favourite tool. mySites.guru ships 228 distinct checks across 15 groups, 19 of them specifically hacked-site detection, and the hack-hunting ones are spread on purpose across places you would otherwise have to visit one at a time, with a different tool and a different login for each.

The ones that matter on a reinfection, all running on every connected site, twice a day, without being asked:

The server’s crontabs, including the root-owned locations your hosting panel does not show you at all, where the cron rebuilding your site usually lives.
Joomla’s own scheduler table and WordPress’s WP-Cron events, both of which live in the database rather than in any crontab, where a file scanner has no way to reach them.
Rogue and hidden administrator accounts, so a cleaned site does not just get logged back into, listed across every site at once.
The files themselves, through two separate scanners that do different jobs.
The server’s own running processes, which is this check, and the only one of the set that looks anywhere other than your disk and your database. The full hacked-site detection group lists the rest.

Then there is the part that tells you before you go looking. The File Watch List emails you the moment a watched file changes, so a site rewriting index.php behind your back reaches your inbox rather than waiting for somebody to notice a defacement. On a reinfection that is often the first hard evidence you get, and it arrives while the process is still running and still catchable.

None of these is clever on its own, and that is the point. What they are is exhaustive and repeatable: they run unattended, across every site you manage at once, and keep running after the afternoon you spent cleaning is over. Doing the same by hand means an SSH session per server, repeated daily, forever, with a different mental checklist each time.

Treat any single green badge, this one included, as one question answered rather than a site declared clean. The site is clean when the whole set agrees, and a hacked site that has only been checked one way has not really been checked.

All of it is part of the subscription rather than a paid add-on, and the pricing is per site. If you want to see what these checks say about a site you already suspect, the free audit runs the full set once without a subscription.

How do I check for this myself over SSH?

If you have shell access, you can answer this in about ten seconds. These are the two commands worth knowing, and both need reading carefully rather than trusting.

ls -l /proc/*/exe 2>/dev/null | grep deleted
lsof +L1

The first lists every running process whose executable has been unlinked, which Linux marks with a literal (deleted) suffix on the symlink. The second lists open files with a link count of zero, which is the same idea reached from the other direction and often catches more. Swap exe for cwd to find processes whose working directory has gone.

To see what a suspicious process actually is, read its command line and its age:

cat /proc/PID/cmdline | tr '\0' ' '; echo
ls -l /proc/PID/exe /proc/PID/cwd
ps -o pid,ppid,lstart,etimes,comm -p PID

The fields come from ps(1): lstart is the full start time and etimes the elapsed seconds, which is the number you want when deciding whether something has outlived every ordinary request.

Three caveats, because this is the part where people either miss the thing or panic about the wrong thing. Without root you only see your own processes, which on shared hosting is usually what you want anyway. A parent process ID of 1 means the process was detached and reparented to init, which is normal for a daemon and expected for this kind of malware. And the deleted marker on its own proves nothing: running that first command on a well-maintained server will usually return something, because any long-lived process whose binary was replaced by a package upgrade shows the same marker. On the machine I tested these commands on while writing this, the single hit was a kernel thread, not malware.

Read the command line before you act. A PHP interpreter running an unnamed script from a directory that no longer exists, detached, started three days ago, is worth stopping. Your own backup daemon is not.

When the answer is a support ticket

Sometimes you have no route of your own, and that is the normal case rather than the unlucky one. On a properly locked-down shared server PHP cannot read the process list, shell access is disabled or restricted to a jail that shows you nothing useful, and the only party who can answer the question is the host. A hardened server blocks mySites.guru for exactly the same reason it blocks you, and neither of us should have the privilege that would get past it.

So open a ticket and ask them directly. Hosts often call these orphaned or ghost processes, so use whatever wording gets you understood, but give them the precise check as well, because the phrase on its own means different things to different administrators.

Please could you check the processes running under my hosting account for
any that are running from a deleted file. On Linux these show a " (deleted)"
marker:

    ls -l /proc/*/exe 2>/dev/null | grep deleted
    ls -l /proc/*/cwd 2>/dev/null | grep deleted
    lsof +L1

I am investigating a site that keeps reinfecting itself within seconds of
the malware being removed, which is the signature of a PHP process still
running from a script that has already been deleted from disk.

Please send me the full command line, the parent PID and how long each one
has been running BEFORE stopping anything, as that command line is the only
evidence left of what the process was.

That last paragraph matters more than the rest of the ticket. A host asked to deal with a suspicious process will very reasonably just kill it, and the moment they do, the command line, the working directory and the script path are gone for good. There is nothing on disk to go back to, so an eager clean-up removes the infection and the only description of it in the same second, which leaves you unable to tell what it was or how it got there.

Why restoring a backup does not fix this, and sometimes makes it worse

A restore replaces files and database rows. A running process is neither of those, so the restore does not reach it at all. The moment your files are back in place the process rewrites them, and you have spent an hour returning to exactly where you started. Changing every password has the same problem: the process is not logging in, it is already inside, and it keeps writing until it is stopped or the server restarts.

That much is only wasted effort. Four things make a restore actively worse than leaving the site alone while you think, and they apply to any hacked site rather than just this one.

The backup probably contains the hack. A compromise is usually found weeks or months after it happened. On the WordPress site behind our last set of checks the earliest marker we could date was five months before anyone noticed, through two rewrites of the malware. Every backup taken in a window like that has the backdoor in it, so “restore last week’s” is often just a slower way of reinstalling the attacker.
It reopens the way in. A restore rolls core and every extension back to the versions you were running before, which are the versions with the vulnerability that was exploited. Patching is usually the one part of the clean-up that was definitely working, and a restore undoes it along with the damage.
It destroys the evidence. This is the cost that shows up later. Modified file timestamps, the files that differ from core, the rogue administrator row, the scheduled task, the correlation between what is on disk and what is in the access log: a restore overwrites all of it in one move. You end up with a site that will be hacked again and nothing left to work out how it was hacked the first time.
A database restore re-arms the persistence that lives in the database. A malicious Joomla scheduled task, a WP-Cron event or a hidden administrator account are rows rather than files, and a restore brings the rows back with everything else. You can clean the filesystem perfectly and hand the attacker their re-entry in the same operation.

None of that makes backups less important. It makes the restore the wrong first instrument for a compromise. Stop what is running, find and close the entry point, then clean, and reach for a backup only to recover content you have actually lost, from a copy you can date to before the compromise rather than one that merely feels old enough.

The order matters: stop, unschedule, then clean

This is the part people reliably get backwards, and getting it backwards is what turns a twenty-minute clean-up into an afternoon.

Stop the running process first. Everything else you do while it is running can be undone by it, usually faster than you can do it.
Remove whatever restarts it. A running process is only half of the persistence. Check every crontab on the server, not just your own, the CMS’s own scheduler table and any systemd timers, or it comes back on the next run. Malicious schedules and resident processes frequently appear together.
Then clean the files. With nothing running and nothing scheduled, a deletion finally stays deleted.
Then close the entry point. A process running from a deleted file is a symptom. Something put it there, and until you find the vulnerable extension or the stolen credential, the same route is open and a second wave is a matter of time.
Check the other sites on the same account. Anything that can start a background process on one site can usually reach the sites beside it.
Reset OPcache if anything still comes back. In the stubborn cases the compiled copy is cached inside PHP-FPM, so the code outlives both the file and the process you stopped. Restarting PHP-FPM clears it, and on a host where you cannot do that, ask them to.

If you are working through this on a compromised site, the full recovery walkthroughs are here for a hacked Joomla site and a hacked WordPress site.

If a site is actively being rewritten while you work on it and you would rather hand it over, fix.mySites.guru is a fixed fee of £120 per incident, screened first so you are not charged if it cannot be fixed.

If you would rather it did not get this far again, connect the sites you manage to mySites.guru and let the checks above run twice a day on all of them. Finding the process that is rewriting a site is a good afternoon’s work once. Having something watch for it on every site you own, without you remembering to, is the part worth paying for.

How To Force MFA on Super Users Across Every Joomla Site You Manage

phil@mysites.guru (Phil Taylor) — Tue, 15 Sep 2026 20:39:54 GMT

Joomla has had a setting to require Multi-Factor Authentication for a whole user group since 4.2, released in August 2022. Write-ups of it, our own included, told you to add the Super Users group to the list.

You could not. Until Joomla 6.1.0 shipped on 14 April 2026, the Super Users group was filtered out of that field, so the one group with the power to install extensions, edit template files and create more administrators was the one group the setting would not accept. The option looked available, and selecting it was impossible.

That is now fixed, which makes this worth doing on any site you manage that is new enough to allow it. Across the Joomla sites mySites.guru monitors, 3.8% of sites on 6.1 or newer enforce MFA for Super Users, and 71% of monitored Joomla sites are still on a version where the field will not offer the group at all. The check behind those figures is Force Multi-Factor Authentication For Super Users, which reads the setting on every connected site twice a day.

What changed in Joomla 6.1

The setting is forceMFAUserGroups, a list of user groups whose members must enrol an MFA method before Joomla will let them use the site. From 4.2.0 through 6.0.4 the field in com_users was declared like this:

<field name="forceMFAUserGroups" type="usergrouplist"
       label="COM_USERS_CONFIG_FORCEMFAUSERGROUPS_LABEL"
       checksuperusergroup="1" ... >

That attribute is read by UsergrouplistField, which drops any group holding core.admin from the list of options:

$checkSuperUser = (int) $this->getAttribute('checksuperusergroup', 0);
...
foreach ($groups as $group) {
    // Don't list super user groups.
    if ($checkSuperUser && Access::checkGroup($group->id, 'core.admin')) {
        continue;
    }

Joomla’s shipped permissions give core.admin to group 8, Super Users, so the group never appeared in the dropdown for anyone. Pull request #46248, merged on 9 January 2026 for the 6.1.0 milestone, removed the attribute, and its own description is blunt about the state of things beforehand: “Its not possible to force or never force MFA for superusers.”

The restriction lived entirely in the configuration form. Enforcement itself is a plain intersection of the stored group list with the groups the user belongs to, with no test for administrator rights anywhere in it, so the feature always worked on Super Users. What did not work was choosing them.

The attribute is still on the field in the Joomla 5 branch. Joomla 5 is in bugfix mode, so it is not coming back to 5.x.

How do I force MFA on the Joomla Super Users group?

There are two answers, and which one you want depends on whether you look after one Joomla site or fifty.

Across your whole portfolio, in mySites.guru

The check is Force Multi-Factor Authentication For Super Users, and it has an all-sites view: one page listing every connected Joomla site eligible for it, each row showing whether that site currently enforces MFA on Super Users. Every row has a toggle. Flip it and mySites.guru adds the Super Users group to forceMFAUserGroups on that site for you, so there is no administrator login, no password manager round trip and no tab per client.

Toggling it back off removes only the Super Users group and leaves any other groups you have enforced in place, which matters on sites where somebody has already set up MFA for Administrator or Manager.

The same page is the audit. Sites that already enforce it read as fine, sites that do not are the queue, and the twice-daily snapshot keeps both current, so next month’s answer is the same page rather than another sweep. If your sites are not connected yet, a free audit is the quickest way to see which of them are exposed here.

On a single site, by hand

On a Joomla 6.1 or newer site:

Log in to https://yoursite.com/administrator.
Go to Users, then Manage, then Options at the top right.
Open the Multi-factor Authentication tab.
Add Super Users to the field labelled Enforce Multi-factor Authentication.
Save.

The requirement attaches to the group, so a Super User account created next year inherits it without anyone going back. The field directly above it, Disable Multi-factor Authentication, is the opposite list, and enforcement wins where a group somehow appears in both.

Either route leaves the same step outstanding, and it is the one most instructions skip: log in as each existing Super User and enrol them there and then, saving the backup codes at that moment. Saving the setting only schedules the work.

Super Users, not Super Admins

Joomla’s group is called Super Users. “Super Admin” is the phrase everyone reaches for in conversation, and going by search results it is mostly the phrase people use once a site has already been compromised.

Why did so few Joomla sites force MFA before 6.1?

Because they could not. The usual explanation for low adoption of an optional security setting is apathy, and this one was measuring something else entirely.

3.8%

of monitored Joomla 6.1+ sites enforce MFA for Super Users

the option has existed there since April 2026

0.1%

of Joomla 4.2 to 6.0 sites have it set

not reachable through the admin interface

71%

of monitored Joomla sites are on a version that cannot

mostly Joomla 5

Latest snapshot per site, 90-day window, across the Joomla sites mySites.guru monitors.

The 0.1% is the interesting residue: sites where the Super Users group reached that parameter through a database edit or a migrated configuration, and where Joomla duly enforces it, holding a setting their own administrator screen would never have offered them. It is fragile in a way worth knowing about, too. The next time anyone opens that options tab and saves, the field re-renders without the group and drops it again, with no warning that a security control just came off.

None of that changes what the accounts themselves look like. On 93.4% of monitored Joomla 6.1+ sites there is at least one Super User with no MFA method enrolled, and across all monitored Joomla sites it is 95.8%. Full administrative control, and a password is the only thing in front of it.

Passwords fail in ordinary ways that have nothing to do with how strong they are. One reused on a forum that later gets breached turns up in a credential-stuffing list, and bots work those lists against /administrator login forms continuously, without anyone deciding to target you. A user enumeration bug in an extension supplies the usernames to try. A dormant account no one has used in six months is still a valid login.

Does forcing MFA on Joomla Super Users change anything?

It does, measurably. Split the monitored Joomla sites by whether the setting is on, then count how many still have at least one Super User with no second factor enrolled:

96.2%

of sites that do not enforce MFA have a password-only Super User

the default outcome

34.0%

of sites that do enforce it have one

and they enrol at their next login

Same window and method. Enforcement is the difference between the two columns.

It does not reach zero, for a mechanical reason rather than a disappointing one. Joomla prompts an account to enrol when it next logs in, so a Super User who has not signed in since you saved the setting still reads as un-enrolled. That remaining third is a queue of accounts waiting for their owners to turn up.

That has a use when auditing a portfolio. A site that enforces MFA and still shows several un-enrolled Super Users is telling you those accounts have not been logged into since, which is usually the moment to ask whether they should exist at all.

What to do on the Joomla 5 sites that cannot enforce it

Seven in ten monitored Joomla sites are on a version where this option does not exist, so “switch it on everywhere” is not a plan on its own. Three things do work today:

Enforce MFA on the groups Joomla will let you select. Administrator and Manager have been available since 4.2, and on most client sites those accounts can do enough damage to be worth protecting.
Enrol the Super Users by hand and then watch the state, rather than trusting that it stayed done. mySites.guru counts Super User accounts with no MFA method at each snapshot, which is the part that is still true after a staff change.
Treat it as one more reason the move off Joomla 5 has a date attached. Joomla 5 leaves bugfix support in October 2026, and this is a security control that is only ever going to exist on the newer branch.

What forced MFA still does not cover

Enforcement is worth having, and there are routes into an administrator account that go around it. These are in Joomla’s own source rather than in anyone’s threat model.

Silent logins skip it by default. “Multi-factor Authentication after silent login” defaults to off, and the silent response types default to cookie, passwordless, so a Remember Me cookie or a passkey login goes straight in without an MFA challenge. If you want the second factor on all of them, that switch needs turning on, and it sits on the same tab you were just in.

API tokens and the CLI never see it. Joomla’s MFA handler is used by the site and administrator applications only, and the core documentation for it says an application designed to work non-interactively “MUST NOT use this trait”. A Super User’s API token is therefore a password-free route into the site that enforcement does not touch. If you use Joomla’s Web Services, the tokens deserve the same attention as the logins, and if you do not, switch the Joomla API off and the route disappears.

Backup codes alone do not count. Joomla treats an account whose only method is backup codes as having no MFA at all, which is correct and also means an account can look enrolled to a person and un-enrolled to the system.

Rolling it out without a lockout queue

Flipping the setting is the easy half. The half that decides whether your Monday is quiet is people, and no toggle covers that.

Worth doing before you turn it on anywhere:

Work out who the Super Users are first. Most sites have more of them than the person paying the invoice expects: an old developer, an agency handover account, a vendor’s support login. Finding rogue admin accounts across every Joomla site you manage covers the search, and enforcing MFA on an account no one recognises is worse than deleting it.
Tell people the day before rather than the morning of. The enrolment prompt is not self-explanatory to someone who has never seen it, and the support call it generates is entirely avoidable.
Make everyone save their backup codes while they are enrolling, because that is the only moment anyone ever will, and on a Super User account it is the difference between a five-minute problem and a database edit.
Keep the recovery path in mind before you need it. Joomla only lets a Super User’s MFA methods be deleted by that same user, so a second Super User cannot rescue the first. Backup codes, or DELETE from the user MFA table, are the whole list.

Remove the account, do not exempt it

The temptation on rollout is to leave one account out of the enforced group so there is always a way in. That account then becomes the one an attacker wants, and it will be the one with the oldest password. If an account cannot hold a second factor, it should not hold Super User rights.

MFA enforcement is not a substitute for patching Joomla

Enforcing MFA assumes the implementation underneath it is sound, and four times this year it was not. Joomla fixed CVE-2026-48896 and CVE-2026-48897, both MFA authentication bypasses, in 5.4.6 and 6.1.1, and CVE-2026-73337, another one, in 5.4.8 and 6.1.3. Those three were insufficient checks in the same area of the captive-page logic. The fourth, CVE-2026-92227, fixed in 5.4.9 and 6.1.4, was different: on front-end logins the Remember Me cookie was issued before MFA was completed, so an attacker who already had the password could tick Remember Me, walk away from the MFA prompt and return later logged in by cookie. It is covered in the Joomla 5.4.9 and 6.1.4 security release. The patch order for those ten CVEs is worth reading if you are running either branch behind.

The rest of the login path matters on the same terms. Enforced MFA sits alongside not shipping a Super User called admin, keeping the administrator session separate from the front end, and not emailing people their passwords in plain text. Each closes a different part of the same route, and a stolen session cookie does not care how you logged in originally.

Checking it is still enforced next month

Settings drift. A restore from a backup taken before the rollout, a hand-edited configuration, a site rebuilt by someone else: any of those undoes the work with no warning, and Joomla says nothing about it.

That is the argument for reading the setting on a schedule rather than trusting a finished checklist. Because the check runs at each snapshot, a setting that comes back off changes state on the all-sites page the same week, rather than waiting for someone to notice at the next annual review. The full list of checks shows what else is read in the same pass.

The wider pattern is the one the numbers keep making. Across every optional security setting we measure, adoption sits somewhere between rare and almost non-existent, which is the subject of what site audits reveal about Joomla and WordPress security. Forced MFA on Super Users spent three and a half years as a setting that looked optional and was actually unavailable. Now that it is real, it is the cheapest thing on that list to fix.

A Backdoor Hides in Joomla's Scheduled Tasks Table

phil@mysites.guru (Phil Taylor) — Tue, 15 Sep 2026 17:54:49 GMT

A Joomla site keeps reinfecting. You have cleaned the files twice, you have been through every crontab on the server, and because you are thorough you have also opened System, then Scheduled Tasks in the Joomla administrator. Three tasks, all of them ordinary, all of them yours.

The list can look exactly like that and still be wrong, because Joomla’s Scheduled Tasks screen does not show you every row in the table. Its filter defaults to Hide Orphaned, and an orphaned task is one whose routine no installed, enabled plugin advertises. That describes a harmless leftover from an extension you uninstalled last year. It also describes a planted task whose author removed the extension behind it afterwards. Joomla applies the same test to both and drops them out of the list without telling you.

A scheduled task is an instruction Joomla will act on, and it comes in two parts that live in different places. The routine is code, implemented by a plugin, sitting on disk. The task is a row in the database naming that routine and saying when to run it. Joomla joins the two during an ordinary page request: Task::run() looks the routine up, and if no enabled plugin advertises it the task is skipped with exit code 127 and rescheduled for next time.

An attacker who wants a site to repair itself needs both, and after that the site does the work for them. A task plugin that rewrites their files, plus a row that runs it every few minutes, and a cleaned site re-drops its own malware the next time anybody loads a page. We measured that pattern running for five months on a WordPress site, where the equivalent was 88 rows of wp_options holding the malware’s own source, a manifest of every path it owned, and a scheduled event on a 600 second interval that rewrote anything on the manifest that had gone missing. Deleted files were back in seconds.

Those two parts are also why the table is worth reading after a cleanup. Remove the plugin and the row stops firing, because Joomla checks that the routine resolves before it runs anything. What the row does not do is disappear. It stays in the table as a record that something scheduled work on this site, and at that point Joomla stops listing it.

What Joomla’s task scheduler actually is

Joomla gained a scheduler of its own in Joomla 4.1.0, released on 15 February 2022. It exists so that site maintenance, update checks, log rotation and privacy consent expiry can run without anybody having to configure a real cron job on the server.

A task is one row in a table called #__scheduler_tasks. The row names a routine, in a column Joomla’s own schema comments as the “unique identifier for job defined by plugin”:

SELECT id, title, type, state, created, created_by, next_execution
FROM jos_scheduler_tasks
ORDER BY id;

The type column holds the routine id. Everything else in the row is scheduling detail, a title, some JSON parameters and the usual Joomla bookkeeping. The routine is the only part that decides what code runs, and it is chosen by whoever wrote the extension, not by whoever created the task.

Core Joomla ships nine task plugins, all enabled on a fresh install, and between them they advertise eleven routine ids. They are worth seeing, because they set the shape of a legitimate one:

checkfiles.imagesize
delete.actionlogs
privacy.consent
rotation.logs
session.gc
update.notification
plg_task_globalcheckin_task_get
plg_task_requests_task_get
plg_task_toggle_offline
plg_task_toggle_offline_set_online
plg_task_toggle_offline_set_offline

Two naming conventions, no consistency between them, and not a digit anywhere in any of the eleven. Both of those facts come back when you have to judge an unfamiliar id.

How does Joomla decide when to run a scheduled task?

By default, when a visitor loads a page. Joomla offers three triggers and the one it picks out of the box is the loosest of them.

The Lazy Scheduler is on by default: a due task fires during an ordinary front-end request from an ordinary visitor. You configure nothing on the server, the server has no way to show it to you, and on a site with traffic the interval you set is a ceiling rather than a timetable. Web Cron is off by default and exposes a hash-protected URL an external service can hit. The CLI runner, php cli/joomla.php scheduler:run driven by a real cron job, is the option you want on any site that matters, and it is the one most sites leave switched off.

That default is why this table is worth an attacker’s time. A row plus a routine gets code running on a schedule with no shell access, no crontab entry, no unusual file permissions, and no dependency on the site being busy enough to matter, because a single page view will do.

A row in a table is not a file

A file scanner reads files, so it never sees this, and both of the file tools here work on that same half of the problem. A crontab audit reads crontabs, so it never sees this either. Neither of them reads memory, which is where a third kind of reinfection lives. Every instrument is working correctly and every one has nothing to say, which is a harder failure to spot than a broken tool.

A malicious Joomla task has to look legitimate to run at all

That routine check at the top of Task::run() sets the shape of every working attack on this table. A routine no enabled plugin advertises is skipped, so an attacker who wants their task to fire has to satisfy the same test a genuine extension does.

In practice that means shipping the plugin. A task plugin advertising a routine, plus a row that names it, and the site runs their code on a schedule like any other maintenance job. The row that results is not malformed, not orphaned and not hidden. It sits in System, then Scheduled Tasks under a title its author chose, next to the update checks and the session cleanup, and its position in that list says nothing to separate it from them.

That is the backdoor worth worrying about here, and it hides in plain sight rather than behind anything. The title is whatever they typed, the schedule is unremarkable, and the only part that gives it away is the routine. Reading that means asking which installed extension owns it, which is the one question the list does not answer for you. On a site you already suspect, the file side of the same question is worth running alongside it.

Joomla hides an orphaned task from you by default

The other half of this is what Joomla does with a row whose routine has stopped resolving.

It does not fail loudly and it does not tidy up. Task::run() records exit code 127, defined in core as Status::NO_ROUTINE, skips the execution, fires an onTaskRoutineNotFound event and reschedules the task for next time. The row stays where it is, and it will not run again for as long as nothing advertises its routine.

The administrator list then hides it. In administrator/components/com_scheduler/forms/filter_tasks.xml the orphaned filter is declared default="-1", and -1 is the Hide Orphaned option. TasksModel turns that default into a WHERE type IN (...) clause built from the routines your enabled plugins currently advertise, so any row naming anything else is excluded from the query before the list is drawn.

The scheduler itself does the opposite. When it collects candidates to run it sets that same filter to include orphaned rows, picks them up, and rejects each one at the routine check.

So an orphaned task is inert, and that is what makes it worth reading. It is the record of a task plugin that was installed on this site and is not installed now. On a site you have just cleaned, that is the shape of the thing you removed, written down in a table that rarely gets opened. On a site that has had no incident, it is more likely to be an extension you uninstalled last year.

The filter is sensible on its own terms, and most orphaned rows are exactly that: an extension is removed, its task plugin goes with it, and the row it created stays behind with nothing left to run it. Hiding those keeps a maintenance screen readable. The side effect is that the one place an administrator would go to look is filtered by a rule the screen never mentions, and it is least helpful in the hour after a cleanup, when a row that has stopped resolving is the most interesting thing in the table.

The core bugs that let somebody else write your schedule

Joomla has published two security advisories touching com_scheduler. The 2026 one reaches further than its rating suggests.

CVE-2026-48900 is an improper access check that “allowed low privileged users to edit the task types of existing scheduler tasks”, in the words of the Joomla Security Centre advisory. Editing a task type means changing the routine an existing schedule runs. Reported by Federico Brasili on 29 April 2026 and fixed on 26 May 2026 in Joomla 5.4.6 and 6.1.1, it affects every release from 4.1.0 to 5.4.5 and from 6.0.0 to 6.1.0.

It was rated Low, and as a standalone bug that is right: you need an account first. Set it beside the mechanism in this post and it supplies the missing step. A user with a modest login could repoint an existing, unremarkable, already-scheduled task without writing a row to the database at all.

The earlier one, CVE-2025-22207, was SQL injection through improperly built ORDER BY clauses in the backend task list, reported by Calum Hutton of Snyk and fixed in 4.4.11 and 5.2.4. Different flaw, same component, and a reminder that the screen you go to for reassurance has had its own problems.

23.7%

of the Joomla sites connected to mySites.guru have no scheduler table at all

Joomla 3 and 4.0, where #__scheduler_tasks was never created

12.3%

of the rest still run a version vulnerable to CVE-2026-48900

Joomla 4.4 is end of life, so those sites never get the fix

127

the exit code Joomla records against a task whose routine it cannot find

Status::NO_ROUTINE. Skipped and rescheduled, never deleted

Version data measured across the Joomla sites connected to mySites.guru on 15 September 2026.

Nearly a quarter of the Joomla sites we see have nothing to check here, because Joomla 3 is long past end of life and never had a scheduler. Of the sites that do have one, roughly one in eight still runs a version where a low privileged account can repoint a task.

What makes a Joomla scheduled task malicious rather than unfamiliar

mySites.guru reads every row in the scheduler on every snapshot, which happens twice a day, and judges each task by the routine it names. The tells that mark one malicious are all about that routine:

It names no routine at all: No plugin can advertise an empty routine id, so the row is malformed however it got there.
No installed, enabled plugin advertises that routine: Nothing on the site can run it. Either the extension that created it is gone, or something that was not an extension wrote the row directly. This is the same test Joomla's own Hide Orphaned filter uses, read the other way round.
The routine name contains a word associated with malware: Matched as a whole token, never as a substring, so an extension advertising something like sql.execute is left alone instead of being flagged on its first four letters.
The routine name has the shape of a generated string: A leading or trailing underscore, a digit welded to a letter on the routine half of a dotted id, or twelve characters with no separator anywhere. This one is advisory, reported on its own, and never marks a site as hacked.

There is no rule about how often a task runs, and it was left out on purpose. One was built and measured, and an entirely ordinary backup extension turned out to schedule itself every sixty seconds. A short-interval rule would have fired on a large share of entirely healthy sites while catching no attacks, so it was deleted before it ever shipped.

A rule about created_by went the same way. The idea was that a task created by user 0 well after the site was installed deserves suspicion. On a real site running three commercial extensions, five of its eight legitimate tasks had created_by set to 0, because an installer has no logged-in user to attribute a row to. The rule fired on 62% of the tasks on an uninfected site and was removed.

Why is the routine the only thing worth matching?

Because the title is free text in the site owner’s own language, and Joomla ignores it.

A task called “Nightly backup” is called that because somebody typed it. It can say anything, in any language, and naming a planted row “System Maintenance” costs an attacker nothing. Matching on titles would break on every site that is not in English and would be trivial to dress up.

The routine is different. It is a machine-readable id that has to exist in a plugin’s TASKS_MAP constant for Joomla to run it at all, it lives in no database column of its own, and it cannot be guessed from the plugin’s name. Core’s rotatelogs plugin advertises rotation.logs, sessiongc advertises session.gc, and sitestatus advertises three ids that all begin plg_task_toggle_offline. Any mapping inferred from the element name instead of read from the site would report a legitimate third-party routine as unregistered on every site running that extension.

So the list of valid routines has to come from the site’s own plugin layer, which has a consequence. If that read fails, for any of the ordinary reasons a Joomla plugin group fails to import, then the strongest of the three tests is switched off for that read instead of being applied to an empty list. An empty list of known routines would otherwise mark every task on the site as malicious. “We could not look” and “there is nothing there” are different answers, and only one of them deserves a green tick.

How do I check a Joomla scheduler by hand?

The administrator screen will do it once you change one filter. The database will do it with no filter at all.

In the administrator, open System, then Scheduled Tasks, then change the Show Orphaned filter from its default to Show Orphaned. Skip that and you are reading a list Joomla has already filtered for you, using the test described above. Once orphaned rows are visible, look at the routine on each one, not the title, and ask which installed extension owns it. If the answer is that something planted it, the wider cleanup starts there.

Better, read the table directly and skip the filtering entirely:

SELECT id, title, type, state, created, created_by, last_exit_code, next_execution
FROM jos_scheduler_tasks
ORDER BY created DESC;

Change jos_ to whatever your own table prefix is, and if you are in the database anyway then the rest of the Joomla database is worth a look while you are there. Sorting by created descending puts anything recent at the top, which is where a planted row tends to be. A last_exit_code of 127 on a row is Joomla telling you it has been trying to run something it cannot find. A locked column with a date in it is a different problem living in the same table, and a task stuck locked after a crash will never run again until somebody clears it.

Remove the task before you clean the files

In that order, every time. Clean the files while the row is still scheduled and the next visitor to the site puts them back, which is how sites reinfect within minutes of a cleanup that looked successful. A backup restore does not settle it either, because the restore replaces the database too and brings the row back with it.

What mySites.guru does about it

The scheduler read runs on every snapshot, twice a day, on every connected Joomla site running 4.1.0 or newer. It sits in the Hacked panel on a site’s audit page, next to the check that reads the server’s own crontabs, which is the layer below it and has never been able to reach this one. The full description of the check covers the classification in more detail.

The row below it in the screenshot, Processes Running Deleted Code, is the newest member of the same family and the one that covers reinfection driven by nothing scheduled at all. Its grey No Data badge there is the honest answer on a server that would not let us read its process list.

The scheduled tasks row sits directly below the cron jobs row, which is the layer it was built to cover. This site is flagged hacked on a different check entirely.

Removal is narrow on purpose. One task at a time, and the row is re-read and matched against a token issued when the task was shown to you, so a stale page cannot delete the wrong thing. Nothing is ever added or edited, and a task’s params are never read or transmitted, because those are yours. The delete also leaves Joomla’s #__assets row alone on purpose: that table is a nested set, and deleting from it without rebuilding the tree corrupts the whole permissions structure. An orphaned asset row costs nothing.

The check reports rather than accusing. A flagged task does not on its own mark a site as hacked, for the reason the orphaned filter exists in the first place: most rows that fail this test are extension leftovers rather than attacks. It belongs next to the other evidence, not in front of it, which is why a rogue Super User account, the administrator list across every site you manage and files that core never shipped are worth reading at the same time.

What this check still cannot do

It asks the site about itself, so a compromised site whose own plugin advertises the attacker’s routine id makes that id look perfectly registered. The vocabulary and shape rules run independently of that list for exactly this reason, but the strongest rule can be defeated by an attacker who ships a plugin alongside their task.

It cannot tell a legitimate routine being used for something else from a legitimate routine. Core’s own plg_task_requests plugin fetches a URL you specify on a schedule and writes the response to disk. A task pointing that at somewhere unhelpful is not orphaned, names a routine an enabled core plugin really does advertise, and reads as ordinary maintenance automation. CVE-2026-48900 is what makes that worth saying out loud instead of filing as theoretical.

And it says nothing about Joomla 3, which is close to a quarter of the Joomla sites we see. Those sites have no scheduler table, so there is nothing here to be clean or dirty. Their server crontabs are still read separately, and that check has always covered every crontab on the box, not just the one your control panel shows you.

On the WordPress site described earlier, four separate instruments each had a good reason to report nothing, and not one of them was broken. Sucuri documented a similar WordPress family in November 2024 that scheduled its own reinfection from encoded database rows, so this is a shape attackers already work in. Joomla’s version of that table has had far less attention, from attackers and defenders alike. The row is just as easy to write.

If a Joomla site is currently compromised and you would rather hand it over, we fix hacked sites for a fixed fee. If you would rather have all of this watched across every site you look after, start with a free audit.

Five New Checks for WordPress Hacks a File Scan Cannot See

phil@mysites.guru (Phil Taylor) — Tue, 15 Sep 2026 17:54:49 GMT

The audit page for a WordPress site in mySites.guru has a panel headed “Hacked ?”. It used to ask six questions of your files and one of your server. It now asks five more, and not one of them opens a file.

The top row, malicious cron jobs, has been there a while and reads the server’s own crontabs. The five underneath it are new. They read WordPress’s own scheduler, its settings table, the two folders it loads PHP from without telling you, and the administrator list. Joomla 4.1 and above gained a matching Scheduled Tasks check on the same day; Joomla 3 gets nothing, because it has no scheduler to read.

All five exist because of one site that ran compromised for five months while four separate instruments each had a good reason to report nothing.

The five new WordPress checks, and what each one reads

Check For Malicious WP-Cron Events: Reads the cron row out of wp_options with raw SQL and decodes it without letting PHP rebuild any objects inside it. An event is called malicious on four tells with no innocent explanation: it runs a file already flagged as malware, the file sits in a dot-directory under wp-content, the code behind it was created at runtime by something no ordinary plugin called, or the hook name belongs to a family we recognise. Any event can be unscheduled from the tool, not just a flagged one, because an ordinary scheduled job is the operator's to remove too, and the row is re-read afterwards so you see the verified result rather than the call's return value.
Suspect WP Options: Asks four questions of every row in wp_options, and the sweep never collects what is in one. Is the name nothing but 10 to 12 hexadecimal characters, anchored at both ends? Is it a name a known family uses, including behind a transient prefix? Do the first eight bytes look like compressed or encoded data, or like an opening PHP tag? The sweep collects the name, the byte length, the autoload flag and an eight-byte fingerprint, and it also reports how many bytes of that table WordPress loads on every page view. A flagged row can then be viewed a value at a time and deleted.
Must-Use Plugins and Drop-ins: Lists every top-level PHP file in wp-content/mu-plugins/ and every drop-in WordPress will load by name out of wp-content, including object-cache.php, advanced-cache.php, db.php, fatal-error-handler.php and sunrise.php, with whether each one is actually being loaded. It reads the directory instead of asking WordPress what is there. The count is inventory rather than an accusation, and the badge is neutral by design, because having these is normal. Only a hidden file, or one already flagged elsewhere, gets a colour, and only an increase turns the trend red.
Rogue and Hidden Administrators: Reads the administrator list twice, once straight from wp_users and wp_usermeta and once the way your own Users screen asks. An account is rogue when its username and email match a shape a known campaign generates. The disagreement between the two readings is itself a finding, because a database holding more administrators than WordPress admits to means something is filtering the list. Accounts can be deleted from the tool, with their content reassigned to an account that stays.
Impostor Plugin Identities: The one check here that never contacts your site. It re-reads the name, version, author and vendor address every plugin already declared about itself, and asks whether the declared author is a plain two-word human name whose surname is also the vendor domain, someone called "Jack Walker" publishing at walker.dev. One family generates a fake plugin per site it breaks into and invents both from the same pool. Suspect, never confirmed.
Check For Malicious Cron Jobs: The row above the new five, and the one that pre-dates them. It reads the account crontab, /etc/crontab, /etc/cron.d/ and the run-parts directories, and flags only tells with no innocent explanation in a website's cron: piping a download into a shell, decoding a blob and executing it, fetching from a bare IP, running something out of /tmp. It stops at the operating system, which is the gap the WP-Cron check now fills.

Read together rather than one at a time, those six describe a whole compromise. One family plants a must-use plugin, hides the loader in a dot-directory, stores its source in the options table, registers a scheduled event to rewrite anything you delete, and creates an administrator account it filters out of your Users screen. Five of the six rows have something to say about that site. The file scan has nothing at all.

Why can a file scan miss a WordPress hack completely?

Because each of these is either not a file, or it is a file with no clean counterpart to compare against.

A database row is not a file. A cron entry is not a file. A user account is not a file. Those three are outside the reach of any scanner that works by reading what is on disk, whether it matches signatures or compares hashes. A must-use plugin, a drop-in and a planted plugin are files, but they have no official version anywhere to compare them against, so a hash check has nothing to say about them either. Hash matching and pattern matching are both good instruments, and both of them work on the same half of the problem.

There is a worse case, and it is the one that prompted this work. The family we measured against kept a pristine copy of the theme’s functions.php in a database row, with a stored hash to verify it, purely so it could restore the innocent file whenever it wanted to. A file integrity check then passes, correctly. Suspect content and hacked files are two different tools on this site and both of them read files, so both were shown the clean version.

The infection that made the case for these checks

A Dutch agency raised a paid clean-up on 10 September 2026 for a site that kept coming back. They had cleaned it themselves twice. We cleaned it once, and it was reinfected by morning.

818KB

of the malware's own source in one wp_options row

837,308 bytes, one of 88 rows holding 3.2MB

hacked files reported across three audits

spanning a 22-file rewrite

5 months

compromised before anyone caught it

through two rewrites of the malware

6 of 43

scheduled events flagged on the infected site

and they were exactly the six malicious ones

Measured during a paid clean-up of one compromised WordPress site, September 2026. One site's figures, not an average.

The persistence was 88 rows in wp_options holding complete compressed copies of the malware’s own PHP, a manifest of every path it owned, captured administrator passwords in readable form, and a WP-Cron hook on a 600 second interval that rewrote any file on the manifest that had gone missing. WP-Cron fires on ordinary page loads rather than on a timer, so on a site with traffic the interval is a ceiling and deleted files came back in seconds. The loader was a two megabyte must-use plugin. Three drop-ins were hijacked alongside it. The administrator account it created was filtered out of the Users screen by a views_users hook.

Four instruments each had a separate reason for saying nothing, and not one of them was a bug:

The file scanner had no signature for the family, and even once patterns were added the malware restored the clean file when a scan looked.
The cron reader ran and answered correctly. It opens crontab spools, /etc/crontab, /etc/cron.d and the run-parts directories. There is no database query in it, and WP-Cron is a database row.
The administrator count came from get_users(), which runs inside the attacker’s own loaded code.
Real-time file alerting would have shown 22 modifications in three minutes, but it is opt-in and this site had not opted in.

The cron check’s own Learn page had always named the two layers above it, WP-Cron and Joomla’s Scheduled Tasks, as “separate surfaces with their own tools”. They now have them, and that page links them.

Why doesn’t mySites.guru just ask WordPress?

Because on a compromised site, WordPress is answering with the attacker’s code loaded.

Reading anything out of a WordPress site means loading WordPress, which loads every active plugin and every must-use plugin first. The malware’s filters are live inside the request that asks the question. A plugin can rewrite the answer to “who are the administrators here” by returning a non-null array from users_pre_query, at which point the query never reaches the database at all.

So every WordPress read in these five checks has a raw SQL path, and a WordPress API call may enrich an answer but never decide it. The cron row is read with SQL and never get_option(), which is filtered at four points in core. Drop-ins and must-use plugins are found with scandir() and never get_dropins(). The administrator count comes from wp_users and wp_usermeta.

One API call is made precisely because it can lie

The hidden-administrator count is the difference between the raw database answer and the answer WordPress gives. The disagreement is the finding. Worth knowing: the family we measured installs views_users, which filters the links above the wp-admin Users table and does not touch the user query itself, so on that family mySites.guru’s number was correct and the customer’s own Users screen was the thing lying to them.

There is a second reason not to trust convenience, and it is sharper. The cron row is parsed by a scalar-only walker that rejects object tokens at the type-tag position, never by searching the raw bytes for O:. A hook name is arbitrary text that add_action() never validates, so an attacker can register a decoy hook literally named O:8:"stdClass":0:{}. A byte scan would then read that site as unparseable for ever, on exactly the site it exists to examine, while the real hook sits beside the decoy. That gives an attacker a switch for turning the detection off, and the naive version of this check would have shipped it.

What makes a WordPress scheduled event suspicious

Attribution comes first, and the name second. A hook whose every implementing file sits under wp-content/plugins/ or wp-content/themes/, with nothing evaluated, hidden, must-use or already flagged, says nothing about its name at all. Plugin authors name their scheduled jobs however they like, and a version number in a name is not a clue about anything.

Only when an event cannot be traced to an ordinary file, or what it is traced to is itself suspect, does the name come into it. Then the two name rules describe a shape rather than listing examples.

The separator test accepts any byte that is not a letter or a digit, so it covers hyphen, slash, dot and colon by construction instead of by a list someone has to remember to extend. The digit test skips a token that is one alpha stem with one digit run, which clears v2, mc4wp, w3tc, s2member and core’s own i18n, while still catching a generated name, because those lead with a digit or hold two digit runs. Both were measured against 2,719 hook names harvested from WordPress core and from installed plugins, and no ordinary name in that set reaches the tier that marks a site as hacked.

The tier ceiling matters too. A name alone never confirms anything. The four tells that can mark a site as hacked are all about what an event runs rather than what it is called: a file already flagged as malware, a dot-directory under wp-content, code created at runtime by something no ordinary installed plugin called, or a hook name belonging to a family we have already pulled apart.

Why a big wp_options row is not a finding

The obvious rule for a table that holds an 837,308 byte payload is a size threshold, and the measurements say no. Three real options tables were available to compare: one from the compromised site, the same site after it was cleaned, and a stock WordPress install.

Signal	Infected site	Same site, cleaned	Stock WordPress
Option rows	860	774	143
Total option bytes	4,807,624	1,393,043	86,015
Largest single row	837,308	372,553	30,181
Rows over 64KB	15	5	0
Option names matching `^[0-9a-f]{10,12}$`	32	0	0

Size does not separate those three columns. The bare hexadecimal name separates them perfectly, and it is nearly free to test.

The case that settles it is rewrite_rules, which is part of WordPress itself, exists on every WordPress site there has ever been, holds the compiled permalink rules and grows past 64KB on any site with enough pages and custom post types. A tier that fires on that is measuring how big a site is. So a large row is context: listed with its byte count and a vendor label where we recognise one, with no tier, no colour and no contribution to the count on your audit row. A site with nine large rows and nothing wrong gets a green tick.

There is a corollary worth stealing. Do not calibrate a size rule on “bigger than the malware we found”. The largest legitimate row measured so far is 1,891KB and the largest malicious one is 818KB, so that threshold clears the sick site and flags the healthy one.

The anchoring in the hex pattern is doing the same kind of work. Formidable Forms writes frm_form_templates_ followed by 32 hex characters, and Elementor Pro writes elementor_pro_api_request_ followed by 15. A rule that matched a hex tail rather than the whole name would report every site running either of them as hacked.

A short repeat interval fails the same test, and it is the one that sounds most like a signal. A widely used backup plugin schedules a job every sixty seconds by design, so an “interval under 300 seconds” tier would fire on every site running it and tell you nothing.

Which of these mark a WordPress site as hacked?

Two of the five. A malicious WP-Cron event and a rogue administrator account both set the flag and both appear inside the red card. Suspect WP Options, Must-Use Plugins and Drop-ins, and Impostor Plugin Identities report only.

That is not hedging, it is what the measurements support. The cost of a false confirmation is telling a paying customer their site is infected when it is not, so a check earns the red card on measured separation rather than on how confident the rule feels. The counters that would justify promoting one out of report mode are collected per site, not per finding, so one site with two hundred suspect rows does not read as two hundred compromised sites.

Impostor Plugin Identities may never leave report mode, and the reason is a fair one. The last time that rule ran across every WordPress site we hold, it matched six plugin records. Five were this malware, all inside a single customer account. The sixth was a real independent developer publishing under his own name at his own domain, exactly as he is entitled to. Tightening the rule to exclude him would mean writing one man’s personal web address into our code, which is fitting a rule to a single example. Every one of those five sites was reading as clean at the time.

How do I clean a WordPress site using these checks?

Order decides whether the clean-up holds. While any part of the malware can still execute, it repairs whatever you just removed, which is what the agency kept running into.

Unschedule the event first, before you touch a file. Clean the files while the event is still scheduled and it will write them back, often within minutes. The WP-Cron tool removes an event and then re-reads the row to show you the verified result.
Read the file the event runs. mySites.guru shows the path where it can work it out, and every must-use plugin, drop-in and impostor plugin directory links straight into the web file manager at the folder rather than the file, so you see it among its siblings. That file is usually the thing that points at how the site was broken into.
Delete the rogue administrators, then change the passwords on every administrator that remains and force everyone to sign in again. When mySites.guru deletes accounts for you, their content is reassigned, and it will not run at all if deleting them would leave the site with no one holding the keys.
Clear the payload rows, but recognise before you remove. Start with the names, not the sizes: a row named after nothing is far more interesting than a large row named _transient_something_sensible. A row the tool actually accused can be read one value at a time and then deleted from the same page. A large row it merely listed cannot, on purpose, because deleting the wrong settings row breaks a plugin and there is no undo.
Then delete the files, once nothing left can rebuild them, and run a full audit and work through everything it flags.
Sweep again. On a live site a visitor can trigger a rebuild while you are still working, and so can something still running from a file you already deleted.

Rotate the authentication salts in wp-config.php afterwards to invalidate harvested session cookies, and change the database and hosting passwords. On the site above, the malware had five months to read all of them. None of that touches Application Passwords, a separate REST API credential that a salt rotation and a password change both leave working, so revoke those too.

Clean every site in the hosting account in one sitting

This family writes to every site it can reach on a server. On the compromise these checks came from, the FTP credentials we were given reached exactly one of several sites on the account, and the neighbours were never reachable. Cleaning sites one at a time, days apart, is how a compromise lasts five months. The rogue administrator search across every site you manage is the fastest way to find out how far it went.

How to check a WordPress site by hand

None of this needs a subscription. Four checks, two in SQL and two on the filesystem, get you most of the way on a single site.

-- 1. Option names, not sizes. A bare hex name is generated by a program.
SELECT option_name, LENGTH(option_value) AS bytes, autoload
FROM wp_options
WHERE option_name COLLATE utf8mb4_bin REGEXP '^[0-9a-f]{10,12}$'
ORDER BY bytes DESC;

-- 2. Administrators, read from the tables rather than through WordPress.
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';

Do not drop the COLLATE from the first query. The column is stored under a case-insensitive collation, so without it the pattern means [0-9a-fA-F] instead and you get matches you did not ask for. Anchoring both ends matters just as much: several perfectly ordinary plugins write a sensible prefix followed by a long hex string, so a rule that matched a hex tail would flag every site running one of them.

# 3. Drop-ins load automatically and appear in no plugin list.
ls -la wp-content/db.php wp-content/object-cache.php \
       wp-content/advanced-cache.php wp-content/fatal-error-handler.php

# 4. Anything in mu-plugins runs on every request and cannot be deactivated.
ls -la wp-content/mu-plugins/

If a drop-in exists and you run nothing that installs one, that is your answer. Same for any file in mu-plugins you did not put there, and anything in either location whose name begins with a dot is not an accident. Compare the administrator list from query two against what your own Users screen shows you: if the database holds an account the screen does not, something on the site is filtering it out.

For the scheduler, install a WP-Cron viewer and read the hook names against your plugin list. A hook nothing installed registers is a leftover at best. WordPress only fires a hook something registered, so if you grep every PHP file under plugins/, themes/ and mu-plugins/ for the literal hook name and get zero matches, no callback for it exists on the site.

What these checks still cannot do

The impostor sweep is WordPress only, and the reason is where it came from. Every rule in it was shaped against real infections on real WordPress sites, and the header it keys on is a plugin’s Plugin URI, which on Joomla holds the author URL instead. The same field means two different things across the two platforms, so a rule measured on WordPress data says nothing dependable about a Joomla site. It also cannot see a vendor address that changes on a plugin already installed, because a plugin’s details are recorded the first time it is seen. It catches something newly planted, not a takeover of something you already had.

The scheduler and options reads cover one site of a multisite network, the one whose address you registered, because iterating five thousand blogs inside a sixty second execution limit is not a thing that works.

Reading the WordPress scheduler changes it, and the tool says so. Loading WordPress makes it schedule its own update checks, so some of what gets listed was created by the visit a moment earlier. Those events are marked and never counted, which is why an empty scheduler is something we can never observe.

And a payload that registers its hook from a file planted under an ordinary plugin path buys the attribution exemption described above. That is tolerable because the file scanner, the dot-directory rule and the known-family list all still apply, and the alternative is flagging one of the most widely installed plugins in the world on every site that runs it.

No single check here is a verdict. Impostor files in core folders and the server crontab check were the last two additions in this group and the same was true of both. What changed this month is that the half of a WordPress compromise that never touches a file is now read twice a day, on every connected site, instead of being something you had to know to go and look for.

Timeline

2026-04-11 A WordPress site is compromised The earliest marker we can date on the site that prompted all of this. It goes unnoticed for five months, through two rewrites of the malware.
2026-09-10 The agency asks us to clean it Cleaned the same day. Reinfected overnight. Three audits across the reinfection report zero hacked files.
2026-09-13 Torn down, and the gap measured 88 wp_options rows, six scheduled events, a hidden administrator and 35 files removed in one pass. Four instruments each had a separate reason for missing it.
2026-09-13 Five WordPress checks and one Joomla check built Scheduled events, suspect options, must-use plugins and drop-ins, rogue and hidden administrators, impostor plugin identities, plus Joomla Scheduled Tasks.
2026-09-15 Live on every connected WordPress site Two of the five can mark a site as hacked. The other three report only, because that is what their measurements support so far.

Six more J2Store flaws fixed in 3.3.23, 4.0.23 and 4.1.8

phil@mysites.guru (Phil Taylor) — Tue, 15 Sep 2026 00:00:00 GMT

J2Store is one of the most widely installed e-commerce extensions for Joomla, turning ordinary Joomla articles into shop products. In August 2026 J2Commerce fixed five vulnerabilities we reported, across all three supported branches, and published them as CVEs crediting mySites.guru. This post is the second round. Reviewing that fix release turned up six more issues, all reported privately to J2Commerce, all assigned CVE identifiers by the Joomla CNA, and all fixed this morning in J2Store 3.3.23, 4.0.23 and 4.1.8.

The one that matters most needs no login at all: a blind SQL injection in the public product list that reads the shop’s entire database. Every supported branch is affected, so whichever version of Joomla your shop runs, it needs updating today. If you manage more than a handful of shops, read on for how to find every affected one at once.

TL;DR

mySites.guru found six more security issues in J2Store and reported them privately to J2Commerce. All six are fixed in 3.3.23 (Joomla 3), 4.0.23 (Joomla 4) and 4.1.8 (Joomla 5 and 6)
Unauthenticated blind SQL injection, scored 8.7 High. The storefront product list reads a filter value from the request without quoting it and concatenates it into a database query. No login, no CSRF token: an anonymous visitor reads the whole database one character at a time, the Super User password hash included
Arbitrary file read through the download handler, also 8.7 High, returning files from outside the shop’s folders including configuration.php
An anonymous request that can mark any order as Failed, 8.7 High, plus incomplete CSRF protection across the checkout and profile controllers at 7.1 High, a forgeable order access token at 6.3 Medium, and unescaped request data in the PayPal notify redirect at 5.3 Medium
Check your checkout overrides before updating. The fix adds an anti-CSRF token to the cart, checkout and profile forms, so custom overrides and add-ons that ship their own copies of those templates need the same token or they return an Invalid Token error
J2Commerce reports no evidence that any of the six were exploited on a live store
mySites.guru already flags every connected Joomla shop still running a vulnerable version

We fix first and publish second

mySites.guru discovered these issues and reported them to J2Commerce before publishing any detail. We are holding back the exact requests and the proof-of-concept payloads until enough sites have updated. This is how we handle every vulnerability we find.

Which version you need

Every supported branch is affected, and each has its own fix. The branch you are on follows from your Joomla version rather than from anything you chose:

Your Joomla version	Update J2Store to	Affected builds
Joomla 3	3.3.23	3.3.22 and earlier
Joomla 4	4.0.23	4.0.22 and earlier
Joomla 5 or Joomla 6	4.1.8	4.1.7 and earlier

One thing to check before you update a live shop. The CSRF fix adds an anti-CSRF token to the cart, checkout and my-profile forms, which means any custom template override, or any third-party add-on shipping its own copies of those templates, needs the same token adding to its own forms. J2Commerce names Easy Checkout specifically. Until those are updated to match, the affected actions produce an Invalid Token error for real shoppers, so a shop with heavily customised checkout templates wants a staging run rather than a Tuesday-afternoon click on Update.

A note from J2Commerce for mySites.guru users

J2Commerce sent this through ahead of the release, and asked us to pass it on.

“Thanks to the responsible disclosure by Phil Taylor of mySites.guru, we’ve fixed six security vulnerabilities in J2Store, ranging from Medium to High severity. We have no evidence any of these were exploited on a live store. Even so, we recommend updating right away rather than waiting for your next maintenance window: Joomla 3 to J2Store 3.3.23, Joomla 4 to J2Store 4.0.23, Joomla 5 and Joomla 6 to J2Store 4.1.8.

Backup your site, then update through Joomla’s Components, Update screen, or download first from your account at J2Commerce.com. Full technical details are in the security advisory. Comprehensive update information is provided on install and in the J2Store dashboard. Contact us at support@j2commerce.com or j2commerce.com/support to request help.

Thank you to mySites.guru for the ongoing responsible disclosure that helps keep J2Store stores secure.”

The worst one: an anonymous visitor reads your whole database

Start with the one that needs no account, because it is the one an attacker can reach on any J2Store shop today. The storefront product list and the product-tags list both accept a product_types array filter, which the framework populates straight from the request into model state. Both models then built the product_type IN (...) fragment by wrapping each supplied value in literal quotes and joining them together, with no escaping and no check that the values were valid product-type keys at all. A value containing a single quote closes the string early, and an anonymous request controls part of the SQL.

We proved it against a running shop. The injection is blind, so nothing is echoed back on the page, but the query can be made to pause for a chosen number of seconds when a guess is right and stay instant when it is wrong. Used as a timing oracle, that reads the database out one character at a time: every user record, every session, and the Super User’s stored password hash. No login, no token, nothing but a crafted request to a public page.

8.7CVSS 4.0

HighJoomla CNA record, published 15 September 2026 · CVE-2026-81567

An anonymous visitor reads the entire database through a blind time-based injection in the public product and product-tags lists: every user record, every session, and the Super User password hash. No account and no CSRF token are needed. Reachable on any public storefront that exposes the standard product listing filter.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

No login neededBlind SQL injectionFull database readPassword hashes exposed

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The download handler that reads any file

The second serious one is an arbitrary file read. getFilePath() built the on-disk path to a purchased digital download by concatenating the configured attachment folder with the product file’s stored save name, normalising the separators but never resolving or rejecting a ../ segment, and never confirming the result stayed inside the attachment folder. A path that climbs out of the web root is served like any ordinary download. We retrieved the site’s configuration.php, which holds the database password and the site secret, and /etc/passwd, to a request holding only an order token.

Reaching it is a chain rather than a single anonymous request, because the traversing path has to be stored first, most plausibly through the admin product-file save actions that the CSRF gap below leaves forgeable. It compounds badly, though, because J2Store’s order access tokens were predictable, which is the next finding.

8.7CVSS 4.0

HighJoomla CNA record, published 15 September 2026 · CVE-2026-81568

The download handler serves files from outside the attachment folder when fed a stored traversing path, returning configuration.php with the database credentials and the site secret. Token-gated rather than fully anonymous, and chainable with the admin CSRF gap to plant the path without ever compromising an admin account.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Arbitrary file readLeaks site secretCSRF-to-read chain

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

The other four

Reported and fixed in the same release:

Finding	Who can reach it	What it does
Incomplete CSRF protection on checkout and profile controllers	Any page a logged-in shopper visits	Checkout flow actions and `saveAddress()` ran without verifying the request came from the site, so a crafted page could overwrite a billing or shipping address before order confirmation, with nothing shown to the shopper. That sub-case is the consequential one, because it redirects a paid order’s goods.
Any order can be marked Failed by anyone	None	A failed PayPal signature check was passed down as an ordinary error rather than stopping processing, and any error made the handler set the named order to Failed regardless of its real status. An anonymous POST with a guessed order id flips a pending, confirmed or shipped order straight to Failed.
Predictable, forgeable order access token	Needs the site secret	The token guarding order lookup and digital downloads was derived from the site secret and the order id rather than generated randomly, and never rotated, so anyone who learns that secret can mint the access token for every order on the shop. This is why the file read above matters twice over.
Unescaped request data in the PayPal notify redirect	Victim must follow a crafted link	The notify handler concatenated every value from `$_REQUEST` into the query string of its follow-on redirect with no encoding, so a separator in a submitted value injected extra parameters into the next request. The least serious of the six.

All six findings at a glance. The scores are J2Commerce’s own CVSS 4.0 figures from the advisory, published alongside the release:

Finding	CVE	Login needed	Severity
Unauthenticated blind SQL injection in the storefront product list	CVE-2026-81567	None	8.7 High
Arbitrary file read via the download handler	CVE-2026-81568	Download token	8.7 High
Any order can be marked Failed by anyone	CVE-2026-82189	None	8.7 High
Incomplete CSRF protection on checkout and profile controllers	CVE-2026-78081	None, per action	7.1 High
Predictable, forgeable order access token	CVE-2026-82190	Needs the site secret	6.3 Medium
Unescaped request data reflected into the PayPal notify redirect	CVE-2026-82191	None	5.3 Medium

The Joomla CNA published all six records later the same day, and every one credits Phil Taylor of mySites.guru as the finder. The scores above are the published records’ own CVSS 4.0 figures. Two came out higher than the draft numbers in the vendor advisory: CVE-2026-82190 moved from 5.1 to 6.3, and CVE-2026-82191 from 4.5 to 5.3. The other four matched.

Why round two exists at all

Round two happened because we retested the August fix release rather than closing the ticket, and it is worth saying why that mattered. Two of these six, the anonymous SQL injection and the file read, were not in the original report and had nothing to do with the CSRF work J2Commerce was fixing. They surfaced only because we went back through the code that shipped alongside the round-one fix.

The vendor’s first fix build had to be rejected, too. It closed the cart CSRF gaps correctly but left both of those criticals open, and it shipped with its version number unchanged, so no Joomla site would ever have been offered it and no scanner would have told the difference between patched and unpatched. The corrected build fixed the version string and closed the rest. A fix release deserves the same scrutiny as the code it fixes, which is the reusable lesson here for anyone shipping security patches.

Joomla 3, and the deadline J2Commerce has already set

Most of the shops these six flaws affect sit on the branch with the least time left. Six in ten of the affected installs we can see are on Joomla 3, which reached its own end of life on 17 August 2023 and has had no free security fixes from the Joomla project since. The paid Extended Long Term Support programme that followed closed on 17 February 2025, so there is no official route to a patched Joomla 3 core at any price.

On 3 September 2026 J2Commerce set a date for the shop extension too. J2Store 3 stops receiving security patches on 19 October 2026, two years to the day after the company took J2Store over. From that date the 3.x line gets no security fixes, no support and no further releases of any kind, including for anything found afterwards. J2Store 4 has its own date a year later, on 19 October 2027.

A Joomla 3 shop on J2Store 3 therefore has two deadlines stacked on top of each other, one that passed three years ago and one about five weeks out, and 3.3.23 is among the last builds that will ever answer either. That is the real context for the six issues above. Today’s release closes the anonymous database read. It does nothing about the arrangement that produced it, which is a shop extension sitting on a platform the project itself stopped patching for free in 2023.

The measured state of those shops is worse than the deadline alone suggests. Seven in ten of the Joomla 3 installs caught by this release are below 3.3.21, which puts them behind all three of this year’s advisories rather than just this one. For a shop in that position 19 October is close to a formality, because nothing has been applied for months anyway.

Patch now, but plan to migrate

The right move for a shop still on J2Store 3 is patch now, migrate soon. Update to 3.3.23 to close what is open, then use the time it buys to plan the move to J2Store 4, or on to J2Commerce 6, rather than treating the patch as somewhere to stay. We cover that route, and why the shop migration and the Joomla migration are one project rather than two, in J2Store 3 stops getting security fixes on 19 October 2026.

Shops on 4.0.x and 4.1.x have no such deadline. They still need the update today, and 4.1.8 is the branch that continues into Joomla 6.

Was any of this being exploited?

J2Commerce states it has no evidence that any of these six were exploited on a live store, and neither do we. No proof of concept has been published for any of them. This post describes mechanisms rather than requests, and we are holding the exact payloads back until enough sites have updated.

The honest caveat is which one to check for. The anonymous SQL injection is the one worth going back through a busy shop’s logs for, because it is reachable without a login and a timing-based extraction leaves a recognisable run of near-identical requests to the product list. The file read and the order-status change leave much less behind. If you ran an affected build, the highest-value review is recent order-state changes with no matching payment, the same advice as round one, plus any unusual burst of product-list requests.

How mySites.guru helps

You do not have to open each shop by hand. mySites.guru records the exact version of every extension on every Joomla site it monitors, so J2Store installs across your whole account list appear on one screen with their versions, and any shop below the fix version for its branch is flagged automatically. Instead of logging into each site to check whether it is updated yet, you get one filtered list of the ones that are not, and can act on them together.

That matters more here than usual, because the fix version is not one number. A shop on Joomla 3 needs 3.3.23, a shop on Joomla 5 needs 4.1.8, and 4.1.8 sorts above 3.3.23 while 3.3.23 is the newer release on its own branch. Checking that by eye across a list of client sites is exactly the sort of thing people get wrong at four in the afternoon. If you want to see it against your own sites first, the free audit covers it.

Field	Detail
Component	J2Store for Joomla (`com_j2store`)
Vendor	J2Commerce (j2commerce.com)
Type	Unauthenticated SQL injection (CWE-89); path traversal file read (CWE-22, CWE-73); business logic error (CWE-840, CWE-345); missing CSRF protection (CWE-352); insufficiently random values (CWE-330); improper output encoding (CWE-116)
CVE	CVE-2026-78081, CVE-2026-81567, CVE-2026-81568, CVE-2026-82189, CVE-2026-82190, CVE-2026-82191
CVSS 4.0	5.3 to 8.7, per the published Joomla CNA records
Impact	Anonymous full database read; arbitrary file read leaking the site secret; anonymous order-status change; missing CSRF across checkout and profile; forgeable order token; reflected parameter injection in the PayPal redirect
Finder	Phil Taylor, mySites.guru
Affected versions	3.3.22 and earlier, 4.0.22 and earlier, 4.1.7 and earlier
Fixed in	J2Store 3.3.23 (Joomla 3), 4.0.23 (Joomla 4), 4.1.8 (Joomla 5 and 6)
Reported	1 September 2026 (privately to J2Commerce)
Acknowledged	5 September 2026 (J2Commerce confirmed the findings)
Fixed	15 September 2026

Timeline

2026-08-25 Round one: five issues reported to J2Commerce The PayPal callback forgery, the reflected XSS, the anonymous cart tampering, the guest-address disclosure and the Apps delegation chain, all fixed on 31 August in 3.3.22, 4.0.22 and 4.1.7 and published as five CVEs crediting mySites.guru.
2026-09-01 Round two opened after retesting the fix release Reviewing 3.3.22 turned up more: incomplete CSRF protection across the cart and checkout controllers, and shipping-price tampering. Reported to J2Commerce the same day, and confirmed by the vendor on 5 September.
2026-09-07 First fix build rejected on retest The vendor's first attempt closed the cart CSRF gaps but left two unreported criticals open, an anonymous storefront SQL injection and an arbitrary file read, and shipped with the version number unchanged so no site would have been offered it. We retested it and sent it back.
2026-09-11 Six CVE identifiers assigned by the Joomla CNA After the second report, the Joomla CNA assigned six identifiers covering the CSRF gaps, the storefront SQL injection, the file read, the order-status change, the order token and the PayPal redirect. A corrected build followed the same night and passed retest on 12 September.
2026-09-15 3.3.23, 4.0.23 and 4.1.8 released J2Commerce shipped all three branches together with a full advisory naming every CVE, its CVSS vector and the affected files, and crediting mySites.guru for the discovery and disclosure of all six.

Tag Your Sites by Client, Server or Retainer

phil@mysites.guru (Phil Taylor) — Tue, 15 Sep 2026 00:00:00 GMT

A site list is a fine way to hold forty sites. You scroll it, you recognise the domains, and when you want a particular one you type part of its name into the search box.

Somewhere past a hundred it stops being a list and becomes a haystack. The question you actually have is rarely “where is example.com”. It is “which of these belong to Meridian”, or “which of these are on the Frankfurt box being rebuilt this weekend”, or “which of these are on the retainer that includes monthly updates, and which are the ones we only touch when they break”. A list sorted by name answers none of that, so the answer gets kept somewhere else: a spreadsheet, a Notion table, or one person’s memory. All three go stale, and only one of them can hand in its notice.

Tags are how mySites.guru keeps that answer next to the sites themselves, and they were rebuilt this month.

What the rebuilt Tags feature does

A tag is a name, a colour, and a list of sites. You make them on the mySites.guru tags page at /en/tags/, which is headed Site tags and has an Add tag button in the top right. The dialog that opens asks for three things: a name, a colour from a palette of twelve, and whether the tag should appear in the left menu.

That is the whole model. Everything else is what you can do with it.

Tags belong to the company, not to your login, so everyone on your team sees the same set. They show up as coloured badges on each row of the sites list, as a section headed Site Group Tags in the left menu of every page, and as pills above the updates list. Wherever they show up, clicking one filters to it.

Where the tags page lives

The left menu section is headed Site Group Tags, and the cog icon beside that heading is the permanent route to the management page. Beside it is a second button, Reorder your tags, which turns the menu itself into a drag list. They used to be one control, which meant the only persistent link to the tags page anywhere in the product armed drag mode instead of navigating. They are now two buttons, each doing the single thing its tooltip claims.

Editing one opens this. A name, the twelve-colour palette with a live preview of the badge above it, and the switch that decides whether the tag appears in the left menu.

Tag by the action you will take

A tag earns its place when it changes what you do next, and that one rule decides whether a scheme is still useful in a year. “Meridian” earns it, because before a Meridian call you want their five sites and nothing else. “Frankfurt” earns it, because when that machine gets rebuilt you want its sites and nothing else. “Built in 2021” does not earn it, because there is no Tuesday on which you act on the sites built in 2021.

The failure mode is tagging descriptively instead of operationally: recording what a site is rather than grouping by what you will do to it. Descriptive tags feel productive to create and then sit there. About a third of the tags in mySites.guru have no sites on them at all, which is roughly the shape of that mistake measured across every account.

Four things worth tagging by

These four keep earning their place. Most accounts use two or three of them, and half of the accounts that use tags at all have three or fewer.

Client: The commonest and the most useful. One tag per client, applied to every site they own. It scopes a report, a backup run, and the five minutes before a call when you want to know whether anything is broken on their side of the portfolio.
Server or host: Group by the machine or the hosting account. When a box needs a PHP bump, a reboot or a migration, the tag tells you what else is affected. It also answers the awkward question during an outage, which is not "is the site down" but "what else is down with it".
Retainer tier: What you are actually paid to do. Monthly updates, quarterly checks, break-fix only. This is the tag that stops you doing forty pounds of unbilled work on a site whose contract does not include it, and it is the one that scopes an automatic update policy sensibly.
Risk or attention: The handful you want to look at first: the legacy builds, the ones on an old branch, the ones that got hacked once and have not earned your trust back. Small by design. A tag holding a third of your sites is not a priority list.

Platform is worth a mention and then a warning. Tagging by Joomla or WordPress feels obvious and is almost always redundant, because mySites.guru already knows which platform every connected site runs and the sites list filters on it without your help. Spend the tag on something the system cannot work out for itself.

Should a site have more than one tag?

Yes, and this is where tags beat folders.

A site belongs to one client, sits on one server, and is on one retainer tier, so those three axes cross rather than compete. Tag Meridian, fra-01 and Monthly on the same site and you can ask three different questions of it without ever duplicating anything. A folder structure makes you pick which of those three is the top level, and whichever you pick is wrong for one of the three questions.

mySites.guru accepts up to 50 tags on a single site in one save, which is far more than anyone sensible needs and exists so a bulk paste cannot be trimmed without you noticing. Over that limit the save is rejected and says so, rather than storing the first fifty and dropping the rest.

★★★★★

“tracking php versions and software via tagging. Invaluable to our business.”

Artful Web Print Designartful.com.au · 13 July 2026

Putting sites on a tag without three hundred clicks

There are three ways in, and which one you want depends on whether you are thinking tag-first or site-first.

From the tags page, the site count in each row is a button. Click it and a dialog opens listing every site you can see, with a filter box and Select all and Clear buttons. Tick what belongs, press Save sites, and the tag’s membership is replaced with your selection in one request. The readout under the list is explicit about that: it tells you how many of how many are selected, and that saving replaces what is on the tag.

From the sites list, the Select button turns every row into a checkbox. Tick some rows, or press Select all shown, pick a tag from the Choose a tag dropdown, then press Add tag or Remove tag. This is the site-first route, and it is the one to use after you have filtered the list to something interesting, like every site on a given PHP version.

From an individual site’s page, the Add tag button in the header opens a type-ahead. Existing tag names autocomplete; a name that does not exist yet is created when you save.

Add and Remove are two buttons on purpose

A single toggle would be shorter and would also be dishonest. Over a selection where some rows already hold the tag and some do not, one click would add for half of them and remove for the other half, and no button label can describe that truthfully. Two buttons, each doing one thing to every row in the selection.

Every bulk tool takes a tag

This is the part that repays the afternoon you spend tagging, and it is why a tag that only filters one screen is worth much less than one that crosses the whole product.

The search token is [tagged:Name], brackets included, and it works in the filter box at the top of the sites list. You will rarely type it, because clicking a tag anywhere puts it there for you, but it is worth knowing it is a text token: it means a tag filter is something you can bookmark, share with a colleague, or keep open in a second tab during a maintenance window.

From there:

Mass upgrade. The en-masse upgrade screen has a Select sites by tag dropdown with Select and Deselect buttons, so a rollout is scoped to one client or one server rather than to everything at once. There is a live badge telling you how many rows matched before you commit.
Remote install. The same control appears in the site picker for installing an extension or plugin across many sites, so “put this plugin on everything Meridian owns” is two clicks rather than a hunt.

Backups. Filter the sites list to a tag first, then use the button that backs up every site visible below. The filter is the scope.
Updates. Both updates views have a row of tag pills labelled Tags: showing your ten largest tags. Click one and the pending-updates list narrows to that group, which is the quickest way to answer “is everything of theirs up to date” before you are asked.
Audits and snapshots. The same filter narrows these too, so a security sweep can be scoped to the tier that pays for security sweeps.

What happens to a tag you stop using?

Tag schemes decay. A client leaves, a server gets decommissioned, a tier gets renamed, and the tag stays behind looking authoritative.

mySites.guru gives you two different answers rather than one. Each row on the tags page has a Show in the left menu switch. Turning it off keeps the tag, its colour and its entire membership, and only takes it out of the sidebar. That is the right move for anything historical: the client you might hear from again, the “hacked in 2024” group you want to be able to reconstitute. The information is still there and the menu stays short.

Deleting is the other answer, and it removes the tag and its membership records only. No site is touched, disconnected or changed; the badge simply stops appearing. Delete asks twice before it does it.

The reason both exist is that hiding and deleting get confused constantly, and the confused version is always the destructive one.

What changed in the rebuild

The previous version of this feature worked, and the way you used it was to drag a site row, by the three dots beside it, onto a tag. That was fine for twelve sites. On a list of several hundred it required you to first filter the list down so that both the site and the tag were on screen at once, which the old documentation cheerfully told you to do.

The rebuild replaced it. Worth knowing if you used the old one:

Reordering exists. Tags used to render alphabetically everywhere, which meant naming a tag 1. Priority was the only way to get it to the top. Now you drag them into the order you want, on the tags page or in the left menu itself, with the arrow keys as an alternative. Each save gets an Undo for nine seconds.
The menu drag only moves what you can see. The left menu holds only the tags you chose to show there, so a drag in the menu permutes those positions and leaves the hidden ones where they were. The alternative would move tags you cannot see, with nothing on screen to tell you it happened.
Colours are chosen, not random. New tags used to get a random hex value, which produced the occasional unreadable badge and the occasional two tags in near-identical shades. There are now twelve presets, each one tested to stay legible against its own text in both light and dark mode, plus a colour picker if you want something specific. A tag saved without a colour gets one derived from its name, so the same name always produces the same colour.
Membership saves once, not once per site. The old assign screen issued one request per site. This matters more than it sounds, and it is the most interesting bug in the rebuild.

The bug worth knowing about if you write PHP

The new dialog originally posted one form field per selected site. PHP’s max_input_vars defaults to 1,000, and it does not error when a request exceeds it: it drops the surplus with no error and gives your script a truncated array. Because a membership save replaces the list, a select-all on a very large tag arrived incomplete and took the tail of that tag off, then reported success. The fix was to send the selection as a single field. The same code now also treats a missing field as a failure rather than as an empty selection, because “the body did not arrive intact” and “the user unticked everything” must never look the same to code whose next act is a delete.

A restricted team member’s save is now bounded by what that member can see, in both directions. If someone has access to three of your sites, saving membership from their account can add or remove those three and cannot touch anything else on the tag.

Tags in the API and in Claude

Tags are readable programmatically, which turns them into a vocabulary rather than a UI feature.

GET /api/v1/tags returns every tag with its slug, name and colour to any token holding the api:tags:read scope, ordered the same way your left menu is. The mySites.guru API covers how to get a token.

The same list is available to AI assistants over MCP through a read-only tool called list_tags, behind the mcp:tags:read scope. That is the piece that makes “queue a backup for every Joomla site tagged client-retainer” a sentence you can say rather than a filter you have to build. The assistant reads your tag names, so you talk about groups of sites using the words you already use internally.

Where to start

If you have never tagged anything, do not tag everything. Make one tag for your largest client, put their sites on it, and use it for a week. If it changes what you click, make the next one.

Tags are part of every mySites.guru subscription, on every plan, for unlimited sites. If you are not a subscriber yet, there is a free month to try it on your own portfolio.

SQL Injection and a Captcha Bypass in the SP Page Builder Joomla Extension, found by mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 14 Sep 2026 13:00:00 GMT

SP Page Builder is JoomShaper’s drag-and-drop page builder for Joomla, one of the most widely installed page builders in the ecosystem. We have reported issues in it before: the June 2026 unauthenticated icon-upload zero-day fixed in 6.6.2, four flaws including a pre-auth SQL injection and an open mail relay fixed in 6.7.1, and a pre-authentication remote code execution fixed in 6.8.0. This round is the fourth, and it found five more, reported to JoomShaper on the day 6.9.0 shipped and all fixed in SP Page Builder 6.9.1.

The two that matter most to you are a blind SQL injection an ordinary Author can use to read your entire database, and an unauthenticated captcha bypass that turns your forms back into open spam and relay targets. If you run SP Page Builder on any Joomla site, update to 6.9.1 now. Sites still on Joomla 3 cannot install it and need the separate patch described further down. If you manage more than a handful of sites, read on for how to find every affected one at once.

TL;DR

mySites.guru found five security issues in SP Page Builder 6.9.0 and reported them privately to JoomShaper the same day the version shipped
Author-level blind SQL injection (High). The com_content integration plugin reads one value out of the article-save request without an integer cast, one line below a cast that is present, and concatenates it into a query. Any account that can save an article, an Author by default, can read the whole database one character at a time, the Super User password hash included
Unauthenticated captcha bypass (Medium, understated). The form addons throw away the real captcha result whenever the request claims the form is being rendered inside a module, so an anonymous visitor defeats reCAPTCHA on the contact form, the opt-in form and the form builder alike. Those three addons ship only in SP Page Builder Pro, so this one does not reach the free Lite edition
Three more: an Editor-level file rename that could reach outside the web root, an Editor-level Joomla menu takeover, and an Author-level file write into the web root
Update to SP Page Builder 6.9.1 immediately
Reported privately on 8 September 2026, all five fixed in 6.9.1. We re-tested the released package to confirm the fixes hold
mySites.guru already flags every connected Joomla site still running a vulnerable version

We fix first and publish second

mySites.guru discovered these issues and reported them to JoomShaper before publishing any detail. We are holding back the exact requests and the proof-of-concept payloads until enough sites have updated. This is how we handle every vulnerability we find.

The worst one: an Author reads your whole database

SP Page Builder integrates with Joomla articles through a content plugin. When an article is saved, that plugin reads a value from the submitted form and uses it to look up the matching page-builder layout. The value on the line above is cast to an integer. This one is not. It is concatenated straight into the WHERE clause of a database query, so an attacker who can trigger an article save controls part of the SQL. On a default Joomla site the account type that can save an article through the ordinary front-end submission form is an Author, the lowest-trust authenticated role there is, and on any site that allows self-registration an attacker can create that account for themselves.

We proved it on a test site. The injection is blind, so nothing is echoed back, but the query can be made to pause for a chosen number of seconds when a guess is right, and stay instant when it is wrong. Using that as a timing oracle we read the Super User’s stored password hash out one character at a time. That is full read access to the entire database, from an account that can do nothing more than submit an article.

8.6CVSS 4.0

HighJoomla CNA, published 14 September 2026 · CVE-2026-78375

An Author account, the lowest authenticated role on a default Joomla site and one an attacker can often self-register, reads the entire database through a blind time-based injection: every user record, every session, and the Super User password hash. The one precondition is that SP Page Builder's com_content integration plugin is enabled, which it is on any site using the builder inside articles.

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Author accountBlind SQL injectionFull database readPassword hashes exposed

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:H: High: Needs an account with elevated rights
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

PR:H in that vector does not mean an administrator. The Joomla CNA uses it for anything above a plain Registered user, so an Author qualifies, which is the point of the finding. VI:H/VA:H is more than we would have given it: our own read was 7.1 High on a read-only vector, because the injection extracts data rather than writing it. The record scores control of the query itself rather than what we did with it on the test site. Either way it is the worst of the six, and either way the answer is 6.9.1.

The captcha check that does not run

The second finding scores lower and is in some ways the more interesting one, because it needed no account at all. On an unpatched site it is the only one of the five an anonymous attacker can reach. SP Page Builder Pro ships three form addons: the contact form, the opt-in form, and the form builder. Each verifies its captcha in a public AJAX handler that anyone on the internet can call. All three are Pro features, so the free Lite edition was never exposed to this one.

There were two separate ways past that handler, and they are worth keeping apart because they have different histories.

Route one: declare the form is in a module

The handler reads a value called view_type straight from the request, and when that value says the form is being rendered inside a module, the code throws away the real captcha result and replaces it with a check of whether the submitted string is simply non-empty:

$res = Factory::getApplication()->triggerEvent('onCheckAnswer', [$gcaptcha]);
if ($view_type == 'module') {
    $res = ($gcaptcha != null || strlen($gcaptcha) != 0) ? [true] : [false];
}

The first line asks Google whether the reCAPTCHA token is valid. The second line overwrites that answer with “did they type anything at all”. Because view_type comes from the request and nothing checks it against reality, an attacker just declares view_type=module and the captcha is gone. We confirmed it against a form configured for reCAPTCHA: the exact same junk token was rejected as a normal page submission and accepted once we flipped that one field, then reached the mailing-platform submission behind the form.

That shortcut was present in all three form addons, in identical form, down to the comment above it.

6.9CVSS 4.0

MediumJoomla CNA, published 14 September 2026 · CVE-2026-79701

Scored Medium because nothing on the Joomla site itself changes, which understates the real cost. An anonymous visitor defeats the captcha the site owner configured, so every SP Page Builder Pro form becomes an open target for spam, list poisoning and mail sent from the site's own identity, on a site whose owner believes the forms are protected.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

No login neededExploitable over the internetCaptcha not verified

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:L: Low: Some data can be altered
VA:L: Low: The site slows or stutters

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

Route two: the captcha that grades its own homework

The second route is the one JoomShaper’s changelog describes, and it has the longer history. SP Page Builder’s built-in question captcha asks the visitor something simple and checks the answer. In the opt-in form, that check read:

} else if ($captcha_type == 'default' && md5($captcha_question) != $captcha_answer) {

The question, the answer and the captcha type all came out of the submitted request. Both sides of that comparison belong to the attacker, so posting any question, its own MD5, and captcha_type=default passes every time. Because the type came from the request too, a form the site owner had configured for reCAPTCHA could be downgraded to the question captcha on the way in, with nothing on the page to show it.

We had seen this pattern before. Reporting the July mail relay we noted in passing that the contact form’s question captcha compared two attacker-supplied values and so verified nothing. That was context for the relay finding rather than a finding of its own, and no CVE covers it. JoomShaper did fix it, in the contact form and in the form builder, and that fix shipped in 6.9.0 with a comment above it reading “Read the expected answer from the stored addon, never from the request.”

The opt-in form, the third member of the same family, sitting in the same directory and running the same code, received neither the comment nor the fix. That untouched line is what we reported on 8 September, in the very release that had just repaired its two siblings.

6.9.1 closes both routes in all three addons at once. The captcha type, the expected answer and whether a captcha is required at all are now read from the stored addon, and the captcha plugin’s answer is the one that counts, in every render context. The changelog credits only the opt-in form, which undersells the work: the module shortcut is gone from the contact form and the form builder too.

The other three

Reported and fixed in the same 6.9.1 release, all three needing a low-trust logged-in account rather than an anonymous visitor:

Finding	Who can reach it	What it does
Media file rename outside the web root	Editor	The rename endpoint took a target path from the request without confining it to the media folders, so a chosen file could be renamed to a path that climbed out of the web root. Renaming the wrong core file takes the site down.
Joomla menu takeover	Editor	The “add to menu” action called Joomla’s menu-item model directly, skipping the com_menus permission check, so an Editor could create menu items or overwrite an existing one, the site’s home item included.
File write into the web root	Author	The upload endpoint accepted a destination folder from the request without confining it, letting an Author write an uploaded file into directories across the web root rather than only the dated media folder.

6.9.1 adds a real permission check to the menu action, and confines both media paths to the configured media folders, rejecting any attempt to climb above them.

All five findings at a glance, against the six CVE records the Joomla CNA published on 14 September. Six rather than five because the captcha bypass was split into one record per route, which is the right call: they are separate defects with separate histories. Scores, affected ranges and weakness classes below are the published ones. Every record names Phil Taylor of mySites.guru as the finder.

CVE	Finding	Who	Editions	Affected	CVSS 4.0
CVE-2026-78375	Blind SQL injection, full database read (CWE-89)	Author	Pro and Lite	5.2.1 to 6.9.0	8.6 High
CVE-2026-79700	Captcha bypass, opt-in form, settings taken from the request (CWE-807)	Anonymous	Pro only	5.1.4 to 6.9.0	6.9 Medium
CVE-2026-79701	Captcha bypass, all three form addons rendered in a module (CWE-807)	Anonymous	Pro only	3.2.6 to 6.9.0	6.9 Medium
CVE-2026-81564	Media file rename reaching outside the web root (CWE-22)	Editor	Pro and Lite	4.0.0 to 6.9.0	7.0 High
CVE-2026-81565	File write into the web root media tree (CWE-22)	Author	Pro and Lite	4.0.0 to 6.9.0	6.9 Medium
CVE-2026-81566	Joomla menu create and overwrite without com_menus rights (CWE-284)	Editor	Pro and Lite	4.0.0 to 6.9.0	5.1 Medium

Our own assessments, written before the records published, agreed within a couple of tenths on four of the six. Two moved: the menu takeover we scored 7.1 High is published at 5.1 Medium, and the web-root file write we scored 5.3 Medium is published at 6.9 Medium. Where the published record and our reading differ, the record is what scanners and auditors act on, so it is the number this post leads with.

The vendor changelog transposes two of the six identifiers

JoomShaper’s 6.9.1 changelog attaches CVE-2026-81565 to the menu permission fix and CVE-2026-81566 to the media upload fix. The published records attach them the other way round: CVE-2026-81565 is the media upload, CVE-2026-81566 is the menu item. The table above follows the records, which are the authority for what an identifier means; an earlier version of this page followed the changelog. The difference shows up the moment you file these against an internal ticket or a client report, because the two findings send you to different accounts: the media upload is reachable by an Author, the menu item by an Editor.

The pattern, four rounds in

This is the fourth consecutive round of findings we have reported in SP Page Builder, and each has told the same story: the fix reaches the exact file that was reported, and not the siblings running the same code. The 6.8.0 remote code execution sat in the method directly below the one hardened in 6.7.1. The question captcha above had been repaired in two of the three form addons in 6.9.0, with the corrected code sitting a few files away from the third as a template for the fix that was never applied.

The rename finding turns out to be a sharper version of the same problem, and JoomShaper documented it themselves. The comment they shipped above the fixed line in 6.9.1 records that an internal commit on 7 September had weakened the check from an AND to an OR, reopening the arbitrary file rename and undoing an earlier fix for the same issue. We reported it the next day, not knowing any of that. A bug they had already closed once was live again for roughly twenty-four hours before an outsider found it.

Two things are worth saying about that. Writing it down in the shipped source, naming the commit and the regression, is more candid than most vendors manage, and the same comment says a regression guard now exists to stop it happening a third time. And it makes the case better than we could: a security fix can be undone as easily as it can be missed.

None of this makes SP Page Builder unusually bad. It is a large, capable, heavily used component, and the vendor fixes what we send them, quickly. The lesson is one every developer can borrow: when you fix a security bug, grep for the pattern across the whole codebase, then write the test that fails if anyone takes the fix back out.

Why keeping SP Page Builder patched matters

SP Page Builder is a mainstream choice, not a niche add-on. Across the Joomla sites mySites.guru actively monitors, roughly one in four, about 23%, run it. Only YOOtheme Pro is on more, and between them those two account for most of the Joomla page-builder market we can see: the next most common builder after them appears on well under a tenth as many sites. A flaw in a component with that kind of reach exposes a large slice of the whole Joomla web at once, and attackers know exactly which component to point a scanner at.

The version spread is the encouraging half of the picture. About 72% of the SP Page Builder installs we monitor were already on 6.8.0 or 6.9.0, the two most recent releases before this fix, so most site owners do take these updates and 6.9.1 will reach them through the normal updater.

The tail is where it gets difficult. Roughly a fifth are on SP Page Builder 5.x or older, and 86% of those sites are still running Joomla 3, where the 6.x package cannot install at all. Taken together, about one in five SP Page Builder installs we monitor sits on a Joomla 3 site, with no route to 6.9.1 whatsoever.

That reach is also why the “needs an Author account” or “needs the content plugin enabled” caveats on some of these findings matter less than they sound. On a base this large there are always sites that allow self-registration, sites that use the builder inside articles, and sites with a stale low-trust account no one has thought about in years. A precondition that trims the exposure on one site does nothing to the total across tens of thousands.

Joomla 3 sites need a different package

Update, 30 September 2026: version 1.0.3 completes the Joomla 3 patch

The gaps described below were in version 1.0.2, the patch as it first shipped on 14 September. We found two of them and reported them the same day, and JoomShaper released version 1.0.3 on 30 September to close them: the captcha bypass is now fixed on the Joomla 3 branch, the opt-in form addon is shipped for the first time, and an incomplete cross-site scripting fix is corrected. The full account is in SP Page Builder’s Joomla 3 Security Patch Was Incomplete. The install limit and the version-invisibility problem described below still apply.

JoomShaper released a third package on the same day: the Joomla 3 Security Patch for SP Page Builder, version 1.0.2. As it first shipped it back-ported four of the five fixes to the Joomla 3 branch, and the captcha work was not part of it (see the update above).

The bigger limitation is who can install it. The patch checks the installed version and will not run on anything except SP Page Builder 5.6.1 exactly. Across the Joomla 3 sites we monitor that run SP Page Builder, only about 3% are on 5.6.1. For the other 97%, this patch will not install, and neither will 6.9.1.

There is a second problem, and it is the one we had already asked JoomShaper to avoid. The patch installs as a Joomla file package: it overwrites files in place and leaves the component’s own version reading 5.6.1, exactly as before. To any updater, and to any scanner that works from version numbers, a Joomla 3 site that has applied it looks identical to one that has not. That is also why our own vulnerability rule for this round stops at the 6.x line rather than flagging 5.6.1: a site that did everything right would have no way to clear the warning.

We have written this paragraph before. JoomShaper’s third Joomla 3 security patch for Helix Ultimate reused the version string 2.1.4-j3sec for the same reason, leaving Joomla 3 sites unable to tell whether they held it. The same objection is why we sent back their first fix build for this round on 8 September. A security patch you cannot detect is one you cannot manage across more than a handful of sites.

How we handle it instead

Version numbers being useless here is why mySites.guru does not use them for these packages. For all three of JoomShaper’s Joomla 3 security patches, Helix Ultimate and Helix3 as well as SP Page Builder, we look inside the installed files for a string that only exists in a given release of the patch. That answers two separate questions that a version number cannot: whether any patch has been applied at all, and whether the one applied is the current release. As of today that check knows about SP Page Builder patch 1.0.3, so a Joomla 3 site still on 1.0.2 reports as outdated instead of showing a green tick it has not earned.

We also host the vendor’s own package, pinned by SHA-256 so what reaches the site is the file JoomShaper published rather than a copy of it, and install it through Joomla’s native installer from the mySites.guru UI in one click, with a revert. Using the vendor’s whole package matters: the patched files call methods that only exist in other patched files, so splicing one file at a time produces a site that fatals.

None of that helps the SP Page Builder 3.8.x sites, which are the largest group on Joomla 3. The vendor’s package installs onto 5.6.1 and nothing else, so those sites get no official fix at all, and there is no version of this that ends with a comfortable answer for them. Joomla 3 reached end of life in August 2023 and the extensions built for it are following it out. The fix there is the migration you have been putting off rather than any patch.

In the meantime, the findings that need a logged-in account are the ones to think about hardest on those sites: audit who holds Author and Editor, and turn off self-registration if nothing depends on it.

Every SP Page Builder flaw we have reported

Four rounds in five months, each found by reading the code or the access logs, each reported privately to JoomShaper before any public detail. In order:

June 2026, fixed in 6.6.2

Found in live exploitation. CVE-2026-48908, CVSS 10.0, added to the CISA Known Exploited Vulnerabilities catalog.

asset.uploadCustomIcon unauthenticated upload to remote code execution. No login, no file-type check: an anonymous visitor could upload and run a PHP web shell. We traced it in real access logs being used to plant hidden Super User accounts, so we treated it as a zero day and published the same day. Every version up to 6.6.1 was affected. Full write-up.

July 2026, fixed in 6.7.1

Reported privately in an audit of 6.7.0, pre-release build shared 23 July, fixed on 27 July. CVE-2026-65766, CVE-2026-65877, CVE-2026-65878, CVE-2026-65879, credited to Phil Taylor.

Pre-authentication SQL injection in the Dynamic Content endpoint, reachable with only the CSRF token Joomla hands every anonymous visitor, reading the whole database.
Unauthenticated open mail relay in the contact-form addons, because every copy of the extension shipped the same hardcoded secret that was supposed to protect the recipient address.
Author-level SQL injection in the media manager search.
Author-level arbitrary file delete.

Full write-up.

August 2026, fixed in 6.8.0

Reported 27 July, fixed on 12 August, sixteen days after 6.7.1. CVE-2026-67285, CVSS 9.3 Critical, and CVE-2026-67286, Medium, credited to Phil Taylor.

Unauthenticated PHP file inclusion in the Dynamic Content “load more” endpoint: pre-authentication remote code execution, sitting in the method directly below the one 6.7.1 had just hardened, so the previous fix release was itself vulnerable.
Unauthenticated arbitrary directory creation and file write on the same endpoint.

Full write-up.

September 2026, fixed in 6.9.1

Reported 8 September, the day 6.9.0 shipped, fixed in 6.9.1 on 14 September. Six CVE records, CVE-2026-78375 (8.6 High), CVE-2026-79700 and CVE-2026-79701 (6.9 Medium), CVE-2026-81564 (7.0 High), CVE-2026-81565 (6.9 Medium) and CVE-2026-81566 (5.1 Medium), all published on 14 September and all credited to Phil Taylor.

The five issues in this post: the Author-level blind SQL injection reading the whole database, the unauthenticated captcha bypass on the Pro form addons, the Editor-level file rename reaching outside the web root, the Editor-level Joomla menu takeover, and the Author-level web-root file write.

JoomShaper’s 6.9.1 changelog describes all six fixes in plain language and, a few hours after release, added the CVE number against each one. Both are real improvements on the one-line security notes of earlier releases, and together they let any site owner judge the urgency without waiting for us. What the changelog does not say is where the findings came from, and that is consistent across every round we have had with this vendor. The published records close that gap from the other side: all six name Phil Taylor of mySites.guru as the finder, exactly as the July and August records did, while JoomShaper’s own changelog for each of those releases did not. Crediting a reporter in a CVE record is the Joomla CNA’s practice, not the vendor’s.

How mySites.guru helps

You do not have to audit each site by hand. mySites.guru tracks the exact version of every extension on every Joomla site it monitors, and flags any site running a version we know to be vulnerable, this one included. Instead of opening each site to check whether it is on SP Page Builder 6.9.1 yet, you get a single list of the ones that are not, and you can update them from the same screen.

That is the whole point of watching a portfolio of client sites in one place: a flaw like this stops being a site-by-site scramble and becomes one filtered list and a batch update.

Field	Detail
Component	SP Page Builder for Joomla (`com_sppagebuilder`), including the com_content integration plugin
Vendor	JoomShaper (joomshaper.com)
Type	Author-level blind SQL injection (CWE-89); unauthenticated captcha bypass (CWE-807); path traversal in the media endpoints (CWE-22); missing access control on menu items (CWE-284)
CVSS 4.0	Joomla CNA published records, 14 September 2026: 8.6 High, 7.0 High, and four at 6.9 to 5.1 Medium, given per finding above
CVE	CVE-2026-78375, CVE-2026-79700, CVE-2026-79701, CVE-2026-81564, CVE-2026-81565, CVE-2026-81566. All six published by the Joomla CNA on 14 September 2026. JoomShaper’s changelog transposes the last two
Impact	Full database read from an Author account; anonymous captcha bypass on all three Pro form addons; Editor-level file rename and menu takeover; Author-level web-root file write
Finder	Phil Taylor, mySites.guru, named on all six published records
Affected versions	SP Page Builder 6.9.0 and earlier. Published lower bounds: 5.2.1 for the SQL injection, 3.2.6 and 5.1.4 for the two captcha routes, 4.0.0 for the three authorisation flaws. Four of the five affect Pro and the free Lite edition alike; the captcha bypass is Pro-only
Fixed in	SP Page Builder 6.9.1 (Pro and Lite), released 14 September 2026. Joomla 3 Security Patch 1.0.3 (30 September 2026) completes the back-port, including the captcha bypass and a corrected XSS fix, and installs only over SP Page Builder 5.6.1
Reported	8 September 2026, 12:47 BST, privately to JoomShaper with the Joomla security team copied in
Acknowledged	8 September 2026. A first fix build arrived the same afternoon and was rejected; a second on 9 September was accepted
Fix verified by mySites.guru	Against the released 6.9.1 Pro package, 14 September 2026

Timeline

8 September 2026 Reported privately, the day 6.9.0 shipped Five issues, reported to JoomShaper with the Joomla security team copied in: an Author-level blind SQL injection reading the whole database, an unauthenticated captcha bypass on the form addons, an Editor-level file rename reaching outside the web root, an Editor-level Joomla menu takeover, and an Author-level web-root file write. All five confirmed by live exploitation on a Joomla 5 test site.
8 September 2026 JoomShaper acknowledged and sent a first fix build, which we rejected Support confirmed within the hour and the development team returned a package the same afternoon. We retested it and sent it back for two reasons. It closed four of the five but left the captcha reachable by a second route, which we then named in all three form addons. And its manifest still read 6.9.0, identical to the vulnerable release, so Joomla's updater would never have offered it and no scanner could tell a patched site from an unpatched one.
9 September 2026 A second build, which we accepted JoomShaper sent a revised package the next morning. We retested it and replied that it was much improved and could be released.
14 September 2026 SP Page Builder 6.9.1 ships, and we verify it Pro and Lite both released as 6.9.1, alongside a separate Joomla 3 Security Patch. We read the released Pro package and confirmed all five fixes are present, that the manifests really declare 6.9.1, and that the captcha route is closed in all three form addons rather than only the one the changelog names.
14 September 2026 Six CVE identifiers appear in the vendor changelog Later the same day JoomShaper added CVE numbers to the 6.9.1 changelog: CVE-2026-78375, CVE-2026-79700, CVE-2026-79701, CVE-2026-81564, CVE-2026-81565 and CVE-2026-81566. Six rather than five, because the captcha bypass was split into one record per route.
14 September 2026 The Joomla CNA publishes all six records Published within minutes of each other, each with a CVSS 4.0 score, an affected range and a credit line naming Phil Taylor of mySites.guru. The vendor changelog puts two of the six against the wrong findings, and the records are the authority: CVE-2026-81565 is the media upload, CVE-2026-81566 is the menu item. This post follows the records.

Regular Labs Publishes 24 Joomla Extension Updates Including 10 Security Fixes

phil@mysites.guru (Phil Taylor) — Sun, 13 Sep 2026 16:00:00 GMT

Regular Labs, Peter van Westen’s Joomla extension house, published 24 extension updates on 13 September 2026. Every one of them shipped the same day. Ten have a [SECURITY FIX] entry in the changelog, covering nine CVE identifiers between them, and four of those ten are flagged by the vendor as BC BREAK.

This is the second catalogue-wide release in eight weeks. The 22 July round patched around thirty extensions with no CVE numbers attached at the time. Every version this batch marks as affected is a build from that July release or later, so the sites that did the right thing in July are precisely the sites with something to do again now.

Update, 27 September 2026: Tabs & Accordions 3.2.0 fixes a second issue

Tabs & Accordions 3.1.0, recommended below, is no longer the version to be on. Regular Labs released 3.2.0 on 27 September with a separate security fix, CVE-2026-100751: data-rlta-url attributes accepted executable JavaScript URLs, so a content author could plant script that ran for visitors. 3.1.0 only fixed the data-rlta-alias attribute, so update to 3.2.0 even if you updated in September. Modules Anywhere 10.0.0 was released the same day with a fix of its own, covered in our post on both releases.

Do Conditional Content first

CVE-2026-85192, fixed in Conditional Content 8.0.0, let an untrusted article author run PHP through an inline Condition Rule. That is code execution reachable by the lowest content-authoring role on a Joomla site. Everything else in this batch is cross-site scripting or information disclosure. If you triage nothing else, triage this one. It affects the Pro edition.

TL;DR

24 extensions updated, all dated 13 September 2026. Ten have security fixes, fourteen are ordinary maintenance.
Nine CVE identifiers, unpublished on release day and live at cve.org the next morning, scored from 5.3 Medium to 9.4 Critical.
Two CVEs span multiple extensions because the code is shared. CVE-2026-85188 covers four extensions, CVE-2026-85196 covers two.
CVE-2026-85192 is the outlier: PHP execution by an article author, in Conditional Content. The rest are XSS and information disclosure.
Four releases are flagged BC BREAK and will stop working features until an administrator re-authorises them. This is a release to stage, not to push.
Every rule is already live in our vulnerability database, so connected Joomla sites running an affected build were flagged on release day, a full day before the records published.

What Regular Labs shipped on 13 September

All 24 releases, with the ten security ones marked. Version numbers link to the vendor’s changelog entry.

Extension	Version	Security fix
Advanced Module Manager	12.1.0	Yes
Articles Anywhere	20.0.0	Yes, BC BREAK
Articles Field	5.0.5
Better Frontend Link	2.2.11
Cache Cleaner	10.0.7
CDN for Joomla!	8.0.4
Conditional Content	8.0.0	Yes, BC BREAK
Content Templater	14.2.0	Yes
DB Replacer	9.1.0
Email Protector	6.3.12
Extension Manager	9.3.5
GeoIP	7.0.4
IP Login	7.0.4
Keyboard Shortcuts	4.0.4
Modals	17.0.0	Yes, BC BREAK
Modules Anywhere	9.0.5
Quick Index	5.0.5	Yes
ReReplacer	16.2.0	Yes
Snippets	11.0.0	Yes, BC BREAK
Sourcerer	16.0.2
Tabs & Accordions	3.1.0	Yes
Tooltips	10.1.0
Users Anywhere	2.1.0	Yes
What? Nothing!	19.79.4

Two of the fourteen non-security releases still change security-relevant behaviour without the vendor labelling them as fixes. Cache Cleaner 10.0.7 “tightens destination checks for URLs requested after cache cleaning”, and Tooltips 10.1.0 adds the same author-group gate on JavaScript Events that earned Modals and Articles Anywhere a CVE. Neither is tagged, so neither gets a rule from us, but both are worth knowing about.

The ten security fixes

Nine CVEs, ten extensions. The affected range in every case starts at the July 2026 build and ends at the version below. Scores are the Joomla CNA’s own, published on 14 September.

CVE	Extension	Fixed in	CVSS 4.0	Issue
CVE-2026-85192	Conditional Content	8.0.0	9.4 Critical	Untrusted article authors could run PHP through inline Condition Rules
CVE-2026-85195	Articles Anywhere	20.0.0	7.5 High	JavaScript Events attachable by any content author
CVE-2026-85196	Articles Anywhere, Users Anywhere	20.0.0, 2.1.0	5.3 Medium	Request input unescaped, raw output open to any author
CVE-2026-85189	Modals	17.0.0	7.5 High	Modal links accepted `javascript:` URLs
CVE-2026-88853	Modals	17.0.0	7.5 High	JavaScript Events attachable by any content author
CVE-2026-88852	Snippets	11.0.0	7.5 High	Snippet variable overrides settable by any author
CVE-2026-85190	Quick Index	5.0.5	7.5 High	Crafted index class options allowed JavaScript injection
CVE-2026-85191	Tabs & Accordions	3.1.0	7.5 High	Crafted `data-rlta-alias` attributes ran JavaScript on click
CVE-2026-85188	Advanced Module Manager, Conditional Content, Content Templater, ReReplacer	12.1.0, 8.0.0, 14.2.0, 16.2.0	6.9 Medium	Condition Set labels could reference unrelated database fields

The shared-code pattern is the thing to take away. CVE-2026-85188 is one defect in one Condition Set implementation that ships inside four separate products, so patching Content Templater and stopping there leaves the same bug live in three other places. Regular Labs has always built this way, and it is why a catalogue-wide release is the normal shape of a fix here rather than an overreaction.

Every one of these needs an authenticated account with content rights. None is reachable by an anonymous visitor. That is the honest framing, and it is also why Conditional Content stands out: on a Joomla site the Author role is the lowest content role there is, and plenty of sites hand it out freely or allow self-registration into it.

Four of these releases will change how your site behaves

This is the part that matters operationally, and it is the part a CVE list will not tell you.

Articles Anywhere 20.0.0, Conditional Content 8.0.0, Modals 17.0.0 and Snippets 11.0.0 are all flagged BC BREAK by the vendor. In each case the fix was not to sanitise a value but to withdraw a capability that had been open to any content author and put it behind an author-group setting that starts switched off.

Articles Anywhere and Modals now restrict JavaScript Events to selected article author groups by default.
Snippets now restricts Snippet variable overrides the same way.
Conditional Content now prevents untrusted article authors running PHP in inline Condition Rules.

In each case the new setting defaults to Super Users only. We confirmed that in the shipped packages rather than inferring it: the javascript_events_usergroups field in Articles Anywhere 20.0.0’s plugin manifest sets default="Super Users", and the code default matches. Articles Anywhere 19.0.6 has no such field and no gate at all, so this arrived whole in 20.0.0.

That default is the right one for a security fix, and it is also why sites will change behaviour. If a site legitimately uses any of those features from a non-Super-User account, and many do, the feature stops working the moment the update is applied, and keeps not working until an administrator re-authorises the groups that should have it. Nothing warns you. The page just renders without the behaviour it had yesterday.

The gate is also narrower than a group check alone. Regular Labs’ shared security code only allows executable attributes through when the content is being rendered as a Joomla article, category or featured view, when the tag is actually present in the stored article row, and when the article’s last editor is in an allowed group. Modules, templates and third-party components never qualify, whatever the group setting says. Anyone using these tags inside a module should expect them to stop working regardless of how the permission is configured.

Conditional Content is the gentlest of the four, and its own field description says so: existing saved Condition Sets keep working, and only the restriction on saving new PHP is enforced. The other three take effect on render.

Stage this batch before rolling it out

A security release that removes a working capability on purpose is a different risk profile from one that patches a string behind the scenes. Update a representative site first, check any page using JavaScript Events, Snippet variables or PHP Condition Rules, re-authorise the author groups you actually trust, and only then push the wave.

For what it is worth, the restriction is the correct call. Joomla’s own default text filters put Author, Editor and Publisher on the Default Forbidden List, which strips script along with iframe, object and embed. Only Super Users get unfiltered HTML, and core tightened this on purpose in 3.8.8 so that even Administrators no longer get unfiltered content by default. An extension that let an Author put executable script in a page was not offering an expected capability. It was routing around a filter Joomla puts in front of that group on purpose.

The records published the morning after the releases

All nine identifiers were RESERVED when the packages went out on 13 September. We checked the MITRE record endpoint, the NVD API and the CVE Project’s own git mirror that afternoon, and all three came back empty. The records went live at cve.org between 06:12 and 06:21 UTC the next morning, each with a CVSS 4.0 score from the Joomla CNA.

That is quick by the standards of this vendor’s July round, and it still left the whole of release day with the vendor’s own changelog as the only place to read about nine security issues. Publication is also a long way short of coverage. Aggregators, feeds and commercial scanners re-import on their own schedules, so tooling that stays quiet on Regular Labs this week is behind the record rather than giving your sites a clean bill of health.

The July round sat in that gap for weeks, and those numbers did eventually arrive. One of them, the Sourcerer issue, turned out to need a second fix release once it was properly scored.

We do not wait for publication. All 34 matching rules for this batch went into our Joomla vulnerability database on release day, so every connected site running an affected build was flagged with the version that resolves it before any scanner could see the CVE. Five more rules followed on 14 September, when the published record spelled out a second affected range for the Snippets Free edition, and the CNA’s own scores replaced the ratings we had assigned before the records went live.

Regular Labs did announce the release publicly and did so promptly, posting eleven times on Mastodon within twelve minutes of the packages going live, each post linking its own changelog. The problem is reach rather than intent. That account had around 70 followers when we checked, the vendor’s RSS feed has not had an item since 2019, there is no security page and no mailing list signup anywhere on the site. The summary post announcing all 24 updates does not use the word security at all, and the Modals post hit Mastodon’s character limit mid-sentence, so one of the two CVE numbers for that extension is simply not in it.

None of that is concealment. It is a release that was announced into a room with almost no one in it, on the one day the CVE records that would have spread it further were still unpublished. If you maintain Joomla sites and you learned about this from us rather than from the vendor, that is why.

What the sites we monitor actually look like

We can see the installed version of every Regular Labs extension across the Joomla sites connected to mySites.guru. Measured on release day, across the ten affected extensions, the picture splits in a way that is worth sitting with.

62.8%

on the July build

current until this morning, newly affected today

36.7%

already behind

running a version with a published CVE before today

0.5%

already patched

as expected on release day

Share of installs across the ten affected extensions, on Joomla sites snapshotted in the last 30 days.

The 62.8% is unremarkable. Those sites were fully current when they went to bed and are affected because a new release exists, which is how patching works.

The 36.7% is the number worth acting on, and when we broke it down by the age of the installed build it turned out not to mean what we first assumed.

Around 32% of all installs we monitor sit on a build dated 4 September 2023 or earlier, with almost nothing in between that and the current release. The obvious reading is a large group of abandoned sites. The obvious reading is wrong.

The 2023 cluster is Joomla 3, and it is stranded rather than neglected

4 September 2023 is the date Regular Labs last shipped a build for Joomla 3. Pull the vendor’s own update feed and every Joomla 3 branch is frozen on that day: Articles Anywhere at 14.2.0, Modals at 12.6.1, Snippets at 8.7.0, Quick Index at 3.6.0, Content Templater at 11.5.0, ReReplacer at 13.2.0. The Joomla 4, 5 and 6 branch is versioned separately and is the only one receiving this batch.

Those terminal version numbers are exactly the versions clustering in our data. Measured across the seven affected extensions with a Joomla 3 branch, 19.1% of installs are sitting on precisely the last build Regular Labs ever released for their platform, and a further 11.8% are older still.

That reframes the number. A fifth of these installs belong to sites that applied every update offered to them and then ran out of updates. Joomla’s own update check tells them they are current, because as far as their branch is concerned they are.

None of these nine fixes will reach a Joomla 3 site

There is no Joomla 3 backport in this batch and there will not be one. For a site in that group the remediation is a migration rather than an update. Applying the fix means moving the site to Joomla 4 or later first, which is work of a completely different size, and worth scoping now rather than at the next release.

So the useful question after this release goes past whether you applied it: which sites in your portfolio could not receive it, and did you know which ones those were before today? The oldest Articles Anywhere install still connected to us is version 1.9.3, released in January 2011.

The vendor’s own update feed is still behind its own release

One practical wrinkle, checked at 16:17 UTC on release day, roughly three hours after the packages went live.

Joomla sites do not poll the changelog page. They poll download.regularlabs.com/updates.xml, and that feed was still offering the previous version for three of the ten affected extensions: Quick Index at 5.0.4, Content Templater at 14.1.0 and Users Anywhere at 2.0.6. Articles Anywhere and Snippets had already rolled over, and Snippets flipped while we were watching, so this is staggered propagation rather than a broken feed. The feed sets a six hour cache lifetime, which fits.

It still means a site checking for updates this afternoon may be told it is current on three extensions that are not. If you are working through this batch today and an extension reports nothing available, check the version against the table above rather than trusting the prompt.

How do you update 24 extensions safely?

Take a backup first. Four of these releases change behaviour on purpose, so a rollback path is not optional this time.
Do Conditional Content first if you run it. CVE-2026-85192 is the only code execution issue in the batch.
Update one representative site, then open a page that uses JavaScript Events, Snippet variables or PHP Condition Rules and confirm it still does what it should.
Re-authorise the author groups you actually trust in each of the four BC BREAK extensions, rather than disabling the new restriction wholesale. The restriction is the fix.
Check your template overrides. Articles Anywhere 20.0.0 also changes full article layouts in feeds, which is exactly where a stale override bites.
Do not trust an empty update prompt today. The vendor’s update feed was still serving the previous version for three of the ten extensions three hours after release. Check the installed version against the table above.
Separate out your Joomla 3 sites. They cannot receive any of this. Put them on a migration list rather than an update list.
Then roll the wave, and turn on automatic updates for the extensions where you are comfortable with it, so the next catalogue-wide release is not another manual afternoon.

How do I find every site running a Regular Labs extension?

Checking 24 extensions by hand across a portfolio is the kind of job that gets postponed, which is how a site ends up on a 2023 build.

mySites.guru keeps an extension inventory for every connected Joomla site. Searching the extension inventory for any of these names returns every install and its version on one screen, and anything below the fixed version is flagged automatically against the rules we added on release day. You get a list of sites to fix rather than a list of sites to check.

The official Joomla Vulnerable Extensions List will almost certainly not record this release, and the public CVE databases cannot yet. That gap between what a vendor has fixed and what the world can see is the whole reason we keep our own vulnerability database rather than mirroring someone else’s.

Timeline

4 September 2023 The last Joomla 3 build Regular Labs shipped its final Joomla 3 release across the range on this date. Every Joomla 3 branch in the vendor's update feed is still frozen here, which is why a fifth of the installs we monitor sit on exactly these version numbers.
22 July 2026 The catalogue-wide security release Around thirty extensions patched at once, with no CVE identifiers assigned at the time. Every version marked affected in today's batch is a build from that release or later.
17 August 2026 Sourcerer 16.0.0 closes CVE-2026-74253 The July round's Sourcerer fix turned out to be incomplete, and the issue was assigned a CVE retroactively. Evidence that a Regular Labs fix release can itself need re-scoping.
13 September 2026 Twenty four updates, ten with security fixes Nine CVE identifiers across ten extensions, four of them flagged BC BREAK. All nine CVE records were still RESERVED and unpublished on the day of release.
14 September 2026 The nine records publish with official scores Every record went live at cve.org the next morning, scored by the Joomla CNA. CVE-2026-85192 came in at 9.4 Critical, six at 7.5 High, and the two shared-code issues at 6.9 and 5.3 Medium.

Unauthenticated SQL Injection in SP Property Finder found by mySites.guru

phil@mysites.guru (Phil Taylor) — Thu, 10 Sep 2026 09:00:00 GMT

SP Property Finder is JoomShaper’s real-estate listings component for Joomla, used to run property search sites: agents, listings, maps, enquiry forms. During a security audit of SP Property Finder 4.1.3, mySites.guru found an unauthenticated SQL injection in the public property search, and reported it to JoomShaper before disclosing anything publicly. JoomShaper closed it in SP Property Finder 4.1.4.

If you run SP Property Finder on any Joomla site, update to 4.1.4 now. If you manage more than a handful of sites, read on for how to find every affected one at once.

TL;DR

mySites.guru found an unauthenticated blind SQL injection in SP Property Finder 4.1.3 and reported it to JoomShaper
Unauthenticated SQL injection, CVE-2026-78082. The Joomla CNA rates it 9.3 Critical and credits it to us; we assess the read-only injection at 8.7 High. Either way, with no login and no token an anonymous visitor could read the entire database, password hashes and the site secret included
Unauthenticated mail relay (CVSS 4.0 6.9, Medium). The property contact and enquiry forms took the recipient address straight from the request, so an attacker could send email to any address with a spoofed sender, from your domain and mail server, an open spam and phishing relay
Update to SP Property Finder 4.1.4 immediately
Reported privately, fixed in 4.1.4. Our two findings are CVE-2026-78082 (SQL injection, credited to Phil Taylor by the Joomla CNA) and CVE-2026-78303 (mail relay); the release fixed three more that we did not report
A month from report to release, 27 days of it silence. Acknowledged 11 August, then quiet until we chased on 7 September with the Joomla Security Strike Team copied in; a fixed build followed within 20 hours
mySites.guru already flags every connected Joomla site still running a vulnerable version

How we handle what we find

mySites.guru discovered this issue and reported it to JoomShaper before publishing details. We withheld the exact requests and any proof of concept until a fix was available and site owners had a reasonable window to update. Fix first, publish second, every time.

The worst one: an anonymous request that reads the database

SP Property Finder’s whole reason to exist is a public property search. A visitor filters listings by city, price, size, number of bedrooms, postcode, and the component turns those filters into a database query. Most of those filters were handled correctly. A few were not.

The postcode filter is the clearest example. The search model took the zip value from the request and pasted it straight onto the end of the query as a.zip = <value>, with none of the quoting that the neighbouring city and keyword filters use (components/com_spproperty/models/properties.php:166, with the same pattern in the map view at models/maps.php:153). The sort control had the same flaw in its ORDER BY clause, where the sort direction was appended raw (properties.php:190), and so did the price and size range dropdowns (properties.php:131 and :136). A postcode and a sort direction are ordinary-looking fields, which is exactly why the missing quoting is easy to overlook.

There is no login, no token and no CSRF check in front of any of it. The property search is meant to be used by anonymous visitors, so the endpoint is open by design, and the missing input handling turns that open endpoint into an unauthenticated SQL injection. An anonymous attacker could read any table in the Joomla database, from user accounts and password hashes to the site secret and every stored enquiry.

We confirmed it on our own SP Property Finder test install, two ways. A boolean proof: a crafted postcode that asked the database a true-or-false question about another table (does a user with this ID exist, does this character of the admin password hash match) changed which listings came back, letting an answer be read out one bit at a time. And a time-based proof: a value that made the database pause for a measurable few seconds against an instant baseline, which shows the injected code ran inside a real query even when nothing is visible on the page. We did not extract any real data beyond confirming the admin username and the first byte of its hash on our own lab box.

This one leaves no trace

A database read leaves your site looking untouched: no file changes, no new admin user, nothing for an integrity scanner to catch. If a vulnerable version was ever live, treat the database as potentially copied, rotate the Joomla secret and any stored API keys, and assume password hashes are known.

Read-only, but not harmless

It is worth being precise about what this injection can and cannot do.

It is a read-only injection. It sits inside a SELECT that fetches property listings, and Joomla’s database driver does not run stacked queries, so there is no way to turn it into an INSERT, UPDATE or DELETE. An attacker cannot use this bug on its own to add an administrator, change a price, or write a file. The Joomla CNA published it as 9.3 Critical, on a vector that assumes integrity and availability impact. We score the injection itself High rather than Critical, because it is read-only: a total loss of confidentiality, with integrity and availability untouched. On a read-only bug, the distinction changes nothing about how fast you should update.

Read-only does not mean small. The injection reads the whole database, not just SP Property Finder’s own tables, so “confidentiality” here means every row on the site is exposed to an anonymous request. On a property site that includes the personal data the component holds, the enquirer names, email addresses and phone numbers submitted through contact and booking forms, the agent records, and the booking and enquiry history. It includes unpublished and draft listings and any prices not yet meant to be public. It includes the Joomla #__users table, with usernames, email addresses and password hashes, the session table, and the site secret. There is no table the query cannot reach: if it is in the database, an anonymous visitor can read it.

The catch is that a full database read is a short step from full compromise. The Joomla session table lives in the same database, so an attacker who can read arbitrary tables can read a logged-in administrator’s session token and step straight into the admin panel with it, no password required. From there, installing a malicious extension is a normal administrator action. Reading the password hashes offers a slower second route through offline cracking. “Read-only” describes the bug, not how far the damage reaches.

The second finding: an open mail relay

The property pages have contact and enquiry forms, so a visitor can ask an agent about a listing. To send that email, the form told the server who to send it to, and the server believed it. The recipient address was taken straight from the submitted request and used as-is, with no server-side lookup of the real agent and nothing to stop a visitor changing it (controllers/agents.php and controllers/properties.php, neither of which has a CSRF token on the send).

Because the recipient comes from the request, an attacker could point it at any address they liked, set the sender to anything they liked, and make the site send arbitrary email. The result is an unauthenticated open mail relay: any SP Property Finder site with a contact form on a published listing could be made to send email to any recipient, with a spoofed sender, from the site’s own domain and mail server. That is a spam and phishing platform running on your domain’s reputation, and the fastest way to get your legitimate mail blacklisted. The correct fix, which the update makes, is for the server to look up the real recipient from the property or agent record it already holds, rather than trusting one supplied by the browser.

Does 4.1.4 actually fix it?

We tested it rather than reading the changelog, because a fix release and a fixed bug are not always the same thing. With this same vendor in August we reported a SQL injection, watched the patch harden the exact method we named, and found the identical flaw still reachable through the function directly below it.

The check worth doing is a before and after on one install. We ran our original attack requests against 4.1.3, confirmed every one of them still worked, then sent the identical requests to 4.1.4. That order matters more than it sounds: a patched site returning no results looks exactly like a site where the filter stopped being applied at all, and only the control run separates the two.

On 4.1.4 the postcode filter still filters and no longer injects. A value crafted to break out of the query comes back treated as ordinary text, and the database reports no error behind it. The sort control is checked against a fixed list of permitted columns and directions, so anything else falls back to the default ordering instead of reaching the query at all. The price and size ranges are validated as numbers before use. The map view got the same treatment as the property list, closing the second route to the same flaw.

The contact forms were rebuilt rather than patched around. The recipient is looked up in the database from the property or agent being enquired about, so the browser cannot influence who receives the mail, and both endpoints require a valid session token before they will send anything.

Fixed properly, shipped by JoomShaper with no announcement or credit

The fix itself is good work, and we say so above. What surrounds it is the pattern we have written about before with this vendor.

It also took a month, and most of that month was waiting. We reported the flaw on 10 August and 4.1.4 shipped on 10 September. JoomShaper acknowledged the report on 11 August, naming the affected parameters back to us, then went silent for 27 days. The build only appeared after we chased on 7 September and copied the Joomla Security Strike Team on the thread, at which point a fixed package reached us within 20 hours. The engineering, once it started, was quick and correct. What it took to start was a chase, with the Joomla Security Strike Team copied in to see the response time for themselves.

JoomShaper released SP Property Finder 4.1.4 on 10 September 2026 with no security announcement and no advisory. It exists as a changelog on the download page, the security entries sitting above routine map and asset-loading tidy-ups with nothing to mark them apart.

Two of those five CVEs are the issues we reported. CVE-2026-78082 is the SQL injection, which the Joomla CNA published at 9.3 Critical and credited to us. CVE-2026-78303 is the mail relay, which the CNA records as an unvalidated email destination in booking requests. The changelog’s own wording does not line up with those records: it labels CVE-2026-78303 as “contextual output escaping” rather than the mail relay it closes, and never uses the word relay anywhere. The other three CVEs cover a missing CSRF check, a gallery access-control flaw and a cross-site scripting bug, and are not our findings. JoomShaper’s changelog credits no one; the Joomla CNA credits us on the SQL injection alone.

The changelog names no reporter. We had asked JoomShaper to tell us when 4.1.4 went public and were not told; we found the release through our own version tracking. It is the same shape we described with SP Page Builder and EasyStore earlier in the year: a complete, well-built fix, shipped without a word to the person who reported it. We have no complaint about the engineering, only about being left to find the release ourselves and about a changelog whose descriptions do not even match the CVE records it cites.

Which versions are affected?

SP Property Finder 4.1.3, the version we audited, and every earlier version that shares the same front-end search models are affected. JoomShaper fixed the issue in SP Property Finder 4.1.4. If you run any earlier version, assume your site is affected and update now: the search endpoint needs no login, so if the site is online, it is reachable.

If you are on 4.1.3 or earlier

Assume your site is affected and update now. The SQL injection needs no login and no token, so a public property search page is all an attacker needs to reach it.

How do you update SP Property Finder safely?

Take a backup first. Before any extension update on a production Joomla site, back up the database and files. If you use mySites.guru, trigger a snapshot or a full backup first.
Update through Joomla’s Extensions manager, or in bulk from mySites.guru. On a single site, open the Joomla administrator, go to System, then Update, then Extensions, and let Joomla pull SP Property Finder 4.1.4. If you manage more than one site, use the mySites.guru mass update feature to upgrade SP Property Finder across every affected site from one dashboard.
Confirm the version. After updating, check SP Property Finder reports 4.1.4 or later.
Clear caches. Clear Joomla’s cache and any CDN or page cache. Property search pages are often cached, which is worth knowing here: page caching hid the flaw from casual testing during our audit, because identical requests returned an identical cached page.
Rotate secrets if you were exposed. If a vulnerable version was live and public for any length of time, rotate the Joomla secret and any stored API keys, and treat password hashes as potentially known.

Updating closes the door. It does not undo any data an attacker may already have read through the SQL injection, so if you handle sensitive data and were on a vulnerable version for a while, treat credentials and exposed data as potentially known.

What the sites we monitor look like today

We keep a live inventory of every extension on every connected Joomla site, so we can see how SP Property Finder is versioned across the ones we monitor. Here is the spread on the day 4.1.4 shipped.

94%

still on a version below 4.1.4

on the day the fix shipped

52%

on 4.1.3, the version we audited

the build the injection was proved against

15%

on a release older than the 4.1 line

some on the 1.x and 3.x branches, years behind

already updated to 4.1.4

within hours of release

Measured 10 September 2026 across connected Joomla sites running com_spproperty with a snapshot in the previous 30 days. Percentages of that group, a small population, not of all managed sites.

Release day is too early to judge an update rate, so the 94% is expected rather than damning. The figures that matter are the half still on 4.1.3, the exact build we proved the injection against, and the sites several releases behind on the 1.x and 3.x branches, where a security release is easy to miss entirely. On the day a fix ships for a public, unauthenticated, whole-database read, almost every affected site is still running the code that leaks. Closing that gap is work, and it is the work the next section is about.

How do I find every SP Property Finder site I manage?

Up to about ten sites, you can log in to each Joomla admin and check. Past that, you need a single view. mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for SP Property Finder once and get back every connected site running it, the version each one is on, and whether an update is available.

View every SP Property Finder install across your sites

Open your Extension Inventory

Search for SP Property Finder across every connected Joomla site and filter for anything earlier than 4.1.4. Not a subscriber? Sign up free and connect your sites.

Why search and listing components keep producing this

A property search is attack surface for the same reason it is useful: it takes input from anonymous visitors and turns it into a database query. A filter for postcode, price or bedroom count cannot require a login, because the whole point is that visitors use it. Every one of those public filters is a place where request input meets the database, and when the code behind them concatenates that input into the SQL instead of quoting it, an anonymous visitor becomes an anonymous attacker.

We have seen the same shape across the Joomla ecosystem this year, from the SP Page Builder pre-auth SQL injection in the same vendor’s flagship builder, to Quix and DPCalendar, and the wider month of Joomla disclosures. The lesson is the same each time: the components that accept input from anonymous visitors need updating the moment a fix exists, which makes these updates security-critical rather than routine maintenance.

Stay ahead of the next one

There will be another, because Joomla runs on thousands of third-party extensions and the ones that accept input from anonymous visitors keep producing bugs like these. The hard part is never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before an attacker does.

That is the job mySites.guru does for you. It keeps a live inventory of every extension on every Joomla and WordPress site in your account, flags the ones with a known vulnerability, and lets you push the update to all of them from one screen.

Get free email alerts when a Joomla vulnerability breaks

We email a plain-English alert the moment a serious flaw like this one is disclosed, with the affected versions and what to do. No charge, unsubscribe any time.

Subscribe to security alerts

Want the alerts and the tooling to act on them? Start with a free audit on one site and see your full extension inventory, or sign up for mySites.guru to get vulnerability alerts and one-click updates across every site you manage.

Disclosure and severity

The main finding is a SQL injection (CWE-89) reachable by an anonymous visitor over the network, with no login and no token. It is read-only, which caps the direct impact at a total loss of confidentiality: full read access to the database, integrity and availability untouched. The secondary finding is an unauthenticated mail relay: the property contact forms trust a request-supplied recipient, yielding arbitrary mail sending with sender spoofing.

SP Property Finder 4.1.4 shipped on 10 September 2026. The Joomla CNA published CVE-2026-78082 for the SQL injection, credited to Phil Taylor of mySites.guru, and CVE-2026-78303 for the mail relay, with no reporter named. Three further CVEs in the same release, for a CSRF gap, a gallery access-control flaw and an XSS issue, are not our findings.

The Joomla CNA published the SQL injection at 9.3 Critical, on a vector (VC:H/VI:H/VA:H) that assumes integrity and availability impact. We assess the injection itself at 8.7 High: it is read-only, so the honest vector is VC:H alone, a total loss of confidentiality with integrity and availability untouched. It sits at the top of the High band either way, and a full-database read is serious regardless of where the number falls.

8.7CVSS 4.0

HighmySites.guru read-only assessment (Joomla CNA published 9.3 Critical)

Reachable over the internet through the public property search, with no login and no token. Ends in full read access to the site database, password hashes and the site secret included. The Joomla CNA scored it 9.3 Critical on a vector that also assumes write and availability impact; we keep the read-only vector we proved.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

No login neededExploitable over the internetFull database readPassword hashes exposed

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:N: None: Other systems keep their integrity
SA:N: None: Other systems stay up

6.9CVSS 4.0

MediummySites.guru assessment

CVE-2026-78303. The property contact and booking forms trusted a recipient address supplied by the browser, so the site could be made to send mail to anyone with a spoofed sender. Scored Medium because nothing on the Joomla site itself changes, which understates the real cost: phishing sent from your own domain and mail server.

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N

No login neededSender spoofingMail sent from your domain

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:N: None: Works against any affected install
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:N: None: Nothing can be read
VI:N: None: Nothing can be altered
VA:N: None: The site stays up

What it does beyond the site

SC:N: None: Other systems keep their data
SI:L: Low: Some data on other systems can be altered
SA:N: None: Other systems stay up

Each finding, scored under CVSS 4.0:

Finding	Vector (`CVSS:4.0/...`)	Score	Severity
Unauthenticated SQL injection (full DB read)	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`	8.7	High
Unauthenticated mail relay (sender spoofing)	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N`	6.9	Medium

CVSS 4.0 scores the mail relay 6.9, Medium, because the direct impact on the Joomla system is low: it reads and changes nothing on the site itself. That number understates the practical risk, which is phishing sent from your own domain and mail server, and the mail-reputation damage that follows. We treat it as a priority fix regardless.

Field	Detail
Component	SP Property Finder for Joomla (`com_spproperty`)
Vendor	JoomShaper (joomshaper.com)
Type	Unauthenticated SQL injection (CWE-89); unauthenticated mail relay (CWE-640 / CWE-79-adjacent)
CVSS 4.0	SQL injection 9.3 Critical (Joomla CNA), 8.7 High (our read-only assessment); mail relay 6.9 Medium
CVE	CVE-2026-78082 (SQL injection, credited to Phil Taylor by the Joomla CNA) and CVE-2026-78303 (mail relay); both published 10 September 2026
Impact	Anonymous read of the whole database including password hashes and the site secret; unauthenticated arbitrary mail sending with sender spoofing
Finder	Phil Taylor, mySites.guru
Affected versions	4.1.3 and all earlier versions sharing the front-end search models
Fixed in	SP Property Finder 4.1.4
Reported	10 August 2026 (privately to JoomShaper)
Acknowledged	11 August 2026 (JoomShaper confirmed receipt)
Fixed	10 September 2026 (SP Property Finder 4.1.4)
CVE published	CVE-2026-78082 and CVE-2026-78303, both 10 September 2026

Timeline

2026-08-10 Reported privately to JoomShaper An unauthenticated SQL injection reading the whole database including password hashes and the site secret, plus an unauthenticated mail relay, both in SP Property Finder. All public detail withheld.
2026-08-11 JoomShaper acknowledges the report The vendor confirmed receipt within a day and named the affected parameters back to us, so the report had reached someone technical rather than a support queue.
2026-09-07 We chase, 27 days after the acknowledgement, copying the Strike Team Nothing had been heard since 11 August. The chase copied the Joomla Security Strike Team, and a fixed build followed within 20 hours.
2026-09-08 JoomShaper sends a fixed build for checking We retested it against our original attack requests, with a control run on the vulnerable version first, and confirmed every reported flaw was closed. Nothing changed for site owners at this point, because the build was not public yet.
2026-09-10 JoomShaper ships 4.1.4 with no announcement Released with no security announcement and no advisory, as a changelog on the download page. We had asked to be told when it went out and were not; we found the release ourselves. It is the same build JoomShaper sent for sign-off, so our verification stands.
2026-09-10 The release cites five CVEs, two of them ours CVE-2026-78082 for the SQL injection and CVE-2026-78303 for the mail relay are the two we reported; three more cover issues we did not. The Joomla CNA credits Phil Taylor as finder on the SQL injection record and no one on the rest; JoomShaper's own changelog credits no one at all. All five published at MITRE the same day.

Digital Peak patches four Joomla extensions after a Claude audit

phil@mysites.guru (Phil Taylor) — Thu, 10 Sep 2026 00:00:00 GMT

Digital Peak shipped five releases across four Joomla extensions today, all rated High and all out of band. The vendor puts eleven of the twelve fixes down to a security analysis run with Claude over the last few days. The twelfth is the DPCalendar location title, which we reported on 27 August and which the announcement now credits to us.

That is the third DPCalendar security release in nine weeks, and the first one that reaches past the calendar into the rest of the catalogue. The code is public for three of the four extensions, so we read the actual changes rather than working from the severity ratings.

Do DPAttachments first, then the rest

DPAttachments 5.8.1 is the only one the vendor asks you to prioritise, and the code shows why: the attachment download route checked that an attachment record existed and never checked whether the person asking was allowed to have it. The other three generally need an account, or content arriving from a source you already trust.

TL;DR

Five releases: DPCalendar 10.12.1 and 8.19.6, DPMedia 1.21.1, DPAttachments 5.8.1 and DPCases 3.8.1. Every one of them is tagged Security: High on its download page
DPAttachments is the priority. Unpublished attachments, attachments on a restricted view level, and attachments outside their publish window could all be downloaded by someone with no entitlement to them
The releases are out of band. Digital Peak normally ships on the fourth Thursday of the month, and today is the second Thursday
The Joomla 3 branch got one fix, not three. DPCalendar 8.19.6 is security only and its release notes list the unescaped location title alone
The DPCalendar fix is one we reported. We sent it to Digital Peak and the Joomla Security Strike Team on 27 August, and the vendor’s announcement now credits it
Eleven of the twelve have no CVE yet. The DPCalendar location title is the exception, under CVE-2026-78071, whose affected range was widened on release day to take in 10.12.0 and 8.19.5
Two of the fixes share a shape worth recognising: in both DPAttachments and DPCalendar, the escaping was already present on the field next door and simply missing on one
DPCalendar is not one update. On release day our Release Radar recorded 59 distinct DPCalendar items moving to the new versions

What did Digital Peak fix on 10 September?

Twelve issues across four extensions, four of them rated High and eight Medium. The vendor’s announcement lists them by severity, and each release page lists the internal tracker numbers.

Extension	Fixed in	High-severity issue	Also fixed
DPCalendar	10.12.1, 8.19.6	Location title not escaped in the map view and upcoming module	Microsoft and Exchange attachment filename hardening, CSRF state parameter on calendar imports
DPMedia	1.21.1	DPReferences shows references to users without media manager access	Path traversal on external file names, Google Drive search injection, OAuth state parameter, two permission plugin fixes
DPAttachments	5.8.1	Unauthorised access to direct downloads	Stored XSS in the CSV preview, upload context validation
DPCases	3.8.1	User information not escaped in views	Path traversal for icons outside the root

The DPCalendar row is the one with a history. That flaw is the tail of an incomplete fix from the previous release, and we are the ones who reported it, which is covered further down.

Digital Peak states that none of the twelve allows a file to be placed on the server, and that there is no evidence of exploitation in the wild. We found nothing to contradict that. There is no public proof-of-concept and no exploit code for any of them.

Two items in the DPMedia release notes are worth flagging because they do not appear in the announcement’s security list at all: a permission plugin that should check delete and save, and a restricted adapter that should consider permissions from the category and the article. Both read as access-control work. Neither is described as a security fix.

DPAttachments 5.8.1 is the update to do first

DPAttachments is developed in a fully public repository, so this one can be read rather than inferred. The fix for the High-severity issue is a single commit, Case 12252: Check access if an attachment can be downloaded.

Before the fix, the download controller looked up the attachment by the ID in the request and made one check:

 public function download(): void
 {
 	$attachment = $this->getModel()->getItem($this->input->get('id'));
-	if (!\is_object($attachment)) {
+	if (!$attachment instanceof \stdClass || !$this->app->bootComponent('dpattachments')->canView($attachment)) {
 		header('HTTP/1.0 404 Not Found');
 		exit(0);
 	}

The original test asks whether the attachment exists. It does not ask whether the requester is entitled to it. Those are different questions, and only one of them was being asked.

The fix adds a canView() method to the component and calls it from both the download controller and the front-end attachment view, which had the same gap:

public function canView(\stdClass $attachment): bool
{
	if ($this->canDo('core.edit', $attachment->context, $attachment->item_id)) {
		return true;
	}

	$user = $this->app->getIdentity();
	if ($user === null || (int)$attachment->state !== 1) {
		return false;
	}

	if (!\in_array((int)$attachment->access, $user->getAuthorisedViewLevels(), true)) {
		return false;
	}

	$now = (new Date())->toSql();

	if (!empty($attachment->publish_up) && $attachment->publish_up > $now) {
		return false;
	}

	return empty($attachment->publish_down) || $attachment->publish_down >= $now;
}

Read that as a list of the things that were not being enforced, because that is what it is. Publication state, view access level, publish-up date and publish-down date were all recorded on the attachment and none of them governed who could download it.

The acceptance tests added alongside the fix say the same thing more bluntly. One is titled canNotOpenUnpublishedAttachmentDetailsPage, and its stated intent is “that an unpublished attachment cannot be viewed by a guest”. A test written to check that a guest cannot do something is a test written because a guest could.

This is the classic missing-authorisation shape, CWE-862, and it is the same pattern we wrote up when Events Booking exposed invoices and when Cotton Cloud patched the login and left the data. Attachment IDs are sequential integers, which is the part that turns a missing check into a practical problem.

We are describing the mechanism at the level the vendor did, and not publishing a request template, because most sites running this extension have not updated yet.

The escaping was already there, one field along

The second DPAttachments fix, Case 12253, is in the CSV preview template. It escaped the body of the table and not the header row.

 <?php foreach ($csv->titles as $title) { ?>
-	<td><?php echo $title; ?></td>
+	<td><?php echo $this->escape((string)$title); ?></td>
 <?php } ?>
 <?php foreach ($csv->data as $row) { ?>
 	<?php foreach ($row as $value) { ?>
-		<td><?php echo nl2br(htmlentities((string) $value)); ?></td>
+		<td><?php echo nl2br($this->escape((string)$value)); ?></td>
 	<?php } ?>

The data cells were already running through htmlentities(). The header cells, four lines above them in the same file, were not. Digital Peak committed a test fixture, test-xss.csv, whose first column heading is a working <script> tag, and an acceptance test that asserts the script does not execute.

The DPCalendar fix has the same signature. In the location map template, the description was escaped and the title beside it was not:

-		 data-title="<?php echo $this->location->title; ?>"
+		data-title="<?php echo $this->escape($this->location->title); ?>"
 		data-description="<?php echo $this->escape($description); ?>"

We reported that line on 27 August, six hours after 10.12.0 shipped, and it is the only DPCalendar item in this release that did not come from the vendor’s own audit.

That is a pattern worth being able to spot in your own code. A defended field sitting next to an undefended one is much harder for a human reviewer to catch than a block with no escaping at all, because the visible escape() call on the neighbouring line makes the whole section read as handled. Anyone who has reviewed a template at the end of a long day has skimmed past exactly this.

If you have overridden any of these templates, your override still contains the unescaped output, and updating the extension will not touch a copy sitting in your template folder. That is the single most likely way to install this update and stay vulnerable, and it applies to the DPCalendar location templates for the second release running.

What changed in DPMedia and DPCases

DPMedia is half readable. The shared library and two of its plugins ship in a public repository; the DPReferences panel and the Google Drive and Dropbox providers do not, so the High rests on the vendor’s description. DPCases has no public repository at all.

The DPMedia High is DPReferences shows references for users without media manager access, an information disclosure: the references panel listed items to people who had no business seeing the media library. The two fixes that can be read are the path traversal and the OAuth state parameter. The traversal fix adds a resolvePath() method that walks a virtual path segment by segment and throws when a .. would climb above the adapter root, then routes the locally cached copy of a remote file through it, so a filename reported by a remote provider cannot steer the cache write outside /images/dp<provider>/media. The OAuth fix checks a state value against a dp_state cookie with hash_equals() before storing a refresh token, which is the standard defence against a forged callback completing an account connection the site owner never started. The same control appears in DPCalendar in this release, so the audit found it missing in two places and both were closed together.

One DPMedia fix is in the code and not in the announcement. The OAuth callback used to redirect to whatever URL the dp_url cookie held, and 1.21.1 adds a getSafeRedirectUrl() guard that falls back to index.php?option=com_media unless the target is relative or on the current host. That is an open redirect closed without being named as one.

The DPCases High escapes user information in views, and a second fix stops icon paths escaping the root directory. DPCases 3.8.1 also contains one feature change, support for a template images folder for icons, so it is not a security-only release.

The DPCalendar CSRF fix is the one worth understanding structurally. Adding a state parameter to an OAuth-style import flow is the standard defence against a forged request completing an account connection that the site owner never started. It appears in both DPCalendar and DPMedia in this release, which suggests the audit found the same missing control in two places and both were closed together.

Why did the Joomla 3 branch only get one of the fixes?

DPCalendar 8.19.6 is labelled security only, and its release notes list exactly one item: the unescaped location title. The package bears that out. Diffing the shipped 8.19.5 and 8.19.6 archives, and setting aside version numbers in the manifests, the entire release is one changed line of executable code. The two Medium fixes in 10.12.1, the Microsoft and Exchange filename hardening and the CSRF state parameter, are not there.

That is a defensible call and it is worth being clear-eyed about what it means. Digital Peak keeps DPCalendar 8.x in what it has called hybrid maintenance mode for Joomla 3, and it is one of the few vendors still backporting anything to a branch whose CMS reached end of life in August 2023. Compare that with JoomShaper ending Joomla 3 security fixes or J2Store 3 stopping in October and Digital Peak looks generous.

The practical reading for anyone still on Joomla 3 is that a security-only branch gets the issues the vendor rates High and not the hardening that goes with them. Every Medium in this release is a Joomla 4, 5 and 6 fix. If a Medium is later reclassified, or turns out to be reachable in some unexpected way, the Joomla 3 branch does not have it.

Where the DPCalendar fix came from

DPCalendar 10.12.0 shipped on the morning of 27 August and fixed a location title XSS reported by Toan Le, escaping nine data-title sinks across the component. It left the tenth, in the location map subtemplate that the location detail page loads by default. We read the release the same afternoon, confirmed the leftover sink against a clean 10.12.0 install, and reported it to Digital Peak and the Joomla Security Strike Team six hours after the release went out.

Allon Moritz confirmed it the next morning and said the fix would ship in about a month, on the grounds that planting the payload needs DPCalendar location create permission. It arrived thirteen days later, inside this batch.

Today’s announcement went up without a credit. We wrote to Digital Peak the same morning, having diffed both packages to confirm the sink was closed, and the line was added a few hours later: “Again thanks to Phil Taylor from mysites.guru for rechecking the latest release and finding the issue in the map view.” Allon Moritz had been ill, and this is a vendor with a good record on attribution: it named Toan Le in August and credited us properly when we reported an unauthenticated SQL injection in July.

The other eleven issues are not ours and we make no claim on them.

The upcoming module held seven more of the same line

The changelog reads “map view and upcoming module”, and the second half is the larger number. The upcoming module is a separate free download, so its packages can be diffed too. Every one of its seven layouts held the identical unescaped sink, and 10.12.1 closes all seven:

-   data-title="<?php echo $location->title; ?>"
+   data-title="<?php echo htmlentities($location->title, ENT_COMPAT, 'UTF-8') ?>"

blog.php, default.php, horizontal.php, icon.php, panel.php, simple.php and timeline.php, each echoing a location title straight into a double-quoted attribute. We reported one instance, in the component; the release closed eight. Whether the other seven came out of the audit or out of someone grepping the codebase after our report is not something we can tell from the outside. Either way, if you run the upcoming module, which layout you picked made no difference.

The CVE record moved on release day

The location title flaw already had a number. CVE-2026-78071 was published on 28 August for Toan Le’s original report, and its affected range stopped at 8.19.4 and 10.11.2. That range declared 8.19.5 and 10.12.0 clean, and those were the two builds still holding the missed sink.

We raised it with the Joomla CNA on the morning of the release and the record was updated within the hour. The affected range now reads 7.0.0-8.19.5 and 9.0.0-10.12.0, and the credits list two finders instead of one.

A site sitting on 10.12.0 could read the old record, conclude it was already patched, and have no reason to install 10.12.1. We follow the affected range a CVE states rather than overriding it, so our own database did not flag those sites while the record called them clean. Widening the range was the fix for that, rather than working around it.

How Digital Peak found these issues

The other eleven came out of the audit, and the vendor is unusually direct about the method. The announcement opens: “We made some security analysis with Claude in the last days and are shipping today fixes for these issues.”

The findings resulted in shipped code with tests attached. Whatever the discovery method, the DPAttachments commits are public, the missing access check is visible in the diff, and the acceptance tests encode the behaviour that was wrong. That is a higher bar than most vulnerability reports clear, and it is the bar that matters when you are deciding whether to interrupt your afternoon.

This is a long way from the first AI-assisted credit in the Joomla world. When Joomla 5.4.6 and 6.1.1 patched ten security issues in May 2026, three of those advisories credited “Doyensec in collaboration with Claude and Anthropic Research”: CVE-2026-40383, CVE-2026-40384 and CVE-2026-48896. We wrote at the time that more attributions like that should be expected, and they arrived. Yannick Gaultier of weeblr credited AI tooling for two 4Analytics CVEs in July and said security audit runs would be systematic from then on, and Roland Dalmulder of RolandD Cyber Produksi described finding flaws the same way in the Joomla Community Magazine in August.

What is unusual here is the placement rather than the method: Digital Peak put it in the title of the release announcement.

Our own position on where AI sits in this work is set out in full, and it has not changed: every one of the vulnerabilities we have disclosed was found by a human reading source code first, with tooling behind it and AI used at the end to check that nothing was missed. Digital Peak has taken a different route to the same destination. Both produced patched code, which is the only output a site owner can actually use.

The code and the downloads went public together

The three DPAttachments fixes were written on 7 September, with commit timestamps between 08:33 and 09:49 UTC. They did not become public then. They reached the public repository in a push at 03:17 UTC on 10 September, and the DPCalendar Free 10.12.1 commit followed at 03:42 UTC, hours before the announcement went up.

That ordering is the right one. A public fix commit is a map to the flaw it fixes, and pushing the code days ahead of the release would have given anyone watching the repository a head start on every unpatched site. Digital Peak held the commits and published the code and the downloads together.

It also means the diff-to-exploit clock started this morning, for everybody, at the same time. That window is measured in hours now, which is the argument against leaving this until the weekend.

DPCalendar is not one update

DPCalendar ships as a component plus a large family of separately installable plugins and modules: payment plugins for Stripe, PayPal, Mollie, Braintree and Bexio, calendar integrations for Google, Microsoft, Exchange, CalDAV, Zoom, Eventbrite and more, plus map, mini, counter and upcoming modules. Each one gets its own version bump in a release like this.

On the day of this release, our Release Radar recorded 59 distinct DPCalendar items moving to the new versions, 29 on the 10.12.1 branch and 30 on 8.19.6. A given site only needs the pieces it has installed, and most sites run a handful. But a site with several calendar integrations has a list to work through, and Joomla’s update manager will present them as separate rows.

Two of those plugins matter more than the rest in this release. The Microsoft and Exchange plugins are the ones the attachment filename hardening applies to, so if you sync a calendar from a Microsoft 365 account, those are the two to check are actually on the new version rather than assuming the component update covered them.

Release Radar is free and needs no account, which is the point of it: an out-of-band release from a commercial vendor is exactly the event that no extension directory records.

How many of the sites we can see are still vulnerable?

We record the installed version of every extension on every connected site, which lets us say something about how a release like this actually spreads instead of guessing. Counting only sites that have reported in during the last 30 days, measured on the morning of release:

About nine in ten DPCalendar installs are on a version below 10.12.1 or 8.19.6. That is ordinary for release day, and it is why we mail affected customers rather than waiting for someone to notice a version badge change
Roughly one in seven is on the 8.x branch, and five in six of those really are running Joomla 3 underneath
About one in eighteen is on the 9.x line or older, where no patch exists at all. Those sites need a staged major upgrade rather than an update, and they have been in that position since July
DPMedia, DPAttachments and DPCases show up on far fewer connected sites than DPCalendar, few enough that quoting a percentage would imply a precision the sample does not have. Treat those three as “check whether you have them” rather than as a trend

We are not publishing site counts. The proportions are the useful part, and the size of the estate is not ours to hand out.

One more figure worth having, because it is the opposite of what the four-extension headline suggests: only about one Digital Peak site in seventy runs more than one of these four extensions. The stacking happens at account level instead, where roughly one affected account in twelve holds more than one of the products. This is a job for the agency owner with several clients, not a job that piles up on any one site.

How fast did the last DPCalendar release spread?

We can measure this one instead of guessing, because DPCalendar 10.12.0 shipped only two weeks ago. Of the sites that took that update through mySites.guru:

Half were patched within a day and a bit, and just under half were done inside the first 24 hours
Around nine in ten were done within three days
More than nine in ten of those updates were somebody clicking update. Only about one in fourteen came from the automatic update engine

One figure should decide how you plan today, if any of your sites are still on Joomla 3:

DPCalendar updates targeting the 8.x branch succeeded 67% of the time. The same operation on the 10.x line succeeded 91% of the time. Roughly one Joomla 3 update attempt in three ends stuck on a failure rather than on a patched site

That gap is the practical cost of running extensions on an end-of-life CMS, and it compounds: a failed update leaves the site unpatched, and it stays that way until someone checks. If your Joomla 3 sites matter, budget time to confirm 8.19.6 actually installed rather than assuming the click worked.

These adoption figures only see updates run through mySites.guru, and only since April 2026, so read every one of them as a floor rather than a total.

How do you update a four-extension wave safely?

The mechanics are ordinary Joomla extension updates. The parts worth care on this particular release:

Start with DPAttachments 5.8.1. It is the one with a missing authorisation check, and the only one the vendor singles out
Check your branch, not the highest version number. On Joomla 3 your DPCalendar target is 8.19.6, not 10.12.1. The 9.x line has no patch at all and needs the staged route across to 10.x
Update the plugins, not just the component. Especially the Microsoft and Exchange calendar plugins, and any payment plugins you run
Check your template overrides. If you have overridden the DPCalendar location templates or the DPAttachments CSV preview, the unescaped output is still sitting in your override and the update will not reach it
Take a backup first, particularly on the 9.x line where this is a staged upgrade rather than a point release
Turn on automatic updates so the next out-of-band release arrives without you watching for it. We wrote up how to enable auto-updates for any Joomla extension

Point four is the one that catches people. An override is a copy, and a security fix in a vendor template never reaches a copy. You can find the overrides an update changed on every site without logging in to each one.

How do I find every site running a Digital Peak extension?

Searching the extension by name in the mySites.guru Extension Inventory lists every connected site running it, with the version each one reports, so you work through one list instead of logging into sites one at a time to check. For a release touching four products, that is the difference between an afternoon and a morning.

Sites running a version below the fix get flagged automatically once the vulnerability is in our database, and the announcement list puts the urgent ones in your inbox on the day rather than the week after. If you are not a subscriber, the free audit will tell you what a single site is running.

The official Joomla Vulnerable Extensions List will almost certainly not record this release, which is why we keep our own vulnerability database.

Timeline

2026-08-27 mySites.guru reports the missed sink DPCalendar 10.12.0 ships that morning and escapes nine data-title sinks in the component. It leaves the tenth, in the location map subtemplate that the location detail page loads by default. We confirm the leftover sink against a clean 10.12.0 install and report it to Digital Peak and the Joomla Security Strike Team six hours after the release.
2026-08-28 Digital Peak confirms the report Allon Moritz confirms it the next morning and says the fix will ship in about a month, on the grounds that planting the payload needs DPCalendar location create permission.
2026-09-07 Digital Peak writes the DPAttachments fixes The three DPAttachments security commits are authored between 08:33 and 09:49 UTC, each named for the internal case number that later appears in the changelog. They stay private for three days.
2026-09-10 The code is pushed to the public repositories The DPAttachments fixes reach the public repository in a push at 03:17 UTC, with the repository recording further activity at 03:34 UTC and the DPCalendar Free 10.12.1 commit at 03:42 UTC. The code and the downloads became public together rather than the code going first.
2026-09-10 Digital Peak publishes the advisory and ships five releases DPCalendar 10.12.1 and 8.19.6, DPMedia 1.21.1, DPAttachments 5.8.1 and DPCases 3.8.1, out of band and outside the vendor's normal fourth-Thursday schedule. The announcement credits security analysis done with Claude and names each issue with a severity.
2026-09-10 The CVE range is widened and the credit added CVE-2026-78071 is updated to cover 7.0.0-8.19.5 and 9.0.0-10.12.0, the two builds that still held the missed sink, and lists a second finder. Digital Peak adds a line to its announcement crediting mySites.guru for the map view issue.
2026-09-10 No CVE for the other eleven The announcement identifies the remaining issues only by internal tracker numbers. Assignment through the Joomla CNA commonly follows a release by several days.

Block AI training if you want. Never block AI answers.

phil@mysites.guru (Phil Taylor) — Thu, 10 Sep 2026 00:00:00 GMT

Somebody reads an article about AI scrapers, opens their robots.txt, pastes in a list of bot names, and saves. It feels like a small act of housekeeping. On some of the sites we measured, it was the moment their site stopped being citable in ChatGPT, Claude, Perplexity or Apple’s answers, and no one noticed, because a site that has been deleted from an AI assistant looks exactly like a site that was never in one.

So we went and read the live robots.txt of roughly 50,000 Joomla and WordPress sites. Among the Joomla sites that had written any AI policy at all, 10.8% had blocked an answer engine. The people getting this wrong are the ones who thought hardest about it.

So mySites.guru now checks this on every site, twice a day, and the checks are built around one distinction that almost no guide on the internet makes.

The distinction that decides whether AI costs you anything

Every major AI company runs more than one crawler, and they do different jobs.

One collects content to train or ground a model. Turning it away is a legitimate editorial decision about your own content, and it costs you nothing that anybody can measure. Google says so about its own opt-out in as many words: Google-Extended “does not impact a site’s inclusion in Google Search nor is it used as a ranking signal in Google Search.” Apple says webpages that disallow Applebot-Extended can still appear in search results. DuckDuckGo makes the same promise. If you want to opt out of training, opt out of training. It is free.

The other decides whether an assistant can cite you when somebody asks it a question your site answers. Blocking that one removes you from a place a growing number of people now ask their questions, and the traffic does not return when you change your mind six months later, because nothing has recrawled you.

The two look identical in a robots.txt. Both are a User-agent: line and a Disallow: /. Nothing in the file tells you which is which, and the advice circulating online does not separate them, so people who meant the first do the second.

The single most common mistake is one word long

Applebot-Extended is Apple’s training opt-out, and Apple’s own documentation states that it does not crawl webpages at all. Applebot is Apple’s search crawler, and it feeds Siri and Spotlight. In the 1,000 files we parsed crawler by crawler, every site that had shut out an answer engine had also blocked plain Applebot. None had meant to. They lost Apple search and stopped no training whatsoever.

What each crawler is actually for

Here is the taxonomy the mySites.guru checks reason in, taken from each vendor’s own documentation rather than from a community blocklist.

Training crawlers: GPTBot, ClaudeBot, CCBot, Bytespider, meta-externalagent and others collect content to train models. Google-Extended and Applebot-Extended belong here too, though neither is really a crawler: both are opt-out tokens applied to data a different bot already fetched. Blocking any of these costs you nothing in search or answer visibility.
Answer engines: OAI-SearchBot, Claude-SearchBot, PerplexityBot and DuckAssistBot decide whether an assistant can find and cite you. Blocking one deletes you from that assistant. This is the set no one means to block, and 10.8% of Joomla sites with a written AI policy had blocked one.
Search crawlers: Googlebot, Bingbot, Applebot, Yandexbot and the rest. Blocking one removes you from that search engine. On the sites we sampled these were almost always collateral damage from a blocklist aimed at something else.
User-initiated fetchers: ChatGPT-User, Claude-User, Perplexity-User fetch one page because a human asked about it. Blocking these does not affect training or indexing. It breaks the case where your own visitor pastes your URL into an assistant and asks a question about it.

The pairs are worth memorising, because getting one wrong is how the damage happens. GPTBot pairs with OAI-SearchBot. ClaudeBot pairs with Claude-SearchBot. Google-Extended pairs with Googlebot. Applebot-Extended pairs with Applebot. In each pair the first is the training opt-out and the second is your visibility.

One site in our sample had blocked GPTBot, ClaudeBot, anthropic-ai and Applebot-Extended alongside OAI-SearchBot, Claude-SearchBot and Applebot. It opted out of training and deleted itself from every answer engine in the same edit.

Does robots.txt keep a page out of Google?

It does not, and Google is unusually blunt about this. Its official introduction to robots.txt opens with a boxed warning:

Google Search Central, in a box marked Warning

“Don’t use a robots.txt file as a means to hide your web pages (including PDFs and other text-based formats supported by Google) from Google Search results. If other pages point to your page with descriptive text, Google could still index the URL without visiting the page. If you want to block your page from search results, use another method such as password protection or noindex.”

The same page says it in the opening paragraph too: robots.txt “is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.”

The mechanism is simple once stated. robots.txt controls crawling. It has never controlled indexing. If another site links to a URL you have disallowed, Google can index that URL from the link alone, and it will appear in results as a bare link with no description, because Googlebot was told not to fetch the page and so has nothing to describe it with.

This catches people out constantly, because it is the opposite of what the action looks like it does. Blocking a page in robots.txt prevents Google from ever seeing a noindex tag on that page. Google’s own guidance on noindex spells it out: for the rule to work, the page “must not be blocked by a robots.txt file”, because a crawler that cannot fetch the page never reads the tag. If you want something gone, let the crawler in so it can be told to leave.

Google’s own specification page puts the same point in one line: Google “can’t index the content of pages which are disallowed for crawling, but it may still index the URL and show it in search results without a snippet.”

Search Console reports this state as “Indexed, though blocked by robots.txt”, and in a Reddit thread covered by Search Engine Journal in June 2026 one WooCommerce site owner found 51,000 pages sitting in it. A block is not retroactive either. Pages already in an index stay there until they are recrawled, and a crawler that is not allowed to fetch a page cannot see that it has changed.

Do crawlers have to obey robots.txt?

No. This is a request, not a control, and the standard says so itself. RFC 9309, published in September 2022, describes rules that crawlers “are requested to honor when accessing URIs”, and then states directly that “these rules are not a form of access authorization.” Its security considerations go further: the protocol “is not a substitute for valid content security measures”, and listing a path in robots.txt publishes that path to anybody who reads the file.

Compliance is a choice each operator makes, and some of them have written the carve-out into their own documentation. OpenAI’s crawler docs say robots.txt rules may not apply to ChatGPT-User, on the grounds that a person asked for that specific page. Perplexity says the same of Perplexity-User. Anthropic is the exception and states that all three of its bots respect the file. TollBit’s State of the Bots data for the first half of 2026, reported by Search Engine Journal in August, found that around 15% of identified AI page-fetchers reached URLs the site had marked as disallowed, with ChatGPT-User, Bytespider and Youbot each doing so on nearly half of the European sites that had explicitly listed them.

Every crawler that matters for your visibility does read it and does honour it, which is why a mistake in it is expensive. It does mean the file can only ask; it cannot enforce anything. If content must not be reachable, it needs authentication or a server-side rule, not a line in a text file that everybody can read.

What 50,000 live robots.txt files actually look like

Since these checks shipped, mySites.guru has sampled the robots.txt of roughly 50,000 connected Joomla and WordPress sites, the way a crawler does: over the public internet, from the host root. About 45,000 of them returned something that parsed. Everything in this section is measured, not modelled.

10.8%

of Joomla sites with an AI policy blocked an answer engine

2.3% on WordPress

81.6%

of Joomla sites declare no sitemap

12.5% on WordPress

7.2%

of Joomla sites serve no readable robots.txt

9.6% on WordPress

1.5%

of Joomla sites are hidden from every crawler

0.4% on WordPress

Roughly 50,000 connected Joomla and WordPress sites, live robots.txt fetched from September 2026 onwards. Figures are a point-in-time measurement and will drift as sites are fixed.

The reassuring finding is the one that does not fit in a card. Almost no one has touched this at all: in a separate pass where we parsed 1,000 files crawler by crawler, 96.7% of Joomla sites and 83.2% of WordPress sites named no AI crawler anywhere in the file. Nothing in this post is an argument that you must go and add AI directives. Doing nothing is a perfectly good policy and it is the one most sites already have.

The 7.2% and 9.6% are the surprise. The commonest finding in the group is not a bad rule, it is no readable file at all: a 404, a 403, a timeout, or a themed HTML error page served with a 200 status. That last shape matters more than it sounds, because a naive checker reads a 200 response as a valid file and reports “no rules, everything allowed” when no one can see the file.

About 1.5% of Joomla sites and 0.4% of WordPress sites are serving User-agent: * with Disallow: /. These are live business sites, asking every search engine and assistant on earth to stay away from everything. The overwhelmingly common cause is a launch that never finished: somebody blocks the site while it is being built, which is correct, and then the site goes live and nothing visibly changes. Pages load, links work, forms submit. The only symptom is the site never appears anywhere.

None of this was a research project. We did not commission a study or crawl the open web: we ran a query against data the product already holds, because every connected site is read on its own schedule anyway and the readings sit in a column. Most writing about AI crawlers has to argue from first principles about what site owners probably do. We can go and look at what tens of thousands of them actually did, get an answer the same afternoon, and re-run it next month to see whether any of it moved.

WordPress owners are getting this right more often than Joomla owners

This was the finding we did not expect, and it came through both datasets.

WordPress owners set an AI policy far more often. Across everything measured, 6.9% of WordPress sites turn away at least one training crawler against 4.4% of Joomla sites, and in the 1,000 files we parsed name by name the gap was wider still: 16.3% of WordPress files named and blocked an AI crawler, against 3.3% of Joomla files. More WordPress owners have made a decision here.

They also do far less damage with it. Of the sites that had written any AI policy at all, 10.8% of Joomla sites had blocked an answer engine against 2.3% of WordPress sites. In the 1,000-file sample the same gap shows up in the raw counts: seven of the 23 Joomla files with a policy (30%) had also shut out a search or answer crawler, against four of the 33 WordPress files (12%). Every one of the five sites that had blocked an answer engine was a Joomla site, and every one of those five had also blocked plain Applebot while blocking eleven or twelve training crawlers in the same paste. The WordPress mistakes were milder in kind: DuckDuckBot and Baiduspider, which costs a search engine each, and no answer engines at all.

The explanation is where the policy comes from, rather than which community is more careful. On WordPress it usually arrives generated, from Cloudflare’s managed file or an SEO plugin, and both of those got the training-versus-answers split right because somebody who understood the taxonomy wrote them once. Content-Signal lines appeared on 13.9% of the WordPress files we parsed and 1.6% of the Joomla ones, which is that same edge-generated policy showing up in the data. On Joomla the policy is far more often hand-pasted from a community blocklist into a file the owner edits directly, and a pasted list is exactly the artefact that cannot tell a trainer from its answer twin.

Generated policies respect the distinction. Copied ones do not, and that has nothing to do with which CMS you run.

The nine checks mySites.guru now runs on every snapshot

A healthy Joomla site. Six measured passes, a sitemap it has not declared, an open AI policy, and a robots.txt served straight from its own server.

There is a new group on every site’s Snapshot tab called Search Engine Visibility. Joomla gets nine checks and WordPress gets eight, and mySites.guru fetches your live robots.txt from your domain root at most twice a day behind a snapshot.

Should Not Block Every Crawler: Fires on User-agent: * plus Disallow: /, the single most damaging line a robots.txt can contain. Has a one-click fix, and it is downgraded to a neutral Staging badge on hosts that look like dev or staging addresses, where blocking everything is the correct setting.
Should Not Block Search Engines: Fires when Googlebot, Bingbot, Applebot or another search crawler is named and shut out. One-click fix restores access to that crawler and touches nothing else.
Should Not Block AI Answer Engines: The check the whole group was built to make. Fires on OAI-SearchBot, Claude-SearchBot, PerplexityBot or DuckAssistBot. It also names the vendor own-goals, where both sides of a pair are blocked, and the Applebot mix-up specifically.
Should Be Reachable: Confirms that a request for /robots.txt returns a robots.txt. Has no fix button: the whole finding is that we cannot read a file, and writing a fresh one would guess at rules your site may already have.
Must Sit At The Domain Root: 0.9% of Joomla sites and 0.6% of WordPress sites are installed below the document root, so the robots.txt inside the site folder is read by nothing. No fix button, because the file has to go above the site root and every write mySites.guru makes is confined to it by design.
Should Point Crawlers At Your Sitemap: Two tiers. If you have a sitemap and never declare it, that is a warning with a one-click fix. If you have no sitemap at all, that is a neutral badge and no advice, because 'add a Sitemap line' is useless to somebody with nothing to point at.
Your AI Training And Answer Engine Policy: Informational and never a fault. It shows which AI crawlers your file turns away and separates the ones that cost you nothing from the ones that remove you from assistants. Two badges, Open and Opt-out, and both are correct answers.
May Be Managed At The Edge: Compares a hash of the file on your server against a hash of the file crawlers are served. When they disagree, something in front of your site is generating its own, and editing your copy changes nothing.
Should Not Block Media & Template Folders: Joomla only, and the one check that predates this group. Blocking /media/ or /templates/ stops Google fetching the CSS, JavaScript and images it needs to render your pages.

All nine ship with a BETA badge in the interface. The crawler taxonomy behind them changes on the vendors’ schedule rather than ours, so if you find a token classified wrongly, tell us and we will fix it.

What the badges mean

A green OK is a measured pass. A grey No Data means mySites.guru has not fetched that site’s robots.txt yet, and it is not a pass. Every one of the underlying columns is nullable, and reading an unfetched site as healthy would have put a green tick on tens of thousands of sites on the day this shipped, having measured none of them.

Why a pasted AI blocklist can block Googlebot too

This is the mechanism that turns a careless paste into a disaster, and it is a quirk of the format rather than anybody’s bug.

Under RFC 9309, consecutive User-agent: lines accumulate into one group, and the first rule line closes the header. So this blocks both bots:

User-agent: GPTBot
User-agent: CCBot
Disallow: /

The related trap is the specificity rule. A crawler obeys the most specific group that names it, and ignores every other group in the file, including the wildcard. John Mueller explained this on Reddit in July 2026 to a site owner whose disallowed search pages were being indexed anyway: “With robots.txt, the more specific rules win, so if you have a user-agent: Googlebot section, it will only use that section. If you want to apply all the rules in the user-agent: * section, you need to copy them.”

Put those two together and you can see how a file goes wrong. Append a block of crawler names to a file whose last line happens to be a dangling User-agent: Googlebot header, and your names join that group. The Disallow: / you write next then applies to Googlebot as well. Nothing about the text you pasted is wrong. The meaning came from the file you pasted it into.

This is why the mySites.guru training opt-out re-parses its own proposed output before sending it, and will not write at all if any search or answer crawler would end up blocked by the result. Three unit tests pin that behaviour. It is the only place in the whole feature where a bug would take a site out of search results rather than putting one back in.

Why naming crawlers cannot be made to work

Blocking crawlers by name is Whac-A-Mole, and that is why we built the tools the way we did.

Your robots.txt can only ever name the bots you have heard of. It cannot name the far greater number you have not, and it cannot name the ones that do not exist yet, so every new AI company is another line somebody has to remember to add. And it will never name the crawlers that ignore the file altogether, because a list of names only works on the ones polite enough to read it. You end up playing Whac-A-Mole with bot names and their access to your site, which is an unsustainable position to be in. It is the same argument that sinks .htaccess blocklists: a list can only ever hold the bad things you already know about.

The practical failure mode is the one our sample shows. A blocklist gets populated with famous names, and the famous names are the search and answer crawlers, so the list fails at its own goal and succeeds only at removing the site from results.

The worst file in the 1,000 we parsed had a single group owning 147 product tokens, ending in one Disallow: /. Applebot, OAI-SearchBot and PerplexityBot were all in it, alongside GPTBot, GoogleOther, DuckAssistBot and Claude-SearchBot. It was copied wholesale from a community blocklist. The same file had its Sitemap: line commented out, and the URL in the comment was misspelled anyway.

On comprehensive AI blocklists

A longer list is not a more complete one. It is a longer list that is still missing everything no one has heard of, while reading to you as though it were a wall. Anyone selling a comprehensive AI blocklist is selling a file that was out of date the day it was written. Opt out if you want to reserve the right, but do not mistake it for a lock.

What we recommend, and why it names no crawlers

The per-site robots.txt page in mySites.guru offers a recommended file, built from your actual site: your own install path, your own real sitemap URL, your own domain in the header comment. Nothing in it says example.com, because a customer who pastes an example domain into their live file has been actively misled.

For a Joomla site at the domain root it looks like this.

# robots.txt for https://example.org
# Everything below is allowed unless it is named here.

User-agent: *
Disallow: /administrator/
Disallow: /api/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/

Sitemap: https://example.org/sitemap.xml

For WordPress it is shorter, and includes the Allow line that keeps admin-ajax.php reachable for the front end.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.org/wp-sitemap.xml

Notice what is missing. There is not one crawler named in either file. No AI blocks, no allowlist, no vendor tokens. It does not disallow /media/ or /templates/ on Joomla either, because blocking those is a finding in its own right and reproducing it in our own recommendation would be recommending the bug.

If you do want to opt out of training, there is a button for it, and it writes exactly five names: GPTBot, ClaudeBot, Google-Extended, Applebot-Extended and CCBot. Those are the five whose opt-out tokens the vendors themselves document. We will not put a token in your file on the strength of a blog post.

That button is the only write in the entire group that adds a block. The other four fixes all restore access. The asymmetry runs deeper than that: the all-sites page has one bulk action and it only ever restores. There is no bulk block button and there never will be, because a single mis-click on one would delete a company’s entire web presence from every search engine on earth, take weeks to notice and months to recover.

We run the same policy here. The live robots.txt for this site names no crawler at all, allows everything, declares its sitemap, and expresses a preference with a single Content-Signal line:

User-agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=no
Disallow: /wp-admin/
...
Allow: /
Sitemap: https://mysites.guru/sitemap-index.xml

Search, yes. Feeding an assistant that cites us, yes. Training, no thank you. No one blocked, and that policy is generated in our own build rather than bolted on by a CDN. mySites.guru reports Content-Signal lines when it finds them and never writes one for you.

Is your robots.txt the file crawlers actually read?

For a meaningful minority of sites, the answer is no, and it is the finding that wastes the most time when no one knows about it.

3.9% of the Joomla sites we have measured, and 8.0% of the WordPress sites, are served a robots.txt that does not match the file on their own server. Several returned an identical 1,836-byte file containing none of their CMS’s own disallow lines, which is what Cloudflare’s managed robots.txt looked like in early September when the origin’s file was never merged into it. Give Cloudflare its due for that version: it named eight training crawlers and left the search and answer crawlers alone, which is the distinction most hand-written blocklists miss.

The eight names have since gone. A zone with the managed setting still on and AI bots still set to block now serves 1,248 bytes that are entirely comment: no User-agent group, no Content-Signal directive, no Disallow line, just the preamble explaining what content signals would mean if the file contained any. The preference moved into Cloudflare’s own Search, Training and Agent controls, where a crawler is stopped at the edge rather than asked in a file. Cloudflare’s documentation still prints the eight-crawler version, and the worked example it links to has already dropped it. Clause (c) of the preamble that remains says that where the operator gives no signal for a use, they neither grant nor restrict permission for it. So the file now reserves rights over nothing.

Cloudflare is not the only culprit either. A host can do it too: SiteGround’s anti-bot challenge serves a noindex page to anything it takes for a bot, Googlebot included. mySites.guru detects the general case by hashing both copies and comparing them, rather than by sniffing a Server: header. Being behind a CDN is not the finding. The disagreement is, and it holds for any edge that rewrites this file rather than only for the one vendor we happen to recognise.

The consequence reaches you, which is the reason the check exists. On an edge-managed site, editing robots.txt on your server changes nothing any crawler will ever see. The obvious next move, which is to open the file manager, edit the file, save it and then wonder why nothing happened, wastes an afternoon and teaches you that the tools do not work. So there is no fix button on that check, and the panel says why: we cannot change what a CDN serves, and a button that appeared to would be lying. It links you to the Cloudflare setting instead.

This is also getting more common. Since 15 September 2026, domains newly onboarding to Cloudflare have Training and Agent crawlers blocked by default on pages that display ads, while Search crawlers stay allowed. That default gets the distinction right, more than most hand-written blocklists manage.

Existing zones are moving to the same three controls. Cloudflare emailed account holders on 16 September to say the migration runs over the following week, and a zone that had Block AI Bots switched on becomes Search: allow, Training: disallow, Agent: block on pages with ads. Cloudflare describes the new Search setting as letting Applebot, Googlebot and Bingbot index a site while telling them not to train on it, so for a zone that was blocking, this is a loosening. Those crawlers feed answer engines, and pages that were invisible to them become eligible to appear there. If you run sites for clients who chose to block, that decision is being relaxed on a schedule they did not pick, and the switch that expressed it leaves the dashboard once the migration finishes.

Which of your sites are hidden right now?

If you have a hundred sites, you should not have to open a hundred pages to find the two that are invisible. There is an all-sites Search Engine Visibility page listing every connected Joomla and WordPress site with a verdict against each one, drawn from the stored readings rather than from a live call, so it renders hundreds of rows at once.

Sites that are hidden from search get a red badge and a Restore button. The restore is careful about what it touches. It comments out the Disallow: / inside the wildcard group rather than deleting it, so you can see exactly what changed and put it back, and it leaves a Disallow: / under a named crawler completely alone, because that is an opt-out no one should undo on your behalf.

Where a crawler shares a group with others, the group gets split rather than cleared. The 180-token file above is why: deleting that one Disallow: / line would have restored Apple and OpenAI’s answer crawlers and simultaneously reversed the owner’s training opt-out for every trainer in the same group, which is an edit to their AI policy that no one asked for.

There is also a daily digest, on by default, that emails you when a site newly starts blocking search engines or answer engines. It is a set difference rather than a count, so a site that has been blocking Googlebot for years never triggers it, and no site is emailed twice for the same block. Blocking an AI training crawler is reported in the interface and never emailed, because it is a legitimate choice and not our business to nag you about.

The one directive that adds reach

Sitemap: is the only line in robots.txt that gives a crawler something. Everything else in the file takes something away.

81.6% of the Joomla sites we have measured declare no sitemap, which sounds like an enormous open goal until you check the second number: only 15.4% of those sites have a sitemap to declare. Telling the other 84.6% to “add a Sitemap line” would be advice they cannot follow, and a check that gives you advice you cannot follow is a check you learn to ignore, and then you ignore it on the day it is right.

So the mySites.guru check has two tiers. Sitemap found but not declared is a warning with a one-click fix that appends the real URL, which is a one-line win. No sitemap found at all is a neutral badge and no nagging, because on Joomla that is an extension decision rather than a robots.txt edit.

WordPress is a different population entirely. 87.5% of WordPress sites already declare a sitemap, against 18.4% of Joomla sites, and most of those lines were injected by Yoast, Rank Math or All in One SEO rather than typed by anybody. Where a WordPress site does omit the line, 56.9% of them have a sitemap sitting there undeclared, so the one-click fix applies far more often than on Joomla. Which leads to the trap that makes this check not act on WordPress more often than you would expect: writing a physical robots.txt into a WordPress webroot is not an addition, it is a takeover. The web server then answers the request itself, WordPress never runs, and every line the SEO plugin was injecting stops being served, including the Sitemap: line you were trying to protect.

What eventually replaces a list of bot names

There is a problem underneath everything above, and it explains why robots.txt can never be more than a request.

A user-agent string is a self-declaration. Anything on the internet can send Googlebot in a header, and plenty does. So the file asks a crawler to identify itself honestly and then to obey rules written for that identity, and both parts of that depend entirely on the crawler’s goodwill. Verifying a bot properly today means reverse DNS lookups and published IP ranges, which works, is fiddly, and ties a bot’s identity to where it happens to be hosted.

Google is now testing a replacement for that, and there is nothing to do about it yet. Web Bot Auth is an IETF draft protocol, developed by a working group formed for it, that has agents cryptographically sign their requests using HTTP Message Signatures. Google’s own summary of the benefit is the useful sentence: it lets a site “move beyond easily spoofed headers to a verified identity and decouple agent identity from IP addresses.”

In practice, a participating agent sends a Signature-Agent header naming a key directory, the site fetches that agent’s public keys once and caches them, and every signed request can then be checked against them. Google is currently signing a subset of requests from its Google-Agent user agent, which authenticates as agent.bot.goog. Most major bot detection services, CDNs and web application firewalls already support the protocol, and Cloudflare publishes a reference implementation.

Google is careful about the status, and so are we. Not every Google user agent uses it, not every request from a participating agent is signed, and Google still recommends verifying by IP address, reverse DNS and user-agent string alongside it. mySites.guru does not check any of this today, and none of the nine checks in the Search Engine Visibility group knows what a signature is.

The direction of travel is what matters. “Which bot is this?” is on its way to being a question with a verifiable answer rather than a trusting one, and that is the thing that would finally make access decisions enforceable in a way a text file has never been. It does not change what you should do with your robots.txt this week. It does suggest that the long-term answer to unwanted crawlers is identity and enforcement at your edge, and that curating a list of names in a public text file was always the wrong layer for it.

Do not paste anything from the internet, including this

Every code block in this post is an illustration. So is every code block in every other article about robots.txt, including the ones that told the sites we measured to block Applebot.

Be careful because this particular file punishes a small mistake out of all proportion to the effort of making it. One line in the wrong group, one crawler name confused with its near-twin, one wildcard section a crawler never reads because you gave it a section of its own, and the site is still up, still fast, still taking orders, and slowly disappearing from the places people look for it. There is no error message. Nothing goes red. You find out from a traffic graph months later.

WordPress owners have the cleanest illustration of how cheap the mistake can be. Settings, Reading, one checkbox marked “Discourage search engines from indexing this site”, ticked during a build and never unticked. It is exactly the right setting while a site is being built and exactly the wrong one the day it launches, and clicking it takes less than a second.

That checkbox is not a robots.txt setting, and this post's checks cannot see it

On current WordPress the Reading checkbox does not write Disallow: / into your robots.txt at all. It emits a site-wide noindex on your pages instead, which is a far more effective way of leaving Google, because noindex is the instruction that actually removes a page from an index. Every check in this post reads robots.txt, so a site can pass all nine and still be invisible. mySites.guru covers that setting with a separate check, Let Search Engines Index The Site, and if you run WordPress it deserves more of your attention than anything to do with AI crawlers.

So before you paste a block of crawler names into a live site, know what each name is for, which group it will join, and what you lose if you are wrong about either. If you cannot say what OAI-SearchBot does without looking it up, that is the signal to leave the file alone. Doing nothing has no failure mode. This file rewards restraint far more reliably than it rewards effort.

What to do this week

You do not need a tool for most of this. Here is the whole job.

Open https://yourdomain.com/robots.txt in a browser. If you get a 404, a 403 or a themed error page, that is your first finding and it is the commonest one.
Look for Disallow: / under User-agent: *. On a live site, that line is almost never intentional.
Look for any crawler named in the file. If Applebot, Googlebot, Bingbot, OAI-SearchBot, Claude-SearchBot, PerplexityBot or DuckAssistBot appears above a Disallow: /, you are paying for it in visibility.
If you have a User-agent: Googlebot section, check that it repeats every rule you meant Googlebot to obey. It will not inherit anything from User-agent: *.
Check the file is at the root of the domain, not inside a subfolder, and remember that www. and the apex are two different hosts needing two different files.
Add a Sitemap: line if you have a sitemap and it is missing. Confirm the URL actually returns XML first.
Compare what you see in a browser against the file on your server. If they differ, your CDN is generating it and your server copy is decoration.

If you would rather this ran by itself across every site you manage, that is what we built. The checks run on every snapshot, the all-sites page tells you which sites are hidden, and there is a crawler tester on each site’s robots.txt page that answers “would this crawler be allowed to fetch this URL”, tested against the editor buffer so you can check an edit before you save it to a live site. Google retired its own tester in 2023 and never replaced it.

Doing nothing remains a perfectly good policy. Doing something careless is the expensive one, and it is expensive in a way that produces no error message, no broken page and no complaint from anybody. Just a slow, silent absence from the places people are increasingly asking their questions.

If you want the fuller argument about why the robots changed, Philip Walton’s piece in the August 2026 Joomla Community Magazine is what sent us off to measure our own. Our older post on checking a Joomla robots.txt for SEO problems covers the /media/ and /templates/ story in more depth.

J2Store 3 Stops Getting Security Fixes on 19 October 2026

phil@mysites.guru (Phil Taylor) — Mon, 07 Sep 2026 00:00:00 GMT

J2Commerce put a date on it on 3 September 2026. On 19 October 2026, two years to the day after they took the J2Store Joomla extension over, the 3.x line stops. No security patches, including for anything found after that date, no support requests answered, no further releases of any kind.

Six in ten of the J2Store installs we can see are on that line.

J2Commerce is drawing a line under the version most of their own users are still running, which is uncomfortable precisely because it is the right call.

What J2Commerce announced, and what end of life means here

The announcement sets out a full roadmap rather than a single cutoff, which is worth reading as a piece of policy rather than as news.

J2Commerce took over J2Store on 19 October 2024, after the original team closed the project citing rising costs and falling revenue. Every release since then has shipped a documented migration path to J2Store 4 alongside it. Two years was the runway they set themselves, and 19 October 2026 is the end of it.

From that date, J2Store 3 gets nothing. The vendor is explicit that this includes security patches for issues discovered afterwards, which is the part that matters, and that no support requests will be answered for the 3.x line.

They have also set a date for the version they are telling everyone to move to. J2Store 4, now branded J2Commerce 4, reaches end of life on 19 October 2027. From here on, their support tracks Joomla’s own major-version cadence one step behind, with a fixed runway rather than a judgement call each time.

The dates that actually apply to a J2Store 3 shop

19 October 2026: J2Store 3 stops receiving anything. 19 October 2027: J2Store 4 stops too. 13 October 2026: Joomla 5, one of the two Joomla versions J2Store 4 officially supports, drops out of bugfix support. Joomla 4, the other one, has been fully end of life since 14 October 2025.

What the J2Store installs we monitor actually look like

Every write-up of an end-of-life announcement says some version of “many sites are still affected”. We can put a number on it, because each Joomla site connected to mySites.guru reports its installed extensions and their versions on its regular snapshot.

60%

of J2Store installs are on the 3.x line

the branch that stops on 19 October

98%

of those run Joomla 3 underneath

core support ended August 2023

74%

never applied the 20 August fix either

three security releases behind

26%

were on 3.3.22 when we measured

the newest build then, until 3.3.23 shipped on 15 September

Measured 7 September 2026 across connected Joomla sites running the J2Store component with a snapshot in the previous 30 days. Percentages of that group, not of all managed sites.

The third figure is the one that should worry a shop owner more than the deadline does. Three quarters of the J2Store 3 installs we can see are below 3.3.21, which means they never took the 20 August 2026 release, let alone the 31 August or 15 September ones. They are three advisories behind while the branch is still being maintained. Whatever happens on 19 October changes very little for a site in that state, because it has already been running as though the vendor had stopped.

J2Store is also the most Joomla-3-weighted shop extension on the platform by a wide margin. Across the carts we see, roughly 61% of J2Store installs sit on Joomla 3, against about 45% for VirtueMart, 40% for EShop, 24% for HikaShop and 9% for Phoca Cart. That is why this announcement reaches a far bigger share of live shops than the same announcement from any of the others would.

Why is J2Store 3 ending now?

Because of what it is built on, at both ends: the CMS underneath it, and the framework inside it. Joomla 3 reached end of life on 17 August 2023. After that, the only thing standing between a Joomla 3 site and an unpatched core was Joomla’s paid Extended Long Term Support programme, and that ended on 17 February 2025. The final Joomla 3 release of any kind was 3.10.20, in January 2025. For more than eighteen months there has been no version of Joomla 3 receiving core security fixes from Joomla, at any price.

J2Commerce kept patching anyway, well past that point, and the 2026 releases are the proof: three separate security batches (20 August, 31 August and 15 September) in under a month, each of them shipped for the Joomla 3 branch on the same day as the modern ones. Their conclusion is that continuing to do this “does more to reassure people than to actually protect them”, which is a harder thing to say in public than most vendors manage.

The announcement stops there, but the public record shows what that patching costs. Between 20 August and 15 September 2026 the J2Store Joomla extension took seventeen CVE identifiers across three advisories, and each advisory meant building and shipping three separate branches on the same day. Nine security builds in twenty-six days.

The architecture is what makes that expensive. J2Store is built on FOF, a framework J2Commerce’s own requirements page describes as no longer maintained and a source of PHP deprecation warnings. At least two of the five flaws we reported in August exist because of how FOF behaves rather than because of anything anyone wrote: a controller task inherited from the framework with no permission check of its own, and a framework default that reads an undeclared ACL node as permission granted. J2Commerce 6 was written without FOF at all. Keeping J2Store 3 patched means keeping that framework going on top of a CMS that is itself unmaintained, and reasoning about every fix three times, once per branch. The team that ran J2Store before J2Commerce closed the project citing rising costs and falling revenue, so the maintenance economics here are not new.

Their wording is careful and worth keeping intact: no version of Joomla 3 receives security fixes from Joomla. Third-party Joomla 3 patching does still exist, including a paid one-off patch set and a free community fork, and the community core backport, which we apply across connected Joomla 3 sites in one click, closes the published core holes without an eLTS licence. None of that helps here. Patching the core does nothing about a shop component that no longer has anyone maintaining it, and that distinction is the trap for a J2Store 3 owner who has been told their Joomla 3 sites are covered.

What actually changes on 19 October

Nothing visible. The shop keeps taking orders on 20 October exactly as it did on 18 October. That is what makes an extension end of life easy to defer and easy to get wrong.

What changes is what happens the next time somebody finds something. Three batches of flaws were found in this extension between 20 August and 15 September 2026, by four separate researchers. Six on 20 August, including CVE-2026-67361, an unauthenticated file upload that the vendor confirmed had already been used against real sites before the patch shipped, and whose published CVSS vector records its exploit maturity as Attacked rather than proof-of-concept. Joomla’s own upload filter blocked PHP files, so it did not become remote code execution, which is luck rather than design.

Then five more on 31 August, which we found and reported. The worst of those, CVE-2026-78069, published on 3 September at 9.5 Critical: a missing permission check that let any account able to log into the Joomla administrator, holding no J2Store permission at all, truncate the shop’s tables and run SQL files off the disk.

Six more followed on 15 September, which we found and reported too after retesting the 31 August build instead of closing the file. The worst of those is an unauthenticated blind SQL injection in the storefront product list, reachable with no account and no token, which J2Commerce scores 8.7 High. All six records were still reserved at cve.org the morning the advisory went out, so those scores are the vendor’s rather than published CNA ones.

Working proof-of-concept code for the 20 August batch is published on GitHub. So the question after 19 October is what a shop owner does when the next advisory arrives with no patch behind it. Seventeen flaws were found in this extension in under four weeks while people were actively looking, and there is no reason to expect the eighteenth to wait politely for a supported version to appear.

An extension at end of life does not fail. It just stops being fixed, and nothing on the site tells you the day that starts.

The route out runs onto ground that is also running out

The documented migration is J2Store 3 to J2Store 4, and because J2Store 4 will not install on Joomla 3, that migration is also a Joomla migration. The vendor is right that the two should be planned as one project rather than two. Where their documentation needs reading carefully is the destination: it targets “the latest Joomla 4 or 5”.

Both of those are further along than they sound. Joomla 4 passed its own security end of life on 14 October 2025 and has been removed from Joomla’s live roadmap. Joomla 5 leaves bugfix support on 13 October 2026, six days before J2Store 3’s end-of-life date, and its security-only phase ends on 12 October 2027. A shop that migrates to J2Store 4 on Joomla 5 in the next few weeks is standing on a version that stops getting bugfixes the week before the deadline it was migrating to beat.

J2Commerce 6, the current line, is a rewrite rather than an upgrade. No FOF, native Joomla 6 code, PHP 8.3 minimum, and the vendor is explicit that it does not run on Joomla 4 or Joomla 5. Reaching it from J2Store 3 means two CMS jumps and two data migrations, because the direct J2Store 3 to J2Commerce 6 tool the announcement mentions is still in development. The shipped migrators for J2Commerce 6 come from J2Commerce 4, eShop, Shopware 6, VirtueMart 3 and WooCommerce, not from J2Store 3.

None of that is an argument for staying put, but it is an argument for aiming at Joomla 6 and J2Commerce 6 as the destination and treating J2Store 4 as a staging post you pass through, rather than budgeting for the halfway house and discovering the second half a year later.

The shop is the hard case in a Joomla 3 migration

There is a reason these particular sites are still on Joomla 3 when the brochure sites moved years ago, and it is not neglect.

A shop has checkout, payment gateway credentials, shipping rules, tax rules, coupon history and years of order records that somebody may need to produce for an accountant. It usually has template overrides written against the old markup, and often a third-party payment or shipping plugin whose vendor is less responsive than J2Commerce. Testing it properly means putting a real card through a real gateway on a staging copy and then doing it again after cutover. That is a week of somebody’s attention, not an afternoon, and it needs a maintenance window on a site that takes money.

So the shop is the last thing an agency migrates, and it is the site that slips from one quarter’s plan to the next without anyone ever deciding that it should. The deadline does not care about any of that, which is the uncomfortable part of writing it down.

The vendor’s own pre-migration checklist is short and worth following exactly: take a full backup first, run the migration on a staging copy rather than the live store, audit template overrides and any third-party checkout or cart add-ons for compatibility, confirm the host meets the PHP and Joomla requirements for the version you are targeting, move through the documented path rather than skipping versions, and test checkout, shipping and payment end to end before cutting over.

One thing their checklist does not mention: J2Commerce is moving nearly 200 add-ons from free downloads back to paid subscriptions. If your shop depends on add-ons that arrived free, price that in before you commit to a date.

What about the other Joomla shop extensions?

The obvious alternative to migrating J2Store is switching cart entirely, and it is worth being honest about what that buys.

HikaShop still ships Joomla 3 builds. Its current release came out in August 2026 and its download page still lists Joomla 3, with no end-of-life statement anywhere. VirtueMart is the strongest Joomla 3 commitment in the market: its update feed still declares support for Joomla 3.0 through 3.10, and the vendor has said the next major version will run on everything from Joomla 3 to Joomla 6. VirtueMart is, however, currently unpublished from the Joomla Extensions Directory pending a review, which is its own kind of signal.

Phoca Cart is the instructive one. Its last Joomla 3 stable release was 3.5.8, in October 2021. When it shipped security releases in August 2026, they went to the Joomla 4, 5 and 6 branches with no Joomla 3 equivalent, and its product page still advertises Joomla 3 support today. The October 2026 fix for a paid-download flaw narrowed that again, reaching the Joomla 6 line only. There is no announcement to find, no date to plan around, and a shop owner reading the requirements would reasonably conclude they were covered.

Set against that, J2Commerce publishing a hard date fourteen months ahead of the version it applies to is the better problem. And switching cart is a data migration with a checkout rebuild attached, so it is rarely cheaper than moving forward on the cart you already know. It is not automatically safer either: we found three flaws in EasyStore, including order forgery, the last time we looked at a Joomla shop extension somebody was migrating to.

How do I find every J2Store 3 install across the sites I manage?

Doing this by hand means logging into each Joomla site, opening the extension manager and reading off a version number, which is slow enough that it gets deferred and then skipped.

mySites.guru records the installed extension inventory for every connected site, so searching the Extension Inventory in mySites.guru for J2Store returns every install with its version on a single screen, including the sites you had forgotten were running a shop at all.

Nine vulnerability rules for this extension are live, one per release branch across all three 2026 advisories, so an affected site is flagged with the fix version for the branch it is actually on rather than the highest number available. This numbering trap bites harder with J2Store than with most extensions: the current patched builds are 3.3.23, 4.0.23 and 4.1.8, and 4.1.8 sorts above the other two while being an entirely different release line that will not install on a Joomla 3 site. Any check that treats “below 4.1.8” as the rule will tell a correctly patched Joomla 3 shop that it is vulnerable.

mySites.guru also tracks end-of-life versions of Joomla and WordPress themselves, back to Joomla 1.5, so the sites with both problems at once are visible in one place rather than two.

What to do before 19 October

If you have J2Store 3 sites, the sequence that wastes the least time is:

Get the update on before you plan anything. Three quarters of the J2Store 3 installs we can see are below 3.3.21 and are missing seventeen fixed vulnerabilities, one of them already used in the wild. Installing 3.3.23 takes minutes and is worth doing today whether or not you migrate by October. Install the build for the branch each site is on, not the highest number you can find.
Decide the destination. Joomla 6 with J2Commerce 6 is the version with a future. J2Store 4 on Joomla 5 is a staging post with thirteen months on the clock and a bugfix deadline of its own six days before this one.
Book the work as a project with a window. Backup, staging copy, override audit, add-on compatibility check, host PHP check, end-to-end payment test, then cutover.
For the shops that will not make October, say so out loud. A client who knows their shop is running unmaintained software and has agreed a date to fix it is in a completely different position from one who finds out afterwards.

If one of these shops turns out to be compromised, fix.mySites.guru is a fixed fee of £120 per incident, usually same day, screened before we commit so you are not charged if it turns out not to be fixable. That is incident work and nothing else. Moving a J2Store 3 shop onto a supported line is a project many times that size, it is not something we sell, and anyone quoting you £120 to do it has not looked at your checkout.

J2Commerce did this properly

Two years of runway. A hard, public, dated announcement, published while the version being retired is still the one most of their own users run. Migration documentation shipped alongside every release since the takeover, not written the week of the announcement. All three security batches patched on the Joomla 3 branch the same day as the modern ones, when patching only the current branch would have been cheaper and would have stranded most of their install base. And advisories in August and September that named the reporter, which is still not a given.

We have documented thirty-odd vendor positions on Joomla 3, and the pattern is that the loudest announcements are the least reliable predictors of what a vendor actually does next. Vendors have announced the end of Joomla 3 support and then shipped Joomla 3 patches six days later. Others have said nothing at all for three years while shipping fixes anyway, or while stopping without a word. Against that spread, a dated roadmap with a stated policy behind it is the only version of this an agency can actually plan around.

The uncomfortable part of this announcement sits on the other side of it, with the six in ten J2Store shops still on the line being retired, three quarters of which have not applied a security release since before the first of this year’s three advisories. For those sites the end-of-life date is not the moment the risk starts. It is the moment the last thing that was still working in their favour stops.

One postscript, because it changes what you should watch for rather than what you should do. The extra J2Store 3 release we expected arrived on 15 September 2026 as 3.3.23, with six more fixes in it. Whether another follows before the hard cut-off on 19 October is still open, so take each one quickly as it arrives: a release that close to the end of a branch is the last chance that branch has to hand you anything. Taking it is still not a reason to let the migration slip.

Timeline

2023-08-17 Joomla 3 reaches end of life The core stops receiving free security fixes. Paid Extended Long Term Support is the only route left, and it is a paid one.
2024-10-19 J2Commerce takes over J2Store Olivier Buisard and Adam Melcher take on the extension after the original team, led by Ramesh Elamathi, closed the project citing rising costs and falling revenue. J2Store 4 becomes the supported path from this point.
2025-02-17 Joomla's paid eLTS programme ends The last Joomla 3 release of any kind was 3.10.20 on 7 January 2025. From this date there is no version of Joomla 3, at any price, receiving core security fixes from Joomla.
2026-05-19 J2Commerce 6 released A rewrite rather than an upgrade: native Joomla 6, no FOF, PHP 8.3 minimum. It does not run on Joomla 4 or 5, so it is not reachable from a Joomla 3 shop in one step.
2026-08-20 Six flaws fixed, one already used against real sites 3.3.21, 4.0.21 and 4.1.6. CVE-2026-67361, an unauthenticated file upload, has exploit maturity Attacked in its published CVSS vector, and the vendor confirmed it was exploited before the patch shipped. Joomla's own upload filter blocked PHP, so it did not become remote code execution.
2026-08-31 Five more flaws fixed, all reported by mySites.guru 3.3.22, 4.0.22 and 4.1.7, ten days after the previous batch. All three branches patched the same day. The five records published on 3 September and credit Phil Taylor, mysites.guru.
2026-09-03 J2Commerce announces the end of life date Two years of runway, one hard public date, and documented migration paths shipped alongside every release since the takeover.
2026-09-15 Six more flaws fixed, all reported by mySites.guru 3.3.23, 4.0.23 and 4.1.8, a third batch fifteen days after the second. All three branches patched the same day again. The worst is an unauthenticated blind SQL injection in the storefront product list, which the vendor scores 8.7 High.
2026-10-19 J2Store 3 end of life No security patches, no support, no further releases of any kind for the 3.x line.
2027-10-19 J2Store 4 end of life Timed by the vendor to around Joomla 7's release, though Joomla has not published a Joomla 7 date.

T4 Page Builder 2.3.0 Fixes an Unauthenticated Mail Relay

phil@mysites.guru (Phil Taylor) — Thu, 03 Sep 2026 00:00:00 GMT

JoomlArt published T4 Page Builder 2.3.0 on 28 August 2026. It closes an unauthenticated open mail relay in the Joomla extension’s front-end contact endpoint, along with a missing CSRF token, absent rate limiting, and a live Mailchimp API key hardcoded into the shipped source. The relay is now tracked as CVE-2026-78374, assigned by the Joomla CNA on 10 September at our request rather than the vendor’s. If you run T4 Page Builder on a public Joomla site, update it.

We reported the flaw to JoomlArt on 17 August, having found it that afternoon on a client’s server while investigating abuse that was already under way. The fix is real, and we have read it rather than taking the changelog’s word for it: we audited the released 2.3.0 package on 3 September and all four issues are closed.

One piece of housekeeping before anything else, because the two are easy to confuse. This is T4 Page Builder by JoomlArt, com_t4pagebuilder. It is not SP Page Builder by JoomShaper, which had a mail relay of its own this summer under CVE-2026-65879. Different vendor, different codebase, different bug. If you run both, both need attention.

What to do now

Update T4 Page Builder to 2.3.0 or later, then clear the Joomla cache and test every contact and subscription form on the site. JoomlArt’s own instructions are a manual download from the member area followed by an upload through System, Install, Extensions. Every version below 2.3.0 is affected, including the whole 1.x branch. If you cannot update today, unpublish any page with a T4 contact or subscription form on it.

What T4 Page Builder 2.3.0 Fixes

The component exposes a front-end JSON endpoint that dispatches named actions. One of those actions, contact, was exempted by design from the permission checks that guard the rest of the editor, so it was reachable by any anonymous visitor. That exemption is still there in 2.3.0, and it is fine now for reasons we will come to, but in 2.2.0 and earlier it opened onto an action that would send mail wherever it was told to.

Four separate problems sat behind it:

Problem	Effect before 2.3.0
Attacker-controlled recipient	The action read a `recipient` field straight from the request and delivered to it, using the site’s configured `mailfrom` and `fromname`. The attacker chose the recipient, the subject and the HTML body.
No CSRF token	No Joomla form token was required, so the request needed nothing but a URL and a body.
No rate limiting	Nothing throttled the endpoint, so the same request could be sent in volume.
Hardcoded Mailchimp API key	A live API key sat in the component’s source, readable in every copy of the extension.

The subscribe task on the same endpoint had the same gap, which let unauthenticated requests write rows into a site’s AcyMailing subscription tables. We have written before about unauthenticated AJAX and JSON endpoints being the CMS security blind spot they are, and this is a textbook instance: the ACL check existed, and one action was excused from it.

We are not publishing the request shape, because most installs have not updated yet. The Joomla Extensions Directory takes the same line in its own guidance to vendors, which says explicitly that it does not ask developers to give away vulnerability details and advises against it.

How Did a Joomla Contact Form Become an Open Mail Relay?

The damage is not that someone can email you through your own contact form. It is that they can email anyone else, and it arrives looking like you.

Mail sent through that endpoint left the site using the sender identity configured in Joomla’s Global Configuration. On a properly set up site that means it went out with the domain’s SPF pass and its DKIM signature. To a receiving mail server it was authentic mail from the domain, because in every technical sense it was. An attacker got a free, authenticated, reputable sending platform, and the site owner got the consequences.

Those consequences outlast the bug. Once a domain has been used to push phishing at scale it goes onto blocklists, and on shared hosting the sending IP takes every other site on the box down with it. We have written about verifying that your Joomla site’s email actually works because deliverability is one of the most expensive things to break and one of the slowest to repair. An hour spent installing 2.3.0 is cheaper than a fortnight spent getting a domain delisted.

The hardcoded API key is a smaller problem with a longer tail. A credential shipped inside a distributed extension is readable by everyone who has ever downloaded it, so it stops being secret the moment it ships. We have seen the same pattern in a live Google Fonts API key hardcoded into Helix3. Removing it from the source is necessary, but it does not un-leak it, and the key should be rotated by whoever owns it.

Is the T4 Page Builder Fix Any Good?

Yes, and it is worth being specific about why, because the vendor’s own summary puts the emphasis in the wrong place.

The release notes lead on CSRF protection. A Joomla form token is now required on the contact action:

// Public endpoint - require a valid Joomla CSRF token (POST body or X-CSRF-Token header).
if (!Session::checkToken('post')) {
    return ['error' => Text::_('JINVALID_TOKEN')];
}

On its own, that would not have closed the relay. Joomla hands a valid form token to any anonymous visitor who loads a page, so a script that fetches the page first and posts second has a token like everybody else. CSRF tokens stop a third-party site forging a request in a logged-in visitor’s browser, which is worth fixing on its own, but it was never the mechanism here, because the attacker was talking to the endpoint directly rather than borrowing anyone’s session.

What actually kills the relay is one line further down, where the attacker’s recipient stops being used at all:

$result = self::sendEmail(self::getAdminMails(), $subject, $emailContent, $fromName, $fromEmail);

getAdminMails() returns two things and nothing else: the mailfrom address from Global Configuration, and the first Super User’s email. The recipient field is still parsed out of the request a few lines above, and the action still will not run without one, but it is never passed to the mail call. It is an untidy way to reach a correct answer, and the answer is correct: there is no longer any input that steers delivery.

Behind that sits a new RateLimitSecurity helper doing IP-based fixed-window limiting through Joomla’s cache, defaulting to five requests per ten minutes and configurable in the component parameters. Captcha validation is now explicit rather than inferred from whether a plugin happens to be enabled, and because T4 stores rendered pages statically, a FormSecurity helper injects the captcha widget and the token into contact forms at render time. The Mailchimp key now comes from component parameters, and the old key is absent from the 2.3.0 package.

That is defence in depth, built by someone who understood the report. Our only quibble is the one above: the announcement sells the weakest of the four fixes as the headline.

Which of Your Joomla Sites Still Run a Vulnerable Version?

This is where the story stops being about JoomlArt and starts being about everyone who has to act on it.

A week after 2.3.0 shipped, here is what the T4 Page Builder installs on Joomla sites connected to mySites.guru looked like on 3 September 2026:

Five in six were still running a version below 2.3.0.
Roughly one in eight had updated.
Nearly half were sitting on a single older release, 2.1.1.
Another one in eight were still on the 1.x branch.

T4 Page Builder is not on many of the sites we monitor, so read those as proportions of a small population rather than as a survey of the Joomla world. The shape is still the shape. Most people did not update, and the ones who did not are clustered on releases that are years of development behind.

There is a plausible reason for the clustering, and it is not laziness. The Joomla Extensions Directory listing for T4 Page Builder still shows version 2.1.0, and the fix is a manual download from JoomlArt’s member area. Anyone who installed from the directory and has never had cause to log in to the member area has no signal at all that they are four releases behind, let alone that one of those releases was a security release.

That gap is why our vulnerability tracking exists. mySites.guru keeps a live inventory of every extension on every connected Joomla and WordPress site, with the installed version on each, and flags any site running below a vendor’s fix. Our rule for T4 Page Builder below 2.3.0 was written from the vendor changelog and dated to the day of release, which means subscribers with an affected site were told on 28 August. JoomlArt got back to the person who reported the flaw on 3 September. That ordering is the problem rather than a boast: the detection had to be reverse-engineered from a changelog because no one was told directly.

If you look after more than a handful of Joomla sites, the multi-site Joomla tooling and the vulnerable extension list are the parts of the subscription that turn an announcement like this into a work list instead of an afternoon of logins. A full site audit covers the other half of the question, which is whether anything reached the site before you got there.

The Ten Days Between the Acknowledgement and the Release

Start with what JoomlArt got right, because it is more than the ending suggests.

When the report reached them, they were fast and they were serious. The Joomla Security Strike Team forwarded it at 11:01 on 18 August. JoomlArt replied at 11:11, ten minutes later, thanked us for the write-up, said they took it very seriously given that it was being actively exploited, and confirmed they were sending it straight to their dev team. A ten-minute acknowledgement is better than most vendors in this ecosystem manage, and the CERT guidance treats 24 to 48 hours as normal. Nine days later they shipped a complete, well-engineered fix. When they finally did reply on 3 September they apologised without being asked to, in plain terms: “We should have notified you directly as soon as the fix was released, rather than leaving you to follow up.”

Now the rest of it.

That report should never have needed the Strike Team. It went to JoomlArt’s published support address on the evening of 17 August and produced nothing. It only reached anyone because David Jardin forwarded it the following morning, noting in his own message that the reporter “tried to reach out to you before hand but had no luck”. JoomlArt’s reply acknowledged the same thing, apologising that “our previous contact attempts didn’t get through”. A reporting route that swallows an active-exploitation report without a word during an incident is a broken reporting route, and it is not hard to see why this one is fragile. JoomlArt publishes no security.txt, no security policy page and no dedicated security contact. Their /security, /security-policy, /report-security and /responsible-disclosure paths all return 404. Their /contact URL currently 301-redirects to http://localhost/cw_2026/ja_mainsite/joomlart/contact-us, which is a developer’s machine, not a website.

After 11:11 on 18 August there was silence. No initial assessment, no status update, no question about our test setup, no draft advisory, and no offer of a pre-release build to verify the fix against. The release went out on 28 August without a word to us. We learned it existed because we track vendor changelogs for a living, and we confirmed it worked by downloading the public package and reading it.

Measured Against Joomla’s Own Standard for Extension Developers

There is a reason to hold this to a written yardstick rather than to our own preferences. On 10 August 2026, one week before we reported this flaw, the Joomla project published twenty numbered rules for extension developers handling a security report, written by David Jardin in his capacity as Team Leader of the Joomla Security Strike Team, and merged into the official Joomla Manual the same day. It is documented best practice rather than an enforced requirement, and nothing checks compliance. But it is the Joomla project’s own answer to the question, and it existed before any of this happened.

Rule	What it asks for	What happened
1. Establish a clear reporting channel	A dedicated security contact, a `SECURITY.md`, or a security page on the vendor site	None of the three exists. The direct report was never answered.
3. Acknowledge the reporter quickly	Receipt inside a business day, an initial assessment in three to five, regular updates during longer investigations	The acknowledgement was excellent. The assessment and the updates never came.
9. Coordinate a disclosure date	Agree a timeline, and accelerate substantially where a flaw is already exploited	No date was proposed or agreed. The release shipped unannounced to us.
11. Assign the CVE before disclosure	Request one from the Joomla CNA at `security@joomla.org`	Never requested by JoomlArt, whose release shipped without one. The Joomla CNA had been a recipient on the thread since 18 August. We asked for it ourselves on 3 September and CVE-2026-78374 was assigned on 10 September.
12. Credit the security researcher	“Always offer appropriate credit to the reporter”	Not offered, not discussed, not given.
13. Publish a security advisory	A dedicated advisory, separate from the changelog	A blog post and a changelog. No advisory.
14. Tell users what they need to do	State the affected versions, the fixed version and the recommended action	Fixed version and recommended action, yes. Affected versions, never stated at all.
17. Do not hide security fixes in vague language	Name the class of flaw that was fixed	An open mail relay is described as “Safer recipients”.
18. Preserve the disclosure timeline	The model timeline includes “Fix provided to reporter for verification”	No pre-release build was offered. We verified against the public package, six days late.

The pre-release build is the one item on that list where no standard actually obliges anybody, so it is worth saying so rather than dressing it up. It is a strong recommendation in FIRST’s PSIRT Services Framework, which says to provide the remedy to the finder so they can validate it, and it is step five of the CERT guide’s ideal flow.

Skipping it is also how a vendor ends up shipping the same fix twice, and we have watched that happen all year. PageBuilder CK answered an unauthenticated file-upload remote code execution with a login check in 3.6.0, which still left any Editor able to run code; the real fix came in 3.6.3, and 3.6.5 was the version people actually needed. Cotton Cloud’s first release closed the login route and left the data reachable, so a second one had to follow. JoomShaper shipped SP Page Builder 6.7.1 as the fix, then 6.8.0 sixteen days later for the flaw 6.7.1 had not closed. Each of those rounds is another emergency update for administrators who had already dropped everything to apply the last one, and there is a limit to how often you can ask people to do that before they stop treating your security releases as urgent at all.

A researcher who has just spent an afternoon proving a bug is the cheapest quality assurance a vendor will ever be offered, and the offer expires the moment the release goes public. JoomlArt got this one right first time, which is worth saying. They had no way of knowing that before they shipped it.

Rule 14 is the one that costs site owners real money, because a reader on 2.1.1 has no way to learn from that announcement whether it concerns them.

Calling a Mail Relay “Safer Recipients” Has a Cost

The T4 Page Builder 2.3.0 announcement runs to about 5,000 characters. Across all of it, these words appear zero times: vulnerability, exploit, relay, attacker, advisory, severity, CVE, report, researcher, credit, disclosure, discovered.

The relay is introduced as “Safer recipients: Hardened anonymous contact submissions to prevent arbitrary recipient addresses from being supplied through requests”, and later as “The contact workflow no longer trusts recipient addresses supplied directly through anonymous requests”. The section explaining why the update matters frames the whole release around “spam and automated abuse”. Nothing tells a reader that a fortnight earlier someone was using their site to send mail.

The word “unauthenticated” does appear, three times. Every one of them describes the AcyMailing subscribe task, the least severe of the four issues. The vocabulary was available. It simply was not applied to the mail relay.

None of this is a case of protecting users by withholding detail, which is the reasonable defence and the one the Joomla Extensions Directory explicitly endorses when it tells vendors not to publish vulnerability details. The directory’s test asks something else entirely: whether “any reasonably intelligent person reading the notice would understand that there is a new version available, that it is a security release, and that users need to update”. The first and third of those are satisfied here. The second is what “safer recipients” removes, and the joint guide that CISA, the NSA, JPCERT/CC and the Dutch and UK cyber security centres published in July 2026 has a name for the result: a silent fix, defined there as a release that fixes a vulnerability without mentioning its existence, and singled out because such releases are far less likely to be deployed.

Which brings it back to five in six. We cannot prove those two facts are connected on a sample this size, and we are not going to pretend otherwise. But the mechanism is not mysterious. An administrator triaging a fortnight of extension updates is deciding, one line at a time, what to do today and what to do eventually.

“Safer recipients: Hardened anonymous contact submissions to prevent arbitrary recipient addresses from being supplied through requests.”

Scheduled for whenever.

“Your contact form can be used to send phishing from your domain. Update now.”

Done before lunch.

The line on the left is JoomlArt's, verbatim from the T4 Page Builder 2.3.0 changelog. The line on the right is not. It describes the same fix.

What This Means for Anyone Running JoomlArt Extensions

T4 Page Builder is a small corner of JoomlArt’s presence. Their T4 and T3 template frameworks sit under roughly thirty-five times as many of the Joomla sites we monitor as the page builder does, which is why the process questions here matter more than this one component. A vendor whose security contact route drops reports, who ships fixes without telling the reporter, and who describes a mail relay as a recipient improvement is going to do those things again, on frameworks with a far larger footprint.

The practical response is to stop relying on vendors to tell you when something matters, rather than to stop using JoomlArt extensions, which are good and widely deployed for good reasons. Watch the versions, not the announcements. Treat any extension release you cannot explain as one worth reading about, keep an inventory you can query in one place rather than fifty, and update the security ones the day they appear.

For JoomlArt specifically, four things would close most of this permanently, and three of them are an afternoon’s work: publish a security.txt and a security contact that reaches a human, fix the /contact redirect that currently points at a developer’s laptop, state affected versions in release announcements, and request a CVE from security@joomla.org when a release fixes a vulnerability rather than leaving the reporter to ask for it. The Joomla project runs the CNA and has published the instructions. The fix in 2.3.0 shows the engineering is there. It is the paperwork around it that let this one down.

Timeline

2026-08-17 Unauthenticated mail relay found on a live client site Traced during an investigation into a Joomla site that was already being abused. Reported the same evening to JoomlArt's support address and to the Joomla Security Strike Team, with the vulnerable code path, the hardcoded credential and a suggested fix. JoomlArt does not reply to the direct report.
2026-08-18 The Joomla Security Strike Team relays the report, and JoomlArt answers in ten minutes David Jardin forwards the report at 11:01, noting that the reporter had tried to reach JoomlArt beforehand without luck. JoomlArt's support replies at 11:11: they take it very seriously given the active exploitation, and are sending it straight to their dev team. It is a good answer, and it is the last one for a fortnight.
2026-08-28 JoomlArt publishes T4 Page Builder 2.3.0 The announcement describes security hardening for contact and subscription forms and tells users to upgrade. It names no vulnerability, no affected versions, no CVE and no reporter. We are not told it has shipped.
2026-08-28 mySites.guru flags every connected site below 2.3.0 Our vulnerability rule was written from the vendor changelog and dated to the release, so subscribers running an affected version were told on the day. The first updated install appeared in our data that afternoon.
2026-09-01 The Joomla Security Strike Team chases for an update "Two weeks is a rather lengthy response time for an actively exploited issue." We confirm the same evening that we have heard nothing since 18 August.
2026-09-03 JoomlArt replies, six days after the fix shipped "We should have notified you directly as soon as the fix was released, rather than leaving you to follow up." The reply points at the release announcement as the answer. There is still no advisory, no CVE and no credit.
2026-09-03 We verify the fix by auditing the released package Read the shipped 2.3.0 component rather than taking the changelog's word for it. All four reported issues are closed, and the hardcoded Mailchimp key is gone from the package.
2026-09-10 The Joomla CNA assigns CVE-2026-78374 Issued a week after we asked the Strike Team for it on the same thread, and thirteen days after the fix shipped. JoomlArt never requested one. The record is reserved rather than published, so it does not resolve at MITRE or in the NVD yet, and the release announcement still credits no reporter.

One Search Finds That User on Every Site You Manage

phil@mysites.guru (Phil Taylor) — Wed, 02 Sep 2026 00:00:00 GMT

What the rebuilt mySites.guru universal user manager does

Every connected site now has a full user manager on its own page inside mySites.guru: a live list of that site’s accounts with search, filters and paging, and the ability to add, edit, block, unblock and delete accounts and change their group membership. You never log in to the site itself.

Then there is the portfolio-wide search. One box, one string, matched against username, name and email address on every connected Joomla and WordPress site at once. Use the site page when you know which site you are fixing, and the search when you know the person but not the sites.

The list is read from your site at the moment you open it, every time. mySites.guru stores no copy of your users, and the page says so above the table. Sorting, the filter chips along the top, and the column picker all work on that live list. Sites with very large user tables stop counting at 5,000 and tell you they have done so, so a forum with half a million registered accounts cannot hang the page while you are trying to find one person.

Why that list is so hard to produce

A developer finished a project for you eighteen months ago. They were given an administrator account on the client’s site so they could get the work done, and it stayed there, because taking it away meant logging in to that site, finding the user list and remembering why the account was there. Multiply that by every contractor, every agency hire, every “can you just give me access for an hour” since 2019, and you have the honest answer to how many people can currently log in to your clients’ websites: no one knows.

The awkward part is not the cleanup. It is that you cannot even produce the list. Your identity provider covers email, chat and the billing dashboard, and covers precisely none of the two hundred separate WordPress and Joomla installs you look after, each with its own database, its own user table and its own set of numeric user ids that have nothing to do with each other. The same person exists on forty of those sites as forty unrelated rows. Matching those rows to one another is the actual problem, and a search that asks every site at once is the only thing that solves it.

Everything it can do

On a single site

Add a user, setting name, username, email, password and groups in one step
Edit an existing account’s name, username and email address
Set a new password, written straight to the site and never stored here
Change group membership: several groups at once on Joomla, one role on WordPress
Block and unblock an account (Joomla only, see below)
Delete an account, choosing what happens to its content on WordPress
Search that site’s users by username, name or email address
Filter by all, active, unactivated, super admins, and blocked on Joomla
Sort by any column, and choose which columns are shown
See last login and registration date per account, on Joomla
Page through large sites, 50 accounts at a time and up to 200

Across every site at once

Search every connected Joomla and WordPress site for a username, name or email address
See every site that person holds an account on, with last login, registration date and status
Change name, username, email address and password across every site you tick, in one action
Block and unblock across the ticked Joomla sites
Edit one account on its own if a single site needs different treatment
Export the results to CSV

What it will not do

Delete the last remaining Super User or Administrator on a site
Leave an account belonging to no group at all
Delete anything without you retyping your own mySites.guru password
Block a WordPress account, which WordPress has no way to express
Change groups or roles from the cross-site search, because group ids differ per site
Remove two-factor authentication from an account, or retrieve backup codes
Store anything about your users, including any password you set

Every action on a single account

Each row has one actions menu rather than a row of competing buttons.

Edit opens one editor that serves both creating and changing an account. The left column is the account itself: name, username, email, and on Joomla the block switch. The right column is group membership, and it is read live from the site the moment the editor opens rather than from anything cached, because a group added on the site last week has to be there when you look.

Two guard rails stop a bad afternoon becoming a catastrophic one. You cannot save an account into no group at all: an account with no group can still sign in, reaches no part of the site once it does, and disappears from every group filter you might use to find it again, which is a miserable state to leave a client’s site in. And you cannot delete the last remaining Super User or Administrator. mySites.guru counts the remaining admins before the delete and stops there, then checks again inside the transaction on the site itself and rolls back if the answer changed. Deleting an account also asks for your own mySites.guru password first, every time, no matter how recently you logged in.

These changes are written straight to your site

There is no staging step and no automatic backup taken first. A password you set is written to the site immediately and is never stored in mySites.guru, which means the tool cannot tell you later what it was. Treat it exactly as you would treat editing the user directly in the site’s own admin.

Joomla has a block switch, WordPress does not

This is the one place where the two platforms cannot be made to behave the same way, and pretending otherwise would be worse than explaining it.

Joomla has a real block column on the user table. Blocking is a first-class thing you can do to an account, and mySites.guru sets it. WordPress has no such concept. There is no supported way to mark a WordPress account as blocked, so mySites.guru does not offer a Block button on WordPress sites, and stops the action before it ever reaches the site rather than writing something ambiguous and calling it success.

What WordPress does have is accounts holding no role at all. Those can still sign in and can then do nothing, which is the closest native equivalent. mySites.guru reads that state and shows it as a “No role” badge, and the blocked filter finds those accounts, so the visibility is there even though the switch is not.

The Last login column is empty on every WordPress row for the same reason: WordPress does not record it. Joomla does, and it is the single most useful column on this screen, which the next section explains.

WordPress support for the full set of user actions shipped on 1 September 2026. Before that the WordPress connector could answer a search but not a browse or a write, so in practice this was a Joomla feature with a WordPress-shaped hole in it. That hole is closed.

What the accounts on client sites actually look like

We audit a large number of Joomla and WordPress sites, and the per-check results give a reasonable picture of what user accounts look like in the wild. These are the figures from the 30 days to 2 September 2026.

56.8%

of Joomla sites have more than one account with full control

68.3% on WordPress

67.7%

of Joomla sites have accounts unused for 180 days or more

52.1% on WordPress

88.4%

of Joomla sites have no Super User with MFA switched on

not one of them

47.9%

of Joomla sites have both extra Super Users and dormant accounts

41.7% on WordPress

Measured across the Joomla and WordPress sites mySites.guru audited in the 30 days to 2 September 2026. Percentages are of sites where the check actually ran, and checks that apply only to certain versions are counted only against those versions.

The median Joomla site and the median WordPress site each have two accounts with full control. At the ninetieth percentile it is five. So the agency owner who believes there is one administrator on a client site is wrong more often than not, and has no practical way to find out without opening every site in turn.

The dormancy figure is the one that matters for offboarding. Two thirds of Joomla sites have at least one account that has not been used in six months, and at the ninetieth percentile a Joomla site has nineteen of them. Those accounts are not exotic. They are the old contractor, the agency hire who left, the client’s former marketing manager, and the migration account somebody created in 2023 and never removed.

The alarming failures are rare. MD5 password hashes, which Joomla never creates itself and which usually point at a compromise, appear on 1.8% of Joomla sites. Actual rogue Super Admin accounts matching a known attacker signature appear on 0.03%. Sites are not generally on fire. The problem is duller than that: 78.3% of Joomla sites and 79.5% of WordPress sites fail at least one basic user hygiene check, and only 21.7% of Joomla sites are clean on all six. The accounts pile up because, until now, seeing across a hundred sites at once meant opening a hundred sites.

One search, every site you manage

Type a username, a name or an email address. mySites.guru asks every connected site at once and streams the answers back as they arrive.

The result is the list you could not previously produce: one person, and every site they still have an account on, with the last login and registration date beside each one. Sort by last login and the dormant access shows itself immediately. There is a CSV export if you want the list somewhere else, and an Edit button per row if one site needs different treatment from the others.

The search takes one string and matches it as a partial against username, name and email together, so there is no separate “search by email domain only” mode. And Generic PHP sites connected to mySites.guru are excluded, because that connector has no user methods at all; the page names the exclusion rather than leaving them out without saying so.

Offboarding in a single pass

Tick the sites you want and a panel appears under the results.

Four fields, and an empty box leaves that field alone. Type a new password and it goes to every ticked site. Change the email address and the same person’s account is updated everywhere at once, which is the mundane version of this job: somebody changes their surname, or moves from a personal address to a company one, and it needs correcting on a hundred sites.

Block and Unblock sit beside the save button and apply to Joomla accounts only, with WordPress rows left untouched. The panel says that on screen rather than leaving you to discover it afterwards.

The warning panel is not decoration. Changes go straight to each site with no backup taken first, mySites.guru applies no password rules of its own so the password has to be one your sites will accept, no check is made that an email address is real, and a site will reject the change if that username or email is already in use there.

Group and role changes stay out of this panel. Group ids are per site, they mean different things on different installs, and mySites.guru validates any group change against that site’s own list before writing it. Doing that in bulk across sites that disagree about what group 7 means is how you accidentally promote someone. So group membership stays in the per-site editor, where the list in front of you is the list from that site.

Where to find it

It is in the left menu as Universal User Management, and on each site’s own page as the User Manager tab. If you prefer the keyboard, press Shift twice to open the command palette and start typing, or use the u u m hotkey.

How is this different from WordPress Multisite?

Almost everything written about managing users across WordPress sites assumes Multisite: one installation, one wp_users table, sub-sites that share an identity, and a plugin that assigns an existing network user a role on one of them. If that describes your setup, the built-in tools already do most of this.

It does not describe an agency. An agency has a few hundred entirely separate installations, often on different hosts, some Joomla and some WordPress, with no shared user table and no shared identity of any kind. There is nothing to “sync” because there is no network. The only thing connecting Dan Whitlock’s account on one client’s Joomla site to Dan Whitlock’s account on another client’s WordPress site is that both happen to use the same email address, and something has to go and ask both sites, live, to find that out.

That is why this works by search rather than by synchronisation, and why it spans two content management systems that know nothing about each other.

Who on your team can change a client’s users?

Browsing, searching and editing follow the site access you have already granted in mySites.guru, so a team member who cannot see a site cannot see or change its users. Everything is rate limited, at 300 requests an hour per person per site, which is generous for real work and unhelpful for anything automated.

Deleting an account requires the operator to retype their own mySites.guru account password, and a wrong password on that step is recorded rather than merely rejected, because a failed authentication from somebody who already holds a valid session is exactly the event you would want to see afterwards.

Every write is recorded: which of your team members changed which fields, on which site, for which account, and whether it succeeded, failed or was denied. The log stores field names, not values, because mySites.guru promises not to store your users’ details and an audit log full of old email addresses would break that promise. The record exists for our own support and incident work; there is no screen in the dashboard that shows it back to you today.

Two separate things get confused here often enough to be worth separating. Managing your own team’s access to mySites.guru is a different feature from managing the user accounts that live on your clients’ sites. Offboarding usually means doing both.

What it costs

Nothing extra. The user manager is part of the mySites.guru subscription, which is £19.99 per month for unlimited Joomla, WordPress and PHP sites, alongside the audits, backups, uptime monitoring, update management and file manager.

If you want to see what is already sitting on your own sites before committing to anything, connect a site and run an audit. The user account checks quoted above are part of the standard audit, so the answer to “who has full control of this site, and when did they last use it” arrives without you doing anything further.

J2Store 3.3.22, 4.0.22 and 4.1.7 fix five flaws we reported

phil@mysites.guru (Phil Taylor) — Tue, 01 Sep 2026 00:00:00 GMT

J2Commerce published a security release for the J2Store Joomla extension on 31 August 2026, fixing five vulnerabilities in com_j2store. We found and reported all five, and the vendor credits mySites.guru in its advisory. The fixed builds are 3.3.22 on the Joomla 3 branch, 4.0.22 on 4.0.x and 4.1.7 on 4.1.x, all published the same day.

The timing is the awkward part. J2Commerce shipped its previous security release ten days earlier, on 21 August, closing six unrelated flaws found by other researchers. Anyone who patched then did exactly the right thing and is still exposed, because 3.3.21, 4.0.21 and 4.1.6 are all affected by this second set.

Update to the fix for your own branch, not the highest number

J2Store patches three branches in parallel, so the correct target depends on which one you are on: 3.3.22 for Joomla 3, 4.0.22 for 4.0.x, 4.1.7 for 4.1.x. Moving from 4.0.21 to 4.1.7 is a branch change, not an update, and 4.1.7 is not an upgrade path for a Joomla 3 site at all.

TL;DR

TL;DR: Five vulnerabilities in the J2Store Joomla extension, all reported by mySites.guru, are fixed in 3.3.22, 4.0.22 and 4.1.7. Three need no login: an anonymous PayPal callback could confirm an unpaid order or fail a real one (8.7), an anonymous request could insert or overwrite any customer’s cart record (8.8), and a crafted link fired script through the product-tags filter (5.3). One needed only an ordinary customer account and returned a guest checkout customer’s name, address and phone (7.1). The worst, scored 9.5, needed only a Joomla backend login of any kind, with no J2Store permission whatsoever, and reached table truncation and traversal-based SQL file execution. Every build below the fix for its branch is affected, including the 21 August security release. All five CVE records published on 3 September 2026. If you manage Joomla shops, mySites.guru already flags every connected J2Store install below the fix version for its own branch.

What the Five J2Store Flaws Actually Were

All five sit in com_j2store and all five affect every supported branch, because the vulnerable code is shared between them. Ordered by the published CVSS 4.0 score:

CVE	Score	What it allowed	Login needed
CVE-2026-78069	9.5 Critical	Table truncation and traversal-based SQL file execution through the admin Apps controller	Any Joomla backend account
CVE-2026-78064	8.8 High	Insert or overwrite any user’s or session’s cart record	None
CVE-2026-77999	8.7 High	Confirm an unpaid order, or fail a legitimate one, through the PayPal callback	None
CVE-2026-78065	7.1 High	Read a guest customer’s name, street address and phone from the address editor	Any customer account
CVE-2026-78000	5.3 Medium	Reflected XSS through the product-tags filter fields	None

Two of these are worth more than a table row, because the mechanism behind each one is a mistake that is easy to repeat in any Joomla extension.

Any Joomla Backend Login Could Truncate the Store’s Tables

The 9.5 is an authorization check that was never written, sitting behind a framework default that opens rather than closes.

J2Store’s administrator Apps controller accepts an appTask parameter and delegates the work to an app-plugin controller. Nothing along that delegation path checks whether the caller holds any com_j2store permission. That would still be manageable if the framework rejected unmatched tasks, but the component’s fof.xml has no <view> ACL entries under its <backend> node at all, and with nothing declared the framework’s default for an unmatched task is allow.

The practical result is a privilege escalation with an unusually low starting point. The only thing standing between an anonymous visitor and this code is Joomla core’s administrator login wall, which is doing its own job and knows nothing about com_j2store permissions. Once any account is through that wall, for any reason, it could reach #__j2store_* table truncation and traversal-based execution of SQL files. An account you created so a client could manage their events calendar was enough to wipe their shop.

An empty ACL node is not a locked door

The pattern to take away from this one is general. If your component’s ACL configuration declares nothing for a view, check what your framework does with a task it cannot match, because “no rule” and “deny” are not the same thing and the difference is invisible in a code review that only reads the controller.

The PayPal Callback That Verified Nothing

The 8.7 is the one a shop owner feels in the accounts rather than in the logs.

J2Store’s PayPal IPN listener is supposed to call PayPal back, ask whether a payment notification is authentic, and act on the answer. Before the fix it did three things that each defeated that on their own. It treated an UNVERIFIED response, and in fact anything that was not literally INVALID, as valid. It made the verification request with CURLOPT_SSL_VERIFYPEER disabled. And it stored the verdict in a field that nothing downstream ever read, so order processing continued regardless of what came back.

The amount check had a separate hole. The comparison between what was paid and what was owed only ran when mc_gross arrived as a positive number, and floatval(null) is 0, so simply leaving that field out of the callback body skipped the check completely.

Put together, an unauthenticated request to the callback endpoint could confirm an order that no one paid for, or push a real customer’s paid order into a failed state. If you ran an affected build with PayPal enabled, that is the thing worth auditing before you move on: orders that changed to CONFIRMED or FAILED with no matching PayPal transaction behind them.

Which J2Store Versions Are Affected?

Every build below the fix version for its own branch, on all three branches. There is no lower bound worth quoting, because the vulnerable code predates every version anyone is realistically running.

Branch	Affected	Update to
Joomla 3 (J2Store 3.3.x and earlier)	3.3.21 and below	3.3.22
J2Store 4.0.x	4.0.21 and below	4.0.22
J2Store 4.1.x	4.1.6 and below	4.1.7

J2Commerce 6 is a separately rewritten codebase for Joomla 6 and is not covered by this advisory.

The three fixed builds are worth staring at for a second, because they are the reason a lot of tooling will get this wrong.

Why One Version Range Cannot Cover J2Store’s Three Branches

4.0.22 and 3.3.22 both sort below 4.1.7. So the obvious rule, “anything below 4.1.7 is vulnerable”, tells a Joomla 3 shop that correctly installed 3.3.22 that it is still at risk, and keeps telling it that through every future scan, because no build on that branch will ever climb above 4.1.7. The site owner then either ignores the warning or goes looking for an update that does not exist for their branch.

We hit this ourselves, which is why the J2Store entries in our Joomla vulnerability rules are three rules rather than one, split on branch boundaries that cannot overlap:

below 3.3.22                 -> Joomla 3 branch
4.0.0 and above, below 4.0.22 -> 4.0.x branch
4.1.0 and above, below 4.1.7  -> 4.1.x branch

We learned that the expensive way on a different extension. Convert Forms fixed one flaw in 4.4.16 for Joomla 3 and 5.2.3 for Joomla 4 and up, and a single range written across both told thirty correctly patched sites they were vulnerable until a customer told us otherwise. Any vendor maintaining a Joomla 3 branch alongside a modern one produces the same trap, and J2Store maintains two of them.

How Do I Find Every Affected J2Store Install?

By hand it means logging into each Joomla site, opening the extensions list, reading the J2Store version, working out which branch it belongs to and comparing it against the right one of three targets. For one shop that is five minutes. For an agency with thirty Joomla sites it is the kind of job that gets postponed, which is precisely what the numbers below show happening.

With mySites.guru, every connected Joomla site reports its full extension inventory, so J2Store installs across the whole account list on one screen with their versions. The three branch rules for this advisory are live now, alongside the three for the 21 August release, so an affected shop is flagged with the fix version for the branch it is actually on rather than the highest number in the advisory. If you want to see that against your own sites before paying for anything, the free audit covers it.

What the Connected J2Store Stores Actually Look Like

This is the part we can measure and most write-ups cannot. Across the Joomla sites connected to mySites.guru that run the J2Store component and reported a readable version in the last thirty days:

93%

below the fix for their own branch

on the day the advisory published

68%

of those are on the Joomla 3 branch

3.3.x and older

74%

of those never applied the 21 Aug fix

two advisories behind

already patched

on 3.3.22, 4.0.22 or 4.1.7

Measured 1 September 2026 across connected Joomla sites running com_j2store with a snapshot in the previous 30 days. Percentages of that group, not of all managed sites.

The 74% is the figure that should bother anyone running a Joomla shop. Three quarters of the affected stores are not one security release behind, they are two: still below the 21 August build that fixed an unauthenticated file upload the vendor confirmed had already been exploited in the wild. Those shops did not miss this advisory. They missed the last one too, and this one arrived before anybody noticed.

That pattern is why an extension inventory beats a mailing list. A shop owner reading a vendor advisory has to already know they run the extension, already know which branch, and already be reading. An inventory does not require anyone to be paying attention on the day.

Was Any of This Being Exploited?

We have no evidence of exploitation of these five before the fix shipped, and no proof of concept has been published for any of them. This post describes mechanisms rather than requests.

The honest caveat is that four of the five leave very little behind. A guest address read through the address editor looks like an ordinary page view. A cart row inserted anonymously looks like a cart row. The one that does leave a trace is the PayPal callback, because the order state changes, so that is the one to go back through if you ran an affected build with PayPal enabled.

The 21 August release is a different matter, and worth restating for the three quarters of shops still below it: the vendor confirmed that the file upload flaw in that set had been exploited in the wild before the patch shipped. If a shop is on 3.3.20 or below, 4.0.20 or below, or 4.1.5 or below, treat it as needing a look rather than just an update. Our guide to checking a Joomla site’s database and file integrity covers what to review.

Credit Where It Is Due

Two things J2Commerce did here are worth saying, because plenty of vendors do neither.

They patched the Joomla 3 branch on the same day as the modern ones. J2Store’s users skew heavily toward Joomla 3, as the 68% above shows, and a vendor who fixes only the current branch effectively strands most of their install base. J2Commerce has now done the simultaneous three-branch release twice in ten days. Three days after this advisory they also put a date on the end of it: the Joomla 3 branch stops receiving anything on 19 October 2026, which makes 3.3.22 the last security build most of these shops will ever be offered.

They also named the reporter. The advisory credits Phil Taylor of mySites.guru with discovery and responsible disclosure of all five issues, and thanks the Joomla Security Strike Team. We have written before about what a good Joomla extension disclosure looks like, and about vendors who shipped our fixes without ever saying where they came from. This one is on the right side of that line.

All five records published on 3 September 2026, assigned by the Joomla CNA, and all five credit Phil Taylor of mySites.guru. The affected ranges came through unchanged, so nothing in the fix advice above moves. Four of the five scores are the vendor’s. CVE-2026-78069 went up, from 9.4 to 9.5 Critical, and the CNA rewrote its vector rather than just its score: AT:P/PR:N where the vendor had AT:N/PR:L. That is worth reading carefully, because PR:N means no privileges required and our own proof needed an authenticated Joomla administrator session. The CNA appears to be treating the backend login as an attack requirement rather than a privilege, which is defensible for a shop where anyone can be given a backend account for an unrelated component, and is why the score rose. The practical advice is the same either way: this was reachable by any backend account holding no J2Store rights at all.

9.5CVSS 4.0

CriticalJoomla CNA, published 3 September 2026 · CVE-2026-78069

The worst of the five. Any account that can reach the Joomla administrator login, holding no J2Store permission at all, could trigger table truncation and traversal-based SQL file execution against the shop. J2Commerce scored it 9.4 with a PR:L vector; the published CNA record raised it to 9.5 and scores the backend login as an attack requirement (AT:P) rather than a privilege (PR:N).

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Backend login, any privilegeNo J2Store permission neededData destructionReaches file execution

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AV:N: Network: Reachable across the internet
AC:L: Low: Nothing to work around, it just works
AT:P: Present: Needs a particular deployment or race to line up
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

What it does to the site

VC:H: High: Everything the site holds can be read
VI:H: High: Data and files can be altered at will
VA:H: High: The site can be taken down

What it does beyond the site

SC:H: High: Data on other systems can be read
SI:H: High: Other systems can be altered
SA:H: High: Other systems can be taken down

Timeline

2026-08-21 J2Commerce ships 3.3.21, 4.0.21 and 4.1.6 for a different six flaws Six CVEs found by other researchers, including an unauthenticated file upload the vendor confirmed had been exploited in the wild. This is the release most affected shops are still sitting one step below.
2026-08-25 Five issues reported privately to J2Commerce The PayPal callback forgery, the reflected XSS, the anonymous cart tampering and the guest-address IDOR, all four proven live against a test installation. The fifth, the Apps delegation chain, was reported as shielded only by accident, with a warning that any change to fof.xml would expose it.
2026-08-25 J2Commerce acknowledges the report the same day Olivier Buisard confirms receipt four and a half hours later and says the issues will be resolved.
2026-08-31 J2Commerce ships 3.3.22, 4.0.22 and 4.1.7 for all five All three branches patched the same day. The advisory credits Phil Taylor of mySites.guru with discovery and responsible disclosure of all five issues, and thanks the Joomla Security Strike Team. The vendor also re-assessed the Apps delegation chain as reachable by any authenticated backend user and scored it 9.4, higher than the report treated it. The Joomla CNA later published it higher still, at 9.5.
2026-09-01 mySites.guru flags every affected connected store Three new vulnerability rules, one per release branch, so an affected site is told the fix version for the branch it is actually on.
2026-09-03 All five CVE records publish, credited to mySites.guru Assigned by the Joomla CNA. Four scores unchanged; CVE-2026-78069 published at 9.5 Critical rather than the vendor's 9.4, with a vector reading PR:N where the vendor used PR:L.
2026-09-03 J2Commerce sets J2Store 3's end of life at 19 October 2026 Announced the same day the CVEs published. 3.3.22, the release that fixed these five flaws, becomes the last security build the Joomla 3 branch is likely to get.

Release Radar, a Free Joomla and WordPress Release Tracker

phil@mysites.guru (Phil Taylor) — Tue, 01 Sep 2026 00:00:00 GMT

FREE!!!! tldr? https://releases.mySites.guru go there instead of reading.

If a Joomla extension developer shipped a new version of their component this morning, how would you find out?

Most people would not, at least not on purpose. They would find out the next time they opened a site’s update screen and saw a number sitting there. Or they would catch a forum post. Or an email would arrive from a mailing list they joined in 2019 and have filtered to a folder ever since.

WordPress looks better served until you check. The wordpress.org plugins API does publish version and last-updated data, machine-readable, for the 71,000-odd plugins hosted in the directory, and it is useful. The plugin RSS feeds that people still recommend redirect to HTML pages now and return no feed at all. The bigger limit is that the directory covers free plugins only. Elementor Pro, ACF Pro, WP Rocket, Gravity Forms and the rest of the commercially distributed plugins have no directory entry, so the software agencies most depend on is the software with no release feed.

Joomla has no equivalent for anything. Extensions there are distributed by their developers directly, each with its own update server, so there is no index to aggregate in the first place. The Joomla Extensions Directory tells you an extension exists; its “Recently Updated” page orders by edits to the listing rather than by releases, and the old feeds.joomla.org extension feed stopped resolving years ago.

We have been sitting on the answer for fourteen years and deleting it twice a day.

What Release Radar is

Release Radar is a free public log of new Joomla and WordPress extension, plugin and template releases. It is live now at releases.mysites.guru, it needs no account, and it has an RSS feed and a JSON endpoint.

Each entry records the extension name, the vendor, the version number, the date the release was first observed, and a link to the vendor’s own page. You can filter it to Joomla only or WordPress only, and you can look at a single vendor’s history.

It also covers paid extensions, which nothing else does. Other public release sources read a central directory, so they see only what that directory holds, and commercial software sits outside it. Release Radar sees what real sites see.

The public log. Name, vendor, version, the date it first appeared, and a link to the vendor.

There is a second half, inside mySites.guru, that answers a different question.

The public log tells you what shipped. The Release Radar page in your mySites.guru account tells you what shipped for the software you actually run, across your whole portfolio, and how many of your sites run each of them.

That page is part of the subscription.

Snapshots per day

of every connected site

100,000+

Site connections daily

across 90,000+ connected sites

Checks before publishing

corroboration, novelty, lineage

Extra vendor requests

nothing new is fetched from vendors

Release Radar is built from update checks the platform already performs.

Where does the release data come from?

Every site connected to mySites.guru asks its own vendors, twice a day, what updates are available for the software installed on it. That check uses the site’s own licence key, from the site’s own IP address, against the vendor’s own update feed. It is what the site would do by itself if somebody clicked the update button in the admin.

We snapshot connected sites twice a day, which works out at over 100,000 site connections daily across the 90,000+ sites connected to mySites.guru. Until now, when a site came back and said “there are six updates waiting, here is what they are”, the platform reduced that answer to the number six and discarded the rest. Six is what the dashboard needed. The detail went in the bin, twice a day, for years.

Release Radar keeps the detail. Each distinct release is recorded once, with the earliest date any connected site saw it.

One other source, for speed rather than breadth

There is a second input. A connected site only reports a release once it polls its own update feed and turns out to be behind, and a full pass over every connected site takes about ten hours. wordpress.org’s own plugin registry knows within minutes.

So Release Radar polls that registry once an hour and folds in what it finds, with one restriction: a plugin no connected site runs is dropped on the spot. wordpress.org lists more than 71,000 plugins and this is not an attempt to mirror them. What the registry buys is latency, not breadth. For a wordpress.org-hosted plugin that connected sites already run, it closes a gap measured at between five and twelve hours down to under one.

Joomla has no equivalent to poll, so Joomla releases still arrive at the speed of mySites.guru’s own update checks.

This is not a scraper

Release Radar makes no requests to any vendor’s server. Every observation from a connected site is a by-product of a check that was already happening for that site’s own benefit, and the one first-party source it does poll, wordpress.org’s public plugin API, is a single page an hour. Crawling vendor download pages would have produced comparable data, a real support burden for the developers on the other end, and a scraper that broke every time somebody changed a page template.

How do we know a release is real, and actually new?

A mySites.guru connector reports what its site tells it. If a site is compromised, or somebody has been editing files by hand, or an extension is misconfigured, that site can report an extension name and a version number that are complete fiction. Separately, a site that has not been scanned for a while reports everything it is behind on at once, most of which shipped months ago.

Three checks sit between an observation and the public log, and each one catches something the other two miss.

Corroboration

One site making a claim is a claim. Two unrelated customers, on different infrastructure, independently reporting the same extension at the same version, is a fact. So a release reaches the public log once two distinct customer accounts have seen it, or once wordpress.org’s own registry confirms that exact plugin and version exists. A first-party registry cannot be somebody’s hacked connector, which is the only thing the customer count was ever defending against.

This costs a little latency on obscure software, and for a commercial extension that only one customer in the world runs it means the release never publishes at all. We took that trade on purpose. A public log whose worst failure mode is “occasionally slow” is worth considerably more than one whose worst failure mode is “a single hacked site put a fake extension on a public website”.

Novelty

Corroboration proves a version exists. It says nothing about whether it is new, and that turned out to be the bigger problem.

Because the platform only records a release when a site is behind on it, a site that connects after a long gap reports its whole backlog at once, and every version in it the corpus has not seen looks like news. On one morning during testing a single site created thirteen releases inside one second, one of them a build that hundreds of other connected sites were already running.

The evidence needed to catch that was already sitting there. mySites.guru records every build every connected site runs, so “was anybody already running this before we first saw it offered?” is one indexed lookup. Applied to the releases published on the last day before this check existed, it caught 78% of them, in 18 milliseconds.

Lineage

The last check is the one nothing else asks. Joomla update feeds are branched by target platform, so a site on an old Joomla release is offered a maximum version that a site on a current one never sees. Two such sites are two customers, which clears corroboration, and the version is still absent from every site we can see, which clears novelty. A thoroughly superseded release passes both and arrives at the top of a feed of new releases.

So a release is also checked against the newest version already held on its own line, matched on the major version and on the branch tag that vendors write into the version string. It has to be both. “Never publish below the highest version we have ever seen” would suppress the security releases vendors ship on old branches, and a customer stuck on an old branch needs those more than anyone.

A release that fails any of the three is held for review rather than rejected, with the reason attached. Branch tags are vendor prose and this will read one wrong eventually, so the failure has to be recoverable.

The same reasoning runs through the rest of the feature. Release Radar’s only real claim is that its facts are facts, so each design argument gets settled in favour of claiming less.

What Release Radar will not tell you

A log like this is easy to over-read, so here are its limits.

Not a complete index

Release Radar only sees software installed on at least one connected site. An extension no one in the connected estate runs is invisible to it. What that filter leaves behind is software in live production use across a large number of real agency-managed sites, which is a reasonable working definition of the releases that matter. Treat it as a wide view of the ecosystem rather than a census of it.

No changelog text

Release Radar publishes the name, the vendor, the version, the date and a link. Changelog text is the vendor’s own copyright and belongs on the vendor’s own page. Republishing it would also put two pages in competition for the same search results, which helps neither the vendor nor the reader.

No back catalogue

The log starts on 1 September 2026 and fills forwards. Anything first seen before then is kept internally and never shown.

The reason is slightly counterintuitive. The platform records a release only when a site is behind on it, so the first harvest after deployment ingests the accumulated backlog of the whole connected estate at once rather than discovering anything new, and each of those rows would be stamped with the date it was imported. A release from 2021 would appear on the front page dated this morning, which would have made every date on the page meaningless.

That cut-off was originally calculated rather than fixed: a rolling window that opened a week after the earliest record. It had one fatal property, which is that rebuilding the corpus reset it. The corpus was rebuilt several times over two days while the way releases are identified was being corrected, and each rebuild pushed the window another week into the future. A guarantee that moves whenever the data is repaired is not a guarantee, so it became a fixed date instead.

The accepted cost is that a release which shipped before that date is invisible for good, which errs towards claiming less.

No judgement on vendors

Release Radar reports what shipped. It draws no conclusions about how, or whether, a vendor announced it.

BONUS: mySites.guru subscribers get their own Release Radar, specific to the products running on their sites

The public log answers “what shipped this week”. Your account answers “what shipped for the software I actually run”.

The Release Radar page inside mySites.guru shows new versions of the extensions, plugins, themes and templates your own sites run, matched on the extension itself rather than on whether you happen to be behind on it. That distinction is the entire point of the page.

The subscriber view: the same log, narrowed to software your own sites run, with a count of how many of them run it.

Consider the agency that keeps everything patched. A list of what you are behind on shows them an empty page, because there is nothing to be behind on, and an empty page tells them nothing at all. Matching on the extension is what tells a diligent agency that Akeeba shipped something yesterday and their sites have already taken it.

The page stops there on purpose rather than becoming a second work queue. “Which of my sites need updating” is what the Updates page already answers, and it sits one click away in the header. Two features answering one question is worse than one.

It applies no moderation filter either. A release that has yet to clear the checks for public publication is still real software sitting on your server, and hiding it from you would be the wrong call.

From there the rest of mySites.guru is already wired up: bulk updates across your sites at once, per-extension auto-updates if you trust a given vendor to ship safely, and the update queue if you would rather not fire two hundred updates at one shared server simultaneously.

How do I follow Release Radar?

RSS

https://releases.mysites.guru/feed.xml has the 50 most recent releases. Any reader will take it, and so will most chat tools if you want new releases dropping into a team channel.

JSON

https://releases.mysites.guru/api/releases.json returns the same data for scripts:

# Everything, most recent first
curl -s https://releases.mysites.guru/api/releases.json

# Joomla only, 200 rows, one vendor
curl -s "https://releases.mysites.guru/api/releases.json?platform=joomla&limit=200"
curl -s "https://releases.mysites.guru/api/releases.json?vendor=Akeeba%20Ltd"

No key, no rate-limit dance, and permissive CORS headers so a browser page can fetch it directly. limit caps at 200. An unrecognised platform value returns an error instead of dropping the filter with no warning, so a typo in your script announces itself.

MCP

Subscribers with the mySites.guru MCP server connected get a list_releases tool, so you can ask an AI assistant what shipped this week and have it cross-reference against your own sites in the same breath.

The paid extensions nothing else tracks

Public release trackers work by reading a central directory, which caps what they can see at whatever the directory holds. On wordpress.org that means free plugins. On the Joomla side it means nothing at all, because there is no central update index to read. Commercial extensions sit outside that model: they ship from the vendor’s own update server, behind a licence key, and a crawler holding no licence sees nothing.

Release Radar approaches it from the other end, reading what real sites got back when they asked their own vendors, using their own paid licences. A commercial Joomla component sold by subscription, a premium WordPress plugin sold from the developer’s own store, a template framework licensed per-domain: if it is installed on connected sites and it shipped a new version, it appears. The wordpress.org registry is read too, but only ever to hear about a free plugin sooner than the connected sites would have told us, and never to decide what belongs in the log.

That is also why the log skews the way it does. Widely-installed commercial software shows up quickly, because plenty of connected sites run it and their update checks agree. Obscure free extensions appear slowly or not at all. For an agency deciding what to test this week, that is the right bias.

Vendor communication is a separate problem and Release Radar does not solve it. An extension can still ship a security fix with a three-word changelog, leaving the people running it with no realistic way of finding out what changed. What the log fixes is narrower: being able to see that something changed at all.

A new version is not the same as a security fix

Release Radar tells you a version shipped. It does not tell you why. For known-vulnerable versions, the Joomla Vulnerable Extensions List and the CVE index are the right tools, and mySites.guru matches those rules against what is actually installed on your sites rather than leaving you to cross-reference by hand.

What is not there yet

Joomla has no registry to poll, so a Joomla release only appears once connected sites have polled their own update feeds and reported it. That is hours rather than minutes, and there is no way to shorten it that does not involve crawling vendors, which is the one thing this was built to avoid.

WordPress themes are inventoried now, and Joomla templates always were, but a theme release cannot be confirmed against wordpress.org the way a plugin release can. Themes wait for the connected sites, the same as Joomla does.

The vendor name used to be missing on a large share of entries, because the name a vendor puts in an update feed and the name that ends up in a site’s installed-extensions table are frequently different strings: one Joomla extension arrives from its feed as “Admin Tools Professional package” and sits in the database as “Admintools”. Matching on the extension’s own identifier instead of its name fixed that, and every release published so far shows a vendor. Sites running an older connector build do not send that identifier yet, so the occasional entry will still appear without one until those sites update.

None of these affects the accuracy of what is published. A release that appears is a release that was corroborated, tested against what the connected sites already run, and checked against its own version line.

Try it

releases.mysites.guru is open now. No account, no email address, no cookie wall.

If you manage more than a handful of Joomla or WordPress sites and you want the version of this that knows which of your sites are affected, that is what mySites.guru does, and there is a free month to try it on your own portfolio.

A Web File Manager for Your Joomla and WordPress Sites

phil@mysites.guru (Phil Taylor) — Sat, 29 Aug 2026 00:00:00 GMT

Touching a live site’s disk has, until now, meant leaving the tool built for security audits and reaching for a completely different, unaudited channel instead: SFTP credentials to dig up, a separate client cPanel login to remember, a five-minute fix that stops being five minutes the moment you have to go and find the tool for it first.

A file manager built into the same dashboard closes that gap. There’s no separate app to open and no fresh credential to request, borrow, or forget to revoke later, so a quick permission fix or a one-line edit stays a quick permission fix instead of turning into a ticket that sits in a queue until someone remembers the client’s FTP password. For an agency running mySites.guru across dozens or hundreds of sites, that’s real time back, not just tidiness: one login already behind two-factor authentication, one jailed connection to the site instead of a raw FTP account with no audit trail of its own, and one activity log that already knows who touched what and when, rather than whatever your host’s own logging happens to catch. Checking a file, fixing a typo, or pulling a suspicious upload off a site stays inside the same window you were already working in, which is what actually makes it quick.

What the New File Manager Does

mySites.guru now includes a full web-based file manager for your connected Joomla and WordPress sites: browse folders, preview and edit files, upload new ones, create folders, rename things, change permissions, and delete files and folders, all from inside the dashboard you already use for audits, backups and updates. It talks to your site through the same connector every other mySites.guru tool already uses, so there is nothing new to install. The result is close to having full FTP access to every site you manage, but fully integrated: no separate client, no credentials to keep track of, and available any time with two taps of f (for File Manager) on the keyboard.

Not the same File Manager you might already know

If you’ve used mySites.guru to fix a hacked site, you’ve probably already clicked “edit” or “delete” on a single flagged file inside an audit’s results. That single-file action still works exactly as it did. This is different: a full browser for your entire site root that needs its own permission, not just the files an audit has flagged.

The two tools share the same audit data, so browsing straight into a folder that already has flagged files shows exactly what the audit found: a red “Hacked” badge on something the suspect-content model already recognises as malicious, amber “Suspect content” badges on the rest. You don’t lose the audit’s judgement just because you’ve opened the general-purpose browser instead of the flagged-file list.

It is off by default, per site, and available on Joomla 3, Joomla 4, Joomla 5, Joomla 6 and WordPress. Sites connected with the Generic PHP connector don’t have the file manager’s connector endpoint yet, so the feature stays hidden for them until one exists.

Now on Joomla 3 and Joomla 4 as well

We have now backported the File Manager to Joomla 3 and 4 sites with additional security and controls for those end of life versions on end of life PHP versions.

It shipped first for Joomla 5, Joomla 6 and WordPress. Joomla 3 is the single largest group of sites we look after, so a tool for keeping an eye on a site’s files was missing from exactly the sites most likely to need it.

Where to Find It in mySites.guru

It lives on the same Manage tab as the tools you already use. Open a connected site, click Manage, and File Manager sits in that dropdown alongside Backup, Update, and Plugins.

There’s no separate app to install and no new part of the dashboard to learn. It’s one more entry in the same menu you already open to run an update or check a backup.

Prefer the keyboard? From the Manage Site page, from any audit or tool page for that site, or from its Learn More screen, pressing f twice (keyboard shortcut: f f) jumps straight to the File Manager tab, no menu required. The full shortcut list lives on the Keyboard Shortcuts page.

Browsing, Editing, Uploading and Deleting Files

Once it’s switched on for a site, the File Manager gives you a folder tree and file listing rendered straight from the live server, with the same kind of interface you’d expect from an SFTP client, but without the client.

It works on the files that are actually on your server right now, not the picture your last audit took of them, which is why every row also has a live Audit column: “Core file” for something the audit already recognises as untouched, “Not audited” for anything it hasn’t seen yet, and, where it applies, the same “Suspect content” or “Hacked” flags the audit itself would show you. Permissions get the same treatment. An ordinary 0644 or 0755 renders in green; something like a world-writable 0666 on wp-config.php is flagged in red the moment the listing loads, before you’ve clicked anything.

From there:

Off by default. Every site starts with the File Manager switched off, and it stays that way until you turn it on yourself.
Browse and preview any folder in the webroot, with file size, permissions and modification date shown per row.
Open and edit text-based files (PHP, JS, CSS, .htaccess, config files, templates) directly in the browser and save the change straight back to the server.
Upload new files into any folder, or overwrite an existing one, without an SFTP client.
Create folders and rename files or folders in place.
Change permissions on a file or folder, the chmod action every SFTP client has, without the SFTP client. This depends on your host letting PHP itself change permissions; where a host locks that down, the option is still there but the underlying chmod call fails the same way it would from any other PHP-based tool.
Delete files and folders, individually or as a batch.
List the contents of a zip file before you decide whether to extract or discard it, useful for checking what a plugin or template package actually contains before it touches your live site.

Every one of those is a real command sent to your site’s connector and executed there. Nothing is simulated, and nothing is queued for later: what you see is what’s on disk right now.

What Happens When You Delete a File?

A normal delete doesn’t unlink the file. It moves it into a folder called .mysites-trash inside your own site, keeping its original path so two files with the same name don’t collide. mySites.guru’s own audit is told to ignore that folder, so trashed files don’t show up as suspect content in your next scan. From there you can put a file back, or leave it, or empty the trash for good.

The trash folder itself is locked down once something’s in it: the File Manager will not open or edit a file while it’s sitting in .mysites-trash, only move it back out or remove it for good. Force-deleting is a separate, explicit action, and anything already inside the trash is removed for good when you force-delete it rather than being trashed a second time. The trash itself is capped at 512MB per site: once it fills, the oldest batches are pruned automatically so it can’t be used to eat your disk quota.

configuration.php and wp-config.php aren’t fenced off either: you can edit or delete them like any other file, because with deletes defaulting to the trash, that’s a recoverable mistake rather than a security gap. The one file the manager will not delete, wherever it appears in the tree, is index.php, since clearing that out would break the connection this whole feature depends on.

How Do You Turn It On?

Two-factor authentication is a prerequisite, not just a checkbox on the way in. No mySites.guru account without it turned on can enable the File Manager, or even open it on a site where someone else already has. That applies per person: if a team member’s own account doesn’t have 2FA set up, granting them access to the site doesn’t get them into the File Manager, because their account doesn’t clear the gate on its own.

With that in place, the switch lives on each site’s File Manager tab. Before you flip it, the tab shows an off-state screen rather than the switch itself: who gets in, where it can reach, what happens when you delete something, and that every read and write is recorded, all laid out before the button that turns it on.

Turning it on itself takes more than one click:

Your account password, typed again.
A site that isn’t flagged with a broken SSL chain. If mySites.guru already knows your site is presenting an untrustworthy or spoofable TLS certificate, the File Manager stays off for an ordinary owner, on the reasoning that a connection we don’t trust isn’t one we should be writing files over either.

Turning it off again never asks for any of that, and it doesn’t happen from the File Manager tab you used to turn it on: it’s on the site’s Config tab, under Advanced, where a “Write channel is open” status sits next to a single Turn it off button.

Closing the write channel only ever reduces risk, so it asks nothing of you beyond that one click: no password, and no signing in again. It’s still the account owner’s switch, the same as turning it on, and your files (and anything sitting in the trash) are left exactly where they were.

How the File Manager Talks to Your Site

Every request the File Manager sends travels over the same encrypted channel every other mySites.guru tool already uses: your site’s own connector, authenticated with the RSA key pair generated when you first connected it, with each request validated once through a single-use callback before the connector will act on it. There’s no separate password, no new port to open, and no additional credential to leak.

The reply travels back the same way, but with one addition specific to a tool that writes to disk: every reply is authenticated with its own HMAC before the encryption masks it. The stream cipher used for that masking has no integrity checking of its own, so without the HMAC a tampered-with reply could look like a successful one. With it, a reply that fails the check is treated as a failure, never as a partial success.

Connector commands

browse, read, save, upload, mkdir, delete, rename, chmod and more

300/hr

Rate limit

per user, per site, on every write

5 min

Upload token lifetime

single-use, then it's dead

512MB

Trash cap per site

oldest batches pruned automatically

Why Every Path Is Jailed to Your Site Root

Every path the File Manager touches is resolved and checked against your site’s own root before anything happens to it, with no exceptions carved out anywhere in the code. A symlink that points outside that root is blocked rather than followed, whether you’re reading through it or trying to write through it. The connector’s own folder, which holds your site’s private key, is on a permanent deny list: the File Manager can’t read it, write to it, or show it in a folder listing, no matter how you navigate.

That jail is also why the feature was worth building carefully rather than quickly. Reviewing it turned up a real, previously unjailed path check in an older, unrelated single-file command that had existed in mySites.guru for years, reachable through the legacy “restore this flagged file” action. It’s fixed now, and the fix went out ahead of this feature rather than alongside it.

Why Uploads Are Pulled, Not Pushed

The encrypted channel every other command travels over is built for small payloads, not multi-megabyte files: pushing a file through it the same way as everything else would mean tens of thousands of individual decrypt operations for anything bigger than a few kilobytes. So uploads work the other way around.

Your browser uploads the file to mySites.guru first, where it’s staged privately with a random key and no trace of the original filename. mySites.guru then hands the connector a single-use link, valid for five minutes, pointing only at mySites.guru’s own domains. The connector fetches that file itself, over its own outbound connection, and checks the exact byte count and a SHA-256 hash of what it actually downloaded before moving anything into your site’s jail. A link to anywhere else simply wouldn’t be accepted: the connector only trusts URLs on the handful of domains it already knows.

That shape has a side benefit beyond speed. Because the connector fetches the file itself and writes it locally, the upload never arrives as an inbound HTTP request to your site. Your own server-level firewall or WAF, the kind that inspects incoming uploads and sometimes blocks a legitimate one that merely looks unusual, never sees it and never gets a chance to interfere.

Every Read and Write Gets Logged Twice

Every action the File Manager performs is written to your site’s own activity log the same way any other change would be, so if a team member deletes a file at 2am, you can see who did it and when, on your own site, independent of mySites.guru. It’s also written a second time into a separate audit table inside mySites.guru itself, regardless of whether the action succeeded or failed. Neither log depends on the other, so losing one doesn’t blind you to the other.

That second log is what you’d open to answer “who touched this file and when”: a plain table of who did what, to which path, and whether it worked, with the full history for every site available from the account activity log.

That mirrors the wider practice this site follows for client activity reporting: an action that touches a live site should be traceable after the fact, not just permitted at the time.

How Do You Manage It Across Dozens of Sites?

Agencies running mySites.guru rarely manage one site at a time, so the File Manager has its own switchboard: one page listing every eligible site with an on/off switch per row, plus enable-all and disable-all for the whole account. It’s restricted to the company owner, and it enforces exactly the same password and two-factor checks a single-site toggle would, just applied to however many sites you select at once.

That switchboard is also one of the results in the command palette (⌘K on Mac, Ctrl+K on Windows): start typing “file” and File Manager Access For All Sites comes up alongside every other tool.

Each row has its own Open button, which drops you straight into that site’s File Manager tab without going through the site’s own Manage page first. Bookmark the switchboard itself and you’ve got one page that shows the File Manager state of every connected site at a glance, with instant access to any of their webspaces from the same list.

We’ve Disclosed RCEs in Other People’s File Managers

We didn’t build this in a vacuum. Earlier in 2026, we found and privately disclosed an unauthenticated file upload vulnerability in RSFiles!, a Joomla extension used for file downloads, where the method that actually wrote a file to disk skipped the permission and file-type checks the extension appeared to have. It’s tracked as CVE-2026-57827. A few weeks later we found a pre-authentication remote code execution flaw in the Joomla page-building extension SP Page Builder, tracked as CVE-2026-67285 and CVE-2026-67286, where an endpoint trusted a filesystem path supplied by the visitor instead of loading it from the saved page.

Both were built by vendors who believed their file-handling code was safe, and both were wrong. That’s the backdrop this feature was designed against: what does the failure mode look like when this goes wrong, and how do we make sure it can’t.

Is a Web-Based File Manager Actually Safe?

It’s a fair question to ask of any tool that reads and writes a live site’s disk, especially given how often attackers plant exactly this shape of tool as a backdoor once they’re already in. The difference here isn’t the interface, it’s what sits underneath it: every path jailed to the site root with no exceptions, every reply authenticated before it’s trusted, uploads verified by hash before they’re written anywhere, deletes recoverable by default, every action logged twice, and the whole thing off until you switch it on yourself, behind your account password and two-factor authentication.

It’s also worth measuring against the access you’ve already given mySites.guru, not against a blank sheet. Every audit already reads every file on your site. The existing suspect-content tools already let you edit or delete a single flagged file with one click. This feature is a wider door onto the same room, and it’s locked more heavily than the door you’re already using: off by default per site, confirmed again with your account password, behind two-factor authentication, and shut for an ordinary owner on a site with a broken SSL chain.

Compare that to the file editor already sitting in your own Joomla administrator or WordPress dashboard. Both ship one by default: a code editor that opens any template, theme or plugin PHP file and saves the change straight to disk, with no jail, no trash, and no second log outside whatever your host happens to keep. We tell WordPress users to turn that editor off entirely with DISALLOW_FILE_EDIT, because it’s the fastest, quietest route from a stolen admin password to running code. A compromised admin login already grants everything the File Manager does, minus every one of the guardrails this feature was built with.

“

One can steal ideas, but no one can steal execution or passion.

Tim Ferriss

Joomla 3 Didn't Fail. Your Retainer Did.

phil@mysites.guru (Phil Taylor) — Fri, 28 Aug 2026 15:30:00 GMT

Do you want to bury your head in the sand?

It is a real question, because burying it is a defensible commercial decision right up until the morning it is not. Joomla 3 reached end of life in August 2023. The paid eLTS programme that extended it ended on 17 February 2025. Since then there has been no official security patch for the Joomla 3 core at any price, from anyone.

And yet, as I write this, mySites.guru is monitoring 30,305 live Joomla 3 sites.

Before you read another number in this post, understand where all of them come from, because it changes what they mean. Every figure here is measured across sites connected to mySites.guru. These are sites whose owners pay us every month so that somebody is watching: so the installed extensions are inventoried, so a new vulnerability raises a flag, so updates can be pushed in bulk. By any reasonable definition these are among the best looked-after Joomla sites in the world.

So everything below is the good end of the ecosystem. Joomla powers millions of sites, and the overwhelming majority of them have no one doing any of this. They are not in these statistics, and there is no reason at all to think they are doing better.

30,305

Live Joomla 3 sites

Three years past end of life

More likely to be hacked

4.90% vs 0.98% on Joomla 6

68.2%

Behind even 3.10.12

The final Joomla 3 release

79%

Have unpatched core files

Of the sites we can check

Measured across sites connected to mySites.guru on 28 August 2026. These are managed sites, so they represent the good end of the ecosystem.

I am not writing this to tell you those sites are a risk. You know that. Every agency I have ever spoken to knows that. I am writing it because we finally have enough data to say something more useful, and more uncomfortable, about why they are still there.

The Joomla 3 dates, for the record

Most arguments about Joomla 3 run on a vague sense that it is old. The dates are more useful than the feeling, because they show how long the gap has been open and how much of that gap somebody was still being paid to cover.

Every release date below is read from the RELDATE constant compiled into that release’s own source code, so it is the date the software itself reports rather than a wiki’s recollection of it.

Release	Date	Gap since the previous minor
Joomla 3.0	27 September 2012	The first Joomla 3
Joomla 3.1	24 April 2013	209 days
Joomla 3.2	6 November 2013	196 days
Joomla 3.3	30 April 2014	175 days
Joomla 3.4	24 February 2015	300 days
Joomla 3.5	21 March 2016	391 days
Joomla 3.6	12 July 2016	113 days
Joomla 3.7	25 April 2017	287 days
Joomla 3.8	19 September 2017	147 days
Joomla 3.9	30 October 2018	406 days
Joomla 3.10	14 August 2021	1,019 days
Joomla 3.10.12	8 July 2023	The final Joomla 3 release of any kind

That 1,019 day row compresses the whole story into one line. Joomla 3.9 in October 2018 was the last release that added features for their own sake. Joomla 3.10 was a bridge built to get people off, complete with deprecation warnings and a pre-upgrade check, rather than a version anyone was meant to settle on. Most of the estate settled on it anyway, and thousands of sites never even got that far, as the next section shows.

The lifecycle dates are the ones that matter in a conversation with a client:

Date	What happened
17 August 2021	Joomla 4.0 released, starting the two-year clock on Joomla 3
8 July 2023	Joomla 3.10.12 ships, the last Joomla 3 release
17 August 2023	End of life. Free security patches stop, at any severity
17 February 2025	The paid eLTS programme closes. No official patch at any price
October 2025	Joomla 4 security support ends, so the version most agencies migrated to is now unsupported as well

10y 10m

Joomla 3's supported life

27 September 2012 to 17 August 2023

1,107

Days since end of life

No free core patch since 17 August 2023

557

Days since any patch was purchasable

eLTS closed 17 February 2025

Counted to 28 August 2026.

Two more facts worth having to hand when somebody tells you this is a small legacy problem.

Joomla 3 shipped 106 stable releases, which is more than Joomla 4, 5 and 6 have managed between them so far. It was supported for ten years and ten months, about two and a half times as long as Joomla 4 lasted. That length is exactly why so much of the web still runs it, why so many extensions were built against it, and why the people who built those sites had every reason at the time to believe they were building on something stable.

The final release also still declares its minimum PHP as 5.3.10, in administrator/index.php, unchanged since 2012. PHP 5.3 left security support in August 2014. Joomla 3 never raised that floor across its entire eleven year life, which is the root of the hosting problem further down this post: the sites are not only running old Joomla, they are running old Joomla on a PHP branch their host is preparing to remove.

Dates are one way to remember a release. Basic Joomla Tutorials marked this one twice, and the pair is worth your time if you ever built anything on Joomla 3.

First the warning, with a month left on the clock:

Then the look back, recorded on Joomla 3’s last day before end of life:

The Joomla 3 estate is worse than the version number suggests

Being on Joomla 3 is not one problem, it is a stack of them, and the stack has been growing for three years.

Start with the version spread. Of those 30,305 Joomla 3 sites, only 9,638 are on 3.10.12, the final release. The other 20,671, which is 68.2%, are behind even that. There are 1,286 sites sitting on 3.6.5, 1,054 on 3.4.8, and 574 on 3.3.6. These are not sites that reached the end of the road and stopped. They stopped somewhere earlier and the road ended without them.

Then the extensions. Across those sites we currently count 22,195 installed extensions with a known published vulnerability. Three sites are running twenty of them. A hundred and seventy-one sites are running thirteen or more.

The extensions doing the most damage are not obscure:

Extension	Share of live Joomla 3 sites	Can a Joomla 3 site apply the 2026 fix?
YOOtheme Installer	4.5%	No. YOOtheme Pro removed Joomla 3 and Joomla 4 support in January 2026
Cache Cleaner	3.1%	No. Regular Labs cut Joomla 3 across its whole range on 21 September 2023
Regular Labs Manager	2.7%	No. Same cut
Advanced Modules	2.5%	No. Same cut
SP Page Builder	2.5%	No. The 6.8.0 installer contains a version guard that blocks Joomla 3
RSForm! Pro	2.5%	Yes. RSJoomla never dropped Joomla 3 and shipped J3 builds this month
JCE Editor	2.3%	Yes. Free patch backported to 2.7.x, 2.8.x and 2.9.x
Sourcerer	1.9%	No. Regular Labs, same cut

Six of the eight cannot be fixed without rebuilding the site onto a supported Joomla. Three of those six are the same vendor, cut on the same day, and two of the CVEs sit in a shared library that every Regular Labs extension bundles.

None of that is theoretical.

4.90% of Joomla 3 sites are currently flagged as hacked, against 0.98% of Joomla 6 sites.

Measured across every Joomla site we monitor. A Joomla 3 site is five times more likely to have been compromised, and Joomla 5 sits at 2.67%. The gradient runs exactly the way you would expect, and it runs across tens of thousands of sites rather than a handful of anecdotes.

And remember whose sites those are. That 4.90% is the hacked rate among Joomla 3 sites that somebody is paying to have monitored.

On the vendor side, it is getting worse rather than better.

In July 2026 JoomShaper ended Joomla 3 support across SP Page Builder, Helix and its template range, with one line doing the damage: no security patches, regardless of severity. Six days later they shipped Joomla 3 patches anyway, and have since shipped a third one. That reversal is good news and a warning at the same time. A vendor changing its mind twice in seven weeks is not a support policy you can plan a business around.

Joomla 4 is the part that should worry you

One number changed what this post was going to be, and I did not expect it.

We ran the same vulnerable-extension analysis across every Joomla branch. Joomla 4, the version agencies migrated to specifically so that this would stop being a problem, is now the worst-maintained branch on our entire estate.

Branch	Hacked	Sites with a vulnerable extension	Average on an affected site
Joomla 3	4.90%	22.3%	3.30
Joomla 4	4.67%	50.6%	2.52
Joomla 5	2.67%	26.6%	2.30
Joomla 6	0.98%	16.2%	1.76

Two different things are wrong, and they are wrong on different branches. Joomla 4 has the widest spread: half of those sites are running something with a known hole in it. Joomla 3 has the deepest infestation: when a Joomla 3 site is affected it is running 3.30 vulnerable extensions, not one.

Every one of those rows is a managed site. Half of all Joomla 4 sites that somebody is paying to look after are running at least one extension with a known, published vulnerability. That is more than double the Joomla 3 rate and more than three times the Joomla 6 rate. Joomla 4 has itself reached end of life, so these sites are in exactly the position their owners paid to escape, except this time they paid first. And it went out with far less noise than Joomla 3 did. Joomla 3 got its own farewell announcement, an eighteen-month paid support programme and a warning in the admin panel. Joomla 4’s last release was 4.4.14 on 30 September 2025, and the series left security support that October with no announcement of its own at all, just a subordinate clause in the post announcing Joomla 6.

Joomla 4 did reach end of life on its own account, with bug-fix support ending in October 2024 and security support in October 2025, and you can read that anywhere. That is a statement about whether the core gets patches, which is a different question from the one I am asking.

The point is the extension column. Whether or not the Joomla 4 core is supported has no bearing on whether somebody updated RSForm! on that site last month. No one is looking after those 50.6%, and they are also the sites that had the most money and effort spent on them in the last three years. Blaming the Joomla project for that would be convenient and wrong.

The finding that reframed this post

Half of all Joomla 4 sites run at least one extension with a known vulnerability. That is 50.6%, against 22.3% on the Joomla 3 sites they migrated away from, and it is the widest spread of any branch we measure. The expensive migration did not fix it.

The agencies who did the hard thing, who got the budget approved, who spent the weekends rebuilding templates and replacing extensions that had no successor, are measurably in a worse state than the ones who did nothing.

And Joomla 5 is next, sooner than you think.

Joomla 5 leaves regular bugfix support on 13 October 2026, which is about six weeks from the day this was written. Security-only support runs to 12 October 2027. If you are on Joomla 5 and reading this feeling comfortable, that is the same feeling the Joomla 4 shops had in 2024.

Migrating is still the only real answer, so read none of this as an argument against it. The argument is that migrating was never the thing that fixed it, and treating it as the fix is what put those sites back in the hole. A Joomla 4 site can even be hurt by trying to do the right thing: an administrator chasing security patches on an end-of-life version can switch update channels and get flung onto the next major release, breaking extensions and ending up worse off than before.

The migration was a payment. The site is a running cost. When the payments stopped, the debt started accruing again the same week.

Joomla 3 is not actually that insecure

Having spent five hundred words telling you the sky is falling, let me argue the other side, because the honest version of this is more useful to you than the alarming one.

Joomla 3 is a mature, well-tested codebase. It had eleven years and twelve point releases to have its corners knocked off, and it shows. Of the twelve core advisories Joomla published in 2026 whose affected range reaches back into 3.x, exactly one is rated High by the Joomla project. The rest are Low or Moderate. That is not the profile of software falling apart.

And look again at our own number the other way up. 95.1% of the Joomla 3 sites we monitor are not flagged as hacked. Joomla 5, fully supported and receiving every patch, sits at 2.67%. Joomla 3 is roughly twice as bad, not a hundred times.

The core is also patchable, which people forget. The community backport closes the published core holes without an eLTS licence, and it has been kept current: four more CVEs were added to it over summer 2026.

What surprises people most is that plenty of extension vendors did back-patch Joomla 3 in 2026, in some cases for free and in some cases the same day they patched the modern branches. JCE shipped a free patch reaching back to 2.7.x. iCagenda published a release literally titled “Security Release Joomla 3”. SEBLOD patched three branches on one day. J2Store, taken over in October 2024 by Olivier Buisard and Adam Melcher after its original team closed the project, patched eleven CVEs across two August advisories and shipped the Joomla 3 build the same day as the Joomla 4 and 5 ones both times. That one now has an expiry date: the J2Store 3 branch stops on 19 October 2026. RSJoomla never dropped Joomla 3 at all and was shipping Joomla 3 builds this month.

So a Joomla 3 site running a well-chosen stack, with the core backport applied and every vendor still shipping, can be well-patched today. I would not call it supported, and I would still move it. But it is not the burning building the first half of this post implies.

That distinction is the whole argument in one turn.

The risk was always the specific set of extensions on the specific site, and whether each of those vendors happened to keep going. “Joomla 3” was never the useful unit. That is not knowable from the version number, it is not knowable from a blog post, and it changes without anyone announcing it. Two Joomla 3 sites built the same year by the same agency can be in completely different states today, entirely because of which page builder each one happened to use.

Which means the safe Joomla 3 sites and the dangerous ones are separated by whether anybody is looking, not by which version they run.

The well-meaning Joomla 3 rescue projects are not a plan, they are a liability themselves

Every time a platform goes end of life, a handful of projects appear promising to keep it alive. Joomla 3 has several, and they are not equal.

The 3rd party projects attempting to keep Joomla 3 alive:

Joomla 3.10.999 our own backport of the core security patches.
Patches the core, and nothing else. We call it a holding position rather than a fix, which is the honest description of every project on this list.
TLWebdesign the same patches, packaged as an installable extension.
Tom van der Laan took our patches and made them installable. That packaging is useful and he was still pushing to the repository in July 2026. Joomla's own security team declines to endorse it, in as many words.
joomlaworks/joomla-3.x continued 3.x development for code security and modern PHP.
Real engineering, but it forks the core. Nothing in it touches the extensions that are actually getting these sites hacked.
Joomla 3.x UTD a fork that keeps the Joomla name and numbers its releases 3.11, 3.13, 3.15.
Those versions never existed. Joomla's updater, the vulnerability databases, hosting scanners and our own inventory cannot interpret them, so no one can tell you whether that site is patched or not.
joomla-update.ch a vibe-coded patcher.
An AI-slop approach to somebody else's security. Generating patches for a codebase you have not read, for a CMS whose maintainers have stopped issuing fixes, then offering them to strangers to run on production sites, produces plausible-looking output and calls it a security process.
The PHP 8 compatibility work getting a Joomla 3 codebase to run on PHP 8.
The most useful of the group and the most likely to be misread. It solves the hosting deadline in the next section. It does not make the site secure. Two different deadlines, arriving together.

Security patching is the one job where the code has to be right rather than convincing, and where the failure mode is silent. If you would not let an unreviewed model commit directly to a client's site, do not let one do it through a download page either.

But be clear about what any of them can and cannot do for you, because three structural problems apply to all of them.

The core is not what is getting you hacked

Look back at that extension table. The three most-installed of those extensions are a template framework, a page builder and an editor, and no core fork touches any of them. This is the whole reason we treat our own patch tool as a holding position rather than a fix, and it is why a patched extension on an unpatched core, or a patched core under an abandoned template, is a safer position and not a supported one.

The version numbers break every tool that could see the problem

Joomla 3 ended at 3.10.12. A fork that calls its releases 3.11, 3.13 or 3.15 is not following semantic versioning and, more practically, it is emitting a version string that nothing in the ecosystem can interpret. Joomla’s own updater cannot reason about it. Vulnerability databases key their affected-version ranges on real Joomla releases. WAF rules and hosting-side scanners do the same. So do we: we are an inventory tool, and a site reporting a version that never existed is a site we cannot honestly tell you is safe or unsafe. We have already seen exactly this failure with vendor patches, where JoomShaper reused the same version string across two different security releases and no inventory tool could tell a patched site from an unpatched one. A fork that invents version numbers has the same problem permanently and by design.

Calling it Joomla is a problem for the reader, not just the lawyers

A fork that keeps the Joomla name and the Joomla branding while shipping code the Joomla project did not write and will not support leaves a client, a hosting provider and an incoming developer with no way to tell what they are actually running. Joomla is a registered trademark and the project has a policy about this, which is its business rather than mine. Mine is that “we are on Joomla 3.15” is a sentence that sounds reassuring and means nothing.

The PHP 8 work solves a different deadline

The PHP 8 compatibility work deserves a separate word, because it is the most useful of the lot and the most likely to be misread. Getting a Joomla 3 codebase running on PHP 8 solves a real and urgent problem, which is the next section. It does not make the site secure. Those are two different deadlines that happen to be arriving at the same time, and clearing the first one does nothing about the second.

No one knows when your extensions stop being supported, including the vendors

If you want one reason a Joomla 3 site cannot be managed by looking things up once and writing the answer down, this is it.

I went through the dated announcements and changelogs of the vendors whose extensions actually appear on the sites we monitor. The pattern that emerged had nothing to do with who dropped Joomla 3. The vendors who made the most absolute statements were the ones who broke them.

Akeeba shipped a release in August 2023 whose notes were titled “Final version for Joomla! 3”. It was followed by four more Joomla 3 releases, the last in May 2025, three months after Joomla’s own paid support programme had closed. Along the way they published three different end dates, including one announced two days after the deadline it replaced.

JoomShaper announced on 9 July 2026 that Joomla 3 would get “no security patches, regardless of severity”, and then shipped Joomla 3 security patches six days later, with two more following on 22 July and 27 August. That sentence is still on their site, uncorrected, while the third patch sits in their GitHub releases. We covered the announcement, the reversal and the third patch as they happened. At the same time, SP Page Builder 6.8.0 added a version check to stop the installer running on Joomla 3 at all. Hard-blocked in the mainline, separately patched on the side.

JCE announced that version 3.0 would remove Joomla 3 support. Then they lowered the Joomla 3 floor from 3.10 to 3.9, backported a free security patch to branches that predate Joomla 4 entirely, and today the Joomla 3 branch has a more recent release candidate than the 3.0 that was supposed to replace it. (Their June 2026 security post credits my own analysis for that one, which is the only reason I noticed how far the J3 branch had drifted from the announcement.)

Joomlashack said in August 2023 that they would reassess Joomla 3 support in August 2024. That sentence is still on their documentation page today, two years after the reassessment date, and the reassessment was never published.

And the spread is enormous. Kunena stopped supporting Joomla 3 in December 2022, eight months before Joomla did. Community Builder stopped on 21 August 2026, three years and four days after. Both are community projects of similar standing. RSJoomla, HikaShop and VirtueMart have not stopped at all and were still shipping Joomla 3 builds this month.

So when somebody asks whether the extensions on a Joomla 3 site are still supported, there is no date you can look up. The answer is different for every extension, it moves, and the vendors themselves keep changing it. The only way to know what a site is actually running, and whether a fix exists for it, is to check the sites continuously. That is not a pitch for our product, it is the reason a product like ours exists at all, and it is the clearest possible argument that this is a service rather than a task.

Every Joomla 3 policy statement we could find, with its link

The section above is the argument. This is the evidence, so you can check it rather than take my word for it.

We went looking for a public, dated, quotable statement from every vendor whose extensions actually appear on the sites we monitor. Every URL below was fetched and the sentence read in context, and a vendor only appears here if there is a real statement to quote. Where a page shows no date, the table says undated rather than guessing one.

Vendor	Extensions	What they said	When
Akeeba	Backup, Admin Tools, Ticket System	“Limited support” from February 2025, free versions “not supported at all”	19 Aug 2024
Akeeba	Akeeba Backup 8.3.3	Final Joomla 3 version, security updates only to 17 August 2024	6 Aug 2023
JoomShaper	Helix Ultimate, Helix3, SP Page Builder	“No security patches, regardless of severity”	9 Jul 2026
JCE	JCE Pro and Core	“Remove official support for Joomla 3” at 3.0	11 Feb 2026
Joomlashack	25 extensions, OSMap	“Support Joomla 3 extensions until at least August 2024”	29 Aug 2023
Joomlashack	Documentation restatement	Same pledge, Pro members only, no bug fixes for Joomla 3 only products	undated
Regular Labs	Sourcerer and eight more, same day	“Removes Joomla 3 support”	21 Sep 2023
YOOtheme	YOOtheme Pro 5.0	“Support for Joomla 3 and 4 has been removed”	13 Jan 2026
Gantry	Gantry 5.5.20	“Dropped Joomla 3.x support”	17 Jul 2025
RocketTheme	The whole company	“The RocketTheme mission officially concluded”, club and downloads closed	states 30 Jun 2025
Kunena	Kunena Forum	“The final release of Kunena 5.2.14 … for Joomla 3.10”	14 Dec 2022
Joomlapolis	Community Builder	“Joomla 3.x support has come to an end”	21 Aug 2026
J2Commerce	J2Store, J2Commerce	“J2Store 3 end of life” on 19 Oct 2026, “no further releases of any kind”	3 Sep 2026
Weeblr	sh404SEF	“No further development … dedicated to Joomla 3 support”	24 Jul 2023
JoomlaWorks	K2, Simple Image Gallery, AllVideos	“We don’t plan on giving up on K2 (or Joomla 3)”	30 May 2024
JoomlaWorks	Their own Joomla 3.x UTD fork	Maintained “to ensure code security and support modern PHP”	22 Apr 2026
Joomlatools	DOCman 6	“Still running Joomla 3 … upgrade safely when you’re ready”	14 Oct 2025
Seblod	SEBLOD 3 and 4	Want to stay on Joomla 3? Remain on SEBLOD 3	5 May 2023
Fabrik	Fabrik 3	“None of this work will be backported to the F3 codebase”	11 Aug 2026
Extly	Perfect Publisher, XT	“Extending our support for Joomla 3 until at least the end of 2024”	26 Oct 2023
Balbooa	Balbooa Forms	“All future versions of Forms wouldn’t be compatible with Joomla 3.x”	21 Apr 2025
Balbooa	Balbooa Forms	“Upgrading Joomla remains the only meaningful long-term security solution”	14 Jul 2026
Digital Peak	DPCalendar	DPCalendar 8.x in “hybrid maintenance mode” for Joomla 3 users	21 May 2024
JEvents	JEvents	“3.6.82 was the last planned release that will support Joomla 3.10.x”	undated
iCagenda	iCagenda	The 3.9 series “is the last one to support Joomla 3”	undated
Tassos	Convert Forms, Engage	Joomla 3 users sent to a “legacy release built for Joomla 3.x”	undated
Solidres	Solidres 2.13.0	“We also dropped support for Joomla 3 to focus only on Joomla 4”	1 Dec 2022
Sigsiu	SobiPro	“The SobiPro 2.5 series will be the last series made for with Joomla 3”	3 May 2024
JoomDonation	OS Property	“Discontinued Joomla 3 Support: Joomla 3 has reached its official end-of-life”	undated
Mosets	Mosets Tree 4.0	“Mosets Tree 4.0 requires Joomla 4 to run”	18 Aug 2021
VirtueMart	VirtueMart 4	Still shipping for Joomla 3: “compatible with Joomla! 3.10.x”	undated

Thirty-one statements, and no two of them agree on anything. Some are two years before Joomla 3 reached end of life, some are three years after. Six of the thirty-one give no date at all, which means a customer reading the page cannot tell whether it was written last month or in 2021.

Exactly one of them names a future date and explains the policy behind it. J2Commerce announced J2Store 3’s end of life fourteen months before the version it retires stopped being the one most of their users run, set the same runway for the next version, and said which Joomla releases each line tracks. That is the shape the other thirty are missing, and it took a vendor who had spent two years patching a branch no one was obliged to patch to produce it.

Where the actions contradict the words

The JoomShaper, JCE and Akeeba reversals are above. They are not the only ones, and the pattern is consistent enough to be worth naming: the loudest announcement is the least reliable predictor of what the vendor will actually do next.

Seblod’s only public words on Joomla 3 remain that May 2023 post, yet SEBLOD 3.30.0 shipped on 28 July 2026 fixing an SQL injection, a search-radius SQL injection and a path traversal, three years past end of life.

Web357 went the other way entirely and added Joomla 3 compatibility in June 2026, nearly three years after EOL.

iCagenda contradicts itself in the customer’s favour. The roadmap says 3.9 was the last series to support Joomla 3, while the changelog lists 3.9.15 in June 2026 and 3.9.16 in August 2026, both labelled “Security Release Joomla 3”.

Balbooa reversed under pressure from its own users, moving from “no future version will be compatible” in April 2025 to publishing and hosting a Joomla 3 compatibility patch in July 2026, credited to a community member.

YOOtheme said nothing at all for twenty-nine months while shipping Joomla 3 fixes in 4.3.7, 4.4.11, 4.4.12 and 4.5.3, and still contradicts itself: ZOO, the same company, currently advertises “Requirements: Joomla 3.x+”.

And OS Property announces “Discontinued Joomla 3 Support” on a page whose own specification box, directly above the announcement, reads “Compatible: Joomla 3.9.0+”.

The ones that said nothing at all

This list matters as much as the table, because a vendor with no statement is the common case rather than the exception. We checked and found nothing public from HikaShop, RSJoomla, StackIdeas, iJoomla, JomSocial, EShop, Phoca, JoomUnited, Falang, OSTraining, JoomlArt, Gavick, Ordasoft, ARI Soft and TemplateMonster. Several of them are still shipping Joomla 3 builds. None of them will tell you when that stops.

Three did not stop so much as vanish. MijoShop’s domain now serves a Thai football and casino blog, and the Wayback Machine shows it had already become that by November 2023, three months after Joomla 3 went end of life. VinaGecko’s domain redirects to a betting site. Xmap’s repository was archived with its last commit in September 2020.

That is the real answer to “is this extension still supported”. For fifteen of the vendors on the sites we monitor, there is no answer to look up, and for three of them the company that would have answered no longer exists.

Your host is about to decide just how long you have left for Joomla 3, and it is out of your hands

Here is the part that turns a deferred decision into an emergency, and it has nothing to do with Joomla.

Joomla 3 needs an old PHP branch. Hosting providers are removing those branches, on their schedule, and they are not asking. When your host drops PHP 7, a Joomla 3 site that has not been made PHP 8 compatible does not degrade gracefully. It stops.

Worse, on some hosts the change is a one-way door. Fasthosts is the example I keep running into: a customer switches a site to PHP 8 to see whether it works, discovers it does not, and then finds there is no route back to PHP 7. The test is the migration, and it is irreversible. So the sensible, cautious thing an administrator does, which is to try it and see, is the exact action that takes the site down with no undo.

That reframes everything above. Your real choice is between migrating on a date you pick, with a staging site and a rollback plan and a budget conversation you had in advance, and migrating on the date your hosting provider picks, at whatever hour they picked it, with the client on the phone. Migrating later was never one of the options.

And I want to be careful about who the villain is here, because it is not the host.

A host that removes PHP 7 is doing its job. PHP 7 left security support years ago. A host still serving it in 2026 is running an unpatched language runtime underneath every customer on that box, including the ones who did everything right and are simply sharing a server with you. That is not a favour to anybody.

So if your host is not forcing PHP upgrades, do not read that as generosity. It is neglect, and it is a reason to leave rather than a reason to stay. A webhost still handing out PHP 5 or PHP 7 in 2026 is telling you exactly how much attention the rest of that platform gets. The hosts causing you grief in this story are the good ones.

The PHP version each site runs is not a technical detail buried in a control panel. Across a portfolio of Joomla 3 sites it is a countdown timer that somebody else is holding, and you want it held by somebody who winds it.

Why the sites are still there, honestly

It is worth saying that this is rarely neglect, because the standard telling of this story insults the people living it.

A Joomla 3 to Joomla 5 or 6 move is closer to a rebuild than a version bump. The template usually has no direct successor. Two or three extensions the site depends on were abandoned years ago and the functionality has to be rebuilt or replaced. No one can quote it accurately upfront, which is why we will not quote a fixed fee for one either.

So it becomes a cost conversation the client has to agree to. And every agency owner reading this already knows how that goes, because from where the client is sitting, the site works. It loads. The contact form arrives. The phone rings. You are asking for four or five figures to deliver something that, on the day it completes, looks exactly the same as it did the day before.

That is a hard sell. I am not going to pretend otherwise.

But notice what has actually gone wrong, because it did not go wrong in that conversation. It went wrong years earlier.

The Real Reason Agencies Avoid Joomla Updates

We posted the numbers above to social media, and a comment underneath it is worth answering properly rather than in a reply box, because it names the reason most agencies actually give for staying on an old version.

Juan Pablo Combeau M., on Facebook

“I agree with everything, I would only add that Joomla updates have a reputation for causing many incompatibilities (well-deserved, in my opinion), and that’s why users tend to avoid them.”

That is a fair description of what agencies experience, and not a rare one either, I hear a version of it constantly. But the word doing the damage is “updates”. The incompatibilities are real. The cause is usually not the update itself.

Joomla is not good at communicating breaking changes in enough detail, and it does not reliably honour its own deprecation notices: the core team has pushed deprecation deadlines back after the fact more than once, and the backward-compatibility guarantees fall well short of what a project like Symfony offers over a comparable timeframe. Extension developers are, on the whole, not much better at tracking the breaking changes that do get published. Plenty of them find out by reading the core source rather than a changelog, and some of the consequences they hit were never fully thought through or tested by the Joomla project in the first place.

So the incompatibility is real, but “the update broke it” undersells what happened. A change shipped with too little warning, on a promise that did not hold, and the extension author had no reliable way to see it coming even while looking for it. That is less a reason to distrust updating and more a reason to distrust how the ecosystem tells you what is about to change: read the actual diffs before a major version, do not trust a changelog to be complete, and budget time for the surprises rather than assume there will not be any.

Software is a child, not a purchase

Most of those 30,305 sites were sold as a project. A price, a launch date, a handover, an invoice. Maybe a support period measured in weeks. And then nothing, until the day something breaks or a version goes end of life and somebody has to ring the client and ask for money to fix a problem the client did not know they had.

Of course they say no. From their side you sold them a finished thing and now you are asking them to pay for it again.

The framing is wrong, and it has been wrong across our whole industry for twenty years. A website is a purchase that never completes, always a work in progress. It is much closer to having a child.

A website is a purchase that never completes. Always a work in progress.

It is much closer to having a child. Enormous investment at the start, a steady cost that never stops, predictable spikes at known milestones, and the occasional emergency that has to be paid immediately.

The investment at the start is enormous and everybody expects it. Then there is a long steady cost that never stops: feeding it, clothing it, keeping it warm. There are predictable spikes at known milestones, when it starts school, when it goes to university, when it needs help with a first house. And there are the emergencies, the ones that arrive without warning and have to be paid immediately, because the alternative is unthinkable.

No one has a child and considers the job finished at the birth. No one budgets for a single payment and is then outraged when the child needs shoes at seven and a laptop at fourteen. And crucially, the investment does not stop when they leave home. It changes shape and it usually gets less frequent, but a parent who says “I paid for the pram, we are done” is describing an abandonment, not a completed project.

That is what a Joomla 3 site is. It is a fourteen-year-old that no one has bought shoes for since it was three.

The client who “would not invest” was, in most cases, never actually asked to. They were sold a pram.

Why we have never sold a lifetime licence

I should declare an interest here, because this argument is the reason mySites.guru is priced the way it is, and I would rather say that out loud than let you find it in the pricing page and wonder.

We have never offered a lifetime deal. Not once in fourteen years of trading, and we get asked for one regularly.

A lifetime licence is a promise to maintain something forever, in exchange for a single payment, made once, at the moment the customer’s enthusiasm peaks and your costs have not started yet. It is the model I have spent this whole post arguing against. It is the pram, sold as the childhood. Every lifetime deal in this industry either ends with the vendor stopping the work, or with the vendor going out of business, and in both cases the customer discovers the meaning of the word lifetime rather late.

We take a subscription because the work never stops. Somebody has to read the Joomla Security Centre the morning it publishes. Somebody has to write the detection rule, test it against real sites, and ship it. That is a daily cost, so it is funded by a daily-cost model.

Here is the whole price list. mySites.guru is GBP 19.99 a month, or GBP 199.99 a year, which is about 16.6% off, so paying annually is roughly two months free. That is for unlimited sites. If you have one site, there is a GBP 5.00 single-site plan.

Single site

GBP 5.00/month

One site, everything included.

Unlimited, monthly

GBP 19.99/month

Unlimited sites. One site or thousands, same fee.

Unlimited, annual

GBP 199.99/year

About 16.6% off, roughly two months free.

See the full pricing Unchanged since the price was set in 2010.

Unlimited means unlimited. We have subscribers with one site and subscribers with thousands, and they pay the same flat fee. No one gets punished for growing.

We set that price in 2010, while we were building towards launching in 2012. In the sixteen years since, there has been not one price increase. Not a single one. Not an inflation adjustment, not a tier restructure, not a quiet grandfathering of old customers onto worse terms.

That is over a period which included near-record inflation, and during which our own costs have roughly quadrupled. Recently the AI boom has pushed hardware prices up again, which we absorbed too.

I am not claiming that is good business practice. It is arguably terrible business practice. But it is the same principle running in the other direction: if I am going to tell you that a website is a living thing with a running cost, I should be willing to absorb a running cost of my own rather than repricing every time it pinches.

For context, I personally spend more on coffee in a month than a mySites.guru subscription costs. Our customers stay, on average, three to five years, which is roughly the interval between major CMS migrations. The two numbers match because that is what a retainer looks like when the thing being retained is alive.

So when I say sell the running cost, I am not asking you to do something I have avoided doing myself.

What to say instead

In practice that means writing a different first proposal. No one ever fixed this with a better closing technique.

Price the build and the running cost as one proposition, not a build with an optional extra bolted on at the end. A maintenance line that appears after the client has mentally signed off the project reads as an upsell, and it gets cut. A running cost that was in the first conversation reads as the cost of the thing.

Say what the money buys in terms of the thing they own, not in terms of your tasks. “Core and extension updates applied and tested monthly” is a description of your afternoon. “Your site stays on a version that still receives security patches” is a description of their asset.

And be specific about the milestone spikes, in advance. Every CMS has a major version transition every few years, and it will cost real money. A client told at the start that there is a significant project roughly every three or four years is a client who can plan for it. A client told about it for the first time when the version has already gone end of life is a client who feels ambushed, and reasonably so.

If you want the argument in one line: you are selling the running cost of something alive, not insurance against something going wrong.

How mySites.guru helps support you, to support your Joomla 3 end of life sites

None of the above helps the sites you already have on the books, so here is what we actually do for them. It is a holding position rather than a fix, and I would rather say that than sell it as something it is not.

One-click Joomla 3.10.999 core patches

We apply the community core patches across your whole portfolio of Joomla sites, with no eLTS licence needed. The one-click Joomla 3 patch tool replaces 65 core files and picked up four more CVEs over summer 2026, including an unrestricted SHTML upload and a com_contact access control flaw. Of the 13,341 Joomla 3 sites where we can currently read the core files, 10,512 have unpatched ones we could fix. That is 79% of the sites that could be safer today and are not, which is the single most fixable number in this entire post.

JoomShaper’s own Joomla 3 packages, deployed and revertible

We deploy them for Helix Ultimate, Helix3 and SP Page Builder, installed through Joomla’s native installer so the vendor’s own version gates run, which is the check that finds them, with a revert if you need it. That matters more than it sounds, because JoomShaper reused the same version string across two different patch releases, so no inventory tool can tell a patched site from an unpatched one by version number alone.

Every published core CVE, flagged per site

We flag each one against the site’s exact version, on the sites list and on the site itself, so an end-of-life core stops being an abstract worry and becomes a count you can show a client.

Every Joomla version tracked back to 1.5

That reach is intended. We support old versions so you can see and move them, not so you can leave them sitting there.

You can point the Joomla 3 end of life check at your portfolio of Joomla sites and have the list in a few minutes.

The uncomfortable part

The data in this post came from our own customers’ sites. These are, by definition, agencies and site owners who care enough to connect their sites to a monitoring platform and pay for it every month. This is the diligent end of the market.

And the diligent end of the market is running 30,305 end-of-life Joomla 3 sites, 20,671 of which are not even on the final release, with 22,195 known-vulnerable extensions between them.

Now scale that up. Joomla runs on millions of sites. Almost none of them are connected to anything like this. No one inventories their extensions, no one tells their owner when a component goes critical, and no one counts them when a number like 4.90% gets published. Whatever the real figure is out there, it is not better than the one measured on sites that are actively being looked after. It cannot be.

So, back to the question. You can bury your head in the sand, and plenty of people reading this will, because the alternative is a difficult conversation with a client who does not want to have it. That cost is real, and I am not going to wave it away.

We even built you the switches.

Those two badge toggles went in this week, and I mean them. If you already know a site is on Joomla 3, and the pills are just noise on a screen you look at forty times a day, turn them off. No one needs to be shouted at by their own dashboard.

Read the help text underneath them, though, because we wrote it carefully. Cosmetic only. The sites are still checked against published advisories, the has-core-vulnerabilities and has-vulnerable-plugins filters still find them, the left-menu counter still counts, and the alert emails still go out. Hiding the badge changes what you see, not what is true.

Which is the whole post in one settings page. You can turn off the warning. You cannot turn off the CVE.

Just be clear about what you are choosing. You are not deferring a technical task. You are holding a liability on someone else’s behalf, for free, until it goes off. And on current numbers it goes off about five times more often than it needs to.

Timeline

2023-08 Joomla 3 reaches end of life The final 3.10 release. From this point the Joomla project ships no free security patches for the 3.x core, regardless of severity.
2025-02-17 The paid eLTS programme ends The Extended Long Term Security Support programme, which had patched Joomla 3 for a fee, stops. From here there is no official route to a patched Joomla 3 core at any price.
2026-07-09 JoomShaper ends Joomla 3 support One line does the damage: no security patches, regardless of severity, across SP Page Builder, Helix, EasyStore and the template range. A large slice of the Joomla 3 estate loses its vendor.
2026-07-15 JoomShaper ships Joomla 3 patches anyway, six days later Free standalone security packages for Helix Ultimate, Helix3 and SP Page Builder. The stated policy lasted under a week, which tells you how bad the alternative looked.
2026-08-28 30,305 live Joomla 3 sites, and Joomla 4 is worse From our own portfolio of Joomla sites: Joomla 3 sites are hacked at five times the Joomla 6 rate, and the Joomla 4 sites that agencies migrated to now have the worst vulnerable-extension rate on the estate.

Impostor Files: How to find every file in a core folder that core never shipped

phil@mysites.guru (Phil Taylor) — Fri, 28 Aug 2026 00:00:00 GMT

Introducing a new mySites.guru audit feature: Impostor Files Check

Impostor Files is a new check in the mySites.guru audit, listed as Check Core Folders For Impostor Files.

It reports every file sitting in a folder the CMS itself owns that the CMS never shipped. Only the folders core is responsible for, rather than every non-core file on your site.

A backdoor that avoids detection is one that looks like it belongs. No one plants hacked.php in the web root any more. They plant session.php among the libraries, or a second index.php in a folder that already holds forty of them, nineteen levels down in a directory no one has opened since the site was built.

Grep is no help, because the file looks like everything around it, and a signature scan only helps once somebody has seen that dropper before.

There is one thing the attacker cannot fake. Every release of Joomla and WordPress ships a known, fixed set of files. Joomla 5.4.7 puts exactly one file directly in /administrator/, and that file is index.php. Anything else sitting there arrived some other way, and that is the whole check.

The old check returns 13,653 files on a median site

We already had a check for this, sort of. Check Files That Are Not Core Files reports every file anywhere on your site that is not part of the CMS distribution, using the same hashing pass the rest of the audit runs on. It works exactly as designed, and almost no one can use it.

On 2026-08-27 we took the most recent completed audit of every site with a snapshot in the last thirty days and looked at what that check returns.

Result	Sites
More than 1,000 non-core files	99.8%
More than 10,000 non-core files	68.3%
More than 50,000 non-core files	5.9%

The median site returns 13,653 files. The mean is higher still at 21,095, because the tail runs a long way: the ninety-ninth percentile is 135,192 and one site returns over 1.5 million.

Nothing is broken. Every extension, plugin, theme and template you install adds files, and none of them are core files, so the count grows with ordinary use. The problem is that the answer looks identical on a clean site and on a hacked one. A list of thirteen thousand filenames is a haystack, and a webshell in /wp-includes/ sits somewhere in the middle of it looking like everything else.

Here are both checks on the same site, one row above the other:

The site in that screenshot is a purposely hacked test install of Phil’s, so treat the numbers as a demonstration rather than a typical result. The shape is the point. The old check hands you 52,746 rows to read. The new one hands you 554, and tells you that 19 of them are executables.

Joomla ships one file in /administrator/, and it is index.php

Core is a tightly specified layout, and the numbers show how tight.

Joomla 5.4.7 ships 10,095 files across 2,877 folders. Of those folders, 1,589 hold exactly one file, and 2,259 of them hold three or fewer. WordPress 6.8.2 ships 3,230 files across 325 folders. Every other release is just as fixed: Joomla 4.4.13 is 9,576 files, Joomla 3.9.23 is 6,410, Joomla 6.1.3 is 9,916 across 2,900 folders.

The one-file rule is not a quirk of a single release, either. Joomla 6.1.3, the current version, also ships exactly one file directly in /administrator/, and it is still index.php.

More than half of Joomla’s core folders contain a single file. That is the whole idea behind the check. If a folder is meant to hold one file and it holds two, the second one is worth thirty seconds of your attention, and there is no version of “normal use” that put it there.

So Impostor Files asks a much narrower question than the old check. A file qualifies when its folder appears in the official release and the file does not. /administrator/ is a core folder, so a second file in it is reported. /administrator/components/com_yourextension/ is not a core folder, so nothing in it is reported and your extensions stay out of the way.

Spot the impostor in /libraries/src/Session/

/administrator/ is the easy example, because one file is small enough to hold in your head. The check works identically nineteen levels down, in the folders where you have no idea what is supposed to be there.

So here is a game. Below is /libraries/src/Session/ on a Joomla 5 site. Eight entries. Joomla ships seven of them.

Take thirty seconds. Every name is plausible, the file sizes are unremarkable, and every PHP file in that folder shares one modification time, so sorting by date tells you nothing at all.

Show me the answer

It is SessionManagerInterface.php.

Joomla 5.4.7 ships Session.php, MetadataManager.php, SessionFactory.php and SessionManager.php into that folder, plus the Storage, EventListener and Exception subfolders. It ships no interface beside SessionManager.php, and it never has. SessionManagerInterface.php appears in no Joomla manifest, not in 5.4.7 and not in the current 6.1.3.

Which is a horrible thing to have to know. A PHP codebase full of SomethingInterface.php files makes one more look like housekeeping, and this one is 1.7 KB, exactly the size of the real SessionManager.php sitting directly above it, with the same modification time as every other file in the folder. There is nothing to notice.

Nothing except the release manifest, which says Joomla put seven things there and something else put the eighth. That is the entire check.

For the record, that one is planted. It is a file on a test site we control, written to be as convincing as we could make it, because a screenshot of a real customer’s backdoor is not ours to publish.

How does mySites.guru know what Joomla or WordPress actually shipped?

We hold the file list for the exact version your site is running, generated from the official release package. Every path, with its hash:

administrator/index.php                          8f1c...
administrator/cache/index.html                   8ca096fda23d564fe62bc65ef5f498e0
administrator/components/com_actionlogs/config.xml   0ea0080554fbea75f60151a5d67f27b4
libraries/loader.php                             b96deb0e0d737e2a6a14082f6274e387

That list is what the audit already compares your files against to spot modified core files. Impostor Files reuses it from the other direction: instead of asking which core files changed, it asks which files are in core’s folders without being in core’s list.

This is manifest-driven, never a hardcoded list of folder names. Between Joomla 5.4.7 and 6.0.1, 61 core folders disappear and 50 new ones appear. A static list written against Joomla 5 would flag legitimate Joomla 6 files and miss real ones. Your site’s own version manifest is always right for your site.

It also costs nothing extra to run. The audit has already walked your webspace, hashed every file and imported the release list. The check is a database question over work that has already happened, so it does not add a second scan or another few minutes to your audit.

Note

Files at the very top of your site are included, not skipped. Joomla 5.4.7 ships six files in the web root, so a seventh one there is reported the same as one buried nineteen levels down.

The executables list is the thing to read, not the executables count

You get two counts back, and they are not two versions of the same answer.

The Executables Count Is the Sharper of the Two

It counts program files only: .php, .phtml, .php3 through .php8, .phar, .inc, .pht and .phps. The match is case-insensitive, because .pHp5 and .PHTML are exactly the sort of thing a dropper uses to slip past a case-sensitive filter.

What it is not is a number that reads zero on a healthy site. This post said it was when it first went up, and that was wrong. Once the check had run everywhere, the lowest count on any connected site was one, on both platforms. A Joomla site most commonly shows six to nine and averages just under nine. A WordPress site averages between four and five. That is not because everybody is hacked; it is because Joomla and WordPress both write files into folders they own.

The count therefore tells you how much reading you have to do. Only the list tells you whether you have a problem.

The Total Is Noisy on Purpose

It averages 332 files on a Joomla site and 23 on a WordPress one, with a worst case in the thousands. Almost all of it is ordinary:

What it is	Why it is in a core folder
Your own uploads under `/images/`	Joomla ships `/images/banners/`, so `/images/` is core’s
Extension language files under `/administrator/language/`	Core owns the folder, your extensions write into it
Leftover `index.html` guards from older Joomla versions	Shipped by a version you have since upgraded past
Extension and vendor assets under `/media/`	Same as `/images/`, core ships into it
`.DS_Store`	Uploaded by somebody’s Mac

/images/ and /media/ are core folders, which is why their contents appear at all. Joomla ships /images/banners/ with sample banners in it, so every photo you have uploaded since sits in a folder core owns.

The three you will almost certainly see, and why each one is fine

In the week the check shipped, a customer switched on Executables only, expected an empty list because that is what we had told them to expect, and got three files. All three were legitimate, and between them they explain most of what any Joomla site shows here.

`/administrator/cache/autoload_psr4.php`

Written by Joomla itself. It is a caching autoloader, created on page load if it is missing and rebuilt whenever you install or update an extension. Joomla 5.4 ships exactly one file into /administrator/cache/, and that file is index.html, so the folder belongs to core and this file does not.

`/administrator/components/com_joomlaupdate/restore_finalisation.php`

Left behind by an upgrade. Joomla shipped it in 3.x and in every 4.x release up to and including 4.4, then dropped it in 5.0 in favour of finalisation.php. Joomla’s updater does not delete it, so it sits on disk being no part of the version you are actually running. You can see the files that should be in that folder in the Joomla repository. Of the three, this is the one to actually open. A filename that core used to ship, in a folder core owns, is an attractive thing for somebody to overwrite, and no one would look twice at it.

`/configuration.php`

Has never been a core file in any version. The release package contains configuration.php-dist, and the Joomla installer writes your configuration.php from it during setup. Every Joomla site therefore has a file in its web root that core never shipped, and the check reports it every time, correctly.

None of the three is a finding. They are the check doing the job described at the top of this post: comparing your disk against what the official release contains, and being honest when the two differ. A file Joomla writes at runtime, a file an older Joomla shipped, and a file the installer created are all, in fact, not core files.

The filters deal with two of them. Hide cache and logs covers /administrator/cache/, and Hide config file covers configuration.php by exact path. Nothing hides restore_finalisation.php, so it is still there even under the Quiet view preset, which is the correct behaviour for a file that used to be core and no longer is.

Nothing is hidden at source, because a dropper can sit in /images/ too

The obvious way to make the total useful is to exclude /images/ at source. We do not, because that hides real findings along with the noise. Attackers put PHP files in image folders constantly. It is one of the oldest tricks there is, and a check that will not look there without telling you is worse than one that shows you too much.

So the filtering happens in the view, and you control it. Toggles are provided for images, language files, media, manifests, index.html guards, dot files, SQL update scripts, cache and logs, and the site configuration file. There is an Executables only toggle, a Quiet view preset that switches on everything ordinary in one click while still showing executables, and a Show everything button to put it back.

Every filter defaults to off. The first view you get shows you everything, and hiding is your decision rather than ours. The filters are applied on your site in the query itself rather than on the page afterwards, so the count at the top always describes the same set of rows you are looking at.

That is the same hacked test site with Quiet view switched on. Nine toggles take it from 554 rows down to ten, and now look at what is left.

Joomla has an /administrator/includes/ folder, an /api/includes/ folder and an /includes/ folder. It ships no includes.php file next to any of them. All three are in that list. Someone picked a filename that reads as the folder beside it, three times, and on a directory listing it slides straight past you.

/libraries/src/Document/PdfDocument.php is the same move done more carefully. That folder holds 33 core classes and most of them are named SomethingDocument.php. A thirty-fourth one looks like it belongs, right up until you check it against the release and find Joomla never shipped it.

Not everything left is sinister. /robots.txt is there because Joomla ships robots.txt.dist and expects you to rename it, so your own copy is a file core never shipped and the check reports it honestly. That is the trade for not hiding things at source.

Each row exports to CSV if you would rather work through the list somewhere else. Files already matched by the other checks keep their badges here too, so a file the audit has independently called out as hacked is labelled as such in this list rather than looking like one more unexplained row.

Why does the list include my own .htaccess?

Because you put it there, and we would rather show it to you than guess.

Without the executables restriction, /administrator/ flags on every site we measured. On all thirteen it was .DS_Store, uploaded by somebody’s Mac. On three of them it was .htaccess and .htpasswd, which is Admin Tools password-protecting the administrator folder. That is a hardening measure we actively recommend, and it produces two files core never shipped, in a folder core owns.

Which is why Impostor Files does not set the hacked flag and does not send you an email. It reports. It never accuses. A check that shouts about your own hardening is a check you will switch off, and then it protects nothing.

WordPress gets a stronger rule than Joomla

WordPress earns a wider rule, because its core folders are stricter about who writes into them.

Core WordPress 6.8.2 ships 93 files directly in /wp-admin/ and 572 across that whole tree, plus 244 directly in /wp-includes/ and 2,210 beneath it. WordPress 7.1 is bigger at 593 and 2,729, and just as exactly specified. Plugins do not write into either tree. Themes do not write into either tree. Core owns both, so we check them recursively: any file under /wp-admin/ or /wp-includes/ that core did not ship is reported, however deep it sits and whatever folder it is in.

That matters because it catches a shell in a directory the attacker created themselves. A backdoor written into /wp-includes/ is a well worn move and one of the first things to check if you think a WordPress site is hacked, because it is the last place an owner thinks to look and it is still there after a theme or plugin is replaced. On Joomla a folder like that is out of scope, for the reason set out below. On WordPress there is nowhere under those two trees to sit that we are not already looking.

Two things get conflated here. The AccessPress backdoor wrote its webshell into wp-includes/vars.php, a file WordPress ships, which makes it a modified core file rather than an impostor one. The audit’s core file integrity check is what catches that, by hash, and reverts it to the original in one click. Impostor Files answers the other half of the question: which files are sitting in core’s folders without being core’s.

WP-CLI already does part of this, on one site, over SSH

Credit where it is due. wp core verify-checksums diffs your on-disk files against the WordPress.org checksums manifest and reports File should not exist for anything extra in wp-admin/, wp-includes/ or the web root. If you have shell access to a WordPress site, that command answers a good chunk of this question today and has done for years.

wp core verify-checksums
Warning: File should not exist: wp-includes/class-wp-cache-init.php

We built this anyway, for three reasons.

It covers Joomla, which has no equivalent. WordPress.org publishes a checksums API; the Joomla project publishes no per-file manifest at all, which is why we generate ours from the release packages ourselves. On Joomla there is no command to point you at.

It runs remotely, across every site at once, with no SSH access, no WP-CLI installed and nothing to run by hand. That is the difference between a command you could run on a site you are already worried about and an answer that arrives for all of your sites on every audit, including the ones you were not worried about. Backdoors are found on the sites no one was thinking about.

And it produces something you can work through. A shell command gives you a wall of text. The check gives you the file list with sizes and modification times, filters to cut the ordinary out of it, and a CSV export.

What this check cannot see on Joomla

We would rather tell you the limits of a check than let you assume it covers more than it does.

On Joomla, this check cannot go recursive. /administrator/components/ is where your extensions legitimately live, so flagging everything under /administrator/ would flag every component you have ever installed and the check would be as useless as the one it replaces.

Which means: on Joomla, a file at /administrator/private/shell.php is not reported by this check, because /administrator/private/ is not a folder core ships into, so it is not a folder we consider ours to police. A file dropped straight into /administrator/ is caught. A file dropped into a folder the attacker made is not.

One tool with one job will never show you everything

That file is not invisible. It is invisible to this check, which is a different thing, and it is the reason the audit runs more than two dozen separate file and folder checks rather than one clever one.

Impostor Files asks a single narrow question: is this file in a folder core owns, when core never shipped it? Ask a narrow question and you get a short answer, which is the entire point. But a narrow question also has a wrong side, and /administrator/private/shell.php is on it.

So other checks ask other questions about the same file:

Check Files That Are Not Core Files lists it, because it lists everything that is not core, anywhere. That is the noisy 13,653-row check from the top of this post, and this is the trade it exists for: it sees the file that Impostor Files cannot, and it buries the answer among thousands of rows. Neither check replaces the other, and running both is the only reason you get the file and a list short enough to read.
Check Suspect Patterns Matched Content In Files reads what is inside it, against roughly 1,500 patterns. It does not care where the file sits.
Hacked Files (100% Certain) matches its hash against confirmed hacked files, so a known shell is named as one wherever somebody put it. Which of those two to believe, and in what order, is its own subject.
Check Files That Can Attempt To Upload Files and Check Files That Can Send An Email (or Mass Emails!) find it by what it is able to do, which is how you catch a dropper and a spam relay that are not in any pattern list yet.
Files Modified Between Audits catches it the moment it appears, under any name, in any folder, which is how you spot a site being re-hacked days after you cleaned it.
PHP Files Should Not Be In These Certain Folders finds PHP under /images/, where PHP has no business being.
Locate And Review Double Extension Files finds name.php.xxx, and Review Renamed Files finds the .old, .bak and .orig copies people leave behind.
Locate And Review Hidden Files and Paths With Hidden Folders In Them find dot-prefixed files and folders: the .tools and .bak directories a listing does not show you by default.
Identify Missing Core Joomla Files covers the opposite failure, where something core shipped is no longer there.

None of those is the whole answer either. /administrator/private/shell.php is found by several of them and missed by this one, and a differently shaped backdoor flips which is which. That is how the audit is built: many narrow checks, each with a job it does exactly, rather than one tool claiming to see everything and seeing less.

No manifest means no answer, not a clean bill of health

If we could not download the file list for your CMS version, Impostor Files shows no result at all, rather than a zero or a green tick.

A zero says we looked and found nothing. That is a specific claim, and it would be a lie in the one situation where you most need us to be straight with you. The core file list is emptied and re-imported at the start of every audit, so a failed download leaves the check with nothing to compare against rather than an answer from a fortnight ago. The status shows as no data, and the reason is on the page.

The same applies to sites running a connector that predates the check. No data is not a passing grade, and we do not display it as one.

Where do I find Impostor Files?

It is in the Hacked ? section of each site’s audit, listed as Check Core Folders For Impostor Files on Joomla and Check Core WordPress Folders For Impostor Files on WordPress. Press Cmd+K and type part of the name to jump straight there.

To answer it across everything at once rather than site by site, the all-sites view for the check is at manage.mysites.guru/en/tools/allsites/joomla/hacked/foreigncorefolderfiles, which lists every connected Joomla site with its executables count beside it. Change joomla to wordpress in that address for the WordPress equivalent. Sort by the executables column and the sites worth your morning are at the top.

The check is Joomla and WordPress only. A generic site has no CMS, so there is no official release to compare against and nothing that can honestly be called a core folder. So the check does not appear on those sites at all, rather than sitting there reporting nothing forever.

Why this one took a while

“

This has been on my own wish list for years and I am pleased I finally had the month to build it. Earlier in this post I called the old check a haystack. This is another magnifying glass for finding the needle in it, and it is the one I have wanted for a very long time.

Phil Taylorwho built it

Check one site right now

The check runs on the next audit, with no setting to enable and nothing to configure.

Connect a site

Not a subscriber? Run a free audit and see what is sitting in your core folders.

Open the executables list and read it. Most of what is on it will be Joomla’s own work, an older version’s leftovers, or a file the installer wrote, and you should expect a handful rather than none. The day something appears on that list that you cannot account for is the day you want to have been looking. When that happens, work through the triage order for a hacked Joomla site or a hacked WordPress site rather than deleting things at random. Connect your sites to mySites.guru and it runs on the next audit.

What Site Audits Reveal About Joomla and WordPress Security

phil@mysites.guru (Phil Taylor) — Fri, 28 Aug 2026 00:00:00 GMT

Every mySites.guru audit runs the same set of checks against every connected site, and every check gets its own column in the database. That means we can say, with real numbers rather than a guess, exactly what fraction of live Joomla and WordPress sites pass or fail any given check. We don’t know of anyone else who can say this. Most security advice for Joomla and WordPress is written from what should be true, not from what actually is.

The numbers below are drawn from each site’s most recent audit within a 90-day window, across the sites we audit. They are not a scolding. They are closer to a map of which security features are optional and which are not, and it turns out that distinction predicts the result better than anything about the platform itself.

The gap between available and enforced

Joomla has supported forced Multi-Factor Authentication on Super User accounts for years. It takes one setting to switch on, and once it’s on, every Super User has to complete MFA to log in. 99.0% of the Joomla sites we audit don’t force it. Not “don’t have MFA available” - don’t force it, on the single account type capable of doing the most damage to the site. This one has an unusual excuse behind it, which we only pinned down later: until Joomla 6.1 the Super Users group could not be selected in that field at all.

WordPress has had DISALLOW_FILE_MODS since version 2.6. Set that one constant in wp-config.php and the entire file editor and plugin/theme installer inside wp-admin switches off, which closes one of the most common paths an attacker uses once they’ve got a foothold: editing a theme file directly through the admin panel. 91.8% of WordPress sites we audit don’t set it. Its narrower sibling, DISALLOW_FILE_EDIT, which only blocks the file editor and leaves plugin installation alone, fares a little better but is still unset on 60.6% of sites.

That’s the pattern across almost every check on this list. When a security feature is optional, adoption sits somewhere between “rare” and “nearly no one,” regardless of how long it’s existed or how well documented it is. No one wakes up and decides to leave MFA off for their Joomla Super User. They just never see the setting, because nothing on the site ever asks them to.

Headers no one sends because no one has to

Security headers are a cleaner version of the same story, because setting them is entirely within the site owner’s control and requires no plugin, no extension, and no code change beyond a handful of server or .htaccess lines. 94.9% of the sites we audit, of either platform, have no Content-Security-Policy header - the header that tells a browser which scripts, styles and frames a page is actually allowed to load, and the single most effective defence against a compromised third-party script running freely on your site.

72.0% of Joomla sites have no Strict-Transport-Security header, so a browser that’s never visited the site before has no instruction to go straight to HTTPS and will happily follow an HTTP link if one exists anywhere. X-Frame-Options is missing on 50.4% of Joomla sites, and X-Content-Type-Options on 32.4% - both one-line headers, both widely recommended for a decade, both configured on a minority of sites we see. None of these require the site owner to understand cryptography or read an RFC. They require someone to add a line to a config file once, and most people never do, because nothing breaks visibly when the header is missing.

The spread: what’s everywhere and what’s vanishingly rare

The interesting comparison isn’t any single number, it’s the range. Some failures sit close to universal. Others sit close to zero, and the reason for that gap is worth sitting with.

On the Joomla side, 60.3% of sites still have the Guided Tours plugin enabled in production, long after anyone needed the onboarding walkthrough it provides. 24.0% still email passwords in plain text rather than a reset link, and 9.0% have user registration enabled on sites that don’t need public signups. These are all things a site owner would probably switch off if they ever looked, and most never look.

Compare that with the checks near the bottom. 4.6% of Joomla sites still have FTP credentials sitting in Global Configuration, a legacy feature almost no one uses any more. 4.2% share sessions between the site and the administrator, which means a session cookie stolen on the front end can be replayed against the back end. 1.0% have debug mode on in production, leaking stack traces and file paths to anyone who requests a broken URL. 0.7% have SEF URLs turned off, which mostly hurts SEO rather than security but travels in the same neighbourhood of “settings no one revisits.” And at the very bottom, 0.1% of Joomla sites connect to the database as root - a database account with no restrictions at all, sitting behind the site’s own credentials.

That bottom group is rare for a reason. Running as root, or leaving debug mode on in production, tends to be visible enough, or catastrophic enough when it goes wrong, that someone eventually notices and fixes it. A missing security header or an unforced MFA setting breaks nothing that anyone can see, so it just persists. Rare failures here are the ones that get caught. Common failures are the ones that don’t announce themselves.

WordPress has the same shape, different specifics

WordPress shows the identical pattern with its own checks. 48.6% of WordPress sites still have XML-RPC enabled - it ships on by default, so this figure is less a measure of active choice and more a measure of how many sites have simply never had a reason to turn it off, despite it being a longstanding target for brute-force and amplification attacks.

At the opposite end, 3.4% of WordPress sites are accidentally blocking search engines via the “discourage search engines” setting left on from a staging environment or a migration. That’s not a security failure at all, it’s an availability one, but it belongs in the same list because it shares the same root cause: a setting flipped once, for a reason that made sense at the time, and never revisited. A further 1.5% of Joomla sites are blocking every crawler in robots.txt as well, which is a separate switch with the same effect.

What this means for a portfolio of sites

None of this is really about any one site owner being careless. Across every one of these checks, the sites that pass are overwhelmingly the ones where the setting is the default, is forced by the platform, or was switched on for a completely unrelated reason. The sites that fail are the ones where a human being would have had to go looking for a setting, understand what it does, and decide to change it, with no visible consequence for leaving it alone.

It also explains why the same handful of checks keep showing up across completely unrelated incidents. A shared session between the front end and the administrator, a Super User without forced MFA, a missing Content-Security-Policy header: none of these cause a hack on their own, but each one removes a barrier that would otherwise have slowed an attacker down or contained the damage once they were in. The sites that get hurt worst tend to be the ones where several of these optional settings were left off at once, not because any single one was the cause, but because nothing stood between the initial foothold and the rest of the site.

That’s the argument for treating these as things to check rather than things to remember. A checklist you run once at onboarding tells you what a site looked like on the day you looked. A check that runs against every connected site on every snapshot tells you the moment any of these regresses, whether that’s a header dropped during a server migration or a debug flag left on after a deploy. The full set of checks behind these figures, including the ones not covered here, is in the tools reference.

DPCalendar 10.12.0 fixes an SQL injection and an XSS

phil@mysites.guru (Phil Taylor) — Thu, 27 Aug 2026 00:00:00 GMT

Digital Peak released DPCalendar 10.12.0 today, with a security section that named two issues and gave no detail beyond a severity rating. So we did what we usually do and diffed the packages.

This is the second security release for this Joomla extension in six weeks. The first was ours: we reported an unauthenticated SQL injection in July, and Digital Peak fixed it in a day. This one is not ours. Both issues were reported by an independent researcher, Toan Le, and both need somebody logged in, which makes this a different kind of problem from July’s.

TL;DR

DPCalendar 10.12.0 fixes a blind SQL injection (vendor-rated High) and a stored cross-site scripting flaw (vendor-rated Medium). Both fixes are backported to 8.19.5 for the Joomla 3 branch
The SQL injection is reached by saving a Joomla article that contains a DPCalendar tag, so it needs article-edit permission. The XSS needs permission to create a DPCalendar location
Neither is reachable by an anonymous visitor. No one can walk in off the internet and trigger either one
No CVE has been assigned yet for either issue
The root cause of the SQL injection is worth understanding: the sort column was passed through the database escaping function, which protects values inside quotes and does nothing at all for a column name
Across the DPCalendar sites we can currently see, more than four in five are still on a version below this fix. More concerning, about one in six is still missing July’s fix, which closed a flaw an anonymous visitor could use

What Digital Peak fixed in DPCalendar 10.12.0

The vendor’s release announcement lists both issues by internal tracker number:

#12206, a blind SQL injection triggered by saving an article, needing update permission for articles, rated High
#12203, a location title rendered into a data attribute without escaping, leading to cross-site scripting, needing create permission in DPCalendar, rated Medium

Digital Peak also states that the site itself cannot be compromised through these, that files are safe, and that they have no information suggesting data was stolen, because the finder contacted them directly. We found nothing to contradict that: there is no public proof-of-concept, no exploit code, and no report of exploitation in the wild for either issue.

How the SQL injection works, and why escaping did not stop it

This one is a good teaching case, because the vulnerable code looks defended.

DPCalendar’s front-end events model builds a query and then adds a sort clause. Before 10.12.0, it took the sort column and direction out of the model’s state and passed each through the database escaping function on the way into the query.

That reads like protection. It is not, and the reason is worth spelling out, because the same misunderstanding shows up across a lot of PHP.

An escaping function exists to make a value safe once it sits inside quotes. It handles the characters that would let a value break out of its quoting. A sort column never sits inside quotes: it is an identifier, part of the grammar of the statement rather than data inside it. So the escaping ran, found nothing it was designed to change, and passed the text through into the query as instructions.

The fix in 10.12.0 checks the sort column against the model’s existing list of columns that actually exist, and the direction against a short list of permitted values, falling back to a safe default when either fails. That is the correct shape for this problem: an allowlist, not a filter.

Where the attacker-controlled value comes from

The part that turns this from a code smell into a vulnerability is how the sort value reaches the model.

The sort parameter that arrives in a normal web request was already validated against that same list of real columns, in both the vulnerable and the fixed version. We checked, because it changes the advice considerably. That path was never the problem.

The route that was open ran through the DPCalendar content plugin. That plugin reads DPCalendar tags inside Joomla article text and turns the options written in the tag into settings on the events model, including the sort column and direction, with no validation on the way through. So the attacker is not a passing visitor tampering with a URL. The attacker is somebody who can save an article.

That also explains the practical workaround. Because the request path was already safe and the plugin path was not, disabling the DPCalendar content plugin closes this specific route while leaving calendar menu items and modules working.

We are describing the mechanism at the level the vendor did and not publishing the tag syntax or a working payload, because most sites running this extension have not updated yet.

The cross-site scripting flaw in DPCalendar location titles

The second issue is simpler. DPCalendar renders a location’s title into an HTML attribute that its map JavaScript reads. In the versions before 10.12.0, several templates wrote that title into the attribute raw.

If a title contains the characters that end an attribute, it stops being text and becomes markup, which is the whole of cross-site scripting. It is stored rather than reflected, so the payload sits in the database and fires for whoever views the page afterwards.

The fix has two parts, which is the right way to do it. On the way in, the location title field now runs through Joomla’s configured text filter, so tags are stripped on save. On the way out, the templates escape the title before writing it into the attribute. Input filtering and output escaping solve different parts of the problem, and this release added both.

Creating a DPCalendar location is a permission, not something anonymous visitors can do, so this needs an account with location-create rights.

Which DPCalendar versions are affected?

Line	Affected	Fixed in
Current (Joomla 4.4.4 to 6.x)	Everything below 10.12.0	10.12.0
Joomla 3 branch	Everything below 8.19.5	8.19.5 (security fixes only)
9.x	All of it	No patch. Upgrade to 10.12.0

The vulnerable code sits in the component’s own front-end model and its location templates rather than in any edition-specific add-on, so this is not a Free-edition problem. If you run DPCalendar, you are on the list until you update.

The 9.x line is the awkward one, exactly as it was in July. There is no 9.x patch, and the route across is staged: 9.x to 10.0.0, then 10.6.0, then 10.12.0.

Who can actually exploit this?

This is the question that decides whether today is a busy afternoon or a routine update, and it depends entirely on your site.

On a brochure site where you are the only person who ever logs in, both of these are housekeeping. Patch on your normal schedule.

On a site with freelance writers, client staff who publish their own news, a membership tier that grants Author, or an old contractor account no one got round to deleting, the picture changes. The SQL injection is the difference between an account that can write a news post and an account that can read every user record and password hash in the database. Blind injection sounds like a limitation, and it is not much of one: a boolean oracle reads a database one character per request, and no one does that by hand.

So the useful exercise today is opening the user list on the sites that matter and asking who still has an account, and why, alongside patching.

What we see across the Joomla sites we manage

We record the installed version of every extension on every connected site, which lets us say something about how a release like this actually spreads, rather than guessing.

Looking only at sites that have reported in during the last 30 days, on the day of release:

More than four in five DPCalendar installs are on a version below 10.12.0 or 8.19.5. That is normal for release day, and it is why we email affected customers directly rather than waiting for people to notice a version badge change in the mySites.guru dashboard
About one in six had already taken the update within hours. Digital Peak’s update channel moves faster than most, which is a credit to them
Roughly one in five installs sit on the 8.x branch or older, meaning they run on Joomla 3. Joomla 3 reached end of life in August 2023, and even the paid extended support programme ended in February 2025. Digital Peak still ships security fixes for that branch, which is more than most vendors do, but the CMS underneath it has had no official security support for well over a year
There are 81 distinct DPCalendar versions in the wild across the sites we can see, and the oldest still running is a 4.x. That version predates every fix discussed here by years

We are not publishing site counts, because the size of the estate is not ours to hand out. The proportions are the useful part anyway.

The tail from July is the bigger problem

Here is the number that made us stop, and it has nothing to do with today’s release.

Six weeks after Digital Peak shipped July’s fix, and after we emailed every affected customer directly, about one in six of the DPCalendar installs we can see is still on a version below 10.11.2 or 8.19.4.

Those sites have a worse problem than the one this release fixes. July’s flaw was CVE-2026-57831, CVSS 4.0 8.7, and it needed no login at all. An anonymous request against a public events feed read the database. Today’s SQL injection at least requires an account with article rights.

If you are reading this and you have not touched DPCalendar since June, the version to worry about is not 10.12.0. Get to 10.11.2 or 8.19.4 first, because that is the one an attacker can reach without knocking.

Credit where it is due: a second fast fix

We were complimentary about Digital Peak in July, and nothing here changes that.

They shipped that fix inside 24 hours, over a holiday break, outside their normal release schedule. This time they fixed both issues in the scheduled monthly release, backported them to a branch supporting a CMS that has been end-of-life for three years, published a security section naming both issues and their severities, and credited the researcher by name with a link to his profile.

The one thing we would ask for is more detail in the announcement itself. “Security: High” with no description is what sent us to a package diff. Site owners deciding whether to interrupt their afternoon deserve to know that both issues need an authenticated user, and that fact was in the announcement only if you read to the security section rather than the changelog line.

For the record, Digital Peak has no published security policy page that we could find, and no security.txt. For a vendor that handles reports this well in practice, that is a gap worth closing.

One claim from July does not hold up

When Digital Peak fixed our July flaw, their advisory described it as the first security vulnerability reported in DPCalendar since the component first shipped in 2012. We repeated that at the time, because it was their statement to make. It is not accurate, and we would rather correct our own record than let it stand.

DPCalendar had a cross-site scripting vulnerability disclosed in February 2024, tracked as CVE-2024-21727 and assigned by the Joomla CNA, affecting versions 8.0.0 to 8.14.0. That is public record, and it predates July’s SQL injection by more than two years.

This is not a mark against the fixes, which have been fast and complete. It matters because “first since 2012” gets repeated, and an extension’s real security history is exactly what tells you whether to keep it patched and watched. DPCalendar now has at least four separate issues on the public record: the 2024 XSS, our July SQL injection, and the two Toan Le reported this week. That is a normal number for a large, actively used extension, and the useful takeaway is the opposite of reassuring folklore about a clean sheet: treat every extension as something that will need updating, because sooner or later it will.

Toan Le is auditing Joomla extensions at pace

The finder here is worth noting, because it fits a pattern we wrote about earlier this month.

Toan Le’s public work since June 2026 includes CVEs in JoomGallery (an IDOR with stored XSS, and a password-protected category bypass), J2Commerce (stored XSS through a cookie filter bypass), PhocaCart (an unauthenticated SQL injection scored 9.3, plus two stored and reflected XSS issues) and PhocaCommander (three path traversal flaws). That is a systematic sweep of widely installed Joomla extensions by one researcher, in the same window we have been running our own.

This is good news, and it has a practical consequence. The rate at which Joomla extension vulnerabilities are being found and disclosed has gone up sharply this year. The extensions have not suddenly got worse; more people are looking. If your update process assumes a couple of extension security releases a year, it is calibrated for a quieter era than the one we are in.

How do you update DPCalendar safely?

DPCalendar updates through Joomla’s own extension updater, so the mechanics are ordinary. The parts worth care:

Take a backup first, particularly on the 9.x line where you are doing a staged upgrade rather than a point release
Check your Joomla version supports the target. The 10.x line needs Joomla 4.4.4 or newer. If you are on Joomla 3, your target is 8.19.5, not 10.12.0
Update on a staging copy first if the site runs a heavily customised calendar. 10.12.0 is a feature release as well as a security one, adding article creation from events and tag display in list views
Check your template overrides. If you have overridden any of the DPCalendar location templates, your overrides still contain the unescaped output, and updating the extension will not fix a copy sitting in your template. This is the single most likely way to update and stay vulnerable
Enable automatic updates so the next one arrives without you doing anything. We wrote up how to turn on auto-updates for any Joomla extension

That fourth point is the one that catches people. Overrides are copies, and a security fix in a template never reaches a copy. Joomla records which overrides an update changed, and mySites.guru lists them across all your sites.

How do I find every DPCalendar site I manage?

If you run one site, open its extension manager and look.

If you look after thirty, that approach is how things get missed. Searching for the extension by name in the mySites.guru Extension Inventory lists every connected site running DPCalendar and the version each one reports, so you can sort by version and work down the list. Version tracking across every connected site is part of the mySites.guru subscription, along with alerts when an installed extension version matches a known vulnerability rule.

That is also how we built the numbers in this post, and how we knew who to email about it this afternoon.

What to do right now

Update to 10.12.0, or 8.19.5 if the site runs Joomla 3
Check you are past July’s fix first. If a site is below 10.11.2 or 8.19.4, it has an unauthenticated SQL injection open, which matters more than either issue in this release
If you cannot update today, disable the DPCalendar content plugin to close the SQL injection route, and treat that as a few days of breathing room rather than a fix
Check your template overrides for copies of the DPCalendar location templates
Look at who holds accounts on any site where people other than you can edit articles or create locations, since that is what both flaws require
If a site was on a vulnerable version for a long time and handles data you would not want read, review your Joomla database security and check for rogue admin accounts

Timeline

2026-07-12 mySites.guru reports an unauthenticated SQL injection in DPCalendar A different flaw from the two in this post: the public events feed took an author filter and placed it into the query without casting it to an integer, so an anonymous visitor could read any table. We disclosed it privately with all public detail withheld.
2026-07-13 Digital Peak ships 10.11.2 and 8.19.4 within 24 hours Built, tested and released over a holiday break, outside their normal fourth-Thursday schedule. The fix cast the author filter to an integer on every path.
2026-07-15 The Joomla CNA assigns CVE-2026-57831 CVSS 4.0 8.7 High, affected range 8.18.0 to 10.11.1, crediting Phil Taylor of mySites.guru as the finder.
2026-08-27 Digital Peak ships 10.12.0 and 8.19.5, fixing two issues found by Toan Le A blind SQL injection in the events query's sort clause, reachable from a saved article, and a stored cross-site scripting flaw in location titles. Both need an authenticated user. The vendor reports no evidence of exploitation.
2026-08-27 No CVE assigned yet for either issue Digital Peak's announcement identifies them only by internal tracker numbers. Assignment through the Joomla CNA commonly follows a release by several days.

Helix Ultimate 2.2.10 Fixes Twelve Security Issues, Including a Pre-Login Bypass

phil@mysites.guru (Phil Taylor) — Thu, 27 Aug 2026 00:00:00 GMT

TL;DR: JoomShaper released Helix Ultimate 2.2.10 on 27 August 2026. It is a security release, rated High to Medium by the vendor, and every version below it is affected. The customer email groups the work into six areas; the release notes published afterwards itemise twelve security fixes and five other fixes. The one that matters most needs no login at all: a URL parameter walked past a Coming Soon holding page and served the administrator’s unsaved template settings. Joomla 4, 5 and 6 sites update through the Joomla administrator in the normal way. Joomla 3 sites need a separate package installed by hand, and three of the twelve did not reach it. Across the Joomla 4, 5 and 6 sites we monitor, around 92 percent of Helix Ultimate installs are still below 2.2.10, and most of them are on 2.2.9, exactly one release behind. Five CVEs were published for the release on 31 August, one of them ours.

Helix Ultimate is a Joomla template framework from JoomShaper, installed as the helixultimate system plugin plus a template such as shaper_helixultimate. It sits underneath the whole front end of a site, which is why a security release for it is worth acting on rather than filing.

If you look after more than a handful of Joomla sites, the hard part is not the update, it is knowing which sites need it. mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account, so you can search for Helix Ultimate once and get every affected site with the version each one reports. The figures in this post come from that same inventory.

What Helix Ultimate 2.2.10 Fixes

These are not our findings, and it is worth saying so before describing them. This was JoomShaper’s own security pass on its own code. We did not discover or report any of it. What follows comes from reading the published code difference between 2.2.9 and 2.2.10, so we can tell customers what actually changed rather than take a changelog on trust. The one Helix-family flaw we had reported before this was in Helix3, a separate product, in June 2026. The Joomla 3 backport of this release did turn up one of ours: an authorisation check applied to the wrong object, confirming the caller could edit an article and then deleting whatever file the caller named. We reported it to JoomShaper on 27 August 2026 and they fixed it in J3 Security Fixes 1.0.3 on 31 August. It was published as CVE-2026-78075 the same day, credited to Phil Taylor of mySites.guru, and it is the only one of the five that is ours.

Five CVEs were published for this release on 31 August 2026, four days after it shipped, all with an affected range of 1.0 to 2.2.9 and all fixed in 2.2.10:

CVE	CVSS	What it covers
CVE-2026-78078	8.9 High	Image uploads validated only the file extension and basic size, so a non-image disguised with a raster extension was accepted. 2.2.10 adds MIME verification and GD binary raster decoding that fails closed.
CVE-2026-78077	8.6 High	Stored XSS in the Mega Menu layout container and embed inputs: unsanitised column and item configuration values held in the layout JSON were rendered without complete contextual escaping.
CVE-2026-78079	5.3 Medium	Open redirect. The return redirect parameter accepted arbitrary Base64 without checking the resolved target with `Uri::isInternal`.
CVE-2026-78075	5.1 Medium	Broken object-level authorisation in blog image deletion. This one is ours, credited to Phil Taylor of mySites.guru.
CVE-2026-78076	5.1 Medium	The `save-megamenu-settings` AJAX endpoint did not enforce item-level or menu-level edit permissions.

Four of the five score PR:H, meaning they need an authenticated account with real privileges on the site. Only the open redirect is PR:N, and it needs user interaction. That is a materially different risk profile from the access control bypass described below, which needed no account at all and has no CVE of its own.

One quirk worth knowing if you read the records directly: CVE-2026-78079 is titled “Privileged File Upload Bypass via Content Spoofing”, a duplicate of CVE-2026-78078’s title, while its description and its CVSS vector are the open redirect. The description is the correct half.

JoomShaper’s customer email gives a severity of High to Medium, an affected range of all versions prior to 2.2.10, and six areas. The release notes published on the repository go further and itemise twelve security fixes, which is the list worked through below. Reading the published code difference between 2.2.9 and 2.2.10, here is what sits behind each of them.

Access Control on Live Preview and Coming Soon

This is the most serious item and the only one reachable with no account at all. Before 2.2.10, adding ?helixMode=edit to any URL on a Helix Ultimate site did two separate things for an anonymous visitor. It skipped the Coming Soon redirect, 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. Both now require an authenticated user with template edit rights.

Authorisation on Media AJAX Actions

The permission map behind the framework’s AJAX endpoints has been tightened. Viewing, uploading, deleting media and creating folders now each require template edit rights plus the matching com_media permission, rather than a single looser check.

Mega Menu Settings and Layouts

The endpoint that saves Mega Menu settings previously checked only that the caller could edit menus somewhere on the site, so anyone past that check could rewrite the Mega Menu settings of any menu item. It is now checked against the specific menu the item belongs to. The layout settings are also escaped on the way out.

Media Upload Validation

Uploads were accepted on the strength of their file extension. They are now decoded and checked, using getimagesize, finfo and a full image decode, so a file renamed to .jpg is rejected. The path handling underneath was also hardened with real path resolution and a null byte check, which closes a symlink route out of the media folders.

Page Title and Attribute Validation

The page title feature took its heading tag, background colour and background image straight from menu item parameters and wrote them into markup. The heading tag now comes from an allowlist, the colour must match a hex pattern, and the background image URL is quoted and escaped before it reaches the style attribute.

Social Sharing and Media Embeds

This one is easy to skip over and should not be. The Facebook, Twitter and LinkedIn share buttons were building their URLs by interpolating the article title and URL directly into a JavaScript string inside an onClick attribute. The blog video and audio layouts were taking a YouTube or Vimeo identifier out of an article’s video field and dropping it, with its query string, straight into an iframe src. Both are now built with http_build_query, escaped with htmlspecialchars, and the embed identifiers are restricted to an allowlist of characters. Anyone who can create an article can set a title and a video field, so this was a route into the page for a low privilege user.

Three further items appear in the release notes but not in the six-area summary, and they are worth pulling out separately.

The Draft Cache Took the Style’s Identity From the Request

This sits in the same feature as the bypass above and is a different problem. When a template style was written to the draft cache, the style’s own identity came out of the POST body: id, template, client_id, home and title were whatever the request said they were. The stored template name is then concatenated into a filesystem path when the draft is read back, templates/<name>/options.json and templates/<name>/templateDetails.xml. 2.2.10 looks the style up in the database by its ID, takes the name from that record, and strips anything outside letters, digits, underscores and hyphens.

Frontend Article Saves Were Not Checked Against the Article

Helix Ultimate hooks onContentBeforeSave so it can merge its own article settings into an article’s attributes when the article is saved from the front end. It checked the context, whether the article was new, and whether the request came from the site rather than the administrator. It never checked whether this user was allowed to edit this particular article. 2.2.10 adds that check: core.edit on the article itself, falling back to core.edit.own plus an ownership test.

Image Source URLs Were Unescaped in the Older Image Layouts

The full image and intro image layouts wrote the article’s Helix image path straight into an img src attribute. The value is the article’s own helix_ultimate_image attribute, so anyone who can edit an article sets it. Both now run through htmlspecialchars. The layouts Joomla 5 and 6 use were already escaped. The ones fixed here are the set Helix Ultimate serves to Joomla 4 and below, which is also the set the Joomla 3 package ships.

Five Fixes That Are Not Security

The release also contains five ordinary bug fixes, and JoomShaper is explicit that these apply to Joomla 4, 5 and 6 only, not to the Joomla 3 package.

The Helix system plugin now keeps its disabled state through a template update. Previously an update switched it back on, which is a real annoyance if you had turned it off. Template style migration no longer overwrites parameters between styles, so a site with several template styles will not find one style’s settings stamped over another during an update. And a frontend image lazy-loading bug is fixed.

Two more deserve a line each, because one touches the update channel and the other the plugin’s own dependencies. Saving licence information used to write to every JoomShaper update site row it could find; it now resolves the right row through the extension IDs Joomla has actually recorded, in #__update_sites_extensions, and keeps any query string already on it. And the template installer now deletes the SCSSPHP 1.x directories that older installs left in the plugin’s vendor folder, where they sat alongside the 2.x version that replaced them.

How Do I Update Helix Ultimate on Joomla 4, 5 and 6?

Through the Joomla updater, in the normal way. Log in to the administrator, go to System, then Update, then Extensions, and update Helix Ultimate to 2.2.10. Nothing needs configuring afterwards. Clear the Joomla cache and your browser cache once it is done.

Take a backup first. That is standard advice for any template framework update, because Helix Ultimate renders your entire front end and a bad update is visible to every visitor rather than tucked away in the administrator.

What About Joomla 3 Sites?

The same security issues apply to Joomla 3, but 2.2.10 will not install there. JoomShaper ships a separate Joomla 3 package that has to be downloaded from GitHub and installed manually through System, then Install, then Extensions.

That route has problems of its own, and they are worth understanding before you plan a Joomla 3 patching round. We covered them separately in our write-up of the Joomla 3 package: the short version is that the Joomla updater will never offer it to you, so nothing will prompt you and you have to go and fetch it on purpose.

The contents differ too. We unpacked the Joomla 3 packages from July and from today and compared them against this release. Nine of the twelve security fixes are in the Joomla 3 build, including the access control bypass. Three are not: the draft cache identity fix, the ownership check on frontend article saves, and the image source escaping described above. The third matters most on Joomla 3, because the layouts it fixes are exactly the ones that package ships, and its copy is unchanged. Details are in the Joomla 3 write-up.

How Many Sites Are Still Below 2.2.10?

Across the Joomla 4, 5 and 6 sites we monitor that run Helix Ultimate, around 92 percent are still below 2.2.10. About 8 percent had already updated within hours of the release, which is what a working update channel looks like.

The version distribution is the part worth knowing. The large majority of the affected installs are on 2.2.9, exactly one release behind, with a smaller group on 2.2.8. Very few are ancient. So the usual reassurance, that you keep your sites reasonably current, does not help here: JoomShaper’s advisory says everything below 2.2.10 is affected, and being one release behind puts you in that group along with everyone else.

Helix Ultimate skews heavily towards the supported Joomla versions, too. About 90 percent of the installs we monitor are on Joomla 4, 5 or 6, where the normal updater works. That makes this an unusually easy security release to close out across a portfolio, provided you know which sites to look at.

Finding Every Helix Ultimate Install in One Place

Searching for an extension across a lot of Joomla sites by hand means logging into each administrator and reading the Manage screen. For twenty sites that is an afternoon.

In mySites.guru, search for Helix Ultimate once in your account and you get every site running it, the version each one reports, and the Joomla version underneath, without logging into anything. From there you can see at a glance which sites are below 2.2.10, which are already done, and which are the Joomla 3 sites that need the manual package instead.

That is the same inventory the percentages above came from, and it is part of the subscription rather than an add-on: GBP 19.99 per month for unlimited Joomla and WordPress sites, a price that has not changed since 2012.

If a site turns out to have been compromised rather than only out of date, 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

Helix Ultimate 2.2.10 is a straightforward security release with one item in it that anyone on the internet could have used, and eleven more that a logged-in user with modest permissions could have. JoomShaper says every version below it is affected, and the install base we can see is overwhelmingly one release behind rather than safely current.

On Joomla 4, 5 and 6 this is a normal update through the administrator, so there is little reason to leave it. Find every Helix Ultimate install you look after, update the Joomla 4, 5 and 6 ones now, and handle the Joomla 3 ones separately with the manual package. Start with a free audit on one site if you want to see what your Helix Ultimate exposure actually looks like.

Timeline

2026-07-07 Helix Ultimate 2.2.7, the previous security release A batch of missing permission and token checks across the framework's AJAX handler, fixed and tagged the same day the code became public.
2026-07-15 2.2.9 ships as a maintenance release Menu item ID handling, an offcanvas arrow position and a copyright field. Nothing security-related in the release notes, and it is the version most sites are still running today.
2026-07-22 Mega Menu sanitisation work is merged The first of the fixes that would become 2.2.10 goes into the repository, five weeks before the release.
2026-08-24 Audio and video embed sanitisation is merged Embed identifiers taken from an article's video field stop being written straight into an iframe source.
2026-08-27 Helix Ultimate 2.2.10 is released Tagged at 12:07 UTC, covering Joomla 3, 4, 5 and 6. JoomShaper rates it High to Medium and states that every version below it is affected.
2026-08-27 Customers are emailed five minutes later The advisory gives a severity, an affected range, a fixed version and a one-line impact summary, and tells Joomla 3 users to install a separate package by hand.
2026-08-27 Fuller release notes are published An itemised changelog goes up on the repository: twelve security fixes and five others, where the customer email had given six areas.
2026-08-31 JoomShaper ships J3 Security Fixes v1.0.3 The Joomla 3 patch is revised to tie blog image deletion to the article's own image fields, fixing the wrong-object authorisation check that v1.0.2 introduced and that we reported on 27 August.
2026-08-31 Five CVEs are published The Joomla CNA publishes CVE-2026-78075 through CVE-2026-78079 for the release, all affecting 1.0 to 2.2.9. CVE-2026-78075 is credited to Phil Taylor of mySites.guru.

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

phil@mysites.guru (Phil Taylor) — Thu, 27 Aug 2026 00:00:00 GMT

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 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.

“No security patches, regardless of severity.”

JoomShaper, 9 July 2026. Three Joomla 3 security patches later.

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 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 are still there after 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 four times. The same string covers four 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.

Important

A version number is a promise that the same string means the same code. When a vendor breaks that promise on a security release, every automated check downstream inherits the mistake, including ours. Reusing a version string on changed files is worse than not shipping a fix, because it makes an unpatched site look patched.

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 not 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 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 no one 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 would not 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.

Timeline

2026-07-09 JoomShaper says Joomla 3 will get no security patches The announcement ends support for the Joomla 3 builds of every JoomShaper product, with one line doing the damage: no security patches, regardless of severity.
2026-07-15 The first Joomla 3 patch, six days later J3 Security Fixes 1.0.0 ships for Helix Ultimate, alongside Joomla 3 patches for Helix3 and SP Page Builder. The stated policy lasted under a week.
2026-07-22 The second patch, advertised but not delivered J3 Security Fixes 1.0.1 is released. The update feed declares version 1.0.1 while the download link still points at the 1.0.0 file, and it stays that way for five weeks.
2026-08-27 The third patch, under the old version number J3 Security Fixes 1.0.2 backports hardening from Helix Ultimate 2.2.10. The patched plugin and template files change, but both keep the version string 2.1.4-j3sec that the July build already used.
2026-08-31 The fourth patch, four days later J3 Security Fixes 1.0.3 fixes an authorisation check we reported to JoomShaper on 27 August: the third patch checked whether the caller could edit an article, then deleted whatever file the caller named. The version string is still 2.1.4-j3sec.

Slower on purpose: the new Update Queue, and why it is off by default

phil@mysites.guru (Phil Taylor) — Tue, 25 Aug 2026 00:00:00 GMT

Select every out-of-date site, click update, walk away. It is the whole point of managing sites from one dashboard, and for most people it works fine. The bulk update Joomla page covers the whole workflow.

Then you get an account with a thousand sites on a single shared server, all of them selected, and the updates go out at once. The server does not come through that. On core updates it falls over under the load. On extension updates you can break an individual site instead, because two updates race inside the same install and neither expected company.

The new Update Queue fixes that by doing less at a time. It runs at most one update per server, and everything else waits its turn. It is opt-in, it is off unless you switch it on, and it will make your big batches take longer. That is the feature, not a side effect.

What actually goes wrong when you update everything at once

There are two separate failures here, and only one of them is about the server.

Start with that one. A Joomla or WordPress core update is not a small job: download, extract, run the post-install work, hit the database. One of those is unremarkable. Several hundred at the same moment on one box is a load spike, and shared hosting is where the sites-per-server count is highest and the resource headroom is smallest. The server goes down and it takes every site on it with it, including the ones you were not touching.

The other failure is the individual site. Two extension updates running against the same install at the same time can collide: both writing files, both touching the database, neither aware of the other. You end up with one site broken by its own maintenance.

What the Update Queue does

When queueing is on, every update you trigger joins a queue for the server that site lives on. One update runs, the rest wait, and the next starts the moment the previous one reaches a conclusion. It covers Joomla core, WordPress core, Joomla extensions and WordPress plugins, and it does not matter how you started the update: the dashboard, the API and the MCP tools all go through the same queue.

You are not left guessing what it is doing. There is a progress bar in the header while a batch is running, a page showing each server with its running job and everything queued behind it, and anything that has not started yet can be cancelled.

The pill only appears while there is something to watch. It counts finished updates against the size of the batch you started.

Because one update of any kind runs per server at a time, you also get the same-site collision fixed for free. A core update and an extension update on one site cannot overlap, because they are both in the same lane.

One lane per server, not one queue for everything

The queue is not a single global line. It is one lane per server, so a slow update on one host never holds up a completely unrelated host. Ten servers means ten updates running at once, one on each.

Hovering the pill opens the per-lane breakdown, so you can see which server is holding things up without leaving the page you are on.

That third row is the fallback in action. Where we cannot see a hostname, the site queues under its own id rather than being lumped in with everything else.

The detail worth explaining is what identifies a server, because getting it wrong would have been worse than not building the feature. Lanes are keyed on your account plus the server hostname, never the hostname on its own.

Hostnames are not unique. Hosting companies hand out the same generic names again and again, so the same string turns up across customers who have nothing to do with each other. In our own data one such name appears on 340 sites belonging to unrelated people, and another on 403. (Both are real counts from our platform; we have changed the names here.) Had we keyed lanes on the hostname alone, one customer’s slow update would have blocked a stranger’s, and neither would have been able to work out why.

About fifteen per cent of connected sites do not report a hostname at all. Those fall back to a lane of their own, per site, which is the cautious answer: it still prevents a site colliding with itself, and it never lets one unidentifiable site block anything else.

Why is it off by default?

Because queueing is slower, and most accounts do not need it.

If you have a handful of sites, or your sites are spread across a lot of different hosts, they were never colliding in the first place. Turning queueing on for those accounts would mean waiting for a problem you do not have. It starts to matter somewhere around twenty or more sites on the same server, which is where “update everything” and “take the server down” become the same action.

There is a version of this feature that ships on by default and makes every customer’s mass update slower to protect the minority who need it. We did not want to build that one. You know your own hosting, and whether your sites are stacked on one box or scattered across twenty, far better than we can infer it. So it is a switch, and it is yours.

Note

Queueing does not add artificial delay. A single update on an idle server is admitted immediately and starts within seconds, rather than waiting for the next tick of a timer. The waiting only appears when there is something ahead of you on that server.

How do I turn it on?

Go straight to manage.mysites.guru/en/updates/queue. You can also open Tools and choose Update Queue, or press Cmd+K and use the hotkey u q.

On that page, click Enable update queueing. Three things happen: updates start queueing per server from that moment, the queue is starred in your menu so you can find it again, and the page starts showing you lanes instead of an explanation.

The setting is company-wide rather than per-user, so it applies to everyone on the account rather than just the person who flipped it. If someone else on your team turns it on, your updates queue too.

Switching it off is the same journey and takes effect immediately. Updates go back to applying the moment you ask for them, and past queue activity stays on the page.

What it does not do

It does not retry failures

A failed update is marked failed, the error is kept and shown on the queue page, and the lane moves on to the next job. Nothing tries again on its own. An update that failed once usually fails the same way twice, and automatic retries on a half-finished update are how one broken site becomes several. Read the error, fix the cause, trigger it again yourself.

It does not reorder your work

Jobs run oldest first within their lane. There is no priority scheme to learn and nothing jumps the queue.

It does not make the updates themselves any faster or slower

Each update takes exactly as long as it always did. The only thing that changes is how many of them are allowed to happen at once.

It is not a substitute for backups

Backups still matter. Queued updates are still updates. Take a backup first, the same as you would if you were applying them one at a time by hand, which in effect is now what is happening. A queue for backups is in planning too, built the same way and for the same reasons: firing every backup on one server at once is the other reliable way to flatten it.

Seeing what actually happened

The queue tells you what is running now. The Update Log tells you what happened, and we have rebuilt it at the same time.

It lists the last 500 updates applied across your sites, newest first, whether you triggered them yourself or mySites.guru applied them overnight. Each row shows the site, the extension and the version it went to, when it ran, and whether it finished or errored.

The filter matches on any part of a site URL, an extension name or a status, so “Error” pulls up every failure in one go. Check it the morning after a big batch. Updates you triggered do not always take, and this is where you find out which ones did. There is an Export CSV button if you need the list somewhere else.

It is at manage.mysites.guru/en/updates/scheduled, and unlike the queue it needs no opting in. It has always been recording; it is just far easier to read now.

Who should turn this on

Turn it on if a meaningful number of your sites share a server, and especially if you have ever had a mass update coincide with a site or a server going down. If you are on shared hosting or a reseller plan with a lot of sites on one box, this is aimed squarely at you.

Leave it off if you have a small number of sites, or if your estate is spread thinly across many hosts. You would only be adding a wait.

If you are not sure which describes you, the Servers view groups your connected sites by the server they are on, which answers the question in about ten seconds. If one server has a long list under it, you are the person this was built for.

You can also just try it. It is a toggle, it applies immediately, and switching it back is one click. Run one mass update with it on and see whether the wait bothers you more than the risk did.

Thanks

A special thank you to Adi, who has been on my case about this one for a long time and was right to keep pushing. It turned out to touch a lot of layers in mySites.guru, from the dashboard and the API through to the background workers and the database lock that makes the per-server lanes safe, and that is why it took as long as it did to get right rather than only working.

Finding Rogue Admin Accounts Across Every Joomla Site You Manage

phil@mysites.guru (Phil Taylor) — Mon, 24 Aug 2026 12:00:00 GMT

The vulnerability gets patched. The webshell gets deleted. A week later the site is hacked again, and everyone stands around wondering how, because the hole is definitely closed.

The answer is usually sitting in the user table, which is why rogue Super Admin accounts are one of the checks we run on every connected site. During the original compromise the attacker created an account for themselves, and that account is still there despite everything you did afterwards. They do not need the exploit any more, or the backdoor, or the file you deleted. They have a login. MITRE ATT&CK catalogues this as T1136, Create Account, and it is the highest-value thing an attacker does on the way in.

Finding those accounts is easy on one site and close to impossible on eighty. mySites.guru now runs the check for you on every connected Joomla site.

How Do I Find Rogue Admin Accounts Across Every Joomla Site?

The Rogue Super Admin Accounts check runs on every connected Joomla site as part of the regular snapshot, with no configuration and nothing to install. It reads the site’s user tables, resolves which groups actually hold Super User permissions on that specific site rather than assuming the stock group, and matches every account against a set of attacker identity rules.

A site that fails this check is marked as hacked in your dashboard automatically. You do not have to go looking.

See which of your Joomla sites have planted accounts

The Compare All Sites view lists every connected Joomla site with a pass or fail for this check, so you find all of them at once instead of one nasty surprise at a time.

Open the Rogue Super Admin check

Not a subscriber? Run a free audit on one site and the check runs on the first snapshot.

Click into any flagged site and you get the accounts themselves: ID, username, name, email, when it was registered, and a plain-English reason each one was flagged. There is a delete button that removes all of them from the site in one action.

Two accounts, planted a month apart, on a site otherwise running a current Joomla. The first holds Super User. The second is the more instructive of the pair: it is flagged as not currently a Super User, because it matched a known attacker signature while sitting in an ordinary user group. No amount of filtering the Super Users list would ever have surfaced it.

Deletion is permanent and we keep no backup of the removed rows, so if you want anything for evidence, record it before you click. Every account is re-checked against the detection rules on the site itself immediately before it is deleted, so a page you left open yesterday cannot remove a user who is fine today.

What the Check Is Currently Holding

None of what follows is visible from a single site.

As of today, across the Joomla sites we manage, this check is flagging 827 planted accounts sitting on 20 different sites. The distribution is the interesting bit:

Accounts on the site	Number of sites	Total accounts
Over 20	10	814
2 to 5	1	4
Exactly 1	9	9

Ten sites account for 814 of the 827 between them. That is what a mass registration looks like, and it is the version you would notice on your own, because the user count jumps and the notification emails pile up. OWASP catalogues the bulk version as OAT-019, Account Creation.

Nine of the twenty affected sites have exactly one planted account, sitting in a user list alongside real users, created on an ordinary day. No one notices that. It is not noisy enough to trigger anything, and it is the one that gets the site re-hacked in a month, because it is still a working login long after the cleanup is declared finished.

The loud compromises find themselves. The quiet ones are the reason this check has to run on every site, all the time, rather than on the site you already suspect.

Why Checking Your Joomla Super Users Misses Them

Every article about hacked sites tells you to open your user manager, filter to administrators, and delete anything you do not recognise. It is sensible advice, and on its own it would miss most of what we find.

When an attacker plants an account, it takes two steps: create the user row, then map that user into a group with Super User permissions. The second step fails a lot. The exploit runs out of privileges, the group mapping is written wrong, the site’s permission setup is not what the payload assumed, or the code simply crashes between the two. The account still exists. It just is not an administrator.

So it sits in whatever group new registrations get by default, indistinguishable from a real signup, and completely absent from the Super Users list you were told to check. Dormant is not the same as harmless. It is a valid credential the attacker holds, on a site they have already proved they can reach, and privilege escalation is a much easier second visit than the original break-in was.

Our check matches identity shape in any user group, not just Super Users, for this exact reason. That is why the second row in the screenshot above is labelled “not currently a Super User” rather than being excluded. The word doing the work there is currently.

How the Check Decides an Account Is Rogue

We are not going to print the matching rules verbatim, because the people running these campaigns read security blogs too and renaming their accounts is a five-minute job. By class, there are three:

Known attacker identities

Specific email addresses and usernames we have pulled out of real compromised sites during incident work. When a campaign reuses the same mailbox across hundreds of victims, and they usually do, a literal match is the most reliable signal available. This class matches in any user group, and it is what caught both accounts in the screenshot above.

Generated identity shapes

Automated tooling generates its names, and every generator leaves a fingerprint. A fixed prefix followed by a run of hex characters, or a username duplicated into the local part of a throwaway domain, is a shape no human picks and no legitimate registration produces. Matching the shape rather than the string means the campaign has to change its generator, not just its mailbox.

Accounts with no valid registration date

A Joomla account created through Joomla always gets a registration timestamp. An account written straight into the database by an exploit frequently does not. This one is reported as a warning rather than a confirmed hit, it is not counted in the rogue total, and there is no bulk delete for it, because a database migration or a CLI import can produce the same result innocently. You get told, you look, you decide.

Note: ordinary spam signups are excluded on purpose

A hit here marks the whole site as hacked, which is a serious claim, so the check ignores the everyday bot registrations that turn up on any site with an open signup form. Those are covered separately by the unactivated users check. A rogue admin result means we believe someone got in, not that your registration form is busy.

Where These Accounts Come From

Rogue accounts are the second half of a compromise, so every one of them started as something else. The recurring pattern across the incidents we have worked this year is a file upload or privilege escalation in a third-party Joomla extension, followed within minutes by an account being created.

The SP Page Builder zero-day is the clearest example we have documented, because we traced it through real access logs: the upload request, the fetch of the planted shell, and a new Super User appearing in the site, in sequence. That incident is what this check was originally built for. The Gridbox authentication bypass and the 23 further Gridbox vulnerabilities we found afterwards include a registration flaw that puts a visitor into whatever group they ask for, which produces exactly the mass-registration pattern in the table above.

Joomla core has produced them too. CVE-2026-48904, patched in Joomla 5.4.6 and 6.1.1, let an unauthenticated attacker manipulate group membership through the com_users webservice endpoints and grant themselves Super User. CVE-2026-90907, fixed in Joomla 5.4.9 and 6.1.4, is a milder case: an anonymous visitor could create Guest-group accounts through the profile save task even with registration switched off. Those accounts are not admins, but they are accounts nobody approved, so they belong in the same review (details in the 5.4.9 and 6.1.4 write-up).

The vector changes every few weeks. The thing the attacker does next does not, which is why detecting the account is more durable than chasing each individual flaw.

How Do I Check a Joomla Site by Hand?

If you want to check a single site yourself, or you want to verify what we are reporting, three queries in phpMyAdmin will do it. Replace #__ with your site’s real table prefix.

Every account holding Super User permissions, newest first:

SELECT u.id, u.username, u.name, u.email, u.registerDate, u.lastvisitDate
FROM `#__users` AS u
JOIN `#__user_usergroup_map` AS m ON m.user_id = u.id
WHERE m.group_id = 8
ORDER BY u.registerDate DESC;

Group 8 is Super Users in a stock Joomla install. If your site has custom groups with administrative permissions, that query will miss them, which is one of the things the automated check handles for you by reading the site’s actual permission rules instead of assuming.

Accounts with no valid registration date, which should be none:

SELECT id, username, email, registerDate
FROM `#__users`
WHERE registerDate = '0000-00-00 00:00:00' OR registerDate IS NULL;

And the one people never think to run, registrations grouped by day:

SELECT DATE(registerDate) AS day, COUNT(*) AS accounts
FROM `#__users`
GROUP BY DATE(registerDate)
ORDER BY day DESC
LIMIT 30;

A mass compromise is a spike. If a site that normally gets two signups a week shows ninety on a single Monday, you have your date, and now you know exactly which window of your access logs to read. That query takes two seconds and has found more compromises for me than any amount of scrolling through a user list.

One timing trap worth knowing: Joomla writes the registration timestamp in the site’s own timezone from configuration.php, while your access logs are almost certainly UTC. Convert before you go looking, or you will search the wrong hour, find nothing, and conclude the logs are clean.

What Should I Do If I Find One?

Treat it as proof of compromise, not as a tidying job. The account is evidence that someone had enough access to write to your database, and they did not stop there.

Record it first. Username, email, registration date, last visit. Deletion is permanent and there is no undo, so capture what you need before you remove anything.
Delete the account, from the mySites.guru user manager for that site or from the Joomla user manager. Removing the row closes that door.
Find the entry point. Use the registration date to narrow your access logs, then look at what was being requested around that timestamp. Our guide to finding hacked files and backdoors covers what to sweep for.
Patch what let them in. Usually an out-of-date third-party extension. Your mySites.guru extension inventory will tell you which ones on that site are on a version with a known flaw.
Rotate everything. Joomla admin passwords, database credentials, FTP and SSH keys, and the Joomla secret. Force-logout every session, and revoke every Joomla API token too, since a password reset does not touch those.
Clean the whole site, not the one folder you found something in. Someone who got in through one component usually leaves a second way back. Our hacked site recovery guide walks through the full process, and if you would rather hand it over, fix.mysites.guru is a single fixed fee of £120 per incident, usually same day.

The part people skip

A patched site with a planted account on it is still fully compromised.

The attacker does not need the vulnerability any more. They have a login, and it works exactly like yours does.

Why This Runs on Every Site Instead of the One You Suspect

The honest reason we built this as an account-wide check rather than a per-site tool is that no one audits a site they think is fine.

You check the site the client phoned about. You do not check the other seventy-nine, because there is no reason to and no time for it. The compromise that matters is the one on a site no one has mentioned, holding one extra account, waiting for whoever planted it to come back. Nine of the twenty sites in our numbers above are in exactly that state, and not one of them was found because somebody went looking.

That is the whole argument for running the check everywhere, automatically, and marking the site as hacked when it fires. It costs you nothing to have it run on a site that turns out to be clean.

Get free email alerts when a Joomla extension flaw breaks

We email a plain-English alert the moment a serious flaw is disclosed, with the affected versions and what to do. No charge, unsubscribe any time.

Subscribe to security alerts

Want the check running across your own sites? Connect them to mySites.guru and it runs on the first snapshot (see snapshot vs audit for what a snapshot reads and what only an audit can), alongside the extension inventory, the file integrity scan and the rest of the audit.

Three CVEs in miniOrange Extensions for Joomla, All Now Fixed

phil@mysites.guru (Phil Taylor) — Mon, 24 Aug 2026 00:00:00 GMT

Update, 4 September 2026: a third record, and the earlier complaint is resolved

This post now covers three CVEs against the same vendor. CVE-2026-77995 in the miniOrange OAuth Client and CVE-2026-77998 in miniOrange SAML SSO for Joomla are both authentication bypasses at CVSS 10.0, and the SAML one is already being exploited in the vendor’s WordPress plugin.

CVE-2026-78074 is new, arrived on 31 August, and reaches a great deal further: a missing authentication check lets an unauthenticated visitor uninstall any extension on the site. It names 23 miniOrange extensions and all 23 now have a fix. Two of those numbers supersede the earlier round, so a site patched in late August is not done: the OAuth Client needs 3.2.1 rather than 3.2.0, and SAML SSO needs 11.0.3 rather than 11.0.2.

This post previously complained that CVE-2026-77998 described only the free line, so a paid install checked against it read as clean. That was fixed on the evening of 26 August. The record now names Basic to 13.1.0, Standard to 24.1.0, Premium to 34.1.0 and Enterprise to 44.1.0, along with the ADFS and Google Apps editions and the three OIDC extensions that had appeared in no record at all.

The last open question has now been answered, though by the vendor rather than by the record. On 4 September miniOrange told us the paid OAuth Client editions were never affected by CVE-2026-77995, that their investigation found the flaw in no paid build, and that this is why no paid security release was ever issued. What that is worth, and what it is not.

Start here: which of the three applies to you

The three records scope themselves differently, which is the single most confusing thing about this whole episode. One covers free and paid alike, one is free-only by design, and one has never said what it does to paid customers. So before any of the detail below, work out which line you are on and read one row.

Step 1: are you on a free or a paid build?

The leading digit of the version number tells you, because with miniOrange it identifies the edition, not the age. A one or two segment number in the low range (3.0.2, 6.4, 11.0.2, 1.2.2) is the free edition. Anything in the tens is paid: the 10s are Basic, the 20s Standard, the 30s Premium and the 40s Enterprise. A site reporting 32.0.2 is a Premium build, not something newer than 3.2.0.

Step 2: read your row

	Free edition	Paid editions (Basic, Standard, Premium, Enterprise)
CVE-2026-77995 OAuth Client account takeover	Affected to 3.1.9. Fixed in 3.2.0	Not affected, on the vendor’s word. miniOrange say the flaw was never present in any paid build. The record itself still names only the free plugin, so nothing independent confirms it
CVE-2026-77998 SAML SSO authentication bypass	Affected to 11.0.1. Fixed in 11.0.2 (ADFS and Google Apps 6.4, the three OIDC extensions 1.2.2)	Affected to 13.1, 24.1, 34.1 and 44.1. Fixed in 13.2, 24.2, 34.2, 44.2
CVE-2026-78074 Unauthenticated remote uninstall	Affected across 23 extensions, each with its own range. See the table of 23	Not affected. The record limits itself to the free editions in its own description

The short version, if you only want the number

On a free build? Update to the version in the table of 23 and you are done. Because CVE-2026-78074 was fixed last, its number sits above the earlier ones for every extension the earlier records touched, so that single number closes all three: the OAuth Client’s 3.2.1 covers the 3.2.0 that fixed CVE-2026-77995, SAML SSO’s 11.0.3 covers 11.0.2, the ADFS and Google Apps 6.5 covers 6.4, and the OIDC extensions’ 1.2.3 covers 1.2.2.

On a paid SAML SP build? You need 13.2, 24.2, 34.2 or 44.2 according to your edition. CVE-2026-78074 does not apply to you.

On a paid OAuth Client build? miniOrange told us on 4 September that the paid editions were never affected by CVE-2026-77995, so on their account there is nothing for you to do. There is no number to install because they say no paid build ever needed one. That rests on the vendor’s word rather than on the record, which still names only the free plugin, so read the caveat before you file it as closed.

The rest of this post is how each record got to that state, in the order it happened, including the two days when a paid install checked against the SAML record was wrongly told it was fine.

The first flaw: CVE-2026-77995 in the OAuth Client

The miniOrange OAuth Client extension lets a Joomla site use an external OAuth provider to log its users in. Every free version below 3.2.0 has a flaw that needs no login, no account and no help from anyone on the site. It is scored CVSS 10.0, the maximum, and it ends with an attacker sitting in your Joomla administrator account.

What the flaw is

The extension works out who a visitor is from a cookie value. That value is set on the visitor’s own machine, so the visitor controls it completely. Change it to name a different account and the extension logs you in as that account. Name an administrator and you are an administrator, with no password and nothing to bypass, because there was never a check to bypass in the first place.

If that sounds familiar, it should. It is the same shape of flaw we found in Gridbox for Joomla back in July, where setting a single cookie, gridbox_username=admin, logged a visitor straight in as a Super User. Trusting a value the browser sends to decide who someone is has a name, improper authentication, and it keeps turning up in Joomla extensions because a cookie reads like server-side state right up until you remember the browser is the thing that writes it.

The Joomla record for this is CVE-2026-77995, published on 24 August 2026 by the Joomla project as the CNA, and credited to Krzysztof Zając of CERT PL. Its own summary is blunt: “The manipulation of a cookie value allows actors to login as arbitrary accounts, including admins.” The affected range is 1.0.0 up to and including 3.1.9, and the fix is 3.2.0.

What to do about the account takeover

Update the miniOrange OAuth Client extension on every Joomla site that runs it. 3.2.0 is what closes this record, but install 3.2.1 or later instead: the third record below affects 3.2.0 as well, and 3.2.1 closes both.

Read the version number carefully when you check. miniOrange ships the same extension as several separately numbered editions, and the leading digit is the edition, not the age: the 20s are Standard, the 30s are Premium, the 40s are Enterprise. A site showing 32.0.2 is not running something newer than 3.2.0, it is a Premium build. miniOrange have told us the paid OAuth editions were never affected, which is why no fixed build exists for them, though that rests on their assessment rather than on the record.

If you cannot update a site straight away, disable or remove the extension rather than leaving it in place. An extension that hands out administrator sessions to anyone who asks is worse than no OAuth login at all for the short time it takes to patch.

Then, because the flaw hands out administrator access, check the site was not already used. Look at your Joomla user list for administrator or super user accounts you do not recognise, and at accounts created or changed recently. Check the Joomla action logs and your web server logs for administrator sessions from IP addresses that are not yours. If anything looks off, treat the site as compromised and clean it properly rather than only updating the extension.

The second flaw: CVE-2026-77998 in SAML SSO

On 25 August 2026 the Joomla CNA published a second record against the same vendor: CVE-2026-77998, an unauthenticated authentication bypass in miniOrange SAML SSO for Joomla, scored CVSS 4.0 10.0. This one is a different extension from the OAuth Client above, and if you use miniOrange for SAML single sign-on it matters more to you than the OAuth flaw does.

What goes wrong

PHP’s openssl_verify() does not answer yes or no. It answers one of three things: 1 if the signature is valid, 0 if it is not, and -1 if OpenSSL could not complete the check at all. That third answer is the trap. The extension tests the result as though it were a plain true or false, and in PHP -1 is true.

So an attacker does not need to forge a valid signature. They need to send one broken enough to make OpenSSL give up. They post a SAML response naming whichever account they like, attach a signature value engineered to trigger an OpenSSL error, and the extension reads the resulting -1 as “signature verified”. It then logs them in as the account they named. A Super User account is as easy to name as any other. There is no login step, no credential to guess and nothing for anyone on the site to click.

It is the same shape of mistake as the OAuth flaw above, just one level further in. The OAuth Client trusted a value the browser sent. The SAML extension does check a signature, but then misreads what the check told it, which gets to the same place.

It is already being used on WordPress

This is not a bug sitting in a database waiting for someone to notice it.

miniOrange build the same single sign-on product for WordPress, where the identical misreading of openssl_verify() is tracked as CVE-2026-15981. Patchstack report that it is being exploited, chained with a second flaw in the same plugin. DigitalOcean caught an unrecognised WordPress administrator session on 16 August, attempts and opportunistic scanning are coming from six addresses across Europe, Africa and the United States, and a working proof of concept is public.

The Joomla record is new enough that we have seen no reports of it being attacked. We would not read much comfort into that. The vendor builds both editions from the same ideas, the mechanism is now described in public on both platforms, and attackers already have working code for one of them.

What happened next on the WordPress side is the part worth sitting with, because it is about to be the Joomla story too. Both flaws were fixed back in July. The vendor’s advisory covered only the free edition, so customers on the six paid editions were never told they were affected, and their WordPress dashboards showed no update prompt because paid editions do not update through the plugin directory. Plenty of them did nothing, reasonably enough, because nothing told them to. Those are the sites now being broken into. The bug was patched for a month before anyone got hurt by it, and the patch is not what failed.

The version numbers do not line up

The CVE record says the fix is version 11.0.2, with 6.4 given for the ADFS and Google Apps editions. Joomla sites running this extension do not report versions that look anything like that. Real installs report 9.7, 10.8, 11.2, 22.7, 32.7, 42.5, 42.6, 44.0, 44.1 and similar. Until the day this record was published we had never seen a single site reporting 11.0.2 at all. One has since updated to it.

miniOrange ships the same underlying extension as several separately numbered editions, which is the problem Patchstack documented on the WordPress side under the title One slug, seven editions. Their write-up was about exactly this: the bug was fixed, but a large number of sites and enterprise customers had no way of working out whether their build was one of the fixed ones. That same trap has now arrived on the Joomla side.

A site reporting version 44.0 is not “newer than 11.0.2”. It is on a different numbering scheme, and for two days no one outside miniOrange could say whether it was fixed. So we asked them. Their first answer settled the free editions and left the paid ones exactly where they were. Their second, thirty hours later, finally gave the paid editions a number. The rule still holds for both: do not read a big version number as reassurance.

What miniOrange told us

On 25 August we put a narrow question to miniOrange through their own support form: for Joomla, what are the exact fixed versions of each of your products affected by this round of vulnerabilities?

They answered the next morning, which is already more than the WordPress side got. Nutan Barad of miniOrange sent this table, prefaced with five words that matter as much as the numbers do: “All are the free versions.”

This table is a record of 26 August, not your update target

Every number below has since been superseded by CVE-2026-78074, which shipped on 31 August and moved each of these free editions up one release. It is kept here because the rest of this section is about what the table did and did not say at the time. For the version to actually install, use the table of 23.

miniOrange product for Joomla	Fixed version	In a CVE record?
SAML SSO for Joomla	11.0.2	CVE-2026-77998
SAML SP Single Sign-On, Login with ADFS	6.4	CVE-2026-77998
SAML SSO Login with Google Apps	6.4	CVE-2026-77998
miniOrange OAuth Client	3.2.0	CVE-2026-77995
OAuth Single Sign-On, OIDC SSO, Login with Azure AD	1.2.2	No
Login with Keycloak OAuth Single Sign-On (SSO)	1.2.2	No
Single Sign-On for Educational Institutes	1.2.2	No

Three things are worth pulling out of that.

The first is that it confirms both CVE records. The 11.0.2, 6.4 and 3.2.0 figures match what the Joomla CNA published, so if you are on a free edition you now have a number you can act on with some confidence behind it.

The second is that three of those extensions were, at the time, fixed with no CVE at all. The Azure AD, Keycloak and Educational Institutes editions are each given as fixed in 1.2.2, and on 26 August neither published record mentioned any of them, so anyone running one had no advisory to be warned by. That has since been put right: the revision to CVE-2026-77998 later the same evening added all three, at an affected range of 1.0.0 to 1.2.1. They are named again in CVE-2026-78074, where the number moves on to 1.2.3.

The third is the one that mattered most, and it was the sentence above the table rather than anything in it. Every version quoted is for the free edition. The paid editions, the ones on that two-segment numbering line, were left unanswered.

So a site reporting 42.6 or 44.0 was exactly where it had been before we asked. We had read the vulnerable code in a live install on the 42.x line, where the tri-state openssl_verify() return was still being tested for truthiness, so that build was affected and its owner still had no version number to compare themselves against.

That was the WordPress story arriving on Joomla almost word for word. Both WordPress flaws were fixed back in July, the vendor’s advisory covered only the free edition, the paid editions were never told, and those are the sites that got broken into.

So we went back to miniOrange and asked for the paid-edition build numbers.

The paid editions, answered

That gap lasted about thirty hours.

At 12:07 on 26 August, miniOrange emailed its paying Joomla customers directly, under the subject “Urgent! Critical fix released for miniOrange Joomla SAML SP Plugin. Update Now!”. This time the numbers were the ones the free table left out:

SAML SP edition	Affected up to	Fixed in
Basic	13.1	13.2
Standard	24.1	24.2
Premium	34.1	34.2
Enterprise	44.1	44.2

David Jardin of the Joomla Security Strike Team posted the same four numbers publicly half an hour later, so this does not rest on a single forwarded email.

Those four rows decode the whole thing. The leading digit is the edition, not the age. A version in the 40s is an Enterprise build, the 30s are Premium, the 20s are Standard, and the low numbers are Basic or free, which share that range. A site on 44.0 was never “newer than 11.0.2”. It was an Enterprise build two releases behind its own line’s fix. Read that way, every version we have seen in the wild falls into place: 22.7 is a Standard build needing 24.2, 32.7 is a Premium build needing 34.2, 42.6 and 44.1 are Enterprise builds needing 44.2.

There is a trap in the update path

miniOrange say that 13.0, 13.1, 24.0, 24.1, 34.0, 34.1, 44.0 and 44.1 can take the fixed version straight over the top, but anything below 13.0, 24.0, 34.0 or 44.0 has to be uninstalled first and then reinstalled. On a site where SAML is the only way anybody signs in, uninstalling the SAML plugin locks everyone out, administrators included. Before you remove anything, confirm you have a local Joomla Super User account whose password you have actually tested, and take a backup. If the plugin was customised for you, save its configuration and tell miniOrange before you replace it.

One of the two gaps has closed

The CVE record moved the same evening. At 22:35 UTC on 26 August, hours after we published the complaint above, CVE-2026-77998 was revised to describe the paid line: SAML SSO Basic affected to 13.1.0, Standard to 24.1.0, Premium to 34.1.0 and Enterprise to 44.1.0, alongside the ADFS and Google Apps editions at 6.3.0 and the three OIDC extensions at 1.2.1. An automated check reading that record now flags a site on 34.1 correctly, which is the outcome that matters. We are spelling that out because the version of this post you may have read a week ago said the opposite.

The paid OAuth Client editions, answered by the vendor

That left one question outstanding for eleven days, and we put it to miniOrange twice. Joomla sites report com_miniorange_oauth versions such as 13.0.0, 21.0.1, 32.0.0, 32.0.2 and 34.0.0, which on the scheme above are Basic, Standard and Premium builds, and the only fixed versions ever published for that extension are the free 3.2.0 for CVE-2026-77995 and 3.2.1 for CVE-2026-78074.

On 4 September miniOrange answered it. Their position is that CVE-2026-77995 “was associated only with the free version of the OAuth Client plugin”, that their investigation “confirmed that the vulnerability was not present in any version of the paid OAuth plugins”, and that this is precisely why no paid security build and no customer communication ever followed. On that account there was never a gap to close: the paid editions were not affected, so there was nothing to publish.

What that answer is, and what it is not

It is the vendor’s own investigation, stated in writing, and it is the answer we asked for. It is not a change to the published record, which still names one product, “miniOrange OAuth Client extension for Joomla”, with no edition qualifier at all. Anyone reading CVE-2026-77995 on its own still cannot tell that the paid line was assessed and cleared, because the record does not say so.

Weigh it against what happened three records ago. miniOrange scoped the SAML fixes to the free line too, and told us in writing that “all are the free versions”. Thirty hours later they shipped security releases for all four paid SAML editions, and the CVE record was widened to name every one of them. The same vendor has now twice said a flaw stopped at the free line. The first time that turned out to be wrong.

So this is reasonable evidence rather than proof, and the honest thing is to say which it is. If you run a paid OAuth Client build and want more than a vendor’s assurance, ask them to put the assessed version range in the CVE record itself, where an automated check can read it.

What to do about the SAML bypass

If your site runs a free edition, do not use the 26 August table above as your target. Those numbers close this record and have since been superseded by CVE-2026-78074, so updating to 11.0.2, 6.4 or 1.2.2 today leaves the third flaw open. Go to the table of 23 and take the number there, which closes both.

If it runs a paid SAML SP edition, update it to 13.2, 24.2, 34.2 or 44.2 according to your plan, reading the leading digit of your current version to work out which line you are on. That is the end of it for you, because CVE-2026-78074 does not touch the paid editions.

If your site runs a paid OAuth Client edition, miniOrange say there is nothing for you to do, because the flaw was never in a paid build. There is therefore no number to install. Read what that answer rests on before treating the question as shut.

In the meantime, if the site can function without it, disable or remove the extension. An SSO extension that will log an anonymous visitor in as an administrator is worse than no SSO for the day or two it takes to get a straight answer. If you cannot remove it, restrict access to the Joomla administrator area by IP or by network while you wait.

Then check whether it has already been used, the same way as for the OAuth flaw: unfamiliar administrator or Super User accounts, recently created or modified users, and administrator sessions in your logs from addresses that are not yours.

The third flaw: CVE-2026-78074, an unauthenticated uninstall

On 31 August 2026 the Joomla CNA published a third record against the same vendor, CVE-2026-78074, and it names 23 miniOrange extensions rather than one. Krzysztof Zając of CERT PL found this one too.

This one is a different class of flaw from the two above. A miniOrange endpoint is missing its authentication check, so an unauthenticated visitor can tell the site to uninstall an extension, and the site does it. Any extension, not just a miniOrange one.

Why an uninstall is worse than it sounds

An uninstall does considerably more than switch the extension off. Joomla runs the extension’s own uninstall script and drops the database tables that go with it, so the content and configuration held in those tables goes too, and no amount of reinstalling brings it back without a backup. Point that at a forum, a shop or a form builder and the damage is measured in whatever the last backup missed.

The second-order problem is what an attacker would aim it at first. Nothing restricts the target to the vendor’s own extensions, so a two-factor plugin, an admin-IP restriction, a security extension or a login handler can all be removed by someone with no account on the site. That is a useful thing to do immediately before trying something else.

The record scores it CVSS 4.0 8.8 High under CWE-284: Improper Access Control, below the two 10.0 records above it, and the vector says why: VC:N, no confidentiality impact. The attacker destroys, it does not read.

The 23 extensions and what fixes each

miniOrange released the fix for all of these on 31 August 2026, with Two Factor Authentication following on 1 September. We checked every number below against the extension’s own Joomla Extensions Directory listing rather than accepting the vendor’s list, and the release dates match.

Only the free editions are affected. The CVE says so in its own description, every range it publishes stops on the free numbering line, and miniOrange confirmed it to us in writing. Paid builds on the decade numbering, the 12.x, 21.x, 32.x and 44.x versions, are outside this record.

miniOrange extension for Joomla	Affected up to	Fixed in
SAML SSO for Joomla	11.0.2	11.0.3
miniOrange OAuth Client	3.2.0	3.2.1
SAML SP Single Sign On, Login with ADFS	6.4	6.5
SAML SSO login with Google Apps	6.4	6.5
OAuth Single Sign-On, OIDC SSO, Login with Azure AD	1.2.2	1.2.3
Login with Keycloak OAuth Single Sign-On	1.2.2	1.2.3
Single Sign On for Educational Institutes	1.2.2	1.2.3
SAML 2.0 IDP for Joomla	7.7	7.8
OAuth Server for Joomla	5.1.5	5.1.6
Two Factor Authentication 2FA for Joomla	5.0.9	5.0.10
OTP Verification For Joomla	6.6	6.7
LDAP Integration with Active Directory and OpenLDAP	6.4.7	6.4.8
Import Export Users for Joomla	4.6	4.7
Custom API for Joomla	4.2	4.3
SCIM User Provisioning for Joomla	4.0.5	4.0.6
Restrict Files / Folders / Media Access	3.7	3.8
Web3, Crypto wallet Login and NFT token gating	3.5.1	3.5.2
Staff/Employee Business Directory Search for Active Directory	2.0.4	2.0.5
Okta User Sync / Bi-directional user management	1.1.0	1.1.1
Keycloak user sync / User management	1.1.0	1.1.1
miniOrange User Provisioning with Azure	1.1.0	1.1.1
JoomAI, AI Assistant for Joomla	1.0.5	1.0.6
JoomShield by miniOrange	1.0.2	1.0.3

Patching in August was not enough

Seven of those rows supersede a fix from the previous round, so the sites most likely to be caught out are the ones that did the right thing a week ago. The OAuth Client’s 3.2.0 closed CVE-2026-77995 and is affected by this one, which needs 3.2.1. SAML SSO’s 11.0.2 closed CVE-2026-77998 and needs 11.0.3. The ADFS and Google Apps editions were fixed at 6.4 and now need 6.5. The three OIDC extensions were fixed at 1.2.2 and now need 1.2.3. If you updated in late August and stopped, update again.

Across the Joomla sites we monitor that run a miniOrange component, 53% are on a build this record covers, which is the highest share of any of the three.

What to do about the uninstall flaw

Update every miniOrange extension on the site to the version in the table, not just the one you were told about last time. The extension inventory is the quickest way to see which of the 23 you actually run and at what version, because several of them install under a display name that does not match the name in the CVE: the Restrict Files extension reports itself as the Joomla Content Access Manager, and the OAuth Client, the OAuth Server and the Azure AD extension all share one element and are told apart only by that name.

If an extension is installed but not actually used, remove it rather than updating it. Several of these turn up on sites that trialled a single sign-on option years ago and left the component behind, and an unused component is a live endpoint regardless.

Where you cannot update immediately, block unauthenticated access to the component’s endpoints at the firewall or in the web server. Unlike the two bypasses above, there is no compromise to hunt for afterwards. If this one was used against a site you would know, because something would be missing.

The part worth remembering

Days before this Joomla record appeared, the same vendor was in the WordPress security news for two critical unauthenticated authentication bypasses in its SAML Single Sign On plugin, both letting an attacker forge their way into /wp-admin as any user. Different extension, different platform, but the same vendor and the same underlying idea: an authentication extension trusting a value the attacker gets to set. That write-up is worth reading in full, not least for the way one WordPress listing turned out to hide seven separately versioned editions, which is the same version-numbering trap to watch for on the Joomla side.

We saw the WordPress write-up on 21 August, thought the vendor’s Joomla extensions deserved the same scrutiny, and forwarded it to the Joomla Security Strike Team that evening. Four days later there were two Joomla records. The OAuth one, CVE-2026-77995, was found by CERT PL and the credit there is theirs. The SAML one, CVE-2026-77998, is credited to us alongside Supakiad S. (m3ez). The lesson is the one we acted on: when a vendor ships a trust-the-client authentication flaw on one CMS, its extensions on the other CMS are worth checking straight away, rather than waiting for a separate disclosure to arrive on its own schedule.

There is a bigger version of this problem sitting behind the specific one. Plenty of extensions ship in both a WordPress and a Joomla edition, built by the same vendor from broadly the same ideas, and it is almost always the WordPress side that gets the security news first. Not because WordPress is more exposed, but because WordPress has Patchstack and Wordfence: funded projects whose whole job is to find these flaws, coordinate the disclosure with the vendor, and push the alert out to the people running the software. Joomla has no equivalent. When a Joomla extension is fixed, there is often nothing between the vendor’s changelog and the next hacked site. So the Joomla edition of a shared flaw tends to arrive later, with less noise around it, on sites whose owners never saw the WordPress headline that would have warned them.

That gap is a good part of why we write these up at all, and why we check a vendor’s Joomla extensions the moment its WordPress ones make the news. We track known security issues across every extension on every site we monitor, because a single vendor’s mistake rarely stays inside one product or one platform, and the sites that get hurt are the ones where no one was watching the version numbers.

The scores

CVE-2026-77995, miniOrange OAuth Client

10.0CVSS 4.0

CriticalThe Joomla CNA’s score, and the maximum possible

CVE-2026-77995 is scored AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, which is every metric at its worst: reachable over the network, no login, no user interaction, nothing that has to be true first, and consequences that reach past the extension into the system around it. The record is titled “Joomla Extension - miniorange.com - Arbitrary account takeover in miniOrange OAuth Client < 3.2.0”.

CVE-2026-77995Full account takeoverCookie manipulationNo login neededReaches admin accounts

Field	Detail
Extension	miniOrange OAuth Client for Joomla (`com_miniorange_oauth`)
Vendor	miniOrange (miniorange.com)
Type	Authentication bypass leading to account takeover
CVE	CVE-2026-77995, published 24 August 2026 by the Joomla CNA
CVSS 4.0	10.0 (critical), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`
CWE	CWE-287: Improper Authentication
Affected versions	1.0.0 up to and including 3.1.9
Fixed in	3.2.0
Finder	Krzysztof Zając, CERT PL, credited in the CVE record

CVE-2026-77998, miniOrange SAML SSO

10.0CVSS 4.0

CriticalThe second maximum score against this vendor in two days

CVE-2026-77998 is scored AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. A malformed SAML signature makes OpenSSL error, the error return value of -1 is read as a successful verification, and the attacker is logged in as whichever account they named.

CVE-2026-77998SAML signature bypassNo login neededReaches admin accountsVersion numbering unreliable

Field	Detail
Extension	miniOrange SAML SSO for Joomla (`com_miniorange_saml`)
Vendor	miniOrange (miniorange.com)
Type	Authentication bypass leading to account takeover
CVE	CVE-2026-77998, published 25 August 2026 by the Joomla CNA
CVSS 4.0	10.0 (critical), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`
CWE	CWE-639: Authorization Bypass Through User-Controlled Key
Affected versions	Free 1.0.0 to 11.0.1. Paid Basic to 13.1.0, Standard to 24.1.0, Premium to 34.1.0, Enterprise to 44.1.0. ADFS and Google Apps to 6.3.0, the three OIDC extensions to 1.2.1. The record was revised to this wider scope on 26 August 2026; it originally listed the free range alone
Fixed in	Free editions 11.0.2, and 6.4 for ADFS and Google Apps. Paid SAML SP editions 13.2 Basic, 24.2 Standard, 34.2 Premium, 44.2 Enterprise. Note that CVE-2026-78074 later supersedes several of these
Finder	Supakiad S. (m3ez) and Phil Taylor, mySites.guru, both credited in the CVE record

CVE-2026-78074, 23 miniOrange extensions

8.8CVSS 4.0

HighThe Joomla CNA's published record · CVE-2026-78074

A missing authentication check lets an unauthenticated visitor uninstall any extension on the site, running its uninstall script and dropping its database tables. It scores below the two records above it because there is no confidentiality impact: the attacker destroys rather than reads.

AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

Remote uninstallNo login neededDestroys data23 extensionsFree editions only

What does this mean?

CVSS 4.0 scores how severe a flaw is, from 0 (no impact) to 10 (critical). Each pair of letters in the string above is one metric; here is what this one's says.

How it is reached

AC:L: Low: Nothing to work around, it just works
PR:N: None: No account needed
UI:N: None: Nobody has to be tricked into anything

Field	Detail
Extensions	23 miniOrange extensions for Joomla, free editions only
Vendor	miniOrange (miniorange.com)
Type	Improper access control leading to unauthenticated arbitrary extension uninstallation
CVE	CVE-2026-78074, published 31 August 2026 by the Joomla CNA
CVSS 4.0	8.8 (high), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N`
CWE	CWE-284: Improper Access Control
Affected versions	One range per extension, all on the free numbering line. See the table above
Fixed in	One version per extension, released 31 August 2026, with Two Factor Authentication on 1 September
Finder	Krzysztof Zając, CERT PL, credited in the CVE record

Timeline

2026-08-16 The WordPress side is already being attacked DigitalOcean catches an unrecognised WordPress administrator session. The identical misreading of openssl_verify() there is CVE-2026-15981, reported as exploited in the wild and chained with a second flaw in the same plugin.
2026-08-21 We forward the WordPress write-up to the Joomla Strike Team We saw the Patchstack write-up that day, thought the vendor's Joomla extensions deserved the same scrutiny, and passed it on the same evening. We did not audit these extensions ourselves.
2026-08-24 CVE-2026-77995 is published for the OAuth Client at CVSS 10.0 "The manipulation of a cookie value allows actors to login as arbitrary accounts, including admins." Affected range 1.0.0 to 3.1.9, fixed in 3.2.0. Found by Krzysztof Zajac of CERT PL, and the credit there is theirs.
2026-08-25 CVE-2026-77998 is published for SAML SSO, also at CVSS 10.0 A different extension, and the one that matters more if you use miniOrange for single sign-on. Credited to mySites.guru alongside Supakiad S. Four days after the forward.
2026-08-25 We ask miniOrange a narrow question Through their own support form: for Joomla, what are the exact fixed versions of each of your products affected by this round. The published records are written on version numbers that do not match what real installs report.
2026-08-26 miniOrange answers, and the table includes three extensions fixed with no CVE at all The full list of fixed versions for every affected Joomla product, which is what an administrator actually needs and what no CVE record gave them. One line above the table limits all of it: all are the free versions.
2026-08-26 The paid editions are released with the fix, and finally have version numbers Thirty hours after telling us the numbers were free editions only, miniOrange emails its paying customers a per-edition table. SAML SP Basic is fixed in 13.2, Standard in 24.2, Premium in 34.2, Enterprise in 44.2, with everything up to 13.1, 24.1, 34.1 and 44.1 affected. David Jardin of the Joomla Security Strike Team posts the same four numbers publicly the same lunchtime, which is the first time any of them appear outside a customer mailbox.
2026-08-26 The CVE record still says 1.0.0 to 11.0.1 Checked straight after the paid versions were announced. The published record was last updated that morning, before the announcement, and still describes the free line only. Anyone comparing a paid install against CVE-2026-77998 alone is told they are fine when they are not.
2026-08-26 That gap closes the same evening CVE-2026-77998 is revised at 22:35 UTC to name all four paid editions (Basic to 13.1.0, Standard to 24.1.0, Premium to 34.1.0, Enterprise to 44.1.0), plus the ADFS and Google Apps editions and the three OIDC ones that had no record at all. An automated check reading the record now flags a paid install correctly.
2026-08-31 A third record, CVE-2026-78074, and this time 23 extensions A different flaw from the two bypasses: a missing authentication check lets an unauthenticated visitor uninstall any extension on the site, dropping its database tables with it. CVSS 8.8 High, CWE-284, credited to Krzysztof Zajac of CERT PL again. The record limits it to the free editions in its own description.
2026-08-31 miniOrange ships fixes for all 23 the same day Every affected free edition gets a release, confirmed against the Joomla Extensions Directory rather than the vendor's word. Two of the numbers move past the earlier fixes: OAuth Client needs 3.2.1 rather than 3.2.0, and SAML SSO needs 11.0.3 rather than 11.0.2.
2026-09-01 Two Factor Authentication follows in 5.0.10 The last of the 23, a day behind the rest. At this point the CVE record disagreed with itself here, giving 5.1.0 in its HTML solution block and 5.0.10 in the plain-text one. The directory listing and the vendor both say 5.0.10.
2026-09-04 miniOrange write to us asking for the fixed versions to be published Nutan Barad reports users arriving at their support desk from our coverage, sends the table of 23 fixed versions, and states that no paid edition is affected by this record. Asked why paying customers were emailed about a vulnerability in late August, they point out that message was CVE-2026-77998, a separate flaw that did affect the paid editions. That checks out against both records.
2026-09-04 miniOrange close the last open question, on their own word Asked a second time about the paid OAuth Client editions, miniOrange reply that CVE-2026-77995 was associated only with the free plugin and that their investigation found the flaw in no paid build, which is why no paid security release ever followed. It is the answer we asked for. It is also not a change to the record, which still names one product with no edition qualifier, and the same vendor scoped the SAML fixes to the free line before widening them to all four paid editions thirty hours later.
2026-09-04 The Joomla CNA corrects both errors within the hour We checked all 23 fixed versions against their Joomla Extensions Directory listings rather than publishing the vendor's list on trust, found two wrong entries in the record's own solution block, and reported them to the CNA. Two Factor Authentication now reads 5.0.10 rather than 5.1.0, and Import Export Users reads 4.7 rather than the truncated "4.". The revision is timestamped 10:30 UTC, about half an hour after the report.

Summer 2026: Everything New in mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 24 Aug 2026 00:00:00 GMT

If you already pay for mySites.guru, most of what follows is sitting in your account right now, and there is a fair chance you have not spotted it yet.

That is the strange thing about shipping steadily. The work arrives a piece at a time. A new check appears in an audit you were already running. A button turns up on a page you have opened a hundred times. Every one of them goes into the changelog in the left menu of your dashboard the day it ships, but not everybody reads a changelog, so this is the highlight reel.

Between 1 June and 24 August 2026 we added 38 new tools and features to mySites.guru, and improved 40 more that already existed. This is the first time we have written any of it up in one place, and it is the first of a seasonal series. Autumn will get its own. The post itself went up on 24 August. Two further days of shipping followed, and rather than hold them for the autumn edition, what went out on the 25th and 26th is folded into the sections below.

What follows is a tour of all of it, grouped by the problem it solves rather than the order it shipped, with a link straight into each tool. If you are not a subscriber, read it as the answer to a fair question: what does a platform like this actually do with three months, and would you rather be the person running those checks by hand?

Summer 2026, in six numbers

38 new tools and features, 1 June to 24 August
40 improvements to tools that already existed
60 new Joomla extension vulnerability rules, out of 221 we now track
19 Joomla extension vulnerabilities we found and disclosed ourselves in the first month alone
43 changes this year that exist because a customer asked for them
90 five-star reviews left over the same three months

Making hacked files stand out from suspect content

The biggest change is a split. Until June your audit had one list called Suspect Content, and it mixed two very different things: files we are certain are compromised, and files that only matched a heuristic pattern and are worth a look. Lumping them together had an honest and predictable result, which is that people learned to skim past the lot. There is now a separate Hacked Files (100% Certain) tool listing only what we are sure about, and Suspect Content shows only the pattern matches. If you have ever wondered which findings actually need you, that is the answer. Here is what the two lists mean.

Then the detection itself. The JCE compromise got a dedicated check that finds the rogue editor profiles the attack creates and the webshells it drops, removes both, and points you at the mass-update tools so the site cannot be breached the same way again. The full guide is here, and thanks to Marc for the push. Days later the scanner learned the mutations: renamed webshells, disguised droppers and obfuscated variants the first signatures missed.

The Helix Ultimate template framework got the same treatment twice. In July we started detecting menu code injected into a Helix mega menu, off the back of the unauthenticated menu write we disclosed in Helix Ultimate 2.2.7. Three weeks after that an attacker shipped a variant that broke out of the CSS class attribute and hid scripts behind font and image file extensions, so the check was rewritten to inspect every mega-menu setting at any depth, and the clean-up now blanks only the settings that actually matched. A separate check finds menu items drawing a correctly styled but completely empty mega-menu dropdown, usually under Home, left behind by a legacy layout setting from old Helix versions. That one is not a hack, a working mega menu is never touched, and one click fixes it.

Smaller, and worth knowing about: double-extension files like config.php.bak and shell.php.json, where a .php hidden behind a second extension can still be executed or leak your source code; PHP files disguised specifically behind a .json extension; the admin_mori and memetkaan worm accounts, now caught by username in the Rogue Super Admin check; and backdoor detection that matches known shell filenames before it reads a single byte, which makes audits faster as well as more accurate.

The new Cron Jobs tool reads the scheduled jobs on your server and flags any that match known malware patterns. Cron is how an attacker is still there after a file clean. You delete the webshell, a scheduled job puts it back an hour later, and you spend a fortnight wondering why the site keeps coming back. It went out in July and has since learned to leave your host’s own cron-auditing scripts alone, since those search crontabs for exactly the words we do. Here is why we built it.

Finally, the Multiple .htaccess Files tool gained a one-click button that deletes every stray .htaccess across your webspace in a single server-side pass, preserving your root file and the known hardening files. We have seen sites with close to 9,000 of them.

★★★★★

“If you think you've manually cleaned your Joomla site of all hacked files, you're 100% wrong. This program is absolutely incredible, and it finds Every File that is hacked or suspect.”

Mike K15 July 2026

AI, now that it earns its keep

Every company rushed to add “AI-powered” to their product: chatbots that frustrated users, buzzwords with nothing behind them. We sat that out, and people asked why.

For over a decade we have secured Joomla and WordPress sites. We knew the audit system worked well at finding threats, but it casts a wide net, and a wide net means false positives. Users had to read the code themselves or wait for us to review files by hand. So we spent months testing before shipping anything: thousands of files analysed, AI results compared against expert review, accuracy and cost measured. The question was never whether AI was fashionable. It was whether AI could reliably do the thing users struggle with, which is reading PHP, spotting suspicious patterns, and telling legitimate code apart from malware. It can.

False positives have cost our users hours of manual review for over a decade. This is the thing that addresses it, which is why this summer went on putting it everywhere it belongs.

“Analyse Files with AI” used to live on one tool. It is now on nearly every file list in the product: Hidden Files, SQL Files, Renamed Files, Mass Mailers, Upload Files, Modified Files and many more. If a tool hands you a list of files, you can bulk-scan them.

Two changes made that practical rather than expensive. Analysis now skips machine-generated cache files and Akeeba backup logs, so your spend goes on files that could plausibly be malicious instead of on noise. And there is a one-click key test on the AI Integration page that confirms your key is live and lists the models it can use, at no charge. When analysis does fail because a provider key has run out of credit, the error now says so in plain English and links you straight to that test, rather than showing you a raw API response.

One more thing, because people do ask. mySites.guru is not a vibe-coded side project. Plenty of those are appearing right now, and a fair number of them will be gone as quickly as they arrived, which is a problem when you have given one of them the keys to every site you manage. This is a full-time job and has been since 2012. The platform was built long before AI was mainstream, it is written and maintained by hand, and it is going to stay that way. We use AI the way any competent developer uses it now, which is to work faster. We do not use it to generate a product no one understands.

The part people miss: AI analysis is bring your own API key. You add a key from Anthropic or OpenAI, it is behind an admin toggle, and it does nothing at all until you turn it on. We do not resell tokens and there is no markup. The model list was refreshed in May to the current generation from each series, so the dropdown now offers Claude Opus 4.7, Sonnet 4.6 and Haiku 4.5 alongside GPT-5, GPT-5 Mini, GPT-4o Mini and o3. How the whole thing works.

The case for centralised management

This is the half of the product that justifies itself when you manage more than about ten sites.

Two new Joomla audit checks come with a toggle rather than instructions. Force SSL Should Be Set To Entire Site warns when a site does not force HTTPS site-wide, which can expose login and password-reset links over plain HTTP, and you flip it on from the audit result. Force Multi-Factor Authentication For Super Users flags Joomla 4.2 and newer where MFA is not enforced for the Super Users group, and turns enforcement on the same way.

A third toggle followed in the same week. Joomla’s Shared Sessions setting lets one session cookie bring your administrator login into the front end, so a stolen front-end session is an admin session. Every snapshot now flags it, and one click turns it off safely. Another new check finds Joomla’s Sample Data still switched on: unpublishing the dashboard tile leaves its install endpoint live, so we report the module and its install plugins separately and disable both together in one click.

Akeeba Admin Tools has a habit of auto-banning our IP address, which breaks audits, snapshots, backups and updates on that site. We now detect it and unblock with one click, both from the tools list and from the connection troubleshooting wizard, with no SSH or hosting login needed.

Joomla itself supplied a good deal of this summer’s work. Sites upgraded to Joomla 6 were being left with language update sites still pointed at the previous version, which stops language packs updating, so snapshots now flag it and fix it in one click. Joomla 5.4.7 and 6.1.2 shipped a regression where every per-article Option is ignored on the front end, so your snapshot counts the affected articles per site and Tools will apply Joomla’s official hotfix on request, only to an unmodified core file, and only when the result matches Joomla’s own patched file byte for byte. Then Joomla 5.4.8 and 6.1.3 broke the Template Manager, so a new tool shows which of your sites are affected and applies or removes the fix from Joomla PR #48274, checking the file before and after every write.

The JoomShaper Joomla 3 patch tool grew twice: it now deploys the latest Helix Ultimate fixes, and backports the SP Page Builder CSRF, rate-limiting and SQL-quoting fixes across 17 files, which matters because JoomShaper stopped shipping Joomla 3 security fixes, backing up each patched file individually rather than all or nothing. Sites still on an earlier patch are flagged so you can re-apply the newer one. It also spots a Helix Ultimate template style that has been wiped, which is what makes a site lose its header, logo and mega menu while the rest of the page still renders. That is the signature of the Helix3 defacement wave that lives in your database rather than your files.

Elsewhere, a new User Accounts and Access check finds users who belong to no user group on Joomla or hold no role on WordPress, and lets you assign or remove them in one click. User search gained last-login, password-reset and blocked-status columns, sortable, with bulk-blocking across your Joomla sites and CSV export, and has since been rebuilt into a full user manager on every site. And Joomla 3 sites with unpatched end-of-life security issues now show a patch count badge on your sites list that takes you straight to the fix.

The Joomla 3 end-of-life patch tool picked up four more core fixes in the same week: incorrect access control in the com_contact vCard download, XSS through language overrides, response header injection in download views, and unrestricted SHTML uploads. Six more core files are patched as a result, one of which Joomla 3.10.12 never shipped at all, so switching the tool back off deletes our copy rather than restoring a stock file that does not exist. It has grown again since, with fourteen more fixes backported from Joomla 5.4.9 and the spring 2026 releases.

The Limit The Number Of Super Admins To One check became a full viewer. It lists every account holding real Super User rights, including custom groups that inherit admin without being named Super Users, shows why each one matched, and can demote, block or delete an account, or reduce the lot to one in a single action. Anything that would leave you unable to log in is rejected. Underneath it, super admin detection stopped depending on the group being called “Super Users”, which had blinded some user tools on sites where the group was renamed or not in English or French.

The day after this post went up, mass updates got their own brake. The new Update Queue, off by default, runs at most one update per server at a time, so applying updates across twenty sites on one shared host stops throwing every update at that box simultaneously. Queued jobs can be cancelled before they run, a progress bar in the header tracks the batch, and hovering it breaks the queue down per server. Slower on purpose explains why it is opt-in and why we think you will want it anyway if your sites share hosting. The Update Log was rebuilt alongside it: the last 500 updates across your account, newest first, whether you applied them yourself or we applied them overnight, filterable on any part of a url, extension name or status, with CSV export. Thanks Adi, who was right to keep pushing for this one.

★★★★★

“In the past week I've been notified regarding new extension security updates and vulnerabilities, and with a 1 button click, all 20 were patched.”

Paul Bailey9 June 2026

The vulnerabilities we found ourselves

The vulnerability rules above have to come from somewhere. Increasingly, they come from us.

Between mid-June and late July we found and responsibly disclosed nineteen separate security vulnerabilities across seventeen popular Joomla extensions. Most were critical. Five rated the maximum CVSS 4.0 score of 10.0. Every one was reported privately to the vendor first.

It did not stop in July. Gridbox turned out to have an authentication bypass where one cookie made you a Super User, and then another 23 critical issues on a second pass. EasyStore was exposing customer invoices and accepting forged orders. SP Page Builder gave up a pre-authentication SQL injection and an open mail relay in July, then unauthenticated remote code execution in August. Phoca Cart had a front-end SQL injection. JEM has five issues and, at the time of writing, no stable fix.

The week this post went up added two more records at the maximum score, both authentication bypasses in miniOrange extensions for Joomla. In SAML SSO the extension checks a login signature with PHP’s openssl_verify(), which returns -1 when OpenSSL hits an error, and the code reads -1 as success. A malformed response therefore logs an anonymous visitor in as any account, administrators included. That record, CVE-2026-77998, is credited to mySites.guru alongside Supakiad S., after we forwarded the exploited WordPress edition of the same flaw to the Joomla Strike Team. The sibling record in the OAuth Client, CVE-2026-77995, is CERT PL’s find: one cookie value decides who you are. The same flaw is being actively exploited right now in the vendor’s WordPress plugin.

Neither CVE record helps much if your install reports one of miniOrange’s other edition numbers, because the same extension ships as several separately numbered products. A site reporting 44.0 sits on a different product line from one reporting 11.0.2, and the bigger number proves nothing. We asked the vendor directly for fixed versions of every affected Joomla product, and they answered with a table of seven, three of which had been patched with no CVE record at all, prefaced by the caveat that every number applies to the free editions only. The paid editions remain unanswered. The handling, as usual, is the part that goes wrong.

We are not the only people doing this, and that is a good thing. But we do it differently in one respect: we publish the standard we hold ourselves to, including what we expect from a vendor handling a report, because the handling is usually the part that goes wrong. Cotton Cloud patched the login and left the data. Page Builder CK shipped a fix that did not fix it.

Every one of those findings becomes a vulnerability rule in your account within hours, usually before the vendor has shipped anything. That is where a good number of this summer’s 60 new Joomla extension rules came from. When you get an alert saying a site is running something vulnerable, there is a reasonable chance we are the ones who found it.

Knowing before we have to tell you

There is now a public Latest Vulnerabilities page listing every Joomla and WordPress vulnerability we track, searchable, filterable by platform and severity, with no login required. Why we published it. The detail pages behind it have since been rebuilt: the advisory facts sit in a summary panel beside the description and use the full width of the screen, each CVE id links to its own NVD record instead of one link wrapped round the whole list, anything published in the last week gets a New pill, and copying a record’s CVE ids is one click.

Better than looking, though, is being told. A daily digest now emails you when a newly vulnerable extension turns up on one of your sites. It lists only what is new since the last one, so a site that fixes one vulnerability and gains another still reaches you, and whatever is already on your sites counts as the starting point so you are not emailed about the backlog. Thanks to Christian for that one. Alongside it, the vulnerable extensions panel on a site’s Manage page now shows a severity badge for each finding, says which version fixes it, and links straight to the full advisory. There is also a weekly digest for any site still flagged as hacked, so a compromise cannot slip off your radar.

On the site itself, warnings that used to stack above the tabs now live in a red Important tab that only appears when a site needs attention and opens itself when it does, so you arrive on what needs fixing. The day after this post went up, the tab gained your CMS itself: Joomla and WordPress sites show which core security vulnerabilities affect the version they are running, each naming the CVE, what the flaw actually is, how serious it is and the version that fixes it, worst first. Where we can already fix one for you the card says so: Joomla 3 sites see which of their vulnerabilities the one-click patch tool has handled and which are still outstanding. Your sites list keeps a core CVE count beside the familiar vulnerable-plugins count, kept separate so neither blurs the other, and the API and MCP endpoints return the same data under the existing site scopes. Near-realtime file change alerts on Joomla sites watch /index.php and libraries/src/Layout/LayoutHelper.php by default, both long-standing favourites with attackers. Downtime notification emails now name the server your site is hosted on, which makes a whole-host outage obvious at a glance rather than after the fifth email. Thanks Troy. Uptime alerts also link to the full explanation of how our monitoring works, including why a site that never went down can still be reported as down.

If you drive mySites.guru from an AI assistant, the MCP server gained a get_site_vulnerabilities tool, so you can ask which vulnerable extensions a site is running and get back the CVE, the severity and the version that fixes each one. Setting that up.

★★★★★

“I have to say the attention and notifications to users as related to JCE and SP PageBuilder exploits, site scans and recommended fixes have elevated mySites far beyond what we ever signed up for years ago when all we wanted was a quick way to automate backups.”

MarkImage Build · 16 June 2026

Getting out of your way

Not everything is security. A good deal of the summer went on the friction you notice every day and never get round to reporting.

You can now add up to 50 tags per site, up from 10. The Site Access list when adding or editing a team member has a search box and grows to show every site instead of sitting in a short scroll box, which matters once you pass about thirty sites. Thanks Tim. The Manage Site menu opens on click, with dropdowns that float over the page, instead of revealing on hover and shifting the content under your cursor.

Browse All Tools and the ⌘K quick launcher now list every audit check we run, not just the popular ones, so you can check a single issue across all your sites from one place. The “taking snapshot” dialog shows an honest elapsed timer with reassurance that updates the longer it runs, rather than a spinner that tells you nothing. The Locate And Review Files Over 2Mb tool sorts by file size, largest first. Thanks Adi.

Backup, Snapshot and Export now show how many sites they will actually touch once you have filtered your list, so the button reads Snapshot (12) rather than just Snapshot. Thanks Adi again. The extensions CSV export honours the filters you have on screen and covers every extension type your site reported.

Backups got three fixes worth having. Runs started from mySites.guru now include a description saying what the site was running and what started the run, such as “Joomla 5.4.8 - Manual - mySites.guru”, where every backup used to get the same fixed label and archives taken either side of a core update were impossible to tell apart. Manual, scheduled, bulk, API and MCP runs are each named. The backups list shows each archive’s description and comment under the date, including any comment you typed in Akeeba itself, which we were already being sent and were throwing away. And after an automatic extension update we now take a snapshot five minutes later, so the extension versions you see are the ones you just updated to rather than yesterday’s.

Then, right at the end of the summer, Frédéric pushed four more through in a single day. Descriptions now have the exact start time in UTC, which matters because Akeeba names each .jpa archive with its own timestamp, so you can finally match a backup in our list to the file on your server, and every row shows that filename with a one-click copy button. Start Backup on the Backups page now opens the profile picker, the same as on a site’s own Backup tab, and if you start one by hand you can type your own comment, which appears in Akeeba’s Manage Backups list beside the automatic description. Scheduled and bulk backups keep the automatic label. Thanks Frédéric, twice.

Paperwork you can hand a client

Agencies get asked for this, usually at the worst moment, and usually by a client’s compliance team.

Our Data Processing Agreement is now published in full: the complete sub-processor list, our technical and organisational measures, and exactly what data does and does not leave your connected sites. It is Article 28 GDPR compliant and you can accept it in one click if your process needs a dated record.

The Privacy page was rewritten to set out how little actually leaves a connected site. Routine monitoring sends counts and version numbers rather than content. Malware scan hashes stay in your own site’s database. Backups never reach us at all. The vendor list was corrected at the same time.

We also published a security disclosure policy covering the platform and the connector: where to send a report, what is in scope, how quickly we respond, and the safe harbour you get for good-faith research. There is a machine-readable copy at /.well-known/security.txt and a CycloneDX software bill of materials that we regenerate on every dependency change.

For the more practical kind of paperwork, there is a shareable reference page for web hosts listing every IP we connect from, the endpoints your connector calls out to, and exactly what to allow through the firewall in each direction. No login needed, so you can send the link straight to a hosting support desk. And the contact page now leads with any current platform issues, shows the three newest changelog entries, and answers 38 of the questions we get asked most.

Forty-three of these started as an email

This is the number I am proudest of, so it gets its own section.

Forty-three of the changes we made in the last twelve months exist because a customer wrote in and told us something. Not a feature request form, not a public roadmap board with votes on it. An email, usually two lines long, usually apologetic about bothering us.

Some of them are exactly what you would expect. Adi wanted the large-files tool sorted by size, largest first, and later pointed out that a bulk action should tell you how many sites it is about to touch, so the button now reads Snapshot (12). Laurent wanted the update results filtered by site tag, and got coloured tag pills under the search box. Tim wanted a search box on the team-member site-access list, which had outgrown its scroll box. Isidro wanted the Reload button on the By Site view to stay on the By Site view. Julian pointed out that our alert emails were unreadable in dark mode. Small things. Somebody’s daily irritation, fixed because there is one person to tell and he replies.

The ones I did not expect are the ones where a customer corrected the detection engine itself.

Andrés noticed the vulnerability matcher was flagging Slider Revolution installs as old as 6.7.x against an advisory that only covered 7.0.0 to 7.0.10, because the matcher was comparing against the patched version and ignoring the bottom of the range. That was wrong for every customer, not just his. Andrzej found two more in one week: a WordPress plugin flagged against a fixed version that only exists in the paid tier, so there was nothing to update to, and advisories writing a version as 4.3.0 while the plugin reports 4.3, which flagged people who had already updated. Marc caught the JCE compromise check reporting a defensive .htaccess as a backdoor, because a directory that denies PHP execution was being read as one that enables it. Scott found that the robots.txt one-click fix was reporting “Fixed!” on files with Windows line endings without changing anything at all, which is the worst kind of bug because it looks like success.

Pat went further and contributed a signature. The Rogue Super Admin Accounts tool now flags accounts created with the joomla@test.com address, because Pat had seen it on compromised sites and told us.

And then there is the one that still surprises me. In July a customer sent us a raw access log from their host, asking what a pattern in it meant. It was an active zero-day in Balbooa Forms, unpatched, letting an anonymous visitor upload a file and run code. We wrote the detection, warned every affected account directly, and published the workaround before the vendor had a fix. That disclosure started as one person forwarding a log file because something looked odd.

Marc, Adi, Laurent, Anne, Chris, Cathy, Tim, Mike, Antonis, Sven, Diggles, Andrés, Mirko, Isidro, Martijn, Nico, Troy, Scott, Julian, Frédéric, Peter, Andrzej, Wilm, Pat and Christian: thank you. The changelog credits every one of you by name, which is the least we can do.

If something in your account annoys you, or looks wrong, tell us. That is not a platitude, it is where forty-three of this year’s improvements came from.

And the nine months before that

Summer was busy, but it was not the whole year. Briefly, and in no particular order.

AI arrived in stages, starting last October with sending suspect content files to Claude or OpenAI, becoming full malware analysis in January. The public API got its OAuth and identifier work over the winter and was finally documented properly in June, and an MCP server went live the same month so you can drive your whole account from an AI assistant, ChatGPT included.

While we are here, two things that turned up on this blog in February are not new at all, and it would be cheeky to count them: passkey login has worked since 2020, and the Raycast extension for Mac has been around for years too. We had simply never written either of them up, which is its own kind of failure.

Two hosting compatibility checkers went up ahead of the big platform releases, one for Joomla 6 and one for WordPress 7, each comparing your server’s PHP and database versions against the official requirements. Joomla backward compatibility plugin status became trackable across every Joomla 5 and 6 site, with a remote toggle so you never log in to turn it off. Module versioning for Joomla 6.1 got a one-click enable, so module config changes can be rolled back.

Locked Joomla scheduled task detection went into the snapshot for Joomla 4.1 and up, thanks to Marc. A new tool audits and toggles the WP_AI_SUPPORT constant across WordPress 7 sites. Every blog post here became downloadable as a PDF. You can finally delete team members, which took an embarrassing number of years and a push from Tim. Three user tools appeared at once for both platforms: inactive users, unactivated users and blocked users, each with block, unblock and delete. Theme and template lists gained CSV export. And the Joomla 3 end-of-life security patch tool was updated in January to include every known fix for a version that is no longer supported.

What you are actually paying for

Speed of response

Two of the tools above exist only because Joomla shipped a regression and there was no upstream fix yet. When 5.4.8 and 6.1.3 broke the Template Manager so that creating overrides and folders failed, the tool that identifies affected sites and applies the community fix went out four days later. If you manage sites for clients, the gap between a platform breaking and someone handing you a fix is the thing you are actually buying.

Detection that keeps up

The Helix Ultimate mega-menu check was written in July and rewritten three weeks later, because an attacker adapted to it and started hiding scripts behind font and image file extensions. That is the normal shape of this work. A signature list no one revisits is worse than no signature list, because it tells you that you looked. The JCE checks went the same way, twice, in a single month. And on 26 August the Joomla CNA widened its Sourcerer advisory from below 14.0.0 to below 16.0.0, because each version published as the fix turned out to be vulnerable too: an unauthenticated remote code execution, exploited in the wild, where three successive “fixed” releases fixed nothing. Our rules had followed the original range, so a Sourcerer site could have read clean for nine days while still exposed. The corrected rules went out the same morning we saw the change. That is what detection keeping up honestly looks like: wrong for hours, then corrected, rather than wrong for weeks.

One person to tell

Everything in the section above happened because somebody wrote in and there was somebody to write to. That is worth more than any single tool on this page, and it is the part a feature list never shows you.

The price, which has not moved since 2010

One thing none of the sections above mention is what any of it costs, so: mySites.guru is £19.99 a month or £199.99 a year for unlimited sites, and annual works out 16.6% cheaper, which is roughly two months free. A single site is £5.00 a month.

The pricing page is the one page on this site we have never had a reason to rewrite. That price was set in 2010, while we were getting ready for the 2012 launch. In the sixteen years since there have been zero increases to the price of a subscription. Not a single one. Over the same stretch inflation has sat near record levels, our own costs have quadrupled since 2010, and AI has recently started pushing hardware costs up with everything else. The subscription has stayed where it was through all of it, every tool described above included.

It is an unlimited set fee, and the unlimited part is literal. We have subscribers with a single site and subscribers with thousands of them, all paying the same set fee. Customers stay an average of three to five years, which is its own answer to whether the arrangement works.

For a sense of scale: I personally spend more on coffee a month than the price of a mySites.guru subscription.

What is coming next

There is a long to-do list. There always is, and some of it has been sat on there for a year. One of the bigger items on it shipped right at the edge of this post’s window: a full web-based file manager for your connected Joomla and WordPress sites, jailed to the site root, opt-in, and logged twice. It is big enough to earn its own write-up rather than a line here.

Most of the next batch will come from somebody writing in, though, rather than off that list. Forty-three times in the last twelve months that is exactly what happened, and autumn will go the same way. So if something is missing, or slow, or in the wrong place, get in touch and say so. A request from somebody managing sites all day is worth more than anything we would sit here and invent.

The rest gets decided for us. A Joomla extension vulnerability turns up and a detection rule has to follow it, sometimes within hours. An attacker adapts to a check and the check gets rewritten, which happened twice this summer. And when the same question arrives in support three weeks running, it usually turns into a feature, because a question asked that often is telling us something is missing.

Which is why there is no roadmap with dates on it. The changelog in the left menu of your mySites.guru dashboard is the closest thing to one, written up the day each thing ships. If you want to know what is coming next, check there first.

Ninety people said so this summer

Between 1 June and 24 August, 90 people left a five-star review.

★★★★★

“So I'm just two weeks (or so...) here at mySites.guru. What should I say? Perfect. Secure. Reliable. And damn fast! Thank you, Phil, you saved my customers and my soul! :-) Greetings from Germany!”

Klaus Brandt1 August 2026

★★★★★

“Life changing. Amazing capability and TOP QUALITY design and interface. Would have added years to my life if I had discovered this earlier. I am dramatically more productive and my 25+ Joomla sites have never been better maintained or run more smoothly.”

TC29 July 2026

★★★★★

“Helicopter view for your sites & Timesaver for resolving technical issues or mass install (and so much more). A must have for everyone with many Joomla! and Wordpress installations.”

Timictineo.nl · 5 August 2026

★★★★★

“Saves time, saves money, saves websites from being hacked. What more could you ask for???”

Peter DowseMarketeam, Brisbane · 7 August 2026

Every reviewer is a real person with a real name, and that is intended. There are no anonymous testimonials on this site and nothing is paid for. WP Mayor also reviewed mySites.guru independently and scored it 4.6 out of 5, which is worth reading because we had no say in it. If you would rather read the recurring themes than the raw list, that is here, and we have since counted what all ninety of this summer’s reviews mention, which threw up a result we did not expect.

If any of this sounds like your week, the free site audit is the honest way to find out, and it does not need a card.

The next one

This becomes a seasonal post, so autumn 2026 gets the same treatment: what shipped, why, and who asked for it.

Subscribers do not need to wait for it. Everything here appeared in the dashboard changelog as it happened, in the left menu, with a badge showing whether it was new, improved or fixed. This post is a summary for people who would rather read the story once than follow it a line at a time.

The latest 90 reviews of mySites.guru - and what they said

phil@mysites.guru (Phil Taylor) — Mon, 24 Aug 2026 00:00:00 GMT

Between the ninth of June and the nineteenth of August, ninety people left mySites.guru a five-star review.

The obvious objection first, because it is a fair one. We asked. In June we replaced the third-party review form we had been using with our own, and then we asked people to use it.

So yes, the volume came from asking. What no one did was tell anyone what to write. There is no discount for leaving one, no prize draw, no template, no approval step, and no filter that loses the unflattering ones. The form is open to anyone, right now, including people who left years ago.

We could of course have chosen not to publish an unfavourable one. In practice the question almost never arises, because people who are unhappy with us do not tend to write it on our own site. They put it on social media, or on Trustpilot, which is an ironically named place to go when you have decided not to say it to someone’s face. That is entirely their right. We would still rather hear it directly, because a complaint we can read is a complaint we can fix, and quite a lot of this product exists because somebody did exactly that.

We already have a post pulling out the recurring themes from the reviews as a whole. This is a different exercise: rather than pick the six most flattering quotes and call it a testimonial page, we read all ninety from this summer and counted what people actually talked about. The result was not what we expected.

The most mentioned thing in the product is a person

Here is what appears in the ninety reviews, counted by hand:

What reviewers mention	Share of the 90
Phil, by name	36%
Time, or saving it	31%
Joomla	30%
Security	21%
Being hacked	21%
Monitoring	20%
Support	18%
Updates	18%
WordPress	9%
Vulnerabilities	8%
Audits	8%
Backups	6%
Price or value	6%

Every row links somewhere. The eight that map to a review topic open the reviews page filtered to it, and the rest go to the thing being talked about. On the filtered ones, expect a longer list than the percentage suggests: the percentages above count how many of this summer’s ninety reviews use the word, while the filter groups every review we have ever received by subject, which is a broader test over a bigger pool.

Read that top row again. In reviews of a piece of software, the single most mentioned thing is not a feature. It is the name of the person who answers the emails.

We did not set out to build a product with a person at the centre of it, and if you asked a product consultant they would probably tell you it is a liability. It is certainly not something you can put on a comparison table. But thirty-two of ninety people chose to name him, unprompted, when they were writing about a site management platform.

★★★★★

“We are using mysites.guru for many years and over 100 websites and are completely satisfied. The monitoring is reliable and provides peace of mind. We are impressed by the incredibly fast support - questions are answered competently and often within a very short time. A great service that saves us a lot of work in our daily operations and is absolutely worth the price. Highly recommended!”

Maya BaasBytekultur · 29 June 2026

The second thing worth noticing is what is low on that list. Backups get 6%. Price gets 6%. These are the things a feature comparison would lead with, and they are close to the bottom of what people bother to mention when writing freely.

What people are actually buying is the end of manual checking

Time comes up in 31% of reviews, and it is almost always the same shape of story: a number of sites that has grown past the point where a human can keep up. That is the whole argument for centralised management, and it is not one anybody believes until they have lived it.

★★★★★

“No one can manually monitor 25 CMS websites for security vulnerabilities in their extensions. With mysites.guru, it's almost a breeze.”

Andre EisenOwner, WERBEWERFT · 20 July 2026

Twenty-five is a modest number by the standards of this summer’s reviews. The counts people volunteered run from 20 sites up to well over 600.

★★★★★

“mySites.guru has been one of my best decisions for many many years. I run well over 600+ websites and simply could not do it without this amazing service. Thank you, Phil!”

John PalmerEmpro Web Development · 13 July 2026

The threshold where this stops being a nice-to-have seems to sit somewhere around twenty sites. Below that you can just about hold it in your head. Above it, something is always out of date and you will not find out which until it matters. The tools people name most often in this context are bulk extension updates, scheduled audits and backups, and the vulnerable extension alerts that tell you which of your sites is running something with a CVE against it.

★★★★★

“Been using mysite.guru for a month now and what a pleasure it has been. Already loaded 20 sites with lots more to come. In the past week I've been notified regarding new extension security updates and vulnerabilities, and with a 1 button click, all 20 were patched.”

Paul Bailey9 June 2026

Twenty-one percent of them mention being hacked

This is the number that would worry us if we were reading it about someone else’s product, so it deserves explaining. A large share of people find the service because they have just been hacked, and a fresh compromise is what they write about when they sit down to leave a review. If that is you right now, start with how to find hacked files and backdoors rather than with this post.

★★★★★

“My joomla-site was hacked by 2 hackers that got in through an older version of JCE. Thanks to Phil my site was completely cleaned, updated and working again in less than 24 hours. Thx”

Herman Vansynghel11 July 2026

That one is worth pausing on because it names the actual attack. The JCE editor compromise ran through the Joomla world this summer, and it is the reason a dedicated check now finds the rogue editor profiles and the webshells the attack drops. Herman’s site was cleaned through fix.mysites.guru, which is the separate fixed-fee service for when a site is already compromised and you want somebody else to deal with it.

★★★★★

“If you think you've manually cleaned your Joomla site of all hacked files, you're 100% wrong. This program is absolutely incredible, and it finds Every File that is hacked or suspect. The ability to view/edit/delete files right in the GUI is amazing, and a real time saver.”

Mike K15 July 2026

Mike is describing the thing that changed in June, when confirmed hacked files were split away from heuristic suspect content so that a real compromise is no longer buried in a list of files that turned out to be legitimate.

The reviews name features we have never marketed

Reading ninety reviews in a row surfaces something a roadmap never will: which parts of the product people actually notice.

Tagging came up, which went unwritten about here for years and now has a page of its own. Neither, for that matter, have we written much about tracking PHP versions across every site, and that turns up in the same review.

★★★★★

“Having all our managed sites in one place is an incredible a time saver not to mention receiving the heads up on updates and vulnerabilities, tracking php versions and software via tagging. Invaluable to our business.”

Artful Web Print Designartful.com.au · 13 July 2026

So did the audit results themselves, and the fact that sites stay permanently monitored between them, from somebody two weeks into using the product:

★★★★★

“I'm pretty new to mySites.guru and still finding my way around some of the tools, but so far I am very enthusiastic about it. The audits are really interesting and useful, and I love that my 70 sites are permanently monitored. I look at it every day and immediately have a good idea of the health of my sites.”

LieveHoot Koetuur · 23 July 2026

And the thing that generates the most email of anything we do, which is telling people about a vulnerability before their vendor does:

★★★★★

“The centralized management (backups, updates, malware protection, etc.) for all 115 of my websites makes my job so much easier. I also appreciate the proactive notifications about security vulnerabilities and the extremely fast response time to support requests!”

Christof RimleRimle IT Services · 14 July 2026

Those notifications are not a feed we resell. A good number of them come from vulnerabilities we found and disclosed ourselves: nineteen across seventeen Joomla extensions in one month alone, five of them rated the maximum CVSS 10.0.

If you have Joomla or WordPress sites and none of this is familiar

One sentence turned up, in one form or another, in a surprising number of these reviews. It is the reason this post exists.

★★★★★

“I've been managing multiple Joomla! websites for years, and I honestly can't believe I wasn't using mySites.guru sooner. It has completely changed the way I maintain and monitor my sites.”

TomaszAL-TAIR · 11 July 2026

Tomasz closes that review by calling it “one of those tools that, once you start using it, you wonder how you ever managed without it.” We are quoting it because it describes a specific and avoidable situation: running ten or fifty or two hundred sites on trust and a calendar reminder, then discovering the gaps only when one of them is defaced.

If you manage more than a handful of Joomla or WordPress sites and you cannot currently answer, in under a minute, which of them is running an extension with a known vulnerability, which has not been backed up this week, and which is on an unsupported PHP version, then you are the person these ninety reviews are describing before they found the tool.

The free audit answers those three questions for one site without a card. If your site is already compromised, fix.mysites.guru is a single fixed fee per incident, usually same day, and it is screened before anyone commits so you are not charged in the very rare case that it cannot be fixed.

Read them yourself, or add one

All 268 reviews are on the reviews page, oldest to newest, every one under a real name. WP Mayor reviewed the service independently and scored it 4.6 out of 5, which is worth more than anything we publish about ourselves because we had no say in it.

And if you use mySites.guru, the form is here. No one will ask you first.

Fabrik 4.7.2 for Joomla: A Long List of Security Fixes

phil@mysites.guru (Phil Taylor) — Sat, 22 Aug 2026 00:00:00 GMT

Updated 24 August: Fabrik 4.7.3 is out, and it is now the version to install

Fabrikar released 4.7.3 on Monday 24 August 2026. It adds no new security fixes: it mops up two regressions that 4.7.2 introduced, links to Fabrik pages from outside websites returning a 404 error, and HEAD requests to Fabrik forms returning 404 while GET returned 200. It has every security fix listed below, and it also ends the guessing that the re-issued 4.7.2 builds caused, because a site showing 4.7.3 has the full fix set. This time the release is in Fabrik's Joomla update feed, so the Joomla updater should offer it on sites with a valid subscription.

Fabrikar released Fabrik 4.7.2 for Joomla on 22 August 2026. It is a security release, and it closes a long list of unauthenticated vulnerabilities in the application and form builder, most of them found and reported by mySites.guru and credited to us by name in Fabrik’s own changelog.

If you run Fabrik on any Joomla site, update now. The current release is 4.7.3, a bug-fix follow-up from 24 August that includes everything 4.7.2 closed. This post is the plain list of what it fixes and what to do. For the back-story of how the 4.7.x line got here, across 4.6.7, 4.6.8, 4.7.0 and 4.7.1, see The Fabrik Fiasco.

TL;DR

Fabrik 4.7.2 (22 August 2026) is a security release closing a long list of unauthenticated vulnerabilities: remote code execution, SQL injection, arbitrary file upload, directory listing, database table listing, row disclosure, comment manipulation, path traversal and a heredoc breakout
Most of the fixes are credited to mySites.guru in Fabrik’s changelog
The Joomla CNA has published seventeen CVE records, and sixteen credit mySites.guru as the finder, four of those at CVSS 10.0
Update every Fabrik install to 4.7.3 (24 August 2026), a bug-fix follow-up that has every security fix in 4.7.2 plus repairs for two 404 regressions, and whose version number, unlike the re-issued 4.7.2 builds, tells you exactly what you have
Joomla 3 sites cannot install any Fabrik 4 release. There is a manual one-line vendor patch for the calc flaw, offered as-is; plan removal or migration
mySites.guru flags every connected Joomla site running Fabrik below 4.7.2

The full list of fixes

The Joomla CNA has published seventeen CVE records for this release, and sixteen of them credit mySites.guru as the finder, four of those at the maximum CVSS 10.0. They are listed here worst first, and every CVE links to its published record. One of the seventeen, the database table listing, appears in no version of Fabrik’s changelog at all; its CVE record is the only public documentation it has.

CVE	CVSS 4.0	What it is	Reported by
CVE-2026-76604	10.0 Critical	Unauthenticated remote code execution via `form_php` `_runPHP`	mySites.guru
CVE-2026-76605	10.0 Critical	Unauthenticated remote code execution via the image element with the eval flag	mySites.guru
CVE-2026-76606	10.0 Critical	Path traversal in the image element	mySites.guru
CVE-2026-76607	10.0 Critical	Missing access check in the download plugin’s foreign-key branch	mySites.guru
CVE-2026-77992	9.5 Critical	Heredoc escaping breakout in the calc element	mySites.guru
CVE-2026-76571	9.3 Critical	Unauthenticated SQL injection in the list filter condition parameter	mySites.guru
CVE-2026-76602	9.3 Critical	Unauthenticated SQL injection in ORDER BY, via a `CONCAT(` allowlist bypass	mySites.guru
CVE-2026-76596	8.7 High	Unauthenticated table truncation via `list.doempty`	mySites.guru
CVE-2026-76597	8.7 High	Unauthenticated arbitrary file upload to the web root, in the list email plugin	mySites.guru
CVE-2026-76598	8.7 High	Unauthenticated arbitrary directory listing via `onAjax_getFolders`	mySites.guru
CVE-2026-76599	8.7 High	Unauthenticated database table and table-prefix disclosure via `ajax_tables`	mySites.guru
CVE-2026-77027	8.6 High	Unauthenticated stored XSS via the JS-Actions feature	Fabrik
CVE-2026-76600	6.9 Medium	Unauthenticated deletion of any comment	mySites.guru
CVE-2026-76601	6.9 Medium	Unauthenticated row reordering in the Order plugin	mySites.guru
CVE-2026-76603	6.9 Medium	Unauthenticated row disclosure via `form.inlineedit`	mySites.guru
CVE-2026-76608	6.9 Medium	Unauthenticated disclosure of any commenter’s email address	mySites.guru
CVE-2026-76609	6.9 Medium	Unauthenticated modification of any comment	mySites.guru

Fabrik 4.7.2 also re-closed a regression of the original calc-element flaw, CVE-2026-66915, which had been reachable again through a second placeholder substituter; the changelog credits mySites.guru with reporting that regression. The two remote code execution flaws that started this whole run, CVE-2026-66915 in the calc element (reported by Moe Khalilov of LeetProtect Research) and CVE-2026-67282 in the list filter model (reported by Murad Gasimov), were both scored CVSS 4.0 10.0 Critical and fixed earlier in the 4.6.x line.

Just how bad is this?

Honestly, about as bad as an extension vulnerability set gets. Four of these are scored CVSS 10.0, the maximum, and each of the four is reachable by an anonymous visitor with no login: two are direct remote code execution, one is a path traversal in the image element, and one strips out an access check. Add the 9.5 heredoc breakout and the two 9.3 SQL injections and that is seven Critical-rated unauthenticated flaws in a single component, before you count the Highs and the Mediums.

We have been finding and reporting Joomla extension vulnerabilities for years, and a list this long and this severe closed in one release is among the worst we have seen in a long time. If you run Fabrik, treat it that way. Any version below 4.7.2 should be assumed exposed, and the sites most at risk are the ones that publish a Fabrik form or list a visitor can reach without logging in.

What to do

Update every Fabrik install to 4.7.3. It is the current release, published 24 August 2026, and it contains every security fix from 4.7.2 plus repairs for two 404 regressions that 4.7.2 introduced, on links to Fabrik pages from outside websites and on HEAD requests. It needs a valid Fabrik subscription, and this time it is in Fabrik’s Joomla update feed, so the Joomla updater should offer it; if it does not, download it from My Download Files on fabrikar.com. A site showing 4.7.3 has the full fix set, which the version string alone could never tell you on the re-issued 4.7.2 builds.
Test before you deploy. 4.7.x is a real upgrade rather than a point release: it breaks any userAjax calls you use, and sites running the FullCalendar or Paypal plugins need those updated to current versions at the same time. Install and test on a sandbox before a live site.
Joomla 3 sites need a different plan. Fabrik 4 installs on Joomla 4.2 and above and Joomla 5.1 and above only. There is no patched Fabrik 3 release. The vendor has published a manual one-line source patch for the calc flaw in its Announcements forum, offered as-is with no warranty; apply it as a stopgap while you plan removal or migration.
Check exposed sites for compromise. An unauthenticated flaw leaves no login trail, so updating does not tell you whether a site was already hit. Look for unfamiliar administrator accounts, recently modified or unexpected PHP files, and scheduled tasks you did not create.

Finding every Fabrik install across your Joomla sites

The hard part of a list like this is not the fix, it is finding every site that needs it before an attacker does. mySites.guru keeps a live inventory of every extension on every connected Joomla site and flags the ones running an affected version of Fabrik, so this turns into a filtered list rather than an afternoon of logging into control panels. We flag every Fabrik install running any version below 4.7.2.

At a glance

Field	Detail
Component	Fabrik for Joomla (`com_fabrik`)
Vendor	Fabrikar (fabrikar.com)
Type	Multiple unauthenticated flaws: remote code execution (CWE-94), SQL injection (CWE-89), arbitrary file upload (CWE-434), path traversal (CWE-22), directory listing and access-control failures
CVSS 4.0	Up to 10.0 (Critical). Four issues score the maximum 10.0, seven are Critical in all, the rest High and Medium
CVEs	Seventeen published by the Joomla CNA, sixteen crediting mySites.guru as finder. The full list, with links and scores, is in the table above
Impact	Unauthenticated remote code execution, full-database SQL injection, arbitrary file upload to the web root, and unauthorised disclosure or modification of data, most with no login, token or user interaction
Finder	Phil Taylor, mySites.guru (sixteen of the seventeen)
Affected versions	Every Fabrik release below 4.7.2
Fixed in	Fabrik 4.7.2, released 22 August 2026. The current release is 4.7.3 (24 August 2026), a bug-fix follow-up with no security changes

Timeline

2026-08-16 We report four unauthenticated issues to Fabrik and the Strike Team A list-filter blind SQL injection reading any table, an arbitrary file upload reaching the web root, a list truncation, and a directory listing. A bypass of the SQL injection fix follows on 18 August, and a heredoc breakout on 22 August.
2026-08-22 Fabrik 4.7.2 ships as a security release It closes a long list of unauthenticated vulnerabilities: remote code execution, SQL injection, arbitrary file upload, directory listing, database table listing, row disclosure, comment manipulation, path traversal and a heredoc breakout. Most of the fixes are credited to mySites.guru by name in Fabrik's own changelog, which is a change from how the 4.6.x releases were handled.
2026-08-24 4.7.3 becomes the version to install No new security fixes. It repairs two regressions 4.7.2 introduced, on links to Fabrik pages from outside websites and on HEAD requests, and it is in Fabrik's Joomla update feed, so the updater should offer it.
2026-08-25 Seventeen CVE records are published, sixteen crediting mySites.guru Four of them score CVSS 4.0 10.0, seven are Critical in all, and the rest High and Medium.

Five Security Issues in JEM (Joomla Event Manager), and No Stable Fix Yet

phil@mysites.guru (Phil Taylor) — Sat, 22 Aug 2026 00:00:00 GMT

JEM, the Joomla Event Manager, is a long-running events component for Joomla. During security research on the extensions our customers rely on, mySites.guru found several security issues in JEM and reported them privately to the developers and to the Joomla Security Strike Team. The Joomla project’s CVE Numbering Authority has assigned five CVE IDs.

The most serious of them lets an anonymous visitor, with no account at all, overwrite and publish a Joomla article. There is one catch that shapes everything below: the fixes exist so far only in a release candidate, not a stable release, so there is no finished version to update to yet. This post covers what was found, the CVE numbers, and what you can do right now.

TL;DR

mySites.guru found and privately reported multiple security issues in JEM (Joomla Event Manager), the com_jem component, confirmed against JEM 5
The most serious lets an anonymous visitor overwrite and publish a Joomla article with no login. Others allow a registered user to take over another user’s event or venue, a reflected cross-site scripting flaw in the PDF export link, and attendee data readable by any logged-in user
The Joomla CNA assigned five CVE IDs, and all five published on 27 August 2026, each crediting mySites.guru as the finder: CVE-2026-77991 (9.4 Critical), CVE-2026-77034 (6.9), CVE-2026-77990 and CVE-2026-77989 (5.3 each), and CVE-2026-77035 (5.1)
The fixes are in JEM 5.0.1, which at the time of writing exists only as a public release candidate, not a stable release. The newest stable version, 5.0.0, is affected
There is no stable fix to install yet. Apply the mitigations below, and update to JEM 5.0.1 the moment the stable release is available
mySites.guru flags every connected Joomla site running an affected version of JEM automatically

We reported these issues privately, as we always do. The reason this is public before a stable release exists is that the vendor pushed the corrected code to a public release candidate on GitHub, and once the fix is public the flaw is too. We are publishing now, with mitigations, so the site owners who depend on JEM hear it from us.

What was found

We confirmed four issues against JEM 5 and noted two more from reading the code. We are describing them at the level of what an attacker can do and how to limit it, not publishing working exploits.

An anonymous visitor can overwrite and publish an article

JEM has a front-end action that updates the Joomla content article attached to an event, and it performed no permission check before writing to that article, including setting it to published. A visitor with nothing more than an ordinary session could republish and overwrite an article, including one that was unpublished. This is the most serious of the set because it needs no account at all and it writes to core Joomla content.

A registered user can take over another user’s event or venue

The check that decides whether you may edit a record trusted values sent in the request rather than the values stored in the database. A logged-in user with permission to edit their own events could send another user’s record along with their own identifier and take the record over. This needs only a plain registered account on a site that lets members create events.

A reflected cross-site scripting flaw in the PDF export link

The export link copied the page’s request parameters into the page without escaping them, so a crafted link could inject markup that runs in the victim’s browser. Joomla’s standard text filtering does not stop this, because the injection does not need HTML tags.

Attendee data readable by any logged-in user

The attendee list only checked that a visitor was logged in, not that they were entitled to see that event’s attendees. Any registered user could read attendee names, usernames, registration dates and statuses for events they do not manage, including events that are not published.

Two further items we noted from the code but did not exploit: an authenticated back-end file write that did not restrict file types, and a stored cross-site scripting issue through unescaped category names. Both need an account with elevated permissions, so they rank below the four above.

The five CVEs

The Joomla project operates its own CVE Numbering Authority, and it assigned five identifiers for these issues on 22 August. All five published on 27 August 2026, and every record credits mySites.guru as the finder. Each one gives the affected range as 1.0.0 to 5.0.0, fixed in 5.0.1.

CVE	Issue	CVSS 4.0
CVE-2026-77991	Privileged remote code execution, through the administrator source model writing dangerous file types including PHP	9.4 Critical
CVE-2026-77034	Unauthenticated article overwrite and force-publish	6.9 Medium
CVE-2026-77990	Attendee lists readable by any logged-in user	5.3 Medium
CVE-2026-77989	Reflected cross-site scripting via the PDF export link	5.3 Medium
CVE-2026-77035	Cross-user event and venue takeover through forged form fields	5.1 Medium

The top score revises what we said above. We put the back-end file write in the “noted from the code, did not exploit” pile and ranked it below the four confirmed issues. The CNA scored it 9.4 Critical, the highest of the set, because writing PHP to the server is code execution however you arrive at it. It does need an account that already holds administrator access, which is why the record calls it privileged rather than unauthenticated. But if you are deciding who gets an administrator login on a site running JEM, decide it on the 9.4.

What to do right now

There is no stable release to update to yet, so the immediate job is to reduce who can reach the affected features:

Find your JEM sites. If you use mySites.guru, we have already flagged every connected site running an affected version of JEM, so you have the list. If not, check each site’s installed extensions for JEM and confirm the version.
Restrict front-end editing. If your site lets members create or edit events and venues from the front end, limit that to trusted users, or turn it off until you can update. This closes the record-takeover route and the article-overwrite route on any site that had front-end submission enabled.
Restrict the front-end attendees view to event managers rather than any logged-in user, so attendee lists are not readable by ordinary members.
Watch for JEM 5.0.1 stable and update the moment it ships. The fixes are already written; they just need to be released as a stable version rather than a release candidate. We will update this post when that happens.

Do not put the release candidate straight onto a production site you care about. A release candidate is a test build, not a finished release. The safer path is the mitigations above now, then the stable 5.0.1 when it is out.

How mySites.guru handles this across many sites

If you manage more than a handful of Joomla sites, the hard part of a story like this is not the fix, it is finding every site that needs it before an attacker does. mySites.guru keeps a live inventory of every extension on every connected site and flags the ones running affected versions, so a vulnerability like this turns into a filtered list rather than an afternoon of logging into control panels. When JEM 5.0.1 stable ships, the same list tells you which sites still need the update.

A note on how this was disclosed

Why is a set of security issues public before there is a stable fix to install? Because the corrected code was pushed to a public release candidate on GitHub before a coordinated release. Once the fix is public, anyone can compare it against the current version and see what changed, which is the moment a private disclosure stops being private. The Joomla Security Strike Team, which assigned the CVE numbers, put it to the vendor: the uncoordinated release candidate turned a responsible disclosure of security issues into a public matter.

We recently republished the Joomla project’s own guidance for extension developers handling a security report, twenty documented practices, and a couple of them are worth noting here. One is to keep the fix private until a coordinated stable release, rather than shipping it in a public release candidate. Another, point 17, is not to hide security fixes in vague language: the commits with these fixes are described with lines like “Improve frontend attendee access handling”, which give no sign that they are security fixes at all. None of this is a swipe at the JEM developers, who are volunteers and who engaged once the report reached them. It is why coordinated disclosure exists, and it is the same standard we hold every extension to.

Where this stands, four days on

Updated 26 August 2026. Four days after the CVE IDs were assigned there is still no stable JEM release, and the gap between what is public and what is installable has got wider rather than narrower.

Nine flaws, mapped in public

RC2 shipped on 24 August with nine security fixes listed in public, each one graded CRITICAL or HIGH, each naming the affected versions and linking the exact commit that fixes it. That is a complete guide to every flaw, published while there is still no stable release anyone can install.

Four days to open an email

The Joomla Security Strike Team assigned the five CVE IDs on 22 August and asked the vendor to push a stable release as soon as possible. The reply came on 26 August: “I apologise for the late response, I initially missed this email.”

RC2 was already two days old

That same message told us RC2 was expected to be ready “today”, and would go public after testing. It had been published on the project's own website on 24 August, security changelog and all, two days earlier.

Five CVE IDs, nothing to link to

Assigned on 22 August and still unpublished on 26 August, so there is no public record, no CVSS score and no official affected range for any of the five. Site owners cannot look up what they are exposed to.

One useful thing did come out of the RC2 changelog. The vendor’s own version labels list 4.4.2 and 4.5.0 as affected alongside 5.0.0, which is the first confirmation that this reaches back beyond JEM 5 into the 4.x line. If you run JEM 4.x and had filed this away as a JEM 5 problem, it affects you too. The same changelog notes that only stable releases confirmed in the project history are labelled, so older versions are not cleared, they are simply unlabelled.

We will update this post with the CVE record links, scores and the stable release version once they are available.

Timeline

2026-08-21 We report the issues privately mySites.guru is asked to review JEM 5. We confirm four issues live and note two more from reading the code, and report all of them the same day to the vendor and to the Joomla Security Strike Team.
2026-08-22 The vendor puts the fixes in a public release candidate JEM announces the corrections in a 5.0.1 release candidate and asks us to re-test. Shipping corrected code before a coordinated stable release is the moment this stopped being private, because anyone can compare it against the current version and see what changed.
2026-08-22 The Joomla CNA assigns five CVE IDs CVE-2026-77034, CVE-2026-77035, CVE-2026-77989, CVE-2026-77990 and CVE-2026-77991. The Strike Team tells the vendor that the uncoordinated release candidate has turned a responsible disclosure of security issues into a public matter. The records are reserved, not published.
2026-08-22 We publish this post and write to affected customers JEM is added to our vulnerability checks so every connected site on an affected version is flagged, and we email the affected accounts directly rather than waiting for a dashboard badge to change.
2026-08-24 RC2 ships with a full public security changelog Nine security entries, each graded CRITICAL or HIGH, each naming the affected stable versions and linking the commit that fixes it. The labels list 4.4.2 and 4.5.0 alongside 5.0.0, so this reaches back beyond JEM 5. There is still no stable release.
2026-08-26 The vendor breaks four days of silence The project's site admin apologises for missing the Strike Team's email, says the developers are working through the reports, and expects RC2 to be ready that day. RC2 had been public on the project's own website since 24 August.
2026-08-26 Still no stable fix, and still no published CVEs The newest JEM release remains 5.0.0-stable, from 8 July. All five CVE records still return nothing on cve.org. Every JEM site is on an affected version with no finished release to move to.
2026-08-27 All five CVE records publish Five days after assignment, all five records go live, and every one credits mySites.guru as the finder. The affected range is 1.0.0 to 5.0.0. The privileged remote code execution issue scores 9.4 Critical, the highest of the set. The newest JEM release is still 5.0.0-stable, so there is still nothing to install.

Joomla 5.4.8 and 6.1.3 Break the Template Manager

phil@mysites.guru (Phil Taylor) — Wed, 19 Aug 2026 00:00:00 GMT

If you have updated a Joomla site to 5.4.8 or 6.1.3 and then tried to create a template override, you will have seen this:

Joomla\Filesystem\Path::check() - Snooping out of bounds

Both releases shipped a regression in the Template Manager. It stops four separate things from working, and it is not caused by your site, your template, or your host.

Update anyway

5.4.8 and 6.1.3 are security releases. Between them they close ten advisories, [20260801] to [20260810], including an MFA authentication bypass and unrestricted uploads of SHTML files. If you are still on 5.4.7 or 6.1.2, the right move is to update and then deal with this bug, not to sit on an older release to avoid it. They also fix the regression that made 5.4.7 and 6.1.2 ignore every article option, which is a second reason not to stay put. This post is about how to deal with the new one.

What is broken

All four are administrator actions, and all four were confirmed working in 5.4.7 and 6.1.2:

creating a template override for a component
creating a template override for a plugin
creating a folder inside a template
deleting a folder inside a template

Editing template files you already have still works. So does everything outside the Template Manager. If you never create overrides, you may never notice.

What caused it

One file, administrator/components/com_templates/src/Model/TemplateModel.php, and one pull request: #48171.

It swapped 33 calls to Path::clean() for Path::check(). The difference matters more than it looks. Path::clean() normalises a path string. Path::check() normalises it and rejects anything that resolves outside the Joomla root, throwing if it finds one. Several of the swapped calls are given relative fragments rather than complete paths, so Path::check() sees what it reads as an escape attempt and stops the request.

Worth saying, because it changes how you should feel about reversing it: the author of #48171 stated in the pull request itself that it was not a security fix. The Template Manager is restricted to super users, who can already edit template files and therefore already execute code. The change existed to stop a stream of automated reports about missing traversal checks. It is also absent from the ten security advisories that accompanied 5.4.8.

That single pull request is the only change to that file between 5.4.7 and 5.4.8, and between 6.1.2 and 6.1.3.

When is it fixed

Pull request #48274 is the fix, and it was merged on 20 August 2026, closing issue #48273. It went into 5.4-dev as commit eacfb318, and reached 6.1-dev the same day through upmerge #48278.

The fix shipped in Joomla 5.4.9 and 6.1.4 on 29 September 2026, alongside 16 security fixes covered in the 5.4.9 and 6.1.4 security release write-up. Any site still on 5.4.8 or 6.1.3 has the broken file on disk until it updates.

The answer is to update to 5.4.9 or 6.1.4. The sections below are for sites that cannot update yet: they can live with it, replace the file by hand, or have something do it for you. Staying on the older release is not an option, for reasons covered below.

Joomla has now documented it

Four days after the releases, the Joomla project published known issues pages for both, dated 22 August 2026:

Both name issue #48273 and point at #48171 as the cause, and both give the same workaround: replace administrator/components/com_templates/src/Model/TemplateModel.php with a copy pinned to a specific commit on GitHub. There is still no installable patcher package of the kind the July article options regression got, which shipped as a ZIP that patched the file and then removed itself. This one is a manual file swap. The file is published and pinned to a commit, though, so you are copying a known file into place rather than reconstructing one from a diff.

That file is, byte for byte, the one our tool already writes. Joomla’s recommended replacement is MD5 8ac7c42c6a821c838699564116b1815e on 5.4.8 and 5169f093c66b466c411f594e9a72e869 on 6.1.3, and those are the two checksums our patched state reports. Either route leaves the same bytes on your site, so you can check ours against theirs instead of taking our word for it.

Fixing it by hand

Take a copy of the file on your site first. Then download the replacement file that Joomla links from the known issues page for your version, check its MD5 against the value above, and put it in place of administrator/components/com_templates/src/Model/TemplateModel.php.

Two things to know before you do:

The next Joomla update overwrites it

That is not a problem. That update is the permanent fix, and your hand-edit becomes redundant the moment it arrives.

Your site now has a modified core file

Anything watching for core file changes will say so, and it should. That is the honest answer to the question it was asked.

Doing it from mySites.guru

We have added a tool that does both directions. It reads that one file on each connected site, tells you exactly which state it is in, and gives you a button.

Here is an affected site. The checksum shown is byte-for-byte what Joomla shipped in 6.1.3, which is how we know this is the unmodified broken version rather than something someone has edited:

Press Apply The Fix and it patches the file and re-reads it from disk to confirm:

The same card now reads back as patched, with the checksum of the fixed file. The Template Manager works again, and the button has become Remove The Fix:

Removing it puts the file back to exactly the bytes Joomla shipped:

It reports one of six states rather than a yes or no, because “we patched it”, “Joomla shipped it broken and we can fix it”, “it is broken but somebody has already edited this file so we will not touch it”, and “we cannot read the file” are four different things to be told.

The safety model is the part worth explaining. Before writing anything, we check the checksum of the file already on your site and require it to be exactly what Joomla shipped. If somebody has edited it, we reject it and tell you, rather than overwriting work we cannot see. After building the replacement we check its checksum too, and after writing it we read it back off disk and check it a third time. If any of those three checks disagrees, nothing is written.

The reverse direction, Remove, runs the same three checks and restores the file byte for byte to what Joomla 5.4.8 or 6.1.3 shipped. At no point does your site hold a version of that file that came from anywhere other than Joomla or that pull request.

Because it is targeted at these two releases specifically, the tool disappears by itself once you update to 5.4.9 or 6.1.4, which shipped on 29 September 2026.

What to do now

If you are on 5.4.7 or 6.1.2, update to 5.4.9 or 6.1.4 now, which fixes both this bug and the ten security issues in 5.4.8 and 6.1.3. Do not sit on the older release to dodge this bug. 5.4.8 and 6.1.3 are security releases, and holding back trades ten security fixes for one admin-panel inconvenience. That is a bad trade in every direction: the bug is an annoyance for whoever builds the site, and an MFA bypass is a way in for someone who does not work for you.

If you are already on 5.4.8 or 6.1.3, update to 5.4.9 or 6.1.4. If you create overrides and cannot update yet, patch it, by hand or from here, and expect your next audit to report one changed core file. That is the patch, and it is meant to be there.

If you are already on 5.4.8 or 6.1.3 and you never touch the Template Manager, you need do nothing. You are on the secure release, and the only thing you lose is the ability to create overrides and template folders until you move to 5.4.9 or 6.1.4.

Across a portfolio the awkward part is not the patch, it is knowing which sites are on which release before a developer hits the error and opens a ticket. That is the same problem as the article options regression a fortnight earlier, and the same answer: mySites.guru records the Joomla version on every connected site twice a day, so you can update them in bulk and see at a glance which ones are sitting on a release with a known bad patch. It is also why accidental version jumps are worth guarding against separately.

A CVSS 10.0 Unauthenticated Upload in YOOtheme ZOO, Fixed in 4.1.66

phil@mysites.guru (Phil Taylor) — Wed, 19 Aug 2026 00:00:00 GMT

ZOO is YOOtheme’s content construction kit for Joomla, installed as the com_zoo component, and it has been in service long enough to be running on sites first built a decade ago. Every version up to and including 4.1.63 has three vulnerabilities that need no login, no account, and no help from anyone on the site. The worst of them is scored CVSS 10.0, the maximum, and ends in an attacker running their own code on your server.

We found all three, reported them, and YOOtheme fixed them in ZOO 4.1.64, released on 19 August 2026. Two more security releases followed inside three days. Update to 4.1.66 or later now.

TL;DR

TL;DR: YOOtheme ZOO (com_zoo) up to and including 4.1.63 has three unauthenticated flaws, all fixed in 4.1.64 on 19 August 2026, all found and reported by mySites.guru and all proved on a live test install rather than inferred from source. CVE-2026-74803 (CVSS 10.0, CWE-434) is an arbitrary file upload to remote code execution: the Image element on a front-end submission form checks the Content-Type the client sent and nothing else, so an anonymous visitor uploads a .php file declared as an image and it executes from inside the web root. CVE-2026-74804 (CVSS 9.3, CWE-89) is an unauthenticated SQL injection in the item element endpoint that needs no submission form at all, only an installed ZOO application, and returns whatever the database holds. CVE-2026-75114 (CVSS 5.1, CWE-601) is an open redirect. Update every ZOO install to 4.1.66 or later, then check images/zoo/uploads/ for anything that is not an image. 4.1.64 closes all three of these flaws; 4.1.65 and 4.1.66 followed inside three days with five more, the worst of them scored 8.6, described in the updates below.

Update, 25 August 2026: the Joomla 3 branch is patched too, and the 5.0.42 fixes now have CVE records.

YOOtheme has backported all four YOOtheme Pro fixes to its Joomla 3 line, in 4.5.34 on 24 August, with 4.5.35 a day later to repair a regression that release introduced. If you have Joomla 3 sites sitting on 4.5.33 because the 5.0.x line needs Joomla 4 or later, they are no longer stranded. The changelog extract and what it means are at the end of the YOOtheme Pro section below.

The two 5.0.42 fixes we flagged yesterday as security work filed under maintenance wording were published as CVE records this morning: CVE-2026-77996 for the unescaped custom field value, scored 7.5 High, and CVE-2026-77997 for the missing authorisation check, scored 5.1 Medium.

Update, 24 August 2026: two more releases, one of them matters.

ZOO 4.1.67 shipped this morning with no security fixes. We diffed it against 4.1.66 before writing this: the whole release replaces Joomla static helper calls left over from the security-fix rewrites with PHP's native file checks, and adds one MIME mapping that repairs a broken JSON import. Nothing here changes. 4.1.66 remains the release that closes all eight issues, and either version is fine to run. One oddity worth recording: the 4.1.66 changelog entry for CVE-2026-77029 has been reworded since Friday and no longer names submission deletion among the actions it protects. The code itself is untouched; only the changelog sentence moved.

YOOtheme Pro 5.0.42, out the same day, deserves closer reading than its changelog gives it. Both entries sit under the heading "Fixed", where 5.0.41's equivalents sat under "Security". One adds an authorisation check that was missing entirely from an endpoint returning any module's title together with its complete parameter set, and because the route is a GET request it never passed YOOtheme's token check either. The other escapes a custom field value that was being written into an HTML attribute unsanitised, which is stored cross-site scripting material. Both were given CVE records the following morning, on 25 August. If you installed 5.0.41 three days ago, install 5.0.42 as well.

Update, 21 August 2026: three releases in three days. Install 4.1.66.

This post was written for 4.1.64, and our customer alert went out naming that version. There have been two releases since, closing five more issues on the same component. We reported those as well.

4.1.65 arrived within the hour of 4.1.64 to finish a tag management fix that 4.1.64 had announced and not shipped. On 19 August we described that as a back end problem needing a login. It has since been published as CVE-2026-76610, scored 6.9, and the record describes it as reachable with no login at all. That is worse than we called it, and we would rather correct it here than leave the old wording standing.

4.1.66 followed on 21 August with four more, all reachable without an account. The one to plan around is CVE-2026-76612, scored 8.6: comments and user-supplied field elements are not escaped on output, so an anonymous visitor can store script that later runs in the browser of anyone viewing the page, administrators included. Alongside it, CVE-2026-76611 (6.9) lists directories through the Gallery element on a submission form, CVE-2026-77028 (5.3) is a reflected cross-site scripting and open redirect through the submission redirect parameter, and CVE-2026-77029 (4.6) is missing cross-site request forgery protection on front-end actions, submission deletion among them.

Two more lines in that changelog are not listed as security fixes at all, and both are worth reading anyway. One enforces the Download element's upload allow-list on front-end submissions, which is the same kind of guest upload route as the CVSS 10.0 below. The other reads "fix support for upload MIME validation on Joomla versions earlier than 4.4", which would mean the upload checking added in 4.1.64 was not running on Joomla 3 or Joomla 4.0 to 4.3. We have not verified that, and we are not going to claim it as fact. What we will say is that if your ZOO sites run on those Joomla versions, treat 4.1.66 rather than 4.1.64 as the release where the upload hardening below takes effect.

Everything below this box still stands: 4.1.64 fixes the CVSS 10.0. 4.1.66 is the version to install.

What Was Wrong in YOOtheme ZOO 4.1.63?

Three separate things, in three separate parts of the component, with one property in common: none of them requires an account on the site.

Flaw	Identifier	Score	Needs a login?
Arbitrary file upload leading to remote code execution	CVE-2026-74803	10.0 Critical	No
SQL injection in the item element endpoint	CVE-2026-74804	9.3 Critical	No
Open redirect in the Twitter comment callback	CVE-2026-75114	5.1 Medium	No

All three are credited to Phil Taylor of mySites.guru in the CVE records published by the Joomla project, which acts as the CVE Numbering Authority for Joomla extensions. The affected range on every record is 1.0.0 to 4.1.63, so this is not a bug introduced in a recent build. It has been there a long time.

If you run ZOO 3.x, read this bit

The CVE records list the affected range as 1.0.0 to 4.1.63, which includes the entire ZOO 3.x line. YOOtheme shipped a fix on the 4.x line only. There is no 3.x security release. If you are on 3.x you are inside the affected range with nowhere to update to, so the realistic options are moving the site to the 4.x line or taking ZOO off it. Leaving a 3.x install published and reachable is not one of them.

The Image Element Trusted the Browser’s Word

This is the CVSS 10.0 one, and the mechanism is worth understanding because the same mistake turns up across the whole Joomla and WordPress extension ecosystem.

ZOO lets visitors submit content through a front-end submission form. That is a documented, intended feature, and guest submissions are the default rather than an exotic configuration. If the form includes an Image element, which the stock layouts do, visitors can attach a picture.

The Image element validates that attachment. It builds a validator configured with a MIME type group of image and a maximum size, which reads, at a glance, like exactly the right check. The problem is which value that validator inspects. It reads the Content-Type header the client attached to the upload.

That header is not a property of the file. It is a label chosen by whoever is sending the request, and there is nothing stopping them writing whatever they like in it. So the check amounts to asking the attacker what kind of file they are uploading and believing the answer.

Nothing else closes the gap:

the file’s actual contents are never inspected, so the bytes can be anything at all;
no allow-list of permitted extensions is configured for this element;
the filename goes through Joomla’s File::makeSafe(), which strips dangerous characters but happily preserves a .php extension;
the file is then written into images/zoo/uploads/, a directory inside the web root, where the web server executes PHP.

Chain those together and an anonymous visitor uploads a PHP file, tells ZOO it is a JPEG, and then requests it in a browser to run it. That is unauthenticated remote code execution, the most severe outcome a web vulnerability can have, and it is why the Joomla CNA scored it at the top of the scale with high impact across confidentiality, integrity and availability, both for the component and for the wider system.

We proved it end to end on a Joomla 5.4.7 test install: a benign file that printed the server’s own php_uname() output was uploaded as an unauthenticated guest and returned that output over HTTP. We are not publishing the request.

Why “Check the MIME Type” Keeps Failing

There are two completely different things people mean by validating a file’s type, and only one of them is a security control.

The first is reading the Content-Type header sent with the upload. That is a hint supplied by the client. It is useful for deciding how to display something, and useless for deciding whether to trust it, because the client is the attacker.

The second is examining the file’s own contents server-side, checking the magic bytes, and rejecting anything that does not match an allow-list of extensions you have decided are acceptable. That one is a security control.

They read almost identically in code review. A line that says “check this is in the image MIME group” looks responsible either way, and the difference is one variable deep. That is exactly why this class of bug still passes audits, and it is the same underlying mistake we wrote up in Page Builder CK, Balbooa Forms, iCagenda and RSFiles over the past few months.

The rule that actually holds: never let the extension of a stored file be decided by anything the caller sent you. Generate the name and the extension yourself from a fixed list, and the entire bug class stops existing.

How Bad Is the ZOO SQL Injection?

Bad enough to matter on its own, and it has a wider reach than the upload flaw because it has no preconditions.

CVE-2026-74804 sits in ItemController::element(). Two values taken straight from the request, filter_type and the type_filter array, are pasted into the SQL condition as string comparisons with no quoting and no escaping of any kind. The condition string is then concatenated into the query verbatim by the table layer underneath.

An anonymous visitor can therefore close the string early and write their own SQL. In testing that let us do two things. First, bypass the filters the query exists to enforce, so items that were unpublished and items restricted to logged-in users came back to a guest alongside the public ones. Second, attach a UNION and read arbitrary data: we pulled back the MySQL version and the database name as an unauthenticated request to prove the reach without touching customer data.

The practical difference from the upload flaw is the precondition. The upload needs a published submission form containing an Image element that guests can reach. The SQL injection needs nothing except an installed ZOO application, which every deployed ZOO site has by definition. A site with no submission form at all is still fully exposed to this one.

That matters for triage. If you were planning to skip the update on ZOO sites that do not take submissions, do not.

The Open Redirect Is the Least of It

CVE-2026-75114 is the small one, and in a release with a CVSS 10.0 in it there is a temptation to ignore the 5.1 entirely. It is still worth patching.

CommentController::twitterAuthenticate() takes a referer parameter from the request and hands it straight to setRedirect() without checking the scheme or the host. Ask for it and the site issues an HTTP 303 to wherever you named. It works whether or not Twitter authentication has ever been configured on the site.

An open redirect costs you the reputation of your domain: a link that starts at your trusted site and ends somewhere else is exactly what a phishing campaign wants, and it still passes the “check the link before you click it” advice that most staff training is built on.

How Do I Find Every ZOO Install Across My Joomla Sites?

If you run one Joomla site, log into it, open the extension manager, and read the ZOO version off the screen. That takes a minute and you are done.

If you run thirty, or two hundred, that approach is where the update stops happening. You get through the first dozen, something urgent arrives, and the rest of the list never gets checked. The sites that end up compromised are almost never the ones no one knew about. They are the ones on a list somebody meant to get back to.

mySites.guru keeps an inventory of every extension on every connected Joomla and WordPress site. Search it for ZOO and you get every install, with its version, on one screen, and you can push the update to all of them from there.

The vulnerability rules go a step further and flag the versions rather than waiting for you to compare numbers yourself. The rule for this one went live on the day the records were published, so any connected site running ZOO below 4.1.64 is already marked, and two further rules cover 4.1.64 and 4.1.65 now that later releases exist. Our own numbers across connected sites when that rule went in were not encouraging: hundreds of sites still on a vulnerable ZOO, and not a single one yet on 4.1.64, which is what you would expect on release day and exactly why the next fortnight is the dangerous part. A meaningful share of those were still on the 3.x line, which has no fix to move to at all.

What to Do Right Now

In order, most urgent first.

Update ZOO to 4.1.66 or later on every site. That closes the three flaws described below, and the five that 4.1.65 and 4.1.66 fixed after them. It is the only step that fixes anything; everything below is about checking what may already have happened.
If a site is on ZOO 3.x, there is no security release for that branch. Plan the move to 4.x, and in the meantime treat the site as exposed rather than patched.
Look in images/zoo/uploads/ for anything that is not an image. Anything ending in .php there should be treated as a web shell until proven otherwise. Widen the search to any unexpected PHP file anywhere under images/.
Check your Joomla administrator accounts for any you do not recognise, and review recently modified files across the site.
If the site was internet-facing on an old version, treat stored password hashes as read. The SQL injection could reach the user table. Force a password reset and rotate the Joomla secret in configuration.php.
Do not skip sites that have no submission form. They are not exposed to the upload flaw, but they are fully exposed to the SQL injection, which needs nothing but an installed ZOO application.

If any of that turns up something you would rather not deal with yourself, fix.mySites.guru is the paid service where we do it for you: the site gets patched, checked for backdoors, and returned clean.

How Do I Tell If a ZOO Site Was Already Hit?

Updating stops the next attempt. It tells you nothing about the last one, and on a flaw this old the window has been open for a long time.

Start with the upload folder, because that is where the evidence would be. images/zoo/uploads/ should contain images and nothing else. A .php file there, or a file with a double extension, or an image with a modification date that does not match anything you submitted, is worth treating as an incident rather than a curiosity.

Then look at the things a successful upload leads to. Administrator accounts you did not create. Scheduled tasks no one set up. PHP files with recent modification times in directories that should be static. Outbound connections from the web server that you cannot account for.

The reason to do this rather than assume you are fine: an anonymous file upload is not a flaw that needs a targeted attacker. Mass scanners work through the Joomla extension list continuously, and we have watched several of these upload flaws get probed at scale within days of the details reaching the public, which the Page Builder CK case documented in detail. mySites.guru runs those checks, including the suspect content tool, across every connected site automatically.

Why Front-End Submission Forms Keep Producing This Bug

Step back from ZOO for a moment, because it is not really about ZOO.

Look at the pattern in what we have published this year: Page Builder CK, Balbooa Forms, iCagenda, RSFiles, and now ZOO. Different vendors, different codebases, different decades in some cases. The same bug.

What they share is a feature requirement that pulls directly against the security requirement. The whole point of a front-end submission form is that a stranger can use it without an account, and if it accepts pictures then it must accept a file from that stranger. Every safeguard you would reach for first is one the attacker controls: the filename, the extension in the filename, and the Content-Type label. The only inputs that are not attacker-controlled are the file’s actual bytes and the rules you wrote yourself, and checking those is more work than checking a header.

So the code that looks careful gets written, review sees a MIME check and moves on, and the bug sits there for years. ZOO’s affected range starts at 1.0.0.

If you build Joomla or WordPress extensions, the takeaway is short: the file’s declared type is not evidence. Read the bytes, enforce an extension allow-list you control, generate the stored filename yourself, and if you can, put the upload directory somewhere the web server will never execute anything.

If you run sites rather than build them, the takeaway is shorter still. Any extension that takes uploads from the public is a standing risk, and the number of them installed across your sites is the thing to keep an eye on. Our vulnerable extension list tracks the ones we know about.

Every YOOtheme CVE Published Since June

Eleven CVE records name YOOtheme as the vendor in the two months to 21 August 2026, spread across three products. Scores are CVSS 4.0 as published by the Joomla CNA, except the WordPress one, which WPScan scored on CVSS 3.1.

ZOO (`com_zoo`)

CVE	Flaw	CVSS	Reported by	Fixed in
CVE-2026-74803	Unauthenticated arbitrary file upload leading to remote code execution	10.0 Critical	Phil Taylor, mySites.guru	4.1.64
CVE-2026-74804	Unauthenticated SQL injection in the item element endpoint	9.3 Critical	Phil Taylor, mySites.guru	4.1.64
CVE-2026-76612	Unauthenticated stored XSS through comments and user-supplied field elements	8.6 High	Phil Taylor, mySites.guru	4.1.66
CVE-2026-76610	Unauthenticated tag modification through the comment controller	6.9 Medium	Phil Taylor, mySites.guru	4.1.65
CVE-2026-76611	Unauthenticated arbitrary directory listing via the Gallery element	6.9 Medium	Phil Taylor, mySites.guru	4.1.66
CVE-2026-77028	Reflected XSS and open redirect via the submission redirect parameter	5.3 Medium	Phil Taylor, mySites.guru	4.1.66
CVE-2026-75114	Open redirect in the Twitter comment callback	5.1 Medium	Phil Taylor, mySites.guru	4.1.64
CVE-2026-77029	Missing CSRF tokens on front-end state changes	4.6 Medium	Phil Taylor, mySites.guru	4.1.66

YOOtheme Pro for Joomla

CVE	Flaw	CVSS	Reported by	Fixed in
CVE-2026-76613	SQL injection the record describes as reachable by any contributor-level user	8.6 High	no one credited in the record	5.0.41, or 4.5.34 on Joomla 3
CVE-2026-75115	Arbitrary file read through glob patterns in the Filesystem source’s path filter, for privileged users	7.0 High	Jörg Steinsträter	5.0.41, or 4.5.34 on Joomla 3
CVE-2026-77996	Stored cross-site scripting through an unescaped value in the Location custom field	7.5 High	no one credited in the record	5.0.42, or 4.5.34 on Joomla 3
CVE-2026-77997	Module controller returns any module’s title and full parameter set with no permission check	5.1 Medium	no one credited in the record	5.0.42, or 4.5.34 on Joomla 3

YOOtheme Pro WordPress theme

CVE	Flaw	CVSS	Reported by	Fixed in
CVE-2026-10077	Author-level stored XSS through UIkit data attributes that get past `wp_kses_post()`	6.8 (CVSS 3.1)	Pierre Rudloff, via WPScan	5.0.35

Two things in that table are worth pulling out.

If you run YOOtheme Pro on Joomla, you have a second update to do today. 5.0.41 shipped on 21 August, the same day as ZOO 4.1.66, and it is a separate download. The affected ranges are 1.0.0 to 5.0.40 for the SQL injection and 2.3.0 to 5.0.40 for the file read, so every install before 5.0.41 is inside at least one of them. Updating ZOO does nothing for these, and neither does updating your template if it is not the YOOtheme Pro one. 5.0.42 followed on 24 August with two further fixes, covered at the end of this section.
The record for CVE-2026-76613 has been corrected, and it now reads 8.6 High. When this post first went up, its title and description said the SQL injection needed a contributor-level account while the vector published alongside them was PR:N, meaning no privileges at all, and that PR:N is what produced the original 9.2 Critical. YOOtheme got in touch to confirm the vector was wrong, and the record was updated on 23 August 2026: the score is now 8.6 High and the title reads “Authenticated, privileged SQL injection”.

One mismatch is still there after the correction. The revised vector says PR:H, which CVSS defines as privileges giving significant control over the component, while the description still says “any contributor-level user”, a role most sites treat as barely privileged at all. We have not audited YOOtheme Pro ourselves, so we cannot settle which reading is right, and the difference matters on any site that hands contributor accounts to people it has not met.

5.0.42, released on 24 August, has two more fixes that read as security work filed under maintenance wording. Both entries sit under “Fixed” in the changelog rather than under “Security”. The first adds an authorisation check to an endpoint that returns a module’s title together with its complete parameter set: until this release it ran no permission test at all, and being a GET route it never passed YOOtheme’s CSRF token check either, because that only applies to state-changing requests. The second escapes a custom field value that was previously written into an HTML attribute raw, which is textbook cross-site scripting. We have verified both fixes in the shipped code rather than taking the changelog’s word for it. Both were published as CVE records on 25 August, the morning after the release: CVE-2026-77996 at 7.5 High for the escaping fix, and CVE-2026-77997 at 5.1 Medium for the authorisation check. Install 5.0.42 either way; it contains everything 5.0.41 fixed plus these two.

The Joomla 3 branch got all four fixes, in 4.5.34

YOOtheme Pro runs two lines at once. The 5.0.x line needs Joomla 4 or later, and 4.5.x is the branch kept alive for sites still on Joomla 3. Every version number in all four CVE records is a 5.x number, so from the records alone a site on 4.5.33 looks stranded: inside the affected range, with nothing it can install. That is not the case. The whole set was backported on 24 August, and the package changelog says so:

## 4.5.35 (August 25, 2026)

### Fixed

- Fix regression in Articles Model (Joomla)

## 4.5.34 (August 24, 2026)

### Security

- CVE-2026-75115: Fix arbitrary file read exploitable by any contributor-level user
- CVE-2026-76613: Fix SQL injection exploitable by any contributor-level user
- Fix escaping location custom field value (Joomla)
- Fix missing authorization check in module controller (Joomla)

## 4.5.33 (December 16, 2025)

Three things are worth reading out of that.

4.5.34 closes all four, not the two it names. The two named CVEs are the pair fixed in 5.0.41. The two unnamed entries under them are word for word the 5.0.42 entries, which is how you can see the Joomla 3 branch caught up with both releases in one go. We checked the shipped code rather than trusting that mapping. The escaping fix adds htmlspecialchars($data['value'], ENT_QUOTES, 'UTF-8') in the Location field plugin, and the authorisation fix adds a core.edit test against com_modules.module.{id} before the module controller will answer. Both are the same change 5.0.42 made.
Install 4.5.35 rather than 4.5.34. The regression named in the 4.5.35 entry follows directly from the SQL injection fix. Quoting the ORDER BY column is what closes the injection, but ordering an article list by a custom field uses a synthetic column name of the form a.field:123, and quoting that as a literal identifier breaks it. 4.5.35 adds a branch that recognises the custom-field form before the quoting runs. If any of your article lists order by a custom field, 4.5.34 broke that ordering and 4.5.35 puts it back.
Older majors are still stranded, which is a different problem from being behind. The affected range starts at 1.0.0, and the fix exists on the 4.5.x and 5.0.x lines only. A site on YOOtheme Pro 3.x, or anywhere in 4.0 to 4.4, has no security release on its own line at all. For those the answer is a move to 4.5.35, or a migration to Joomla 4 or later and the 5.0.x line. There is no update that fixes them where they stand.

Timeline

2026-08-19 ZOO 4.1.64 fixes the three flaws we reported CVE-2026-74803, an arbitrary file upload to remote code execution scored CVSS 10.0, plus CVE-2026-74804 and CVE-2026-75114. All three were found and reported by mySites.guru, and all three were proved on a live test install rather than inferred from the source.
2026-08-20 4.1.65 closes a hole 4.1.64 had claimed to fix CVE-2026-76610, in tag management. The first release did not finish the job, which is the reason 4.1.64 is not a safe ceiling.
2026-08-21 4.1.66 closes four more, and this is the version to install CVE-2026-76612, an unauthenticated stored cross-site scripting flaw at 8.6 and the worst of the set after the 10.0, plus CVE-2026-76611, CVE-2026-77028 and CVE-2026-77029. Three releases in three days. Our customer alert had named 4.1.64, so we wrote again.
2026-08-21 YOOtheme Pro 5.0.41 ships the same day, and is a separate download CVE-2026-76613 and CVE-2026-75115, neither of them ours. Updating ZOO does nothing for these, and neither does updating your template if it is not the YOOtheme Pro one.
2026-08-23 CVE-2026-76613 is corrected from 9.2 Critical to 8.6 High Its description said the SQL injection needed a contributor-level account while the vector published alongside said PR:N, no privileges at all, and the PR:N is what produced the original 9.2. YOOtheme took it to the CNA and the vector was the wrong half.
2026-08-24 The Joomla 3 branch is backported, and two more Pro fixes ship YOOtheme Pro 4.5.34 brings all four Pro fixes to the line kept alive for Joomla 3 sites, so a site on 4.5.33 was behind rather than stranded. YOOtheme Pro 5.0.42 adds CVE-2026-77996 and CVE-2026-77997, both filed under maintenance wording rather than security. ZOO 4.1.67 also shipped with no security fixes in it.
2026-08-25 4.5.35 repairs a regression the SQL injection patch caused Quoting the ORDER BY column broke ordering by a custom field, whose synthetic column name is not a plain identifier. A day after the backport.

iCagenda 4.0.12 fixes an unauthenticated SQL injection

phil@mysites.guru (Phil Taylor) — Mon, 17 Aug 2026 00:00:00 GMT

The Joomla project’s CVE Numbering Authority published CVE-2026-67365 on 14 August 2026: an unauthenticated SQL injection in the iCagenda Calendar module, part of the iCagenda events extension for Joomla. It is scored 9.2 Critical under CVSS 4.0, and the fix is iCagenda 4.0.12.

This is not our find. The CVE credits Joep van Antwerpen of Onvio. We found the previous iCagenda flaw in June, an unauthenticated file upload that ended up in the CISA Known Exploited Vulnerabilities catalog, so this is the second security issue in the extension in two months and the two are unrelated.

mySites.guru already flags this

Every connected Joomla site running an affected build of the iCagenda Calendar module is flagged against our vulnerability rules. Search for iCagenda across all your sites and see the version each one is on. Not a subscriber? Sign up free and connect your sites.

TL;DR

CVE-2026-67365, published 14 August 2026 by the Joomla CNA, CVSS 4.0 9.2 Critical, CWE-89
Unauthenticated SQL injection in the iCagenda Calendar module (mod_icagenda_calendar), described in the record as reachable via com_ajax with no session, token or account
Affected: 4.0.0 to 4.0.11. Fixed: 4.0.12
The module version does not match the package version. The Calendar module stayed at 4.0.7 through the 4.0.8, 4.0.9, 4.0.10 and 4.0.11 releases and only moved with 4.0.12, so a site can show iCagenda 4.0.11 while the vulnerable module reports 4.0.7
Reported by Joep van Antwerpen of Onvio, not by us
No vendor release note. The icagenda.com changelog lists nothing above 4.0.11 at the time of writing
Separate from CVE-2026-48939, the file upload fixed in 4.0.8 and 3.9.15. Patched for that one does not mean patched for this one

What CVE-2026-67365 is

The CVE record is the whole public description, so here it is verbatim:

CVE-2026-67365, description in full

Joomla Extension - icagenda.com - Unauthenticated SQL injection in iCagenda < 4.0.0-4.0.11 - Unauthenticated SQL injection in mod_icagenda_calendar (iCagenda), reachable via com_ajax with no session, token or account.

Three things in that sentence decide how quickly you act. It is unauthenticated, so no one needs an account. It is reached through com_ajax, Joomla’s generic front-end AJAX entry point, which is available to anonymous visitors by default and which we have written about before as a recurring blind spot. And it is SQL injection, so what is at risk is the contents of the database, which on a Joomla site includes the user table and its password hashes.

We have not written an exploit for this and we are not publishing one. Nothing here needs it.

The version number that will mislead you

This is the part worth your attention if you manage more than a couple of sites, and it is why a sensible-looking version check gives the wrong answer.

The vulnerable code is in a module, not the component, and the module’s version did not move with the package. Across the Joomla sites we manage, the iCagenda Calendar module reports only a handful of distinct versions, and the pattern is clear: it sat at 4.0.7 while the package went through 4.0.8, 4.0.9, 4.0.10 and 4.0.11, then jumped straight to 4.0.12 when this fix shipped.

So on a site running iCagenda 4.0.11, the extension manager shows you 4.0.11 for the component and 4.0.7 for the Calendar module. Both are accurate. Neither, on its own, tells you whether this flaw is closed. The reading that does is the module at 4.0.12.

Two practical consequences:

A version comparison against the package version is wrong in both directions. Written one way it misses affected sites, written another it flags patched ones. Our own rule matches the module and treats anything below 4.0.12 as affected, which is the only form that lines up with reality.
Sites without the Calendar module installed are not exposed through this route, because the flaw is reached through that module. The component alone is not enough.

One open question we are not going to answer by guessing. iCagenda also ships an older calendar module, mod_iccalendar, labelled “deprecated”, and it is still installed on plenty of sites. The CVE names mod_icagenda_calendar and only that, so we have not flagged the deprecated one as affected: doing so would mean asserting something the record does not say. If you still run mod_iccalendar, the safe assumption is that a deprecated module is not getting security attention either way, and the right move is to replace it rather than wait to find out.

Which Joomla sites are affected?

Any site with the iCagenda Calendar module below 4.0.12. The module is common but not universal on iCagenda sites: across the Joomla sites we manage, a bit under three quarters of iCagenda installs have the Calendar module, and more than four in ten of those are still on the vulnerable 4.0.7 today.

What to do

Update the iCagenda package to 4.0.12 or later, then confirm the module shows 4.0.12 rather than trusting the component version or the “up to date” message.

If you cannot update immediately, unpublishing and uninstalling the iCagenda Calendar module removes this exposure, because the flaw is reached through that module. That obviously removes the calendar from the site too, so treat it as a stop-gap.

One more thing worth doing on any site that has been sitting on an old iCagenda for a while: this extension had an actively exploited flaw two months ago, so it is worth checking the Hacked? section on each affected site and reading through Users in the Joomla admin for administrator accounts no one created. Updating closes the door and tells you nothing about whether anyone already came through it.

Disclosure and severity

This flaw is CWE-89, SQL injection, reached over the network by an anonymous visitor with no privileges and no user interaction. Unlike our own assessments on vendor-silent releases, the numbers here are official: the Joomla CNA published a CVSS 4.0 vector with the record.

9.2 CVSS 4.0

Critical Official vector, published by the Joomla CNA

Unauthenticated SQL injection reachable through com_ajax with no session, token or account. High confidentiality impact on the vulnerable component and a high impact on the wider system, which is what accounts for the score reaching Critical.

No login needed Exploitable over the internet No user interaction Database read

Field	Detail
CVE	CVE-2026-67365, published 14 August 2026 by the Joomla CNA
Component	iCagenda Calendar module (`mod_icagenda_calendar`) for Joomla, shipped with the iCagenda events extension
Vendor	JoomliC (icagenda.com)
Type	Unauthenticated SQL injection (CWE-89), reachable via `com_ajax`
CVSS 4.0	9.2 (Critical), `AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/SA:H` (official, from the CVE record)
Affected versions	4.0.0 up to and including 4.0.11
Fixed in	4.0.12
Finder	Joep van Antwerpen, Onvio. Not a mySites.guru find
Vendor advisory	None. The icagenda.com changelog lists nothing above 4.0.11 at the time of writing

Timeline

2026-07-18 The update feed's newest entry is dated, and it is not the fix The feed still lists 4.0.11 from this date and nothing above it, even though 4.0.12 is shipping and installing on real sites. A site running an update check is told it is current.
2026-08-14 CVE-2026-67365 is published at CVSS 4.0 9.2, Critical An unauthenticated SQL injection in the iCagenda Calendar module, described in the record as reachable via com_ajax with no session, token or account. Affected 4.0.0 to 4.0.11, fixed in 4.0.12. Classified CWE-89.
2026-08-17 We publish, and flag the version number that lies The Calendar module stayed at 4.0.7 through the 4.0.8, 4.0.9, 4.0.10 and 4.0.11 releases and only moved with 4.0.12, so the module version and the package version disagree and a site can look patched when it is not.

mySites.guru Blog

Phoca Gallery 6.1.6 fixes a stored XSS hidden in a photo's EXIF data

TL;DR

How a photo’s EXIF data becomes script in Phoca Gallery

What changed in Phoca Gallery 6.1.6

Which Phoca Gallery versions are affected?

Joomla 4 and 5 sites have to install Phoca Gallery 6.1.6 by hand

What to do about it on each Joomla version

See which of your sites are still on Joomla 4 or 5

How mySites.guru flags vulnerable Phoca Gallery installs

Why a gallery’s EXIF data is attacker-controlled

Further Reading

The PHP Project Advises Turning Off Session Upload Progress Until the Next Release

Do You Need to Do Anything Right Now?

How mySites.guru Shows Which Sites Have It On

See which sites still have session upload progress on

What Is PHP Session Upload Progress?

Why Most Sites Are Not Exposed

How Do You Set session.upload_progress.enabled to 0?

How This Fits This Week’s PHP Security Releases

Further Reading

How mySites.guru Helps Agencies Firefight PHP2Shell at Scale

TL;DR

Every Affected Site on One Screen

Sorting the Fire by Host and Server

The Spreadsheet Does Not Know What Your Host Did Overnight

Most of This Is in Your Host’s Hands

A Ticket for Your Host, Already Written

How Do You Know When a Host Has Finished?

What If the Host Patched but the Version Number Did Not Move?

End-of-Life PHP Has No Number to Wait For

The Session Upload Progress Check

Your Clients Have Never Heard of PHP2Shell

Reporting It to Clients (and Your Own Tools)

Further Reading

Joomla.org Is Offline After the PHP Security Release: What It Means for Your Site

What Is Down and What Still Works

Why Did Joomla Take Its Own Sites Offline?

Can You Still Update Joomla Core During the Outage?

The Joomla TUF Update Expiry to Watch For on 23 October

What About Joomla Extensions and Install from Web?

What mySites.guru Keeps Doing, and What It Cannot

How Do You Check PHP on Every Joomla Site?

PHP Version Should Be Latest Supported Series

What to Do While Joomla.org Is Down

Further Reading

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

What the YOOtheme Pro 5 Joomla template flaw is

Why YOOtheme Pro 4 Joomla sites are not affected

mySites.guru flags affected YOOtheme Pro 5 Joomla sites

The first attacks reuse droppers mySites.guru already detects

Find files that match known hacks

What Joomla site owners running YOOtheme Pro 5 should do now

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

Timeline

Further Reading

PHP's Critical Security Release and Your Joomla or WordPress Site

TL;DR

What the Two Flaws Are, in Plain English

The Internet Was on Fire (Well, Social Media Was)

Why a PHP Flaw Matters to Every Joomla and WordPress Site

Which PHP Versions Got the Fix?

What Our Monitoring Shows About PHP Right Now

Why Do So Many WordPress Sites Run End-of-Life PHP?

Does Your Host Actually Apply PHP Patches?

What You Can Actually Do About It

PHP Version Should Be Latest Supported Series

Timeline

Further Reading

The Joomla Content Editor (JCE) Hack, Four Months On

What is the JCE hack?

How the JCE hack unfolded

What we are still finding today

How far the JCE hack reached

How to tell if your Joomla site was hit

Is the JCE hack still a threat?

The JCE hack was a starting gun

The worst extension flaws we have found since

Is JCE safe to use?

I patched JCE. Am I still at risk?