Zerodayhub

TL;DR: A maximum-severity zero-day in SP Page Builder, one of the most widely installed page builder extensions for Joomla, lets anyone upload and run a PHP web shell with no login at all. Attackers are already exploiting it in the wild to plant hidden Super Administrator accounts — patch to 6.6.2 immediately and then go hunting for rogue admins.

Key takeaways

• SP Page Builder 1.0.0 through 6.6.1 lets anyone, with no login at all, upload and execute a PHP file on the server.
• Attackers have already exploited this as a zero-day, using it to plant hidden Super Administrator accounts as a long-term backdoor.
• CISA added CVE-2026-48908 to its Known Exploited Vulnerabilities catalogue on 7 July 2026, with a federal remediation deadline of 10 July 2026 — which has now passed.
• Updating to 6.6.2 closes the hole, but it does not remove an attacker who already got in. Every site that ran a vulnerable version needs an admin-account and backdoor sweep.

What is CVE-2026-48908?

CVE-2026-48908 is a critical, unauthenticated file-upload vulnerability in SP Page Builder, a drag-and-drop page builder extension for Joomla developed by JoomShaper and used across a large share of the Joomla install base. The Joomla security team published the CVE on 20 June 2026, rating it CVSS v4.0 10.0 — the maximum possible score — and classifying the root cause as CWE-284, Improper Access Control.

The flaw sits in a component task that JoomShaper itself ships: asset.uploadCustomIcon. It was meant to let a logged-in editor upload a small custom icon for a page element. Instead, it processed uploads from anyone, authenticated or not, without checking what type of file was being written to disk. That is the entire bug, and it is about as bad as a web application flaw gets: no credentials, no user interaction, full code execution.

How the SP Page Builder exploit works

In plain terms: the vulnerable endpoint accepted a file upload and saved it into a folder under the Joomla web root without checking the file extension or requiring a login. An attacker could send a PHP file disguised as an icon upload, then simply request that file’s URL to have the web server execute it — instant remote code execution, with no account and no user having to click anything.

The technical chain, as documented by researchers who traced live attacks:

• Root cause: the SP Page Builder controller task asset.uploadCustomIcon (reached via index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon) ran with no authentication check and no server-side file-type validation, unlike Joomla’s own upload helpers which enforce an extension allow-list.
• What the attacker sends: a crafted multipart/form-data POST to that endpoint, substituting a PHP payload for the expected icon image.
• What they get: the file lands in a web-served directory; a follow-up request to its path executes it, handing the attacker a working web shell under the permissions of the web server user.
• Pre-conditions: essentially none. The endpoint is reachable on any default Joomla install with SP Page Builder present — nothing needs to be enabled or published first.

[NON-OPERATIONAL, illustrative only — not a working exploit]
POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon HTTP/1.1
Host: victim-site.example
Content-Type: multipart/form-data; boundary=----X
------X
Content-Disposition: form-data; name="file"; filename="icon.php"
Content-Type: image/png
<PHP payload withheld>
------X--
# Followed by a GET request to the resulting file path to trigger execution.

Researchers who examined compromised sites found the payload does more than pop a shell: it connects directly to the Joomla database using credentials read out of configuration.php, then inserts a brand-new Super Administrator account — using a randomly chosen role-sounding username (e.g. webeditor, sysadmin, portaladmin plus digits) paired with an email address ending in @secure.local. It also drops a full-featured PHP file-manager backdoor (browsing, a PHP console, a SQL console) in several near-identical copies under paths like images/<random>/fonts/ and /media/com_admin/, so that removing one copy still leaves others in place.

Is CVE-2026-48908 actively exploited?

Yes. This was exploited as a zero-day — attacks were already under way before or immediately around public disclosure, rather than starting only after a patch appeared. Security researchers at mySites.guru, who monitor extension versions and file changes across a large base of Joomla sites, traced live compromises directly to this endpoint: a POST to the asset.uploadCustomIcon task returning HTTP 200, followed by a request to a newly planted PHP file, followed by the appearance of a hidden Super User account.

