---
title: "Joomla extensions security vulnerabilities June 2026"
date: 2026-06-24
author: "Jeroen Moolenschot"
intro_image: "https://www.joomill.com/images/blog/veiligheidslekken-juni2026.png"
---

# Joomla extensions security vulnerabilities June 2026

![Joomla extensions security vulnerabilities June 2026](https://www.joomill.com/images/blog/veiligheidslekken-juni2026.png)

June 2026 was not a good month if you run a Joomla site. In the space of a few weeks, five critical vulnerabilities were discovered in extensions used on a huge number of sites: the **JCE editor**, two page builders (**SP Page Builder** and **PageBuilderCK**), the **iCagenda** events component and the **Helix3** template framework. All five were roughly the same type of vulnerability, and all five were already being actively exploited before most site administrators realised anything was amiss.

 The good news is that updates are now available for all five. The less good news is that installing an update closes the door, but if someone has already gained access, they’ll still be there after the update. That distinction is often overlooked, and it’s precisely where sites still end up falling foul of the problem.

 
## What exactly went wrong

 All five vulnerabilities boil down to the same thing. Somewhere within the extension, there was a component that accepted an uploaded file without checking who the uploader was – meaning no login was required – and without properly verifying the type of file. This allowed an attacker to place a PHP file on the server and then execute it. In practice, this means complete control over your site: extracting data, modifying pages, installing a backdoor, or using your server to attack other sites. In technical terms, this is known as remote code execution, and it’s pretty much the worst thing that can happen to a website.

 
| Extension | What it is | Vulnerable | Secure from |
| --- | --- | --- | --- |
| JCE | The most widely installed editor for Joomla | Anything older than 2.9.99.6 | 2.9.99.6 |
| SP Page Builder | JoomShaper’s page builder | All versions up to and including 6.6.1 | 6.6.2 |
| PageBuilderCK | Free page builder from JoomlaCK | up to and including 3.5.10 | 3.6.0 (Joomla 4: 3.4.10, Joomla 3: 3.1.1) |
| iCagenda | Calendar and events component | Older than 4.0.8 | 4.0.8 |
| Helix3 | Template framework by JoomShaper | Older than 3.1.1 | 3.1.1 |

 Below, I’ll go through each of the five in turn: what the extension is, what went wrong and what you need to do.

 
## JCE: unauthenticated profile upload, secure from version 2.9.99.6 onwards

 [JCE](https://www.joomlacontenteditor.net/), which stands for Joomla Content Editor, is the most widely installed editor for Joomla. On a great many sites, it replaces the default editor, often without the administrator even realising that it is a separate extension. It is precisely this ubiquity that makes a vulnerability in it so attractive to attackers.

 The vulnerability allowed visitors without a login to upload editor profiles, and via this workaround, any file could be placed on the server, including executable PHP files. The developers responded in two stages: first with an emergency update (2.9.99.5) that patched the vulnerability, and shortly afterwards with 2.9.99.6, the result of a few days’ thorough review of the entire extension and the tightening of input validation. Important detail: 2.9.99.6 is the version you need to be running, not 2.9.99.5. So don’t stop halfway.

 Moreover, this isn’t the first time JCE has had an upload vulnerability. Years ago, there was another one that was exploited on a large scale, and that’s precisely why you must take a new JCE vulnerability seriously straight away: attack bots know that the editor runs just about everywhere. Update to 2.9.99.6 via the Joomla updater or directly from the developer; the Pro version works fine on Joomla 3, 4, 5 and 6. If you can’t update, temporarily remove JCE. Afterwards, check whether any editor profiles have been added that you did not create.

 
## SP Page Builder: upload vulnerability that creates hidden administrators, patched in 6.6.2

 [SP Page Builder](https://www.joomshaper.com/page-builder) by JoomShaper is one of the most popular page builders for Joomla, allowing you to drag and drop elements to build pages without coding. The vulnerability was in an upload function within the component itself – the task that normally allows you to upload a custom icon (`asset.uploadCustomIcon`). This function accepted a file without requiring any login, allowing an attacker to place and execute a PHP webshell.

 What makes this vulnerability particularly troublesome is what attackers actually did with it. They used the control they gained to create a hidden Super User, ensuring they retained their own point of entry, even after you’ve duly updated the system. Another point to note: a firewall rule designed to block the JCE attack will not automatically block this one. It uses a different file extension with a different pattern, so relying solely on your WAF is not enough in this case.

 Every version up to and including 6.6.1 is vulnerable; this has been fixed in 6.6.2. So update to 6.6.2 and then check your user list for administrators you haven’t created yourself.

 
## PageBuilderCK: file upload to any folder, patched in 3.6.0

 And it wasn’t limited to just one page builder. [PageBuilderCK](https://www.joomlack.fr/en/joomla-extensions/page-builder-ck) by JoomlaCK is one of the most popular free page builders for Joomla, a drag-and-drop tool used by thousands of sites for their landing pages and content. On 27 June, the developer, Cédric Keiflin, released version 3.6.0 with a changelog that simply read: “IMPORTANT: Fix security issue”. No explanation, no bells and whistles. Behind that single line lies a serious vulnerability.

 In every version up to and including 3.5.10, there was a front-end endpoint that accepted an uploaded file without requiring a login or permission checks. What’s more, this vulnerability is a step worse than the rest: the attacker can choose which folder the file ends up in. A PHP webshell could therefore end up anywhere the server is permitted to write – in /images, /media, /templates, /administrator, or anywhere else. The only thing standing in the way was a CSRF token, and any visitor could simply read that from the page. So it wasn’t really any protection at all.

 Important: unpublishing the extension or the page in question does not help. The vulnerable endpoint remains accessible. Only updating (or blocking the endpoint at firewall level) will actually close it. When updating, make sure you use the correct version for your Joomla: 3.6.0 for the current version of Joomla, 3.4.10 as a backport for Joomla 4, and 3.1.1 for Joomla 3. Afterwards, check for any leftover PHP files, and don’t just look in the obvious places, as with this vulnerability the file could literally be anywhere.

 
## iCagenda: file upload in the events component, fixed in 4.0.8

 [iCagenda](https://www.icagenda.com/) by JoomliC is a calendar and events component, used on sites that publish activities or an events calendar. The vulnerability was an unauthenticated file upload in the directory where the component stores its uploads, again resulting in remote code execution.

 This was a genuine zero-day vulnerability: it was already being exploited before a fix was available. The developer had version 4.0.8 ready on the very same day. If you want to check your logs to see whether your site has been targeted, look out for a pattern where a bot first posts something to the site and then immediately requests a .php file from the component’s upload directory. This is the kind of attack that assumes it has already gained access.

 Update to version 4.0.8 and check the component’s upload folder for PHP files that do not belong there.

 
## Helix3: unauthenticated file writing and deletion, patched in 3.1.1

 [Helix3](https://www.joomshaper.com/joomla-templates/helix3) is JoomShaper’s template framework, the foundation upon which a large proportion of Joomla templates are built. It is therefore not a standalone feature on a single page, but the foundation underpinning your entire site design. And as it’s from the same developer as SP Page Builder, this is the second JoomShaper extension in this series.

 The vulnerability was in Helix3’s AJAX plugin. This was accessible via Joomla’s `com_ajax`Joomla dispatcher and carried out a number of actions even before any token or permissions checks took place. As a result, an attacker could, without logging in, write files to your template, delete arbitrary files on your server and overwrite your template settings in a single request. A file being written to your server again poses a potential code execution risk, and the deletion of files can bring your site down in an instant. Incidentally, this does not only affect older installations: it applies to the current versions of Joomla 4, 5 and 6. The vulnerability came to light during an investigation into a hacked site and was reported via responsible disclosure.

 The fix is Helix3 3.1.1. If any of your sites run on Helix3, update to 3.1.1 via the Joomla updater. Afterwards, check whether any files have been added to or removed from your template and media folders, and whether your template settings are still correct.

 
## A “security update” is not a changelog

 Helix3 immediately exposes a second problem. JoomShaper did what it was supposed to do: they emailed users and posted a changelog entry. To be fair, a great many vulnerabilities are patched in complete silence, so that’s better than nothing. The problem is what was actually stated in those announcements. The changelog consisted of exactly two words: “Security Update”. The email went on to mention a targeted security update that they recommended all users install as soon as possible, but even there you don’t find out what has been fixed, how serious the issue is, or whether it’s already being exploited.

 And that is precisely the information you need. If you manage sites for clients, the only question that matters is: do I patch this tonight, or can it wait until the next maintenance window? “There’s an update” without any context leaves you guessing, and guessing is exactly what you don’t want when it comes to security. Keeping track of what an update fixes is therefore just as important as installing the update itself.

 
## Why this keeps happening with Joomla extensions

 This is no coincidence, nor is it down to Joomla itself. The pattern is always the same. A popular extension has a component somewhere that is allowed to receive files – a media manager, an icon uploader, an event attachment – and somewhere in that chain, a check is missing. The more sites running such an extension, the more valuable that single vulnerability becomes, because an attacker only needs to find it once.

 After that, it happens automatically. Bots scan the internet en masse for sites running the vulnerable extension and unleash the same trick everywhere. Your site doesn’t even need to be of particular interest. It’s enough that you’re running the wrong extension in the wrong version. That’s precisely why standalone extensions, however handy they may be, represent your greatest area of risk: the Joomla core is strictly monitored, but every extension you install is someone else’s code that you simply have to trust.

 
## The intruder may already be inside

 This is the real message. If one of these vulnerabilities was exploited on your site before you updated, the attacker will have left something behind during that period to allow them to remain inside. Updating closes the hole through which they got in, but it doesn’t remove what they’ve planted in the meantime. Here are three things you might find:

 
- **A hidden administrator.** An additional Super User with a plausible name – think of something like “Web Editor” or “Admin Backup” – and often an email address that makes no sense. That account is simply listed in your user list. You just need to look there to spot it.
- **A webshell.** An uploaded PHP file that allows the attacker to execute commands again later, even if you’ve already patched the original vulnerability. These files are usually found in places you wouldn’t expect, in upload folders or hidden amongst legitimate files.
- **A malicious setting within the extension itself.** In JCE, for example, an editor profile that is permitted to do far more than it should.

 At the same time, the reverse is also true: not everything that looks suspicious is a hack. If you run a scanner over your site, you’ll often get a list of files flagged as ‘suspicious’ because they match a pattern. That’s something to look into, not something to panic and delete. The difference lies between “this file resembles something malicious in its structure” and “this file has demonstrably been modified or injected”. The former requires a closer look, the latter requires action. Anyone who fails to make that distinction will either wreck their own site or miss the real backdoor.

 
## What you should do now

 
1. **By now, you’re probably already too late** if you haven’t carried out the steps below on the same day (16 June 2026). The best course of action now is to restore a backup from early June.
2. **Update immediately if you’re running any of these extensions:** JCE to 2.9.99.6, SP Page Builder to 6.6.2, PageBuilderCK to 3.6.0 (or 3.4.10 on Joomla 4, 3.1.1 on Joomla 3), iCagenda to 4.0.8, Helix3 to 3.1.1. Do this via the Joomla updater or directly from the developer. If you really cannot update, disable the extension until you can.
3. **Afterwards, check whether anything has changed.** Go through your list of Super Users to check for accounts you didn’t create yourself, and look in the upload folders of the relevant extension for PHP files that shouldn’t be there. With PageBuilderCK, such a file could be located anywhere, so don’t limit yourself to the obvious folders.
4. **Don’t forget your other sites.** If you run multiple Joomla sites, or manage them for clients, go through them all. An attack bot makes no distinction, so neither should you. Also check your development and test websites. Even though these aren’t indexed, they’re easy for bots to find.
5. **Keep a pre-update backup to hand,** in case you need to roll back or want to compare.


## Custom Fields

**Call2Action Titel:** Fancy a quick look?

**Call2Action Tekst:** If you come across this and don’t feel like, or don’t have the time to, check through your sites one by one, then this is exactly the sort of work that falls under maintenance. I keep an eye out for these kinds of vulnerabilities, apply the updates to the sites I manage, and check whether anything has gone wrong before it becomes a problem. If you’d like me to take a look, or if you’d like us to take over the maintenance of your website or websites, please send me an email. We’ll then discuss together what’s needed.