Something has changed in how Joomla extensions get attacked, and it has changed faster than most of the ecosystem has adjusted to. This post is about that shift, and about an incentive problem in the extension market that the EU Cyber Resilience Act (CRA in short) may end up fixing almost by accident.
Hours, not weeks
There used to be a rhythm to extension vulnerabilities. A researcher finds a flaw, reports it responsibly, the developer has days or weeks to build and test a fix, a patch ships, and only later does technical detail become public. That rhythm gave defenders time.
That rhythm is breaking down. Exploit development, writing the actual code that turns a vulnerability into a working attack, is one of the tasks AI coding tools have gotten genuinely good at. The gap between "a vulnerability exists" and "there is a weaponized, automated exploit being sprayed at every reachable installation" has collapsed from weeks to hours, sometimes less.
The JCE editor case from June 2026 is a clean illustration of exactly how fast and how brutal this has become.
What happened to JCE
JCE is one of the most widely installed content editors in the Joomla ecosystem. In early June 2026, an unauthenticated vulnerability was found in its editor profile system, CVE-2026-48907. An attacker with no login at all could import a malicious editor profile that re-enabled PHP and TXT file uploads, then use that profile to drop a webshell. No credentials, no registration form, nothing. Just a reachable JCE install.
The developer responded fast, a patch on 3 June, a hardening release on 8 June, a follow-up fix on 18 June. By most historical standards, that is a genuinely fast response.
It was not fast enough. Working exploit code was published publicly on GitHub on 9 June. From that point, this stopped being a targeted attack and became automated mass exploitation, a botnet spraying the same request pattern at every JCE installation it could reach, with no regard for who owned the site or how well maintained it was.
The result, as documented by mySites.guru, who found the attack live across real client sites: hundreds of compromised installations within days, with thousands expected. And the detail that should give every Joomla site owner pause, the official Joomla Extensions Directory itself, along with the Joomla community and certification sites, were taken offline by this exact attack. Not hobbyist sites. The flagship properties of the project, run by people who understand Joomla security better than almost anyone.
If extensions.joomla.org (Joomla Extension Directory) can get hit, "my site is well maintained" is not the protection it feels like.
This is not a one-off
JCE is the most visible recent example, but it is not isolated. In the same window, mySites.guru's running list of active Joomla advisories included an unauthenticated file upload RCE in PageBuilder CK, a zero-day file upload RCE in iCagenda being used to plant fake Super User accounts, a critical auth bypass in the Astroid Framework rated CVSS 10.0, and a vulnerability in AcyMailing initially classified as WordPress-only that turned out to affect Joomla too once someone actually diffed the code.
The pattern across all of them is the same: unauthenticated, automatable, and weaponized within days of disclosure, sometimes within hours of a patch being released, because the patch itself becomes the blueprint for the exploit once someone diffs the before-and-after code.
This is the new baseline. Not the exception.
The uncomfortable economics of the old model
Here is the part of this story that is less discussed, and it is the part that matters most for where the Joomla extension market goes from here.
Under the old model, a serious vulnerability was, commercially, often good news for an extension developer. Here is why: when a high-profile vulnerability is patched, word spreads fast. Site owners who had let their subscription lapse suddenly need the fix. They cannot get it without an active subscription. So they buy one, sometimes for software they had already been using for years, sometimes for software that had quietly stopped working for them entirely.
The mySites.guru JCE write up makes this dynamic explicit, and credits it positively: "the single best thing you can do for JCE's security is pay for it... when the attack surfaced, the developer shipped 2.9.99.5, a hardening release in 2.9.99.6, a follow-up in 2.9.99.7, and a free patch for older sites, all in a matter of weeks. That responsiveness is exactly what a paid subscription keeps running."
That is a completely reasonable thing to say about a hardworking independent developer who responded admirably under pressure. But step back from the individual case and look at the system level incentive it describes: a vulnerability becoming public is a revenue event. The worse the vulnerability, the more renewals and new subscriptions it generates. Security incidents and commercial upside point in the same direction.
That is not a healthy incentive structure for an ecosystem. Whether a developer is doing everything right or cutting corners, a serious vulnerability tends to produce the same commercial outcome: a wave of renewals. The model does not distinguish between the two. A developer who has invested heavily in secure development and simply has fewer incidents gets, perversely, fewer of these renewal-driving moments than one who has more incidents to fix, regardless of how carefully either of them actually works.
How the CRA changes this, possibly for the better
The EU Cyber Resilience Act's free security update requirement, which we covered in detail in our first post on this topic, removes exactly this lever.
Under the CRA, a security update, as opposed to a feature or maintenance update, must be made available free of charge to all license holders within the support period, including those whose subscription has lapsed. A vulnerability can no longer be a covert subscription renewal campaign. The customer with an expired subscription does not need to pay to get the fix. They are entitled to it regardless.
This has a knock on effect that is easy to miss: if a lapsed customer receives the security fix for free, and that fix happens to ship in the same release as new features (which, as we discussed in our terms and conditions work on this exact scenario, is often a practical necessity due to component version dependencies), the customer has just received feature improvements they did not pay for. They have very little remaining incentive to renew.
So the commercial calculus flips entirely. A security incident is no longer a renewal driver. It is now closer to a straightforward cost: development time, support load, and a release that gives away value to people who are not currently paying.
The only way left to make money is to not have the vulnerability in the first place.
What this should mean in practice
This is genuinely a follow the incentives story, and the incentive now points where it always should have: toward secure by design development, proper risk assessments, dependency hygiene, and rapid, disciplined response when something does go wrong, not because a fix generates revenue, but because not fixing it fast enough is now pure cost and pure reputational risk with no offsetting upside.
This does not mean every developer suddenly becomes perfectly secure. It means the commercial reward for being insecure has been removed, and the commercial reward for genuine security first development, fewer incidents, lower support burden, a calmer customer base, a credible compliance story for enterprise procurement, is now the only reward on the table.
The practical question this leaves you with
If you are a site owner or an agency choosing which extensions to build on, you cannot directly observe how careful a developer was during development. You cannot see their code review process or their dependency scanning habits from the outside.
What you can observe is whether they have done the CE marking work under the CRA. CE marking requires, among other things, a documented cybersecurity risk assessment carried out before the product is placed on the market, not bolted on re-actively after an incident. A developer who has gone through that process has, at minimum, formally assessed their product's risk surface and committed to addressing vulnerabilities within a defined, public framework, with no commercial upside attached to doing it slowly.
That is not a guarantee of perfect security. Nothing is, especially in an environment where exploit development has gotten this fast. But it is a meaningfully better signal than "this developer has a good reputation" or "I have used this extension for years without a problem", because, as the JED outage demonstrated, reputation and track record stopped being reliable predictors the moment exploit generation became largely automated.
Our suggestion, going forward: when you evaluate a Joomla extension, yours, ours, or anyone else's, ask whether the developer has published a vulnerability disclosure policy, a documented risk assessment, and a CE marking or a clear path toward one. Not because the paperwork itself makes you safe, but because it is currently the best external evidence available that security was a design input rather than an afterthought monetized after the fact.
What OnlineCommunityHub is doing about this
We are in the process of CE marking our extensions under the CRA, likely the first in the Joomla extension market to do so formally. Practically, this means our security updates are free for all license holders within the support period regardless of subscription status, our risk assessments are documented before release rather than written up after an incident, and our vulnerability disclosure process is public on our security page.
We are not claiming this makes our software immune to the kind of attack JCE experienced. Nobody can claim that, and anyone who does is not being straight with you. What we can say is that the commercial incentive to be slow, vague, or reactive about security has been removed for us, by law, not by goodwill, and we think that is a genuinely good thing for everyone building and running Joomla sites.
Further reading
- mySites.guru, The JCE Profiles Hack, the full technical write-up of the case study referenced in this post
- mySites.guru blog, ongoing tracking of Joomla and WordPress vulnerabilities
- What the EU Cyber Resilience Act means for your Joomla website, our first post on this topic, covering the regulation in full
- CRA compliance checklist for Joomla agencies, practical guidance for agencies evaluating their extension stack
- OnlineCommunityHub Security page, our vulnerability disclosure policy and support matrix
This post is informational and reflects our own analysis and opinion on the commercial incentives at play in the Joomla extension market. It does not constitute legal advice.
Photo by Sasun Bughdaryan on Unsplash