• Severity: CVSS 4.0 10.0 (Critical) - CWE-284: Improper Access Control
  • Affected: SP Page Builder (com_sppagebuilder) for Joomla, versions 1.0.0 through 6.6.1 (all versions)
  • Patched: June 14, 2026 (SP Page Builder 6.6.2) · Exploitation: Actively exploited in the wild; public PoC available

Introduction

SP Page Builder is one of the most widely installed Joomla extensions around, a drag-and-drop page builder shipped by JoomShaper and bundled on a significant portion of active Joomla deployments. On June 14, 2026, JoomShaper quietly shipped version 6.6.2 as an “urgent morning task.” The reason: an unauthenticated arbitrary file upload vulnerability, now tracked as CVE-2026-48908, that had already been found and was being actively exploited before the patch landed.

The bug lives in the asset.uploadCustomIcon controller task inside com_sppagebuilder (CWE-284: Improper Access Control). No authentication is required. No anti-CSRF token is checked. No file-type validation runs. An anonymous POST request is sufficient to write attacker-controlled files, including PHP scripts, into a web-accessible directory under the Joomla document root.

Joomla itself (core), Joomla SaaS offerings, and any deployment where SP Page Builder is not installed are unaffected. The vulnerability is entirely contained to third-party extension com_sppagebuilder in versions 1.0.0 through 6.6.1 inclusive. If you run SP Page Builder, this one is as bad as it sounds.

Attribution note: The detailed post-exploitation analysis and log evidence in this post draw heavily from mySites.guru’s writeup by Phil E. Taylor, who traced live attacks in real Joomla access logs and retrieved a copy of the dropper from a compromised site. IONIX’s threat center also contributed technical detail. We are standing on the shoulders of people who did the hard work.

What Happened

SP Page Builder exposes a task called asset.uploadCustomIcon for the purpose of letting administrators upload custom icon font packages. The request looks like this:

POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon HTTP/1.1
Host: target.example.com
Content-Type: multipart/form-data; boundary=...

[ZIP archive in the custom_icon field]

In every version up to 6.6.1, this task ran with no access check whatsoever. The controller received the request, accepted the ZIP archive supplied in the custom_icon multipart field, extracted it, and wrote the contents to:

/media/com_sppagebuilder/assets/iconfont/[name]/fonts/

That directory sits under the web root and is web-accessible. No allow-list validation was applied to the extracted files. If the ZIP contained a .php file, it landed on disk in a browsable location and the server would execute it on a direct GET request.

The result is a single unauthenticated HTTP POST yielding a persistent PHP web shell. From there, an attacker has full server-side code execution.

6.6.2 closes the hole by requiring a valid authenticated session, admin or component-manage permission, and a valid anti-CSRF token before the upload controller runs at all. The endpoint that was wide open is now gated the way it should always have been.

The IONIX research team confirmed active exploitation at the time of publication. Public PoC code appeared on GitHub within two days of the CVE being published.

CVE-2026-48908 - SP Page Builder Controller Exposure

Fig 1: How the `asset.uploadCustomIcon` endpoint sits fully exposed on every affected Joomla install, from the attacker's unauthenticated request straight through to PHP execution on disk

The Attacker’s Playbook Post-Exploitation

This is where things get worse than a typical file upload bug. Threat actors exploiting CVE-2026-48908 are not just executing a one-off command and leaving. The payloads observed in the wild are persistence-first, designed to leave an attacker inside the site even after the entry point is patched.

Step one is the web shell itself. The PHP file lands in /media/com_sppagebuilder/assets/iconfont/[name]/fonts/ and is immediately accessible via a direct HTTP GET. Observed shell filenames follow a consistent pattern: a component name prefix concatenated with a hash-like suffix, for example codex-sppb-d1a93331.php.

Step two is the hidden Super Administrator account. The dropper, once executed, reads configuration.php directly to extract database credentials, then connects to the database and inserts a rogue user. Usernames are drawn from a hard-coded list of role-sounding words (webeditor, contentmgr, sysadmin, webmaster, portaladmin, siteeditor, webmanager, cmsadmin), each followed by two random digits, with the email always set to [username]@secure.local. The @secure.local domain is the consistent attacker signature, it is not a real domain, and no legitimate Joomla account should carry it.

The dropper also disables sql_mode to bypass strict-mode rejections, inserts the user as unblocked, maps it to the Super Users group, and adds the matching #__assets row so the account looks completely native in Joomla’s ACL. Multiple rogue accounts are often created in a single hit.

Step three is the file manager backdoor. The payload drops several copies of a PHP file manager (branded internally as “PHP File manager ver 1.4”) in multiple locations: typically under images/[random]/fonts/ and as stray users.php files in directories like /media/com_admin/ and /media/regularlabs/. Identical copies in multiple locations ensure that removing one does not remove the attacker’s access.

The @secure.local accounts are the polite tap on the shoulder telling you something is very wrong. The users.php file managers scattered around your media directories are the part you’ll regret missing. :/

Once the rogue Super User exists, the attacker no longer needs the upload endpoint at all. A patched site with a rogue admin is still a compromised site.

CVE-2026-48908 - Persistence Mechanisms Left Behind

Fig 2: Post-exploitation persistence: the three components an attacker leaves behind after CVE-2026-48908 exploitation, and where to find each one

Why This Is Especially Dangerous

The CVSS 4.0 score of 10.0 is not generous rounding. Every metric is at its worst possible value:

  • No network path restrictions - any internet-facing Joomla site with the extension installed is reachable
  • No authentication required - attack works on a default install with zero configuration
  • No user interaction required - fully automated; scanning bots confirmed active in the wild
  • High impact on confidentiality, integrity, and availability - for both the vulnerable component and subsequent system scope

