If your Joomla website uses SP Page Builder by JoomShaper, there's a critical security issue you need to deal with today, not next week. A vulnerability tracked as CVE-2026-48908 allows attackers to take complete control of a vulnerable site without needing a username or password. It's already being actively exploited.
These general guidelines could also apply to the recent hacking of Tassos Nr Framework and JCE Editor. I would like to make clear, all three companies have responded in a timely and responsible manner after the security breaches were discovered. I would not hesitate in continuing to use their products.
We're a Joomla development agency based in London, and we're putting this guide together so our clients — and anyone else running Joomla — knows exactly what's going on, how to check if they've been affected, and what to do about it.
We are providing this information below but if you want us to quote for de-hacking it, please contact us
What Is CVE-2026-48908?
CVE-2026-48908 is a critical-severity vulnerability (CVSS 4.0 score: 10.0, the maximum possible) in SP Page Builder, one of the most widely used Joomla page builder extensions. The flaw sits in a component task called asset.uploadCustomIcon, which is supposed to handle icon uploads for logged-in administrators.
The problem: that endpoint didn't check whether the person making the request was logged in, and it didn't properly restrict what kind of file could be uploaded. That combination means anyone on the internet — with no account, no password, no admin access — could upload a PHP file to the server and then run it.
Once an attacker can run their own PHP code on your server, they effectively own the site. They can read your database, deface pages, steal customer data, or use your server as a launchpad to attack other sites.
Who's affected: every version of SP Page Builder up to and including 6.6.1.
The fix: version 6.6.2, which adds the authentication and permission check that should have been there from the start.
Why This One Is Worse Than a Typical Vulnerability
Plenty of security flaws get patched quietly before anyone exploits them. This isn't one of those. CVE-2026-48908 is being exploited in the wild right now, and the attack doesn't just get in and leave — it sets up camp.
Once attackers gain code execution, the payload typically does two things:
- Creates a hidden Super Administrator account. These accounts use innocuous, forgettable names — things like "Web Editor," "Site Helper," or "Admin Backup" — paired with a username built from ordinary-sounding role words plus a couple of digits. The giveaway is the email address: it ends in
@secure.local, a domain that doesn't belong to any real organisation and is never used by legitimate Joomla accounts. - Drops a PHP file manager backdoor. This gives the attacker a full file browser, a PHP console, and a SQL console, all running quietly on your server. Copies are often scattered in multiple locations (commonly under
images/subfolders or disguised asusers.phpin component or plugin media folders) specifically so that deleting one copy doesn't lock the attacker out.
This means that simply updating SP Page Builder to 6.6.2 is not enough if your site was already compromised. Patching closes the front door, but if an attacker already let themselves in and made a copy of the key, they're still inside.
How to Check If Your Site Has Been Compromised
Here's a practical checklist:
1. Update SP Page Builder to 6.6.2 immediately. This closes the vulnerability and stops new attacks. Do this first, regardless of anything else — every hour on an unpatched version is additional exposure.
2. Check your Joomla user list for Super Administrator accounts you don't recognise. Go to Users → Manage in your Joomla admin panel and look specifically for Super User accounts with email addresses ending in @secure.local. If you find one, that site has been compromised — full stop. Don't delete it immediately without first noting the account name and creation date for your own records, in case you need to investigate further.
3. Search your server for unexpected PHP files. Look for unfamiliar .php files in unusual locations — particularly inside images/ subfolders, or files named users.php sitting in folders where you wouldn't expect a PHP file at all, such as media folders for unrelated components or plugins. If you find a file resembling a "file manager" with a PHP console and SQL console built in, that's the backdoor.
4. Mind your timezones when checking logs. Joomla records account creation times using your site's configured timezone, while most server access logs run in UTC. If you're cross-referencing a suspicious account's creation time against your access logs, convert the timezone first — otherwise you'll be looking at the wrong few hours of logs and may incorrectly conclude there's nothing there.
5. If you find anything, treat the whole site as compromised — not just the one thing you found. An attacker who got in through one hole will often leave more than one way back in. A proper clean-up means: removing every rogue admin account, removing every backdoor copy, rotating all passwords (Joomla, database, hosting/FTP/SSH), forcing all active sessions to log out, and reviewing the site more broadly rather than assuming the job is done once the first thing you found is gone.
What This Means If You're Not a Developer
If you read through that checklist and felt your stomach drop a little, that's a completely normal reaction — and it's exactly why agencies like ours exist. Checking for hidden admin accounts and backdoor files isn't something most business owners should have to do themselves, particularly under time pressure with an active exploit in the wild.
UPDATE: Wednesday 24th June 2026
What These Infections Actually Looked Like in Practice
Since publishing the guide above, we've worked through several live cases of this vulnerability being exploited. A number of things we found are worth sharing, because they change how you should approach cleanup — and because several of them would catch out anyone treating this as a simple "delete the bad file" job.
The attacks had usually been running for far longer than anyone realised. On more than one site, the first visible symptom appeared days after the earliest attacker activity we could find in the database and file timestamps. By the time a compromise becomes obvious in the browser, it has typically been quietly established for a week or more. Don't assume it started when you first noticed something wrong.
Patching the component did not, on its own, stop the reinfection. This was the hardest lesson. On the sites we cleaned, we'd update the vulnerable component, remove the backdoor files, clean the malicious database entries — and the infection would rebuild itself within minutes. The reason was scheduled tasks (cron jobs) the attacker had installed, in one case running every ten minutes, each one a self-healing dropper that re-wrote the backdoor files and re-created the malicious records from scratch. Until those scheduled tasks were found and deleted, every round of cleanup was silently undone before we'd finished. This is the single most important takeaway: updating the vulnerable component and deleting the files you can see is not enough. If the attacker has established persistence through a scheduled task, the site simply rebuilds itself. Always check your cron jobs after a compromise.
The persistence was layered, deliberately, to survive partial cleanup. Removing the obvious backdoor was never the end of it. Across these cases we found the same payload re-established through multiple independent mechanisms at once:
- Dozens of randomly-named folders, each carrying a copy of the payload, dressed up to look like legitimate font or asset bundles so that deleting a few wouldn't lock the attacker out.
- A PHP directive (
auto_prepend_file) planted in server configuration that forced a backdoor to load on every request — and crucially, planted in two places, so that fixing one (the.htaccess) left the other (a.user.ini) silently doing the same job. - Malicious code injected directly into the live template's main file and into core configuration, so the backdoor loaded before the site itself did.
- Scheduled tasks (above) that regenerated all of the above on a timer.
Cleaning any one of these without the others meant the site reinfected itself. You have to find and cut every layer.
The most serious finding: it spread sideways across the server. The most dangerous payload we recovered wasn't a simple webshell — it was a command-and-control framework that, once running, scanned the entire hosting account for other Joomla installations, read each one's database credentials straight out of its configuration file, connected to those databases, and created hidden administrator accounts on every site it could reach. If you run multiple Joomla sites on the same shared hosting account or server, a compromise of one can seed hidden admin accounts across all of them. Cleaning the site you know about is not sufficient — every Joomla install reachable from the same account needs checking.
The hidden admin accounts had a consistent signature. Where the attacker created rogue Super User accounts, they carried email addresses ending in a domain that no legitimate account would ever use. A single Super User with an out-of-place email domain you don't recognise is a reliable red flag — but a clean user list does not mean a clean site, because on some sites the persistence relied entirely on files and scheduled tasks, with no rogue admin at all. Any single clean check rules out one thing, not everything.
The site appeared to be "blocked" when it was actually self-sabotaging. At one point an entire site returned errors on every request, which initially looked like the host had locked the account down. It hadn't — the malicious auto_prepend_file directive was pointing at a backdoor file that had since been deleted, so PHP failed on every single request trying to load a file that no longer existed. A confusing symptom with a mundane cause, and a reminder to check your own configuration before assuming the worst about the host.
Our recommended approach, based on what we learned
Assume full compromise, not a single bad file. In order:
- Take the site offline or restrict access.
- Update the vulnerable component to close the entry point — but understand this alone does not clean an already-compromised site.
- Check scheduled tasks (cron jobs) and remove anything you didn't create. Do this early — until it's done, everything else you clean will come back.
- Find and remove every persistence layer: backdoor files,
auto_prepend_filedirectives in both.htaccessand.user.ini, injected code in template files and configuration. - Check the user list for unfamiliar administrator accounts — and if you run other Joomla sites on the same hosting, check every one of them too.
- Rotate every credential (admin, database, hosting, FTP/SSH, and any mail or API keys stored in configuration) — but only after the backdoors are gone, since a still-active backdoor can simply read the new ones.
- If you can't be confident you've found everything, rebuilding from clean core files against a properly audited database is often safer and faster than trusting an in-place clean.
If any of this is beyond what you want to take on — particularly the situation where a site keeps reinfecting no matter what you delete, or where you're not sure whether other sites on your hosting have been touched — that's exactly the kind of work we handle. Get in touch with SE24 Media and we can take a look.
How SE24 Media Can Help
We've spent over a decade building and maintaining Joomla websites, and we deal with security incidents like this regularly. If you run SP Page Builder and you're not certain whether your site is exposed or already compromised, we can help with:
- A SP Page Builder security check — confirming your version, applying the 6.6.2 update safely, and checking your user accounts and file system for the specific signs of this exploit
- Full hacked-site recovery — if your site has already been compromised, we'll remove rogue accounts and backdoors, rotate credentials, and audit the site properly so the attacker doesn't have a second way back in
- Ongoing Joomla maintenance — so the next zero-day doesn't catch you off guard in the first place
This is exactly the kind of problem that's far cheaper to deal with this week than after a customer's data has been stolen or your site has been blacklisted by Google. Get in touch with SE24 Media and we'll take a look.
SE24 Media is a London-based Joomla web development agency with over a decade of experience building, maintaining, and recovering Joomla websites. We develop and sell commercial Joomla extensions under the SE Extensions brand.
