CVE-2026-48908: SP Page Builder for Joomla allows unauthenticated arbitrary file upload via asset.uploadCustomIcon, enabling PHP upload and remote code execution.

SP Page Builder for Joomla (com_sppagebuilder) exposes the controller task index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon to upload a custom icon-font package. In versions 1.0.0 – 6.6.1 the task is reachable without authentication, authorization, or a valid anti-CSRF token. The uploaded ZIP archive is extracted and copied into the web root under /media/com_sppagebuilder/assets/iconfont/<name>/, including its fonts/ subdirectory. Because the archive entries are not validated against an extension allow-list, an attacker can package a web shell and a .htaccess file that registers an uppercase .PHP extension with the PHP handler, then execute the shell over HTTP. This yields unauthenticated remote code execution as the web-server user.

• Package / component: SP Page Builder (com_sppagebuilder) by JoomShaper — site/controllers/asset.php (SppagebuilderControllerAsset::uploadCustomIcon).
• Affected versions: 1.0.0 – 6.6.1.
• Patched version: 6.6.2.
• Risk level: Critical (CWE-284 → CWE-434 Unrestricted Upload of File with Dangerous Type; advisory CVSS 4.0 10.0). Any unauthenticated remote attacker can upload and execute attacker-controlled PHP code on the Joomla host.

Impact Parity

• Disclosed / claimed maximum impact: Unauthenticated arbitrary file upload leading to remote code execution.
• Reproduced impact from this run: Full parity.
  1. Unauthenticated upload: The PoC sent a multipart custom_icon ZIP to the asset.uploadCustomIcon task with no Joomla session cookie and no CSRF token; the server accepted it and extracted the contents under the web root.
  2. Code execution: The uploaded .htaccess plus uppercase .PHP shell executed the PoC’s echo 7*6 marker (SPPB-RCE-42) and then id, returning uid=33(www-data) gid=33(www-data) groups=33(www-data).
  3. Negative control: The same PoC against the fixed 6.6.2 install received HTTP 403 with the message You require admin access, confirming the patch closes the path.
• Parity: full.
• Not demonstrated: Further post-exploitation (e.g., privilege escalation beyond www-data) is not part of the CVE claim.

Root Cause

In the vulnerable build the SppagebuilderControllerAsset class (in site/controllers/asset.php) has no authentication, authorization, or CSRF logic in its constructor or in the uploadCustomIcon() method. The method reads the uploaded custom_icon file, validates only basic size/length limits, writes it to a temporary ZIP, and calls the local unpack() method:

$zip_file = $tmp_path . '/builderCustomIcon.zip';
...
if (File::upload($tmp_src, $zip_file, false, true))
{
    $extract = $this->unpack($zip_file);
    ...
    Folder::copy($extract_path . '/' . $font_path, $rootPath . '/' . $fontFamily . '/fonts');
    File::copy($extract_path . '/' . $font_css, $rootPath . '/' . $fontFamily . '/' . $font_css);
    ...
}

unpack() uses Joomla\Archive\Archive::extract() to unpack the ZIP into a subdirectory of the Joomla tmp_path. The controller then copies the entire fonts/ (and CSS) contents into the public web-root directory JPATH_ROOT/media/com_sppagebuilder/assets/iconfont/<fontFamily>/. No extension allow-list is enforced on the archive entries before copying, so the attacker can include arbitrary files such as .htaccess and .PHP.

The server-side extension filter that does exist is a case-sensitive block-list (rejects lowercase .php, .php3–.php8, .pht, .phtml, .phar, etc.), but the block-list misses uppercase .PHP and .htaccess. A default Apache PHP handler (<FilesMatch "\.php$">) does not execute uppercase .PHP, so the PoC also drops a fonts/.htaccess containing:

AddType application/x-httpd-php .PHP

Where AllowOverride is permitted, this reconfigures the directory to treat .PHP as PHP. The same HTTP request that uploaded the shell can then fetch it from the web-accessible iconfont directory and execute it.

The 6.6.2 fix adds a constructor to SppagebuilderControllerAsset that blocks unauthenticated/unauthorized requests before any method runs:

public function __construct($config = [])
{
    parent::__construct($config);
    $user = Factory::getUser();
    $authorised = $user->authorise('core.admin', 'com_sppagebuilder')
                   || $user->authorise('core.manage', 'com_sppagebuilder');
    if (!$authorised)
    {
        ...
        $this->sendResponse($response, 403, true);
    }
    if (!$user->id)
    {
        ...
        $this->sendResponse($response, 401, true);
    }
    if (!Session::checkToken())
    {
        ...
        $this->sendResponse($response, 403, true);
    }
}

