Threat feed
CVE-2026-48908 — Unauthenticated upload to RCE in SP Page Builder (Joomla): explainer & fixes
CVE-2026-48908 is an unauthenticated arbitrary file upload → RCE in Joomla's SP Page Builder (JoomShaper), versions 6.6.1 and earlier. CVSS 10.0 and actively exploited (listed in CISA KEV). What happens, what's affected, and the real fix (update to 6.6.2) plus compromise checks — defensively, with no attack how-to.
A defensive advisory for a vulnerability with confirmed in-the-wild exploitation (listed in CISA KEV). What happens, what's affected, and how to respond — with no attack how-to or proof-of-concept. For the durable design-level defense, see file upload vulnerabilities and how to defend.
- CVE
- CVE-2026-48908
- Severity
- Critical (CVSS 10.0 / v4.0) — actively exploited (CISA KEV)
- Type
- Unauthenticated arbitrary file upload → RCE (CWE-434)
- Impact
- Remote code execution (RCE) with no authentication
- Affected
- SP Page Builder for Joomla (JoomShaper) — 6.6.1 and earlier
- Real fix
- Update to 6.6.2 or later
Why not-patching is dangerous
Because RCE is reachable without authentication, it's a prime target for blind scanning (which is why it made the KEV list). Censys measured well over a hundred thousand internet-facing properties running SP Page Builder, and affected versions were hit en masse. "We're too small to be targeted" does not hold.
What's affected
| Item | Detail |
|---|---|
| Extension | SP Page Builder for Joomla (JoomShaper) |
| Affected versions | 6.6.1 and earlier |
| Fixed version | 6.6.2 and later |
| Precondition | No authentication required |
| Reachable impact | Remote code execution (RCE); data theft |
A note on patch completeness (both sides, unresolved)
6.6.2 is reported to close the actively-exploited path (the custom-icon upload). Separately, a community report claimed a secondary path (part of the admin-side handling) still lacked an authentication check in 6.6.2; in response the vendor (JoomShaper) is reported to have disputed it — saying the editor-side controller enforces authentication first — while indicating a fix in a following update. As this is not settled, update to 6.6.2, keep defense-in-depth in place, and watch for the next release (6.6.x).
How to respond
Update to 6.6.2+ (top priority, the real fix)
Check for compromise (assume you were reached before updating)
Buy time until you can update (defense-in-depth)
Inventory extensions + machine-monitor CVEs
This site's take: kill the pattern, not just the CVE
This incident is one instance of a common pattern — "unauthenticated upload → RCE" (a sibling Joomla extension, CVE-2026-56290, was exploited the same way in the same period). The single update is mandatory, but what pays off long-term is designing the pattern out: authenticate the upload endpoint, allow-list plus content-inspect server-side, and store outside the web root or disable execution. See file upload vulnerabilities and how to defend.
Read next
- Defense (durable): file upload vulnerabilities — designing out web shells / RCE
- Glossary: what RCE (remote code execution) is / what a CVE is
- All alerts: vulnerability alerts
FAQ
QWhat does CVE-2026-48908 let an attacker do?
An unauthenticated attacker can upload an arbitrary file (e.g. PHP) to a Joomla site running the affected extension, and have it executed — reaching remote code execution (RCE). That leads directly to defacement, data theft, secretly minted admin accounts, and pivoting to other systems. It is a worst-case flaw: CVSS 10.0, and exploitation has been confirmed (listed in CISA KEV).
QWhat's the surest fix?
Update the SP Page Builder extension to 6.6.2 or later. 6.6.2 reportedly gates the affected upload behind an authentication/permission check plus a CSRF token. Until you can update, reduce exposure in layers: restrict access to the feature, disable script execution in the upload area, and use a WAF.
QIf I update, am I safe from compromise?
Updating stops future intrusion, but whether you were reached before updating is a separate question. The attacks are reported to be persistence-first — planting web shells and rogue admin accounts (e.g. admins with a non-existent email domain) that survive the patch. After updating, always run a compromise check (unexpected admins, stray PHP files, odd outbound traffic).