SP Page Builder: Critical RCE Flaw (CVE-2026-48908) Actively Exploited

Published on 5 August 2026

A single unauthenticated HTTP request is enough to gain complete control over a Joomla server. That is precisely what the vulnerability CVE-2026-48908 in the widely used JoomShaper SP Page Builder makes possible – and attackers are actively exploiting it right now. On 2 August 2026, further attacks were observed, even though a security update has been available for weeks. Anyone using the SP Page Builder on their Joomla website who has not yet updated should read this article to the end and then act without delay.

What happened?

JoomShaper's SP Page Builder is one of the most widely used extensions for the content management system Joomla – the software many websites are built and managed with. With over 13.6 million downloads by more than 790,000 users worldwide, it is one of the most popular builder tools for Joomla sites. According to Watchful.net, the SP Page Builder is installed on around 21% of all professionally managed Joomla websites.

A vulnerability discovered in this extension is rated as about as severe as it gets: it received the maximum possible CVSS 4.0 score of 10.0 (CVSS is the internationally used scale for assessing the severity of security flaws, from 0 to 10). The flaw allows attackers to upload arbitrary files – in particular executable PHP code – to the server and run them there, without any authentication whatsoever. In technical terms this is called "unauthenticated remote code execution" (RCE): executing code remotely without a login.

The US Cybersecurity and Infrastructure Security Agency CISA added CVE-2026-48908 to its Known Exploited Vulnerabilities Catalog (KEV) on 7 July 2026 – a list of vulnerabilities demonstrably being actively exploited. The deadline for US federal agencies to apply the patch already expired on 10 July 2026. The entry is now marked as "OVERDUE." CISA describes the flaw as follows:

"JoomShaper SP Page Builder contains an unrestricted upload of file with dangerous type vulnerability that allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code. […] This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks." – CISA

The technical background – explained in plain terms

The weak point lies in a particular endpoint of the extension, meaning an address the server processes upon request: index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon. This endpoint was originally intended for uploading custom icon packs (small symbol graphics) as a ZIP file.

The problem: the responsible part of the program performed no access check whatsoever before processing the upload, nor did it verify what type of file was being uploaded. Technically, this is a so-called CWE-434 flaw – the unrestricted upload of dangerous file types. Joomla provides its own protective functions that check uploads against a list of permitted, safe file extensions. This upload path simply did not use them.

The attack unfolds in just a few steps:

1. The attacker sends a crafted file (such as a PHP file) to the endpoint – without a login, without a security token.
2. The file lands in a directory accessible via the web.
3. The attacker simply calls up the uploaded file through the browser – and the server executes the malicious code it contains.
4. The malicious code reads out the configuration file, creates hidden administrator accounts and plants backdoors.

Particularly insidious: the automated attacks create hidden Joomla super administrator accounts – recognisable by email addresses ending in @secure.local. In addition, PHP backdoors (so-called web shells, specifically a "PHP File Manager v1.4") are placed in several directories at once, for example under /images/<random folder>/fonts/ and /media/com_admin/. The security research team at mysites.guru explains the reason for this multiple placement:

"The attacker doesn't just get a one-time code execution […]. First, they create hidden super administrator accounts. Second, they leave behind a PHP File Manager backdoor. The point of the scattered, identical copies is persistence: if you find one and delete it, the others are still there – and all of them let the attacker straight back in." – mysites.guru

Important note for anyone relying on a firewall: A Web Application Firewall (WAF) that only blocks known, other Joomla exploits does not automatically protect against this. Moreover, the dot in the task name (asset.uploadCustomIcon) can be transmitted URL-encoded as asset%2euploadCustomIcon – naive filter rules must account for both variants.

Who is affected?

All versions of the SP Page Builder from 1.0.0 up to and including 6.6.1 are affected. JoomShaper released the fix in version 6.6.2 on 20 June 2026. Version 6.7.1 followed on 27 July 2026, addressing four further critical vulnerabilities (CVE-2026-65766, CVE-2026-65877, CVE-2026-65878, CVE-2026-65879) – including an unauthenticated SQL injection with a CVSS value of 9.2.

For German SMEs, the situation is especially relevant: according to TechnologyChecker.io, Germany leads worldwide Joomla usage at around 17% (roughly 11,600 companies). And 85% of Joomla users are micro-enterprises with up to ten employees – precisely the kind of businesses that rarely have a dedicated IT security team.

The volume of attacks is enormous. At the time of the outbreak alert on 17 July 2026, FortiGuard Labs (Fortinet) recorded:

"FortiGuard Labs continues to observe the active exploitation of CVE-2026-48908 […]. At the time of publication, FortiGuard telemetry registered 1,210 blocked exploitation attempts in the last 24 hours and 15,626 attempts over the last 7 days. The highest attack volumes targeted organisations in Poland, Turkey, Australia and the USA." – FortiGuard Labs

How to check whether you are affected

