Hi Tomislav,

First - everything on the cleanup side is real. The unpaid hours, the quarantine, the "but I paid for a commercial tool" call with a panicked customer. That pain is genuine and deserves acknowledgement.

But I'd push back on the framing, because I don't think JoomShaper is the villain here. Full disclosure: I build a Joomla security tool, so weigh my view accordingly - it also means these exact compromises are what I look at all day.

Widespread adoption is the attack surface. Helix and SP Page Builder run on a huge share of the Joomla web, and the moment an extension reaches that scale it becomes the most attractive target there is - not because the vendor got careless, but because attackers go where the install base is. Same story on every CMS, WordPress included. Core is rarely the entry point anymore; the popular third-party layer almost always is. Blaming the most-used vendor for being the most-attacked one is like blaming the busiest intersection for the most traffic.

Your legitimate ask - a proper advisory with version ranges, endpoints, IoCs, the paths and tables to check - is fair, and I support it fully. But "please publish an advisory so we can respond faster" is something they can say yes to; "JoomShaper failed us" just starts a fight.

Here's the part no vendor can patch away: there's always a window between disclosure and every site actually being updated, and that window is where sites get hit. You clearly already know this - you mention ModSecurity, com_ajax blocks, iconfont-path execution blocks. That's exactly the layer that has to exist, and it's probably why your damage stayed containable instead of catastrophic. Those patterns are all blockable that way, much of it with plain ModSecurity or .htaccess rules. The layer matters more than which product provides it.

