SP Page Builder Rogue Icon-Font Assets

What this check and mySites.guru tool looks at on your site

SP Page Builder is one of the most widely installed page builders for Joomla. This check reads the SP Page Builder assets table (#__sppagebuilder_assets) and flags a row when both of these are true: it is an iconfont asset, the entry type SP Page Builder creates for a custom uploaded icon font, and it was created by no Joomla user, created_by = 0. A genuine custom icon font is uploaded by a logged-in administrator through the page builder’s interface, so it always carries that admin’s user ID. An asset created by nobody was registered anonymously, which only the upload exploit does, since there is no other route to that table that skips setting a user ID.

Each flagged row is annotated with why it is rogue: a name built from parent-directory hops (../../) aimed at writing outside the media folder altogether, a machine-generated random blob name such as o39t8sem or ico4o0q5r, or simply that it was planted with no user attached. A row’s folder column points at where SP Page Builder unpacked the matching files, normally media/com_sppagebuilder/assets/iconfont/<name>/, and that folder is checked alongside the row: a rogue row with no matching folder, or a folder whose contents do not look like icon-font files at all, is exactly what a dropped webshell looks like once you know where to check. Because both the iconfont type and the missing created_by have to be true together, a legitimate icon font you or your team genuinely uploaded is never flagged.

A hiding place picked on purpose

Up to and including version 6.6.1, SP Page Builder’s asset.uploadCustomIcon task was an unauthenticated arbitrary file upload, the zero day behind a wave of fake Joomla admins: an anonymous visitor, with no Joomla account, could send a single request that both registered a new iconfont row in the assets table and wrote the accompanying files into the site’s media tree. No login, no CSRF token and no permission check stood in the way, because the endpoint trusted the request rather than checking who sent it.

An icon-font folder is a genuinely good hiding place, which is why the campaign chose it. Every SP Page Builder site legitimately has an iconfont folder full of oddly named files, since icon-font libraries are themselves a pile of generated font and CSS assets with short, meaningless names. A rogue folder with a random eight-character name sits there unremarked next to real ones, and a webshell dropped inside it looks, to a casual glance, exactly like the rest of the folder’s contents. Automated tooling sprays this at scale: one compromised site in the wild carried 6,572 fake iconfont asset rows, each with a matching folder under media/com_sppagebuilder/assets/iconfont/. The rows all share the same fingerprint: type = iconfont, created_by = 0, and a machine-generated or traversal name.

The webshell files dropped alongside these rows are also caught by a general suspect-content file scan, and the same attack typically creates a fake Super Administrator for persistence, which is a separate check: see Rogue Super Admin Accounts. This check owns the database side, the thousands of asset rows a file scan alone would never see, since nothing about an #__sppagebuilder_assets row looks unusual to a scanner that only reads the filesystem.

Every row traceable to a real upload

Every iconfont row in #__sppagebuilder_assets carries a real administrator’s user ID in created_by, every icon-font folder under media/com_sppagebuilder/assets/iconfont/ matches an asset you or your team genuinely uploaded, and none of those folders contain anything other than font and stylesheet files.

How to fix it

1. Update SP Page Builder to the current version first. Cleaning without patching invites the rogue assets straight back, since older versions accept the same anonymous upload. In the administrator, go to System, then Update, then Extensions, and update SP Page Builder.
2. List the rogue rows before deleting anything. Query #__sppagebuilder_assets for type = 'iconfont' AND created_by = 0 and note what you find, including the folder value on each row.
3. Open each folder before you delete it. Check what is actually inside, PHP files mixed in with the fonts are the webshell, not scaffolding. Note anything that is not a font, CSS or manifest file.
4. Delete each rogue row and its matching folder. Remove the database row, then delete the corresponding folder under media/com_sppagebuilder/assets/iconfont/. Be careful with any name built from parent-directory hops (../); confirm the resolved path stays inside that folder before deleting anything, since a traversal name is designed to trick exactly this step.
5. Find the dropped webshell. The same attack drops a PHP File Manager backdoor in several spots. Deleting the asset rows alone does not remove it, so run a full file scan across the site.
6. Check for a rogue Super Administrator. The attack also typically creates one for persistence. See Rogue Super Admin Accounts and remove anything you do not recognise.
7. Rotate secrets and check your portfolio. Change every Joomla admin password, the database credentials and any FTP/SSH access, then check every other site running SP Page Builder. This is automated, sprayed tooling. If a Joomla 3 site cannot run the fixed mainline version, see Unpatched JoomShaper Security Holes for JoomShaper’s separate Joomla 3 patch.

What mySites.guru does about it

On every snapshot, twice a day, mySites.guru reads the SP Page Builder assets table and flags any row matching both conditions above. We show you every rogue row, its folder, and why it was flagged, so you can verify the evidence before removing anything.