How to Use the SP Page Builder Infection Scanner to Check & Clean Your Joomla Site

In June 2026, a critical unauthenticated Remote Code Execution vulnerability was disclosed in SP Page Builder versions below 6.6.2. Attackers could upload PHP webshells without any login, read your configuration.php, and inject rogue administrator accounts — all in under a minute. This guide walks you through using the free scanner to safely detect and remove any traces of this attack.

In this guide

1. Understanding the vulnerability
2. Before you start — backup and staging
3. Setting up the scanner
4. Using the scanner — section by section
5. After the scan — what to do next
6. Hardening your site going forward

Understanding the Vulnerability

The flaw lives in a single endpoint — asset.uploadCustomIcon inside /components/com_sppagebuilder/controllers/asset.php. Three security failures were chained together:

Once a shell was in place, attackers read configuration.php, extracted database credentials, and injected rogue Super User accounts — typically with emails ending in @secure.local and usernames like webmanager83.

Before You Start — Backup and Staging

Recommended workflow

1. Back up everything — use Akeeba Backup, your hosting snapshot, or a direct DB dump + file archive. Download it off-server.
2. Patch first, then scan — update SP Page Builder to 6.6.2+ before running the scanner so the upload hole is closed.
3. Use staging if possible — clone your site and run the scanner there first. Review findings before touching production.
4. If scanning production directly — do it during low-traffic hours and delete the scanner file the moment you're done.

Setting Up the Scanner

php -r "echo bin2hex(random_bytes(32));"

47f475d52f1edaf1607159aaafdf9581fb524ac2a16c0059d9353da96c1b3df4

$ACCESS_KEY = 'REPLACE_THIS_WITH_YOUR_OWN_KEY';

$ACCESS_KEY = '47f475d52f1edaf1607159aaafdf9581fb524ac2a16c0059d9353da96c1b3df4';

https://yoursite.com/security-scanner.php

Using the Scanner — Section by Section

Once logged in, the scan runs automatically. Here's how to read each section:

Summary stats

Four cards show issue counts per category. Green = clean, red = something found. A fifth DB offline card appears if the scanner can't reach your database — confirm configuration.php is in the same directory and your DB credentials are current.

Section 1 — Suspicious files & folders

The most important section. Each row shows a path, confidence level, and reason:

• → High confidence — a known malware signature like eval(base64_decode($_POST[...])), a filename matching real attack patterns like codex-sppb-*.php, or a PHP file inside an icon-font folder that should only contain fonts and CSS.
• → Medium confidence — a structural anomaly: an executable inside a media directory, or a file modified at a very different time from its siblings. Worth reviewing but not automatically malicious.
• → DIR badge — the finding is a folder. Deleting it removes the entire folder recursively.

Section 2 — Super User accounts

Lists every Super User in your Joomla database. A red Suspicious badge flags accounts matching known attacker patterns — email addresses ending in @secure.local or usernames like webmanager83. The scanner doesn't auto-delete accounts — go to Joomla Admin → Users → Manage to remove them.

Section 3 — Menu XSS injections

Checks your #__menu table for a known Stored XSS payload targeting the Helix Ultimate mega-menu. If found, do not edit the menu item through Joomla's admin panel — the editor may render the payload. Use phpMyAdmin or a direct SQL query to clear the params field instead.

Section 4 — SP Page Builder asset table

Scans sppagebuilder_assets for rows containing eval(, base64_decode, or known payload URLs. Remove any suspicious rows via phpMyAdmin.

After the Scan — What to Do Next

If findings were detected

1. Delete High-confidence files first — PHP files inside /media/com_sppagebuilder/assets/iconfont/ and files matching codex-sppb-*.php should be removed immediately.
2. Rotate all credentials — change your database password (update the file too), SMTP password, any API keys, and regenerate the Joomla secret value in Global Configuration.
3. Remove rogue Super Users via Joomla Admin → Users → Manage.
4. Force-logout all sessions — truncate #__session in phpMyAdmin or use Users → Sessions in Joomla admin.
5. Check cron jobs — look in cPanel → Cron Jobs and run crontab -l via SSH. Remove anything base64-encoded or referencing ~/.config/ paths.
6. Ask your host to run a full server scan — Imunify360 or ClamAV can find files outside your webroot that this scanner can't reach.
7. Re-scan in a few days to confirm nothing has re-appeared.

If no findings were detected

A clean result is reassuring but not a guarantee — the scanner uses heuristics, not checksums. Still:

• → Confirm SP Page Builder shows version 6.6.2+ in the Extension Manager.
• → Check your access logs for POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon — if the line exists, an attempt was made.
• → Run a full filesystem scan via your host's malware scanner as a second opinion.

Hardening Your Site Going Forward

The single most effective change is blocking PHP execution in upload-only directories. Add this to your main .htaccess in the Joomla root:

<DirectoryMatch "/(media|images|uploads|tmp|cache|assets|icons|fonts)(/|$)">
  AllowOverride None
  <FilesMatch "(?i)\.(php|phtml|phar|php[0-9]?|php\..*|shtml)$">
    Require all denied
  </FilesMatch>
</DirectoryMatch>

This makes the entire upload-and-execute attack class inert — even if a webshell reaches /media/, the server returns 403 Forbidden instead of running it.

• → Enable 2FA on Joomla admin, your hosting control panel, and linked email accounts.
• → Keep all extensions updated — most Joomla compromises trace back to a known, already-patched vulnerability that was simply never applied.
• → Enable Action Logging (System → Action Logs) so every login and user creation is recorded.
• → Turn on cPanel API token alerts in cPanel → Contact Information so you're notified immediately if a token is created.
• → Consider a Joomla firewall component — Akeeba Admin Tools Pro and RSFirewall both added rules specifically targeting this vulnerability.