1. Check the version: In the Joomla admin area under Extensions → Manage, read off the installed version of the SP Page Builder (com_sppagebuilder). Version 6.6.1 or older means: urgent action required.
2. Look for suspicious admin accounts: Under Users → Manage, bring up the super administrators. Accounts with email addresses ending in @secure.local were very likely created by this exploit and must be deleted immediately.
3. Search the file system: Look on the server for PHP files in /images/, /media/ and /tmp/ that do not belong there. Particularly suspicious: files under /media/com_sppagebuilder/assets/iconfont/, files named users.php in /media/com_admin/ or /media/regularlabs/, as well as PHP files under /images/<random folder>/fonts/. If a file contains the text "PHP File manager", it is a backdoor.
4. Analyse the server logs: Search the access logs of Apache, Nginx or LiteSpeed for POST requests containing the string task=asset.uploadCustomIcon. Entries from unknown IP addresses point to attack attempts.
5. Check the extensions: Under Extensions → Manage → Installed Extensions, watch for unknown or recently installed templates and plugins.
6. Inspect the database: In the tables #__users and #__user_usergroup_map, look for super user entries that do not originate from the legitimate administrator – particularly those with @secure.local addresses.

What you need to do now

Important first: The update only closes the entry point. Already compromised systems must additionally be cleaned up – a mere update does not remove existing backdoors and rogue admins.

1. Update immediately: Bring the SP Page Builder up to version 6.7.1 or higher (Extensions → Manage → Update or manually from joomshaper.com). This closes CVE-2026-48908 and the subsequent vulnerabilities.
2. Check for compromise: Even after the update, carry out all the checking steps listed above.
3. Delete rogue admins: Immediately remove all super administrator accounts with @secure.local addresses and all other unknown admin accounts.
4. Remove web shells: Delete all foreign PHP files found. Since multiple identical copies are typical, all of them really must be found.
5. Rotate passwords: Change all Joomla admin passwords, update the database password in configuration.php, and change FTP/SSH access credentials and the hosting panel password.
6. Block PHP execution: Disable PHP execution in /images/ and /media/ (e.g. via .htaccess with php_flag engine off or the corresponding Nginx location blocks). This renders uploaded web shells ineffective.
7. Add WAF rules: If an immediate update is not possible, set up rules for POST requests to asset.uploadCustomIcon (including the encoded variant asset%2euploadCustomIcon).
8. Terminate all sessions: In Joomla, invalidate all active sessions via Tools → Global Check-in or by clearing the #__session table.
9. Full audit: If a successful compromise is suspected, run a complete malware scan (e.g. Imunify360), restore a clean backup from before the attack window, or rebuild the site entirely.
10. Set up monitoring: Enable file integrity monitoring for the web root and check logs regularly for attack patterns.

The security research team at mysites.guru sums up the urgency:

"This is being actively exploited right now. The fix exists, and the technical details are going public – which means more scanners know exactly what to look for. The sites that get caught are the ones still running an old version. Update first […], then check whether you've already been hit." – mysites.guru

GDPR classification: what you must observe legally

A successful attack via this flaw is, as a rule, a reportable data breach under Art. 33 GDPR. Because the attacker gains full access to the server and database – including all personal data stored there, such as customer records, contact form entries, user accounts and password hashes.

Once such a breach becomes known, the controller must inform the competent data protection supervisory authority without undue delay and, where feasible, within 72 hours (Art. 33(1) GDPR). If there is a high risk to the individuals concerned, they must additionally be notified (Art. 34 GDPR). In Germany, the responsible body is the respective state data protection authority, and reporting is usually done via their online portal.

The liability risks are considerable: breaches of Art. 32 GDPR (inadequate technical security measures, such as failing to patch known vulnerabilities) can be penalised with fines of up to 10 million euros or 2% of worldwide annual turnover. Supervisory authorities have imposed fines in comparable cases where available security updates were not applied promptly. As a minimum measure, the BSI recommends remedying known vulnerabilities with an available patch within a few days. Regardless of the reporting obligation, there is also a documentation obligation (Art. 33(5) GDPR).

What the case reveals about the costs

Just how expensive such an incident can become is illustrated by the account of the affected agency AGON PARTNERS INNOVATION AG in the JoomShaper forum:

"But with current clients alone, our internal costs to fix this came to over 20,000. […] But once the damage is done, the cleanup takes longer. Changing all passwords for all services, setting up a new OWASP rule, deploying more proxy servers." – AGON PARTNERS INNOVATION AG

ChronoEngine, another Joomla extension developer, frames the scope like this:

"Unlike simple homepage defacements, this exploit grants unauthenticated attackers total control over your server backend – they can steal data, plant persistent backdoors and run malicious scripts." – ChronoEngine

Conclusion

CVE-2026-48908 is not a theoretical threat but a vulnerability that has been actively exploited for weeks, with the maximum possible severity score of 10.0. The barrier to entry for attackers is minimal – no login, no special expertise, publicly available attack tools. Automated botnets constantly scan the internet for vulnerable Joomla sites, and as recently as 2 August 2026 further attacks were observed.

If you use the SP Page Builder, there is only one sensible order of action: update first, then check whether you have already been compromised. Bring the extension to at least version 6.7.1, then work through the checking and cleanup steps rigorously – and document everything. Because a mere update is not enough: anyone who was exposed between the disclosure of the flaw and the patch could already have a backdoor on their server, patiently waiting for its next use. Act now.