CISA added CVE-2026-48908 to its Known Exploited Vulnerabilities (KEV) catalogue on 7 July 2026, alongside a related Joomla page-builder flaw (CVE-2026-56290, in the separate “Page Builder CK” extension) and two other actively exploited bugs, citing evidence of in-the-wild exploitation. Federal civilian agencies were given until 10 July 2026 to remediate — a deadline that has now passed. Public exploit code (proof-of-concept scripts capable of mass-scanning for the flaw) is also circulating on GitHub, which raises the likelihood of continued opportunistic exploitation against any site still running 6.6.1 or earlier.

There is no confirmed attribution to a specific named threat actor or group at the time of writing; reporting describes the activity as automated, opportunistic scanning and exploitation rather than a targeted campaign against particular organisations.

How to fix CVE-2026-48908: remediation & mitigation

Patch: Update SP Page Builder to version 6.6.2 or later on every Joomla site where it is installed. This can be done through the standard Joomla extension updater, in bulk via a fleet-management tool, or by downloading 6.6.2 directly from JoomShaper and installing it over the existing copy. If you removed or renamed the component as an emergency measure, reinstall from a clean 6.6.2 download rather than restoring the old files.

If you can’t patch immediately:

• Block or rewrite requests containing the asset.uploadCustomIcon task at the web server or WAF layer. Note that a naive rule matching a literal dot in the task name can be bypassed if the dot is URL-encoded as %2e — the rule needs to account for the encoded form too.
• Do not rely on unpublishing SP Page Builder in the Joomla backend — the vulnerable controller task remains reachable regardless of whether any SP Page Builder content is published.
• Restrict or firewall off admin-facing paths where feasible while the update is scheduled.

After patching: Updating alone does not evict an attacker who already got in. For every site that ran a version at or below 6.6.1:

• Review the Super Administrator user list for accounts you did not create — the clearest signal is an account with an email address ending in @secure.local, often using generic role-style usernames (webeditor, siteeditor, portaladmin, cmsadmin, etc., typically followed by digits).
• Search the file system for unexpected .php files under paths such as images/<random>/fonts/ and stray files named users.php under /media/com_admin/ or similar component media directories — these are signatures of the dropped PHP file-manager backdoor.
• If anything is found, treat the site as fully compromised: remove the rogue admin accounts and every backdoor copy, rotate Joomla, database, and FTP/SSH credentials, force-terminate all active sessions, and audit the site more broadly rather than assuming SP Page Builder was the only entry point touched.

Detection / IOCs:

• Attacker-created Super Administrator accounts with email addresses at the @secure.local domain.
• Files matching a “PHP File manager” signature, frequently duplicated across multiple directories for persistence.
• Web server access log entries showing HTTP 200 responses to index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon (or its URL-encoded variant) from unfamiliar source IPs, followed shortly by requests to newly created files in upload directories.

Frequently asked questions

Is my site affected if I don’t remember installing SP Page Builder?

Check your installed Joomla extensions directly — SP Page Builder ships as com_sppagebuilder. If it is present and at version 6.6.1 or earlier, it is vulnerable regardless of whether you actively use its page-building features or have any of its pages published.

Does removing or disabling SP Page Builder protect me instead of updating?

Not reliably. Reporting indicates the vulnerable controller task remains reachable through Joomla’s routing even when SP Page Builder content is unpublished. Updating to 6.6.2, which adds the missing authentication and permission check, is the dependable fix.

I’ve already updated to 6.6.2 — am I safe now?

The upload hole is closed, but that only stops new intrusion attempts. If your site was already compromised while running a vulnerable version, the attacker’s planted Super Administrator account and backdoor files persist after the update. You still need to check for and remove them.

How can I tell if I was actually exploited, rather than just exposed?

Look for the specific indicators above — @secure.local admin accounts and PHP file-manager backdoor files. Their presence indicates confirmed compromise; their absence rules out this particular attack signature but doesn’t guarantee the site is otherwise clean, so a broader security review is still worthwhile if you were running a vulnerable version for any length of time.

Sources & further reading

• NVD — CVE-2026-48908 Detail
• CISA — Adds Three Known Exploited Vulnerabilities to Catalog (7 July 2026)
• The Hacker News — CISA Adds 4 Actively Exploited Adobe, Joomla, and Langflow Flaws to KEV
• mySites.guru — SP Page Builder Zero Day Is Being Used to Plant Fake Joomla Admins
• JoomShaper — SP Page Builder

ZeroDayHub tracks critical vulnerabilities as they break. Subscribe for updates.