Four Joomla extensions, one pattern: the unauthenticated-upload wave that plants ghost admins

The same bug, four times in a month

Between late June and early July 2026 CISA's catalog of known-exploited vulnerabilities took in four different Joomla extensions within days of each other. SP Page Builder by JoomShaper and PageBuilder CK by Joomlack were added on 7 July; iCagenda and Balbooa Forms on 10 July. Different vendors, different jobs — a page builder, another page builder, an event calendar, a form builder — and a single flaw underneath: an extension endpoint that accepts a file upload without asking for a login and without checking the file type.

The score is identical and maximal: CVSS 9.8 on the 3.1 scale, 10.0 on 4.0, for all four. The mechanism is the most classic and the most severe of web vulnerabilities: an attacker uploads a .php file, browses to it, and the server runs it. From there control is total — steal data, deface pages, plant backdoors, use the server to attack others.

The best-documented case: asset.uploadCustomIcon

The most detailed of the four is SP Page Builder (CVE-2026-48908), one of the most installed Joomla extensions anywhere. Researcher Phil Taylor, who runs the mySites.guru platform and traced the attack in real access logs, pinned down the exact point: the controller exposes a task called asset.uploadCustomIcon, meant for a trivial admin job — uploading a custom icon — but reachable with an ordinary Joomla request, with no access check at all and without using the helpers Joomla provides to validate uploads against an allow-list of safe extensions.

Nothing had to be enabled, no page had to be published: the endpoint was live on any default install with the component present. Version 6.6.2 closes the hole by adding the gate that should have been there from the start — an authenticated user with admin permission and a valid anti-CSRF token, otherwise 401/403. Every version up to and including 6.6.1 stays vulnerable.

1. 01
   POST asset.uploadCustomIcon

   request with no credentials, .php file attached
2. 02
   Written under the web root

   no check on the file type
3. 03
   GET the uploaded file

   the server executes the web shell
4. 04
   Full compromise

   data, backdoors, new admin accounts

What the attacker leaves behind

This is where the story stops being a CVE and becomes a clean-up problem. According to the mySites.guru analysis, the payload observed on SP Page Builder does not stop at one-time execution: it creates one or more hidden Super Administrators. The display names are reassuring — "Web Editor", "Site Helper", "Admin Backup" — with usernames like webeditor67 or portaladmin51, but the detail that never changes is the email ending in @secure.local, a non-existent domain no legitimate account uses. If a Super User with that address shows up on a Joomla site, that site was compromised through this exploit.

In parallel the dropper scatters identical copies of a backdoor — a "PHP File manager ver 1.4" panel with a file browser, PHP console and SQL console — in inconspicuous places: a .php under images/<random>/fonts/, and files named users.php in folders like /media/com_admin/ and /media/regularlabs/. The multiple copies are for persistence: find one and delete it, the others remain.

There is also a concrete defensive trap mySites.guru flags: a WAF tuned for this year's JCE wave may not stop this one. It is a separate vector with a different request signature, and rules tuned for com_jce were seen returning 403 on the JCE exploit while letting asset.uploadCustomIcon through with a 200. Signature blocking protects against exactly what it was told about, and nothing else.

What is verified and what is not

To be precise: there is no attribution. No named actor, no named campaign. The KEV catalog lists ransomware-campaign use as "Unknown" for all four. Whether a single group or several actors reusing the same bug class sit behind the four extensions is not established: the certain part is the pattern — an AJAX or form endpoint that skips its authorization check — one of the most common ways Joomla sites get hacked through third-party code.

The operational detail of the payload (the @secure.local accounts, the backdoor paths) comes from the mySites.guru reconstruction on sites actually compromised via SP Page Builder; for the other three CVEs the primary source is the KEV entry and the NVD record, which confirm active exploitation and the flaw class but do not detail the same payload. The ATT&CK IDs at the top — T1190, T1505.003, T1136.001 — are not copied from an advisory: they are a reasoned mapping of what the chain enables (reach an exposed app, install a web shell, create an account), not a primary-source datum.

What to do, now

Remediation is to update, on every site, to the latest version: SP Page Builder 6.6.2, iCagenda 4.0.8, PageBuilder CK 3.6.0, and the fixed Balbooa Forms release. But updating shuts the front door, it does not evict whoever is already inside: a patched site with a ghost Super User on it is still fully compromised. For every site that ran one of these extensions in a vulnerable version, the hunt is concrete — check the user list for Super Administrators with an @secure.local email, look for unexpected .php files under images/<random>/fonts/ and users.php files carrying the "PHP File manager" signature in /media/. If you find anything, treat the site as breached: remove the admin and every backdoor copy, rotate Joomla passwords, database credentials and FTP/SSH keys, force-logout all sessions. The lesson, more than any single CVE, is that the security of your sites depends on code other people wrote: the day a flaw like this goes public you need to know within minutes which of your sites run it, and who was already inside before you.