SP Page Builder security flaw: update Joomla to 6.6.2 now

A critical Zero-Day vulnerability has been identified in SP Page Builder. The vendor provides an emergency fix in SP Page Builder 6.6.2.

Why this matters: a non-authenticated attacker can upload and execute a malicious file on the server—resulting in full control of the Joomla site. The exploit is already being actively used.

Key details: what remains after the update

The patched component closes the initial vulnerability, but the attack chain is more serious than a single entry point:

• the malware may leave hidden administrator accounts
• and multiple backdoors that can remain accessible even after updating the extension

Therefore, updating alone is not sufficient. After patching, you must check whether your site is already compromised, then perform remediation steps.

Automated scanners are expected to start probing for installations still vulnerable to this issue.

What is SP Page Builder and who is affected?

SP Page Builder is a widely deployed Joomla page builder component:

• Joomla extension: com_sppagebuilder
• Function: drag-and-drop page building
• Usage: present on a large number of Joomla installations

Affected versions

• All SP Page Builder 6.x releases up to and including 6.6.1
• The vulnerability exists as soon as the component is installed—no specific page created with it needs to be published.

Deactivation is not a fix

Disabling the component does not fully protect you, because the vulnerable endpoint remains reachable.

Check whether you’re vulnerable (installed version)

In the Joomla backend:

1. Go to Extensions → Manage
2. Search/filter for SP Page Builder
3. Verify the installed version number

If you have a version below 6.6.2 (i.e., 6.x < 6.6.2): action is urgent.

Vulnerability explained (technical overview)

SP Page Builder contains an internal function intended for a relatively small administrative task: uploading a custom icon (asset.uploadCustomIcon).

The flaw:

• the function performs insufficient validation
• it does not properly enforce authentication
• it does not adequately restrict file type
• it writes the uploaded file into a web-accessible directory

Impact:
An attacker without login can upload a PHP payload and then execute it by requesting it via the browser.

This is effectively Remote Code Execution (RCE) caused by an unauthenticated arbitrary file upload—one of the most severe categories of web vulnerabilities.

What the patch changes in 6.6.2

In version 6.6.2, the function is guarded properly:

• require an authenticated user
• require sufficient authorization
• require a valid CSRF token
• reject anonymous requests

The article notes the change is confirmed by comparing the source code before/after the patch.

The persistent compromise: why you still need to clean up

In these incidents, code execution isn’t the end of the story—the attacker uses the initial foothold to maintain access:

1) Hidden super-user backdoor accounts

The attacker creates administrator accounts with misleading names such as:

• “Web Editor”
• “Admin Backup”

A distinguishing identifier is the email suffix:

• @secure.local

This domain is not a real Joomla account domain. If you find any super-user with @secure.local, treat the site as compromised.

2) PHP backdoors placed in multiple locations

The attacker drops a “file manager”-style PHP backdoor (including PHP/SQL console capabilities) typically as:

• a .php file under paths like:
  images/.../fonts/
• plus copies such as:
  users.php

Common target directories mentioned:

• media/com_admin/
• media/regularlabs/

Why multiple copies? so that deleting one instance doesn’t remove the persistence.

What to do now (concrete remediation steps)

Step 1: Update SP Page Builder immediately to 6.6.2

Use one of these paths:

Option A: Joomla updater

• System → Updates → Check for Updates
• update SP Page Builder

Option B: direct package installation

• download the package from joomshaper.com
• install via Extensions → Manage → Install

Important guidance

If you previously removed or renamed the component in an emergency:

• do not restore old files
• reinstall 6.6.2 cleanly
• otherwise the vulnerable code may be reintroduced.

Step 2 (if update cannot be done immediately): temporary webserver mitigation

As a stopgap, you can block requests tied to the vulnerable task:

• block the endpoint parameter/function: asset.uploadCustomIcon
• ensure you also match URL-encoded traversal patterns such as %2e

This is explicitly not a replacement for updating—it’s an interim containment measure only.

Was your site already attacked? (Indicators and how to verify)

Because exploitation can occur without login and leaves noticeable artifacts, you should perform targeted checks.

A) Check Joomla user list

Look for super-users you did not create—especially accounts with:

• email ending in @secure.local

Often multiple such accounts appear at once.

B) Search for injected PHP files

Look for malicious .php files in these patterns:

• under images/.../fonts/
• and for a filename like users.php in:
  • media/com_admin/
  • media/regularlabs/

Content clue: the file contents may include the string “PHP File manager”.

If you find one, continue searching: attackers typically leave multiple identical copies.

C) Logging tip: timezone mismatch

If you inspect server logs:

• Joomla records account timestamps using the Joomla timezone set in configuration.php
• server logs often use UTC

Convert timestamps before correlating events, otherwise you may search the wrong time window and miss the compromise.

If you find evidence: incident handling (treat as compromised)

When indicators are found:

1. Delete all unauthorized admin accounts (remove @secure.local users)
2. Remove all backdoor file copies (don’t stop after deleting just one)
3. Rotate credentials:
   • Joomla/database passwords
   • FTP/SSH keys (and any other exposed secrets)
4. End all sessions
5. Perform a full site review—not only SP Page Builder.
6. Remember: a clean result for SP Page Builder is not “all clear” unless you verify the absence of the described persistence mechanisms.

Additional hardening (recommended, but not a substitute)

This class of vulnerability highlights why server-side hardening is a strong second defense line.

If PHP execution is restricted in upload/media directories (e.g., images, media), an uploaded malicious file often cannot execute—even if the upload occurs.

HTProtect is presented in the article as an automated way to implement exactly this kind of protection, plus it adds scanning/alerting for known vulnerable extensions and checks for already placed backdoors.

However, the article is clear: the patch is required, server hardening complements it.

Summary / action order

1. Update SP Page Builder to 6.6.2 today
2. Immediately check for backdoor users and injected PHP files
3. Apply server hardening and monitoring after remediation