⚠ Security Incident ✓ Patch Available — v6.6.2 SP Page Builder June 2026 · 8 min read

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.

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:

No authentication check

Any visitor — logged in or not — could trigger the upload endpoint directly.

No CSRF protection

No session token required, so bots could fire thousands of requests at scale.

Unsafe ZIP extraction

The validator only checked for a dummy icofont.css but extracted everything — including PHP webshells — into /media/.

Automated in the wild

Bots using the agent sppb660-batch/1.0 were scanning and exploiting sites within minutes.

Which versions are affected?

SP Page Builder 6.x builds with the Custom Icons feature. SPPB 3.x, 4.x, and 5.x don't include this feature and are not affected. The fix shipped in version 6.6.2 — update immediately if you haven't already.

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

Take a full site backup before doing anything else

The scanner can permanently delete files. You need a recovery point first. Download a copy off-server before uploading the scanner.

Recommended workflow

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

On shared hosting — scan every site on your account

A breach on one site under your cPanel account may have given the attacker access to all neighbouring Joomla installations. Scan every one of them.

Setting Up the Scanner

Step 1 — Generate your secret key

Run this on your server or locally (requires PHP):

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

You'll get a 64-character string like this — yours will be unique:

47f475d52f1edaf1607159aaafdf9581fb524ac2a16c0059d9353da96c1b3df4

Copy it — you'll need it in the next step and again at login.

Step 2 — Edit the scanner file

Open security-scanner.php in any text editor. Find line 12:

$ACCESS_KEY = 'REPLACE_THIS_WITH_YOUR_OWN_KEY';

Replace the placeholder with your generated key:

$ACCESS_KEY = '47f475d52f1edaf1607159aaafdf9581fb524ac2a16c0059d9353da96c1b3df4';

The scanner won't start if the key is shorter than 32 characters or still contains the placeholder text.

Step 3 — Upload to your Joomla root

Upload via FTP, SFTP, or your hosting file manager to the Joomla root directory — the same folder as index.php and configuration.php. The scanner reads that file automatically to connect to your database.

Always access the scanner over https:// — over plain HTTP your secret key travels in clear text.

Step 4 — Log in

Visit the scanner URL:

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

You'll see a login prompt. Enter the key from Step 2 and click Unlock Scanner. The scanner redirects you with the key in the URL briefly, then strips it and sets a secure session cookie — your key won't sit in browser history. After 5 failed attempts the tool locks itself out for 15 minutes.

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.

Review every path before deleting

Don't check all boxes and click Delete without reading what you're removing. High-confidence findings under /media/com_sppagebuilder/assets/iconfont/ are almost certainly malicious. Medium-confidence vendor library findings need a manual check first.

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

Delete High-confidence files first — PHP files inside /media/com_sppagebuilder/assets/iconfont/ and files matching codex-sppb-*.php should be removed immediately.
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.
Remove rogue Super Users via Joomla Admin → Users → Manage.
Force-logout all sessions — truncate #__session in phpMyAdmin or use Users → Sessions in Joomla admin.
Check cron jobs — look in cPanel → Cron Jobs and run crontab -l via SSH. Remove anything base64-encoded or referencing ~/.config/ paths.
Ask your host to run a full server scan — Imunify360 or ClamAV can find files outside your webroot that this scanner can't reach.
Re-scan in a few days to confirm nothing has re-appeared.

On shared hosting — check every site on your account

Once an attacker has a shell on one site under your cPanel account, they can typically read the directory tree and target all neighbouring sites. Scan every Joomla installation.

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.

Quick reference — full cleanup in 7 steps

Take a full site backup and download it off-server.
Update SP Page Builder to 6.6.2+ to close the upload hole.
Generate a secret key, paste it into the scanner file, upload to your Joomla root.
Visit the scanner URL, enter your key, review all findings carefully.
Delete High-confidence files, remove rogue Super Users, rotate all credentials.
Add the .htaccess PHP execution block to protect /media/ and /images/.
Click Self-destruct at the bottom of the scanner page to remove the tool from your server.

Download the scanner & support the project

Get the latest version from GitHub, or star the project to support updates and security improvements.

Download Repository Star the project ⭐

Remove the scanner when you're finished. The Self-destruct button at the bottom of the scanner page permanently deletes the script and its log files in one click. Leaving any diagnostic tool accessible on a live server is a security risk in itself.

SP Page Builder Infection Scanner for Joomla: Detect & Remove Malware Fast

Comments (0)