Security Incident Report - Malicious Code Injection In Helix Ultimate Template Files - Question | JoomShaper

Celebrate JoomShaper's Sweet 16 with Flat 35% OFF!

Security Incident Report - Malicious Code Injection In Helix Ultimate Template Files

GP

Gianluca Pantaleo

Template 6 days ago

Subject: Security Incident Report - Malicious code injection in Helix Ultimate template files

Dear JoomShaper Support Team,

I am writing to report a security incident that affected my Joomla website and involved files belonging to the Helix Ultimate template framework. I want to bring this to your attention so you can verify whether this issue may affect other users of your products.

What happened: Our security monitoring plugin (AdminTools) detected unauthorized modifications to the following files:

• templates/shaper_helixultimate/index.php • templates/shaper_helixultimate/js/main.js

Both files had malicious obfuscated JavaScript code injected immediately after the <head> tag (in index.php) and within the main JS file. The injected code (identified by the id='jmtouch') established a connection to an external server and redirected website visitors to a malicious spam site (followfromapps.icu).

The same payload was also injected into the Cassiopeia default template file (templates/cassiopeia/index.php), confirming this was a coordinated, automated attack targeting multiple template files simultaneously.

Timeline: • Day 1: Malicious code detected and manually removed from index.php files • Day 2: Site was reinfected automatically — same files, same payload • Investigation revealed main.js as the persistence mechanism enabling reinfection • All files have now been restored and passwords changed

What we would ask you to verify: We kindly ask you to check whether:

  1. Any of your official Helix Ultimate distribution packages may have been compromised
  2. There is a known vulnerability in Helix Ultimate that could be exploited for this type of injection
  3. Other users have reported similar incidents

We are happy to provide additional technical details or samples of the malicious code if helpful for your investigation.

Thank you for your attention to this matter. Best regards

Joomla 6.1.1 SPpageBuilder 6.6.2 Helix Ultimate 2.2.6

0
5 Answers
Ziaul Kabir
Ziaul Kabir
Accepted Answer
Support Agent 6 days ago #226057

Hello Gianluca,

Thank you for your detailed message, and please accept our apologies for the inconvenience caused.

Could you kindly confirm which version of SP Page Builder was installed at the time the incident occurred?

We would like to highlight that a security vulnerability was identified in earlier versions of SP Page Builder and has since been fixed. We strongly recommend ensuring that version 6.2.2 is installed, as older versions may have been exposed to this issue before the patch was applied.

To ensure your site is fully secure, we recommend taking the following steps:

Remove any infected or modified files and replace them with clean copies from the official installation package Perform a full malware and security scan of your website and hosting environment Check your server for any backdoors or malicious scripts that could allow reinfection Update all credentials, including Joomla administrator, hosting panel, FTP/SFTP, and database passwords

If you need any assistance during this process, please let us know—we’re here to help.

Best regards,

0
GP
Gianluca Pantaleo
Accepted Answer
6 days ago #226058

Dear JoomShaper Team,

thank you for your follow-up.

After checking, I can confirm that SP Page Builder 6.2.2 was already installed at the time of the attack, which occurred yesterday morning. The update had been applied as soon as it was released.

This means the site was running the latest patched version and was still compromised. I would therefore kindly ask:

  1. Does the vulnerability fix in 6.2.2 only protect against future attacks, or could a site already have been exploited before the update was applied and left with a persistent backdoor?
  2. Is it possible that the attacker exploited the vulnerability in a previous version, planted a backdoor, and the reinfection we observed was triggered by that backdoor even after the update?
  3. Are there any specific files or database entries we should check to ensure no backdoor remains from a prior exploitation of the SP Page Builder vulnerability?

Any additional guidance would be greatly appreciated, as we want to make sure the site is fully clean and protected going forward.

Thank you for your continued support.

Best regards,

0
Ziaul Kabir
Ziaul Kabir
Accepted Answer
Support Agent 6 days ago #226060

Hello,

It appears that the site may have been compromised prior to the update.

First, please ensure that all backdoor or malicious files are completely removed from your website.

We also recommend reviewing all newly created user accounts and deleting any that are not recognized or authorized.

For additional guidance and related information, please refer to this discussion: https://www.joomshaper.com/forum/question/45152

Please carry out these checks and let us know once completed, along with any updates.

Thank you.

Best regards,

0
Paul Frankowski
Paul Frankowski
Accepted Answer
Senior Staff 5 days ago #226099

Short answers 1-2-3:

  1. You cannot back the time (unless you can somehow), so new update fixed for the future.
  2. No. The backdoor is something else. In our case it was just a security hole. More info in link below
  3. There is no simple way like delete file(s) with name "infected.php" it doesn't work this way like in the past. So please read whole forum topic (link you have) and focus my topic about steps, it starts with phrase "To scan website use:"

But a week ago, few days, or just one day ago somebody could upload a single file, and wait for ocasion to run it and infect your site even more, like virus spead. Your hosting firewall should detect that sooner, but it's not always easy to find suspicus pattern.

If AdminTools detected modification in file(s), you have to reinstall that extension or template to be sure that it's not hidden anywhere deep inside. But this is one of many steps.

0
Paul Frankowski
Paul Frankowski
Accepted Answer
Senior Staff 5 days ago #226100

Remember that Akeeba Backup Pro (or any other firewall extension) is the last line of defense; a firewall should also be running at the hosting level. It’s just like in the Middle Ages—you need multiple walls and active archers (but instead of arrows > using IP block).

0