SP Page Builder security flaw: update Joomla to 6.6.2 now

A emergency update to version 6.6.2 is now available for the widely used Joomla page builder SP Page Builder (from JoomShaper). It closes a critical zero-day vulnerability that lets a non-authenticated attacker upload and execute a malicious file on the server - effectively taking full control of your site. This SP Page Builder security flaw is already being actively exploited.

What makes this attack especially dangerous is that it leaves behind hidden administrator accounts and multiple backdoors that can remain open even after the update. Updating alone is therefore not enough - you also need to check whether your site has already been compromised. And you should act now: the technical details will soon be made public, and once that happens automated bots will start scanning specifically for outdated installations.

What is SP Page Builder - and who is affected?

SP Page Builder is one of the most widely used page builders for Joomla: a component (com_sppagebuilder) that lets you build pages using drag and drop. Precisely because it runs on so many sites, this Joomla security flaw is especially serious.

All 6.x versions up to and including 6.6.1 are affected. The issue is only fixed in 6.6.2. It is enough for the component to be installed - not a single page built with it has to be published. Simply disabling the component also does not help, because the vulnerable endpoint remains accessible.

How to check your installed version:

1. Log in to the Joomla backend
2. Go to Extensions - Manage
3. Filter by SP Page Builder and check the version number

If it shows a 6.x version below 6.6.2, immediate action is needed.

The vulnerability in simple terms

SP Page Builder has an internal function that is only supposed to perform a small administrative task: uploading a custom icon (the task asset.uploadCustomIcon). The problem is that this function checked neither whether the requester was logged in nor which file type was being uploaded - and then stored the file in a folder accessible via the web.

That left the door wide open: an attacker with no login at all could upload a PHP file, open it in the browser - and the server would execute it. In technical terms, this is a Remote Code Execution (RCE) based on an unauthenticated file upload: the most dangerous class of web vulnerability there is, because after that the attacker can practically do anything.

Version 6.6.2 closes this by putting a real check in front of the function: a logged-in user with sufficient rights plus a valid security token (CSRF). Anonymous requests are rejected. (Confirmed by comparing the source code before and after the patch.)

The truly devious part: what remains behind

With this vulnerability, code execution is not the end, but the beginning. The malicious code uses the one-time access to establish a persistent foothold:

• It creates hidden super users - with harmless-sounding names like "Web Editor" or "Admin Backup". The telltale sign: the email address ends in @secure.local. This domain is made up; no real Joomla account uses it. If you find even one super user with this address, the site is compromised.
• It places a PHP backdoor (a file manager with a built-in PHP and SQL console) in several locations at once - typically a .php file under images/.../fonts/ as well as copies named users.php in folders such as /media/com_admin/ or /media/regularlabs/. The multiple placement is deliberate: if you delete one, the others remain.

So the rule is: the update closes the front door - it does not remove access that has already been set up.

Has my site already been attacked?

Because the vulnerability can be exploited without a login and leaves clear traces, you can check specifically for the following:

• User list: Super users that you did not create yourself - especially those ending in @secure.local. Often several appear at once.
• Files: foreign .php files under images/.../fonts/ as well as users.php in /media/com_admin/ and /media/regularlabs/; the content says "PHP File manager". Keep searching even if you have found one - there are usually several identical copies around.

Tip for reading logs: Joomla stores the creation time of an account in the site timezone (from configuration.php), but your server logs usually run in UTC. Convert the times before searching the log - otherwise you will scan the wrong time window and mistake an infected log for a clean one.

If you find anything, treat the site as compromised: delete all unauthorized admins, remove every backdoor copy, then change Joomla passwords, database access, and FTP/SSH keys, end all sessions, and check the entire site - not just SP Page Builder. And an inconspicuous finding is not all-clear; it only rules out exactly this one attack pattern.

Not sure whether your Joomla site is affected or already has a foreign admin account? We check and clean it up for you - the whole site, not just one component. Also see our immediate help for hacked Joomla sites.

Conclusion

The SP Page Builder security vulnerability is critical and is being actively exploited - but the fix is available in 6.6.2. The order is clear: update to SP Page Builder 6.6.2 today, then check the user list and files for the signs described. Server hardening and monitoring come after that and do not replace the update.

Source: official patch release from developer JoomShaper on joomshaper.com.

• Next