And credit where it's due: this wasn't only an "update now" email. JoomShaper has posted hands-on cleanup guidance multiple times (e.g. https://www.joomshaper.com/forum/question/45152) - a free scanner, the FTP paths to clear, the rogue-Super-User check, removing injected code from the template's Custom JavaScript field, firewall scanning. That's real incident-response material.

So the fair ask isn't "JoomShaper failed us." It's: take the tips you've already published and turn them into one proper, versioned advisory - the JCE model you mention, with a clear patch path for older sites. That's the template worth copying. And put it somewhere people can actually find it: right now it lives in forum threads, but a permanent advisory page linked from the front page or a dedicated Security section would reach the owners who need it long after this thread scrolls away. Joomla is solid, JoomShaper builds real value on it, and the guidance already exists. Turning it into a findable, versioned advisory is the one thing still missing.

Hi there,

I completely understand your concerns, and I want to assure you that we made every effort to respond sincerely and release the fixes as quickly as possible. No company ever wants to lose its users or see their websites compromised.

I agree with several of the points you raised. In particular, we should have provided a clearer security advisory, practical cleanup guidance, and, where possible, guidance for affected users.

In fact, I created a feature request on our forum regarding SP Page Builder to improve this process in the future. Likewise, the Helix development team was informed about the need for better guidance. Their response was that updating to the latest version resolves the vulnerability itself. However, if a site had already been compromised before the update, some attackers may have injected malicious code into the Template Settings > Custom JavaScript field. Simply updating Helix does not remove that injected code. It must be removed manually. I believe this should have been communicated much more clearly.

Hopefully, we can learn from this experience and avoid similar shortcomings in the future. We will certainly remain more vigilant and continue improving both our security response and our communication with users.

For reference, I also shared a related feature request here:

https://www.joomshaper.com/forum/question/45258

Best regards,

Toufiqur Rahman (Team Lead, Support)

Hi Pascal,

I agree that popularity increases the attack surface. Popular software will always attract more attackers.

However, I think you're overlooking something fundamental.

This was not simply a case of attackers targeting a widely used extension. During our forensic investigations we repeatedly found evidence that the SP Page Builder icon upload functionality lacked basic security controls that should exist in any modern file upload implementation.

A file upload endpoint is one of the highest-risk features in any web application. It is Security 101.

What we observed was not an exotic chain requiring multiple bugs. We found malicious PHP payloads uploaded into SP Page Builder asset directories where they could be executed by the web server. That should never have been possible.

This is not about popularity.

This is about an upload mechanism that did not sufficiently enforce server-side validation, executable file restrictions, and defence-in-depth. Those are not advanced security features—they are fundamental engineering practices that have been standard for many years.

Our incident response was not limited to applying updates.

We had to:

remove uploaded web shells from SP Page Builder directories, deploy .htaccess rules to prevent PHP execution inside icon and asset folders, inspect databases for injected JavaScript, verify administrator accounts, analyse Apache logs, correlate attack patterns with installed extensions, quarantine compromised files, and build our own forensic scanner because there simply was no sufficiently detailed guidance available.

Those are not the actions you perform after a "routine security update".

They are the actions you perform after a successful compromise.

This is exactly where I disagree with your statement that JoomShaper is simply the most attacked because it is the most popular.

Popularity explains why attackers looked at the software.

It does not explain why they were able to upload executable payloads in the first place.

That distinction matters.

When an upload endpoint handling user-controlled files lacks sufficient protection against executable uploads, responsibility lies with the software vendor. That is not something hosting providers, agencies or customers can reasonably prevent before the vulnerability becomes public.

The burden of implementing secure upload handling belongs to the developer.

Likewise, expecting thousands of site owners to compensate afterwards with custom .htaccess rules, ModSecurity filters, WAF signatures, malware scans and forensic investigations is not an acceptable substitute for secure application design.

So yes, I absolutely agree that comprehensive advisories, IoCs and incident-response guidance are needed.

But I also believe JoomShaper has to accept responsibility for weaknesses that, based on the evidence we encountered during multiple forensic investigations, should never have existed in a commercial product to begin with.

Edit: Security is ultimately a matter of trust.

After having to investigate compromised websites, remove web shells, deploy emergency WAF rules, harden upload directories, inspect databases, verify administrator accounts, and perform extensive forensic analysis, that trust has been lost.

As a result, we have removed all JoomShaper products from every Joomla installation we manage. We no longer consider the additional operational risk acceptable for our customers.

I'm not a technical person, so I'm going to give my perspective on this: 1 - Communications were and still are very poor. Do this to prevent that from happening. It's much more effective to explain to clients that all their websites are under potential attack and that, in addition to patches, they recommend using ABC to increase security. 2 - In the template list, they need to remove those they don't recommend users install, such as those that still use Helix 3. 3 - If they don't want to give the impression of vulnerability to potential clients who buy products every day, they should create a closed forum only for active clients. 4 - Two weeks ago, between JCE and Joomshaper, end users need to be vigilant. // If every successful Joomla component helps educate its clients about updates, component and plugin purchases, backups, and additional security systems, these incidents would be reduced because hackers would have much less success. 5 - What's expected of a company like yours—taking advantage of the World Cup—is that you don't chase after the ball and that you anticipate the moves.

Couldn't agree more. Just spent the last 3 days of my life restoring my VPS after a brutal attack from these vulnerabilities that seemed to hijack a session, gain access to cPanel and then infect other accounts via backdoors, SSH and API keys, .ht, crons etc. Tracked the piece of shit hacker's IP's down, not that it means anything and spent 3 days stopping it with minimal help from support and a big journey with ChatGPT. Am now paying for immunify as it seems impossible to function without it now and still feeling sick and hypervigilant and hope that's the end of it. I wish the hacker well with their karma.

Can you please be more clear about what needs to be installed or not in these emails?

I received link to Helix Ultimate last night. I go to download and obviously I don't need the template, but do I need the plugin? I stuck 2.7 on there cause I don't know if it relates to Rhino or not, so now I guess I better stick 2.8 on too.

I've seen you guys, JCE, Ossolution and more throw out tonnes of little incremental updates the past couple of weeks and these exploits are so quickly smashed now cause of AI. It really does need quicker and clearer communication. I'm no security expert or advanced server admin and its getting to the point where its almost just not worth doing this stuff anymore and to just suggest clients use some kind of hosted builder. That's not anyone's fault, just the sucky nature of Wordpress, Joomla and all the rest of it these days

For Page Builder

We worked as quickly as we could to deliver a fix. This was an issue we had never encountered before, and we recognize that we should have provided clearer guidance from the beginning. We will make sure to improve our communication and documentation if we ever face a similar situation in the future.

I have recorded a screencast that shows how to remove the custom icons using the Security Scanner, as well as how to remove the related database entries. If you have any custom icons that you intentionally installed, simply keep those and remove the remaining entries from the database.

One thing I have always said throughout my 12 years at JoomShaper is that we stand with our users. Our goal has always been to protect our users, support them through difficult situations, and continue improving our products and the way we communicate whenever we identify areas where we can do better.

https://drive.google.com/file/d/1nxDCGjvYchgbsEyrZ1JmhbduuEcQFmmE/view