CVE-2026-48908: SP Page Builder Zero-Day Hits Joomla Sites Hard

A Joomla site running SP Page Builder doesn’t need a stolen password, a phished admin, or a misconfigured server to get taken over. It just needs to be reachable on the internet. CVE-2026-48908 lets an anonymous attacker upload a PHP file straight through the plugin’s own icon-upload feature, and that file runs the moment it lands. CVSS 10.0, no login required, already exploited in the wild before most site owners had heard of it.

CISA added it to the Known Exploited Vulnerabilities catalog on July 7, 2026, alongside a near-identical bug in a different Joomla page builder extension called Joomlack Page Builder (CVE-2026-56290), an Adobe ColdFusion flaw, and the Langflow IDOR bug we already wrote about on this blog. Four vulnerabilities, one batch, all confirmed under active attack. This post is about the two Joomla ones, because if you or a client runs either extension, the fix is not optional.

What actually happens in the attack

SP Page Builder ships a feature that lets site editors upload custom icons for page elements. The endpoint behind that feature, reached through index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon, is supposed to only accept image files. It doesn’t check what it’s given closely enough. An attacker sends a POST request to that URL with a file that looks like it could be an icon but is actually PHP code, and the server saves it somewhere it can later be requested and executed.

Here’s the shape of the vulnerable pattern, illustrated generically rather than as a working payload:

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

------boundary
Content-Disposition: form-data; name="file"; filename="icon.php"
Content-Type: image/svg+xml

<?php /* arbitrary code would run here */ ?>
------boundary--

The problem isn’t the request itself, it’s what the server does with it. A correctly-built upload handler validates the file’s actual content type, strips or rejects executable extensions, and stores uploads somewhere the web server won’t execute as a script even if one slips through. SP Page Builder’s uploadCustomIcon task reportedly skipped enough of that validation that a .php file saved through it would run like any other PHP script on the server. Once that first request succeeds, the attacker has a webshell, meaning they can execute arbitrary commands with whatever permissions the web server process has.

From there, according to reporting on the active exploitation, attackers didn’t stop at the webshell. They used it to reach into Joomla’s own admin database and create a brand new Super User account. That’s a smarter move than it sounds: a webshell can get spotted by a file integrity scan or a hosting provider’s malware sweep, but a Super User account that logs in through the normal /administrator panel looks like a legitimate admin unless someone is specifically auditing the user list. It’s a quieter, more durable way to keep control of the site even after the webshell itself gets cleaned up.

The sibling bug in Joomlack Page Builder

CVE-2026-56290 hits a different extension, Joomlack Page Builder, but the shape of the bug is the same story: unrestricted upload of a dangerous file type, no authentication needed, CVSS 10.0, added to the same CISA KEV batch on the same day. The public advisories don’t currently give a confirmed patched version number for this one, so if you run Joomlack Page Builder, go check the extension’s own changelog or its listing on the Joomla Extensions Directory rather than trusting a version number pulled from a general news summary. When in doubt, treat any installed version as unverified until the vendor’s own advisory says otherwise.

Side-by-side comparison

CVE	Affected extension	Vulnerability type	CVSS	Status / fix
CVE-2026-48908	JoomShaper SP Page Builder	Unrestricted upload of dangerous file type	10.0	Fixed in version 6.6.2 and later
CVE-2026-56290	Joomlack Page Builder	Unrestricted upload of dangerous file type	10.0	No confirmed fixed version in public sources; check vendor advisory/changelog

What to actually do about it

If you run SP Page Builder, log into your Joomla admin panel, go to the extension’s details, and check the installed version. If it’s older than 6.6.2, update it now, not at the next scheduled maintenance window. This is the kind of bug where “we’ll get to it next sprint” is how sites end up with a rogue Super User account nobody noticed for three months.

If you run Joomlack Page Builder, don’t wait for a version number to show up in a news article. Go straight to the extension’s own support page or changelog and see what the vendor has published. If there’s no clear fix yet, the safer move is to disable the extension’s upload-related features, or the extension entirely, until one exists.

Either way, it’s worth auditing your Super User list right now, whether or not you think you’ve been hit. New accounts you don’t recognize, especially any created in the last few weeks, are the clearest sign this bug was already used against you.

This is the same failure pattern we wrote about with WordPress core’s wp2shell RCE chain: a file upload or request-handling path that trusts input more than it should, reachable by anyone, turning into full control of the site. Page builder plugins are an especially common source of this because they’re built to let non-technical editors upload media and assets quickly, and “quickly” often means the validation gets thin. If you’re responsible for a portfolio of Joomla or WordPress sites and don’t have a process for tracking plugin versions across all of them, that gap is exactly what bugs like this one exploit. It’s also the kind of thing a periodic security audit catches before CISA does, which is part of why we run those as an ongoing part of our security services work rather than a one-time check.

The practical takeaway here isn’t complicated: know which page builder extension your Joomla sites are running, know its version number, and don’t let “I’ll check that later” survive a CVSS 10.0 with confirmed active exploitation. The patch for SP Page Builder exists and takes minutes to apply. There’s no good reason to still be running 6.6.1 or earlier by the time you finish reading this.