In practice, what an attacker gains:

  • Full PHP code execution on the server hosting the Joomla site
  • Read access to configuration.php, including database credentials
  • The ability to create or modify any database record, including user accounts
  • Durable access through planted file managers that survive a patch and a cache flush
  • Joomla Super Administrator privileges, allowing template edits, plugin installs, and full site control
  • A staging point for lateral movement if the web server shares a host or network with other services

Sites most at risk are any internet-exposed Joomla installation running SP Page Builder below 6.6.2. Which, given this is one of the most-installed Joomla extensions with a long tail of unmaintained deployments, is a large exposure surface. Unpublishing SP Page Builder pages does not help: the endpoint is reachable through the component controller regardless of whether any page using the extension is published.

A note on WAF rules: WAF configurations tuned for the concurrent JCE editor RCE wave (CVE-2026-48907) may not block this. The request signatures are different vectors. Observed cases include WAF deployments that correctly return 403 for the JCE com_jce paths while letting the SP Page Builder asset.uploadCustomIcon POST through with a 200. Signature-based blocking protects against exactly what it was told about.

Affected Versions

BranchVulnerable VersionsFix Available
SP Page Builder (Free & Pro)1.0.0 - 6.6.1 (all versions)Yes - upgrade to 6.6.2
SP Page Builder 6.6.2+Not affectedN/A - already patched
Joomla coreNot affectedN/A
WordPress (all versions)Not affectedN/A - unrelated platform

The vulnerable range covers the entire lifetime of the extension, from its first public release through 6.6.1. There is no version of SP Page Builder that is safe except 6.6.2 and above.

Mitigations

1. Update SP Page Builder to 6.6.2 or later, this is the only complete fix. Install through the Joomla updater, push via your site management platform, or download directly from joomshaper.com and install over the existing installation. Confirm the installed version shows 6.6.2 in Extensions Manager after the update.

2. If you cannot update immediately, block the upload endpoint at the web server level. Add a rule that rejects requests containing task=asset.uploadCustomIcon (and its URL-encoded form task=asset%2euploadCustomIcon the dot can be encoded as %2e to bypass naive string-match rules). This is a stopgap only. It does not address any files already uploaded or accounts already created.

3. Check for rogue Super Administrator accounts. In Joomla admin: Users > Manage. Filter for Super Users group and look for any account with an email ending in @secure.local. These are the attacker’s persistence accounts, delete them and treat the site as compromised. Also look for accounts with role-word names like webeditor48, siteeditor38, adminbk.

4. Hunt for dropped web shells. Search for unexpected .php files in the following locations:

  • /media/com_sppagebuilder/assets/iconfont/*/fonts/
  • images/[any subdirectory]/fonts/
  • /media/com_admin/users.php
  • /media/regularlabs/users.php

Any file matching “PHP File manager ver 1.4” in its contents is a backdoor. Remove all copies, not just the first one found.

5. Rotate credentials after any compromise. If your site was running a vulnerable version: change the Joomla admin password, the database user password (and update configuration.php), and any FTP/SSH keys used for deployment. Force-log-out all active sessions via System > Global Check-in and by regenerating the session secret in Global Configuration.

6. Consider RsFirewall 3.3.7 as a supplementary layer. The vendor forum advisory notes that RsFirewall 3.3.7 includes a rule that mitigates exploitation of this endpoint for sites that cannot patch immediately. It is not a substitute for 6.6.2, but adds a defense-in-depth layer while a patch window is arranged.

7. Disable PHP execution in upload directories at the server level. This is a hardening step that limits the blast radius of any future file upload vulnerability, not just this one. In Nginx, deny PHP execution in /media/, /images/, and /tmp/ explicitly. In Apache, set AllowOverride None on those directories so a dropped .htaccess cannot re-enable PHP handler mappings.

Indicators of Compromise

Active exploitation was confirmed in Joomla access logs before the patch was released. The following behavioral indicators are based on real attacker activity observed in the wild.

In web server access logs:

  • POST request to /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon returning HTTP 200
  • Followed (within seconds) by a GET request to /media/com_sppagebuilder/assets/iconfont/[name]/fonts/[filename].php returning 200

Note on timestamps: Joomla writes user account creation timestamps in the site’s local timezone from configuration.php. Your web server access logs are typically in UTC. A rogue admin created at 19:20 in the Joomla user table may correspond to a log entry at 02:20 the next morning in UTC. Correlate with the timezone offset before concluding the log is clean.

In the Joomla admin (Users > Manage):

  • Super Administrator accounts with email addresses ending in @secure.local, this is the primary IoC and is hard-coded in the dropper
  • Usernames matching the pattern [roleword][2 digits]: webeditor48, siteeditor38, webmaster63, portaladmin51, webmanager38, etc.
  • Super Users with a creation date/time in the recent exploitation window that you did not create

On disk:

  • PHP files under /media/com_sppagebuilder/assets/iconfont/ with names like [prefix]-sppb-[hash].php
  • Files named users.php in /media/com_admin/ or /media/regularlabs/
  • PHP files inside images/[random name]/fonts/ directories
  • Any file whose contents reference “PHP File manager ver 1.4”

Network-level attacker infrastructure:

As of the time of writing, no fixed attacker IPs or C2 domains have been publicly attributed. Botnet scanning is confirmed active. Watch the JoomShaper security advisory and the Joomla Vulnerable Extensions List for updates. This advisory was last reviewed on June 26, 2026.

References