Two Joomla page builders are exploited for site takeover. The patch won't evict the intruder.

The fastest way to lose a Joomla site this month is to run a page-builder extension and treat the vendor update as the end of the story. It is not. On July 7 CISA added two more Joomla add-ons to its Known Exploited Vulnerabilities catalog, both scored CVSS 10, both letting anyone on the internet upload a file and run it with no login. Federal agencies have until July 10 to patch. The harder truth for everyone else: patching removes the way in, not the attacker who already walked through it.

The two flaws are CVE-2026-48908 in JoomShaper's SP Page Builder and CVE-2026-56290 in Joomlack's Page Builder CK. Different vendors, different code, the same defect and the same week on the exploited list.

One upload flaw, three Joomla extensions in a month

This is not a one-off you can patch and forget. In mid-June we covered the JCE editor flaw (CVE-2026-48907), an unauthenticated upload in the most-installed Joomla content editor that CISA listed on June 16. Three weeks later the same failure shows up in two more popular Joomla extensions at once. That is three separate front-end upload endpoints, in three widely deployed add-ons, all reachable with no credentials, inside a single month.

The shared root cause, per the CVE records and vendor advisories, is a design decision rather than a stray coding bug. Each endpoint checked for a Joomla anti-CSRF token and treated a valid token as permission to upload. That token is an integrity check: it proves a request came from a page on the site, and any visitor can read one straight off that page. It says nothing about who you are or whether you may write files. Page Builder CK's upload also let the caller choose the destination folder and the filename, so an attacker decided where the PHP file landed. When three separate extensions treat a forgery token as a login, the issue is the pattern, and Joomla's extension upload surface is where it keeps surfacing.

The fix closes the endpoint. It does not close the breach.

Both extensions were patched weeks before CISA listed them, because KEV entries only appear once exploitation is confirmed. SP Page Builder was fixed in 6.6.2 in June; Page Builder CK shipped 3.6.0 on June 27. Researchers tracking Page Builder CK reported a live webshell on a site within hours of that release. So the gap between a public fix and real attacks was measured in hours, not weeks, and any internet-facing Joomla site that ran a vulnerable build should assume it was reachable during that window.

What the attackers leave behind is why a clean update is not the finish line. In SP Page Builder intrusions, researchers found new Super Administrator accounts created from a fixed list of plausible names, each on an @secure.local email, plus self-contained file-manager shells copied into several spots under the site's images/ and media/ folders. Page Builder CK cases dropped a shell into a directory named to blend in, /media/com_pagebuilderck/gfonts/. Update to the fixed version and the upload endpoint closes; the rogue admin and the shell stay exactly where they are. A patched Joomla site that still carries an admin account you never made is a fully owned site.

How to tell if a site was already hit

Treat every Joomla install that ran a vulnerable SP Page Builder or Page Builder CK build as suspect until you have checked it, not just updated it. Two checks find almost all of this.

First, audit the user table. Look for any Super User or Administrator account you cannot tie to a real person, and in particular for the SP Page Builder tell: machine-style usernames on an @secure.local domain. One forensic detail worth knowing: Joomla records those account timestamps using the site timezone, but your web-server logs run in UTC. A creation time that will not reconcile with the access-log clock is itself a signal.

Second, hunt for files that should not exist. A page-builder media folder holds fonts and images; a .php file inside one is close to a definitive indicator of compromise. Known drop locations from these two campaigns include:

• a random subfolder under images/ and copies named users.php under /media/com_admin/ and /media/regularlabs/ (SP Page Builder)

• /media/com_pagebuilderck/gfonts/ (Page Builder CK)

This is the kind of change file integrity monitoring is built to catch: a new executable file in a directory that only ever holds static assets. A managed detection layer with file integrity monitoring flags the write the moment it happens, which is the difference between finding a shell in an afternoon and finding it after the next incident. Ranking your own exposure first, by which hosts even run these extensions, is what vulnerability detection is for, and it is how you scope the hunt before you start it. For the wider job of hardening the public apps on your servers, our web application coverage lays out the surface.

Clean the media folders before you trust the patch

Order of operations matters here, and it is the lesson we drew from Ivanti Sentry: patch, then hunt, and on any host that shows an artifact, clean before you call it done. Update SP Page Builder to 6.6.2 or later and Page Builder CK to 3.6.0 or later, using the back-ported fixes if you are on an older Joomla 3 or 4 branch. Then remove any Super User you did not create, delete the dropped shells, rotate every Joomla admin credential and secret, and invalidate active sessions. Running the update without the cleanup leaves the door you locked with the intruder still inside. CISA listed a third exploited flaw the same week, in Adobe ColdFusion; the page builders are the ones most likely sitting on a small-business Joomla host that nobody is watching.