Nineteen and Counting: Joomla Extension Vulnerabilities We Found and Disclosed in a Month

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, and seven are rated the maximum CVSS 4.0 score of 10.0 on their CVE records. 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. If you want to know which of your sites run an affected extension, the Joomla vulnerability scanner checks them against these rules.

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. Further down there is now the full archive of every security announcement we have published, all 54 of them, which is the wider reading 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 attention, not security.

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 audited less because there is no reward for doing it, not because they are safer. 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.

TL;DR

• It started as an argument: a friend claimed Joomla extensions were more secure than WordPress plugins. They are not, no one 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
• Seven scored CVSS 10.0 on their CVE records: PageBuilder CK, SP Page Builder, Balbooa Forms, RSFiles!, iCagenda, DJ-Classifieds and jDownloads. We rate Gridbox 10.0 as well, where its record says 9.4
• 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

The vulnerabilities we found in a single month

The table is ranked by the Joomla CNA’s CVSS 4.0 score from each published CVE record. Where our own assessment differs, it is in brackets: Gridbox scores higher with us because it needs no account at all, and DJ-Classifieds and jDownloads lower because on a default server they write a file rather than run one. The last three rows have no CNA score, so they sit at the foot, with CISA’s CVSS 3.1 rating shown where one exists.

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.

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.

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.

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.

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

CISA reached the same conclusion we did, independently of our marketing or any CVSS calculator we ran, and backed 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 no one 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 also comes in a WordPress version, 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 good security track record.

If extensions of this calibre, from teams who take security seriously, all had 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 went after the biggest names on purpose

There is an easy version of this exercise and a hard version, and we chose the hard one on purpose.

The easy version is to trawl the long tail: the abandoned, single-download, one-afternoon extensions that no one has touched in years. That corner of any ecosystem, Joomla or WordPress, is riddled with holes. Finding a critical bug there proves nothing, because no one 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 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. A post like this can leave the wrong impression, but 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 releasing 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 stands or falls 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 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.

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 lists 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 carefully, 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 no one is. Our nineteen is what one team turned up in about five weeks of actually looking, a long way short of the total that exists out there, 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 behind only 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 10.0). 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, and two of them are where our scores and the Joomla CNA’s part company. DJ-Classifieds (CVE-2026-61424, CVSS 10.0) and jDownloads (CVE-2026-61900, CVSS 10.0) both let an anonymous visitor write an arbitrary file into a web-served folder. The CNA scored them as full remote code execution, level with the five 10.0 code-execution flaws above. We score both 8.8, because on a default server the file is written but never executed: it becomes code execution on a host that runs secondary file extensions, or where an administrator has widened the allowed types. Cheap shared hosting is full of the first, so patch them as the 10.0s their records say they are. The third, Events Booking (CVE-2026-60024), came 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: a read, not code execution. 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. The Joomla CNA scored DPCalendar, EDocman and Quix at 8.7, AcyMailing at 9.2 (we had it at 8.7) and EasyStore at 9.3 Critical. They sit below the upload flaws’ 10.0 only because they read data rather than executing code. Every one is the same public-endpoint-meets-unchecked-input pattern.

• AcyMailing (CVE-2026-56292, CVSS 9.2 from the Joomla CNA, 8.7 in our own assessment). 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 had 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 released 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 gives up 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. How far the damage goes is “everything this database login can see”, not just “this site’s data”.

“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 write 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 was released 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.

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 to expose this surface.

Every one of those public endpoints is attack surface. The bug is almost always the endpoint trusting what arrives, rather than the endpoint existing: 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

These bugs are ordinary. Nothing in this roundup is novel. There is no exotic new attack class, no clever chain no one 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:

Those three questions, nineteen times over. They are the first week of any secure-development course and the top of every checklist OWASP has published for twenty years, and experienced developers are expected to get them right by default without thinking about it. That is also the reassuring part: the defences are well understood, cheap and boring. 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 that much harder, and the first two alone would have stopped almost every vulnerability in this post before it was released.

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 truthful 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 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 reject 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 allowed it on purpose”.

Those two small features, a request filter and an upload block, 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 comes with 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 no one who copies it understands it, and that does not stop the attacks that actually happen, is the feeling of security plus a support burden, not security itself. 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. We set out the full argument, and exactly which requests go straight through the rules, in Your .htaccess Won’t Stop a Joomla Hack.

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

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 does help is after the file has been written: a rule in your upload directories that will not execute PHP downgrades a remote code execution into an arbitrary file write. That is a real reduction in how far the damage goes, 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.

This all deserves its own full treatment, and it got one. Your .htaccess Won’t Stop a Joomla Hack covers 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.

Every security announcement we have published

The table near the top of this post is the original nineteen, ranked by their CVE severity scores. This is the whole archive: every security announcement on the mySites.guru blog, newest first. It covers the flaws we found ourselves, the vendor security releases we pulled apart to work out what was actually fixed, and the reports from other researchers that still meant your sites needed patching.

In the Found by column we name the other researchers wherever the CVE record or the vendor credits them, because absorbing someone else’s find into our own tally without a word is the behaviour we complain about elsewhere in this post.

Joomla, Joomla extensions and Joomla core

WordPress and cross-platform

If you would rather not read an archive to find out whether it applies to you, that is the entire point of the platform. mySites.guru already knows which extensions and versions are installed on every site in your account, so every one of these that is in our vulnerability database flags itself against your sites without you checking a single admin panel.

More Joomla disclosures are already in the pipeline

The archive above is what we can talk about, and every one of the original nineteen 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. The archive is still not the whole of what we have found. We are holding further confirmed vulnerabilities in widely installed Joomla extensions, some reported and sitting on a vendor’s timeline, some about to be reported, and none of them named here. We will not name an extension or a vendor until a fix exists, for the obvious reason that naming an unpatched flaw is just publishing an exploit. The one thing that overrides that is the vendor making the fix public first: JEM went out with five CVEs and no stable release to install because the corrected code was pushed to a public release candidate on GitHub, and once the fix is readable the flaw is too.

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 Joomla 6 release line. It is early days, but our assessment is that a remote compromise of current Joomla 6 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 releases a fix, exactly as the fifty-four above did, and each will be added to the archive. So treat that list as a snapshot rather than a finished total. If you are a mySites.guru subscriber you do not have to track any of it by hand: the affected sites get flagged automatically as soon as each vulnerability is public and in our database, and the announcement list puts the urgent ones in your inbox on the day.

AI is shrinking the gap between a Joomla patch and mass exploitation

The moment a fix is released, 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.

On our own side of that, 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. What mattered 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 released. 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 no one is given 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 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 seven scored 10.0 (PageBuilder CK, SP Page Builder, Balbooa Forms, RSFiles!, iCagenda, DJ-Classifieds and jDownloads) and Gridbox, which its record puts at 9.4 and we put at 10.0
• 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 block 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
• Add mySites.guru as a Google Preferred Source so the next disclosure is more likely to show in your Top Stories when you search for it