This requires the user to be logged in, to have admin/manage privileges for the component, and to present a valid Joomla CSRF token, making the upload task unreachable from an unauthenticated attacker.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained; exits 0 on confirmation, non-zero on failure).
2. What it does:
   • Reads the durable project cache if one is configured, otherwise creates bundle/artifacts/sppb.
   • Clones the public PoC https://github.com/papageo75/CVE-2026-48908-PoC.git once and reuses it across runs.
   • For each role (vuln and fixed):
     • Builds a Docker Compose stack with joomla:5.2-php8.2-apache and mysql:8.0, downloads the SP Page Builder ZIP (6.6.1 for the vulnerable role, 6.6.2 for the fixed role), and installs it through Joomla’s web installer using the real administrator workflow.
     • Waits for the Joomla health check to return HTTP 200.
     • Runs the PoC against the running container from the same Docker network (http://joomla), using the real asset.uploadCustomIcon HTTP endpoint.
   • Writes bundle/repro/runtime_manifest.json and per-role evidence logs under bundle/logs/.
3. Expected evidence of reproduction:
   • Vulnerable (6.6.1): PoC prints CODE EXECUTION CONFIRMED via '.htaccess+.PHP' and the output of id (uid=33(www-data)).
   • Fixed (6.6.2): PoC prints TARGET NOT VULNERABLE — SP Page Builder is patched and the first upload attempt returns 403 'require admin' = patched.

Evidence

Log file locations (written by reproduction_steps.sh):

• bundle/logs/vuln_compose.log — Docker stack creation for the vulnerable run.
• bundle/logs/vuln_poc.log — PoC transcript showing RCE on 6.6.1.
• bundle/logs/fixed_compose.log — Docker stack creation for the fixed run.
• bundle/logs/fixed_poc.log — PoC transcript showing 6.6.2 rejects the upload.
• bundle/logs/reproduction_steps.log — full transcript of the latest run.
• bundle/repro/runtime_manifest.json — structured runtime evidence.

Key excerpts (from the latest verification run):

Vulnerable 6.6.1 — code execution confirmed:

[*] try .htaccess+.PHP  -> EXECUTED
[+] CODE EXECUTION CONFIRMED via '.htaccess+.PHP' (echo 7*6 -> 42)
[+] webshell : http://joomla/media/com_sppagebuilder/assets/iconfont/.../fonts/....PHP?t=...&c=<cmd>
[*] running: id
------------------------------------------------------------
uid=33(www-data) gid=33(www-data) groups=33(www-data)
------------------------------------------------------------

Fixed 6.6.2 — upload now requires admin authentication:

[*] try .php            -> 403 'require admin' = patched
[-] TARGET NOT VULNERABLE — SP Page Builder is patched (6.6.2+); the upload task now requires authenticated admin access.

Environment: Joomla 5.2 with PHP 8.2 (Apache), MySQL 8.0, SP Page Builder 6.6.1 (vulnerable) and 6.6.2 (fixed), running in Docker on a single custom network. The PoC is executed from an ephemeral python:3-slim container on the same network, with no session state or credentials.

Recommendations / Next Steps

• Upgrade to SP Page Builder 6.6.2 or later. The 6.6.2 patch adds the constructor checks described above, which are the primary fix.
• Defence in depth on the web server:
  • Disable PHP execution in directories that are only expected to host static assets (/media/, /images/, /templates/*/css, etc.).
  • Set AllowOverride None on these directories so an uploaded .htaccess cannot re-register handlers.
  • Use a case-insensitive extension allow-list (e.g., only .ttf, .woff, .css, .json) on uploaded archive contents; never rely on a block-list of dangerous extensions.
• Assume-breach review: search for unexpected .php/.PHP, .htaccess, and newly created directories under /media/com_sppagebuilder/assets/iconfont/, and look for new Super User accounts or planted web shells.
• Backport: if a site cannot upgrade immediately, apply the 6.6.2 constructor guard (authorization + user session + Session::checkToken()) to site/controllers/asset.php.

Additional Notes

• Idempotency: The reproduction script was run twice consecutively; both runs exited 0 with the same positive RCE evidence on the vulnerable build and the same 403 rejection on the fixed build.
• Limitations: The full RCE chain depends on the Apache configuration permitting AllowOverride in the iconfont directory and on PHP being enabled there. If AllowOverride is disabled or the case-sensitive .PHP handler is blocked, the bug still permits unauthenticated file write but not direct RCE; this is still an unauthenticated arbitrary file upload vulnerability.
• References:
  • NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-48908
  • Technical write-up — https://mysites.guru/blog/sp-page-builder-zero-day-uploadcustomicon-rce/
  • PoC repository — https://github.com/papageo75/CVE-2026-48908-PoC
  • Vendor — https://www.joomshaper.com/page-builder