CVE-2026-48908 — SP Page Builder for Joomla: Unauthenticated File Upload → RCE

CVE-2026-48908 is a maximum-severity (CVSS 4.0 = 10.0) unauthenticated arbitrary-file-upload vulnerability in the SP Page Builder extension for Joomla, one of the most widely deployed Joomla page-builders. The component's asset.uploadCustomIcon controller accepts a file with no authentication and no file-type validation, so any remote attacker can upload a PHP web shell into a web-served directory and execute it — full remote code execution as the web-server user. All versions up to and including 6.6.1 are affected; the fix is 6.6.2 (released 2026-06-14), which gates the controller behind an authenticated session, a permission check, and a CSRF token.

The flaw has been exploited in the wild as a zero-day and was added to the CISA KEV catalog on 2026-07-07 (federal remediation due 2026-07-10). Observed exploitation is automated: a bot POSTs to index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon (HTTP 200), then GETs the planted PHP file, then a brand-new Joomla Super Administrator account appears on the site. Some campaigns upload ZIP archives containing PHP web shells into /media/com_sppagebuilder/assets/iconfont/, and drop persistent PHP file-manager backdoors under /media/com_sppagebuilder/assets/.

Because initial access is a web request, the highest-value endpoint signal is the web server / PHP-FPM process spawning a shell or recon binary — the moment the web shell runs an OS command. The upload itself is best caught in web-server access logs (the uploadCustomIcon → GET-.php sequence) and by the tell-tale hidden admin whose email ends in @secure.local.

Defender priority: Inventory every Joomla site running SP Page Builder and confirm it is on 6.6.2+ today. Then hunt for (1) httpd/php-fpm spawning sh/bash/id/curl (§8 Q1), (2) new files under /media/com_sppagebuilder/assets/, and (3) any Joomla Super Admin with an @secure.local email. Treat a pre-6.6.2, internet-facing instance as presumed-compromised.

Provenance note: IOCs here are structural/behavioral (endpoint path, controller task, webshell directories, @secure.local admin email) and are well-corroborated across the vendor advisory and multiple analyses. No reliable attacker C2 IP set is published as of 2026-07-12 — this pack is detection-by-behavior, not IP blocklist.

Hunt hypotheses (ordered by fidelity)

1. H1 (high): A web-server or PHP-FPM process spawns a shell or recon/download binary (sh, bash, id, whoami, uname, curl, wget) — a PHP web shell executing OS commands post-upload.
2. H2 (med): A ZIP archive or new file is written under /media/com_sppagebuilder/assets/ (esp. iconfont/) — the web-shell delivery artifact.
3. H3 (med): The web-server process makes outbound network connections (reverse shell or second-stage fetch) to an external host.
4. H4 (med): The web-server process spawns an interactive reverse-shell one-liner (bash -i, python … pty.spawn, perl … Socket, nc -e).
5. H5 (high, native): A new Joomla Super Administrator account exists whose email ends in @secure.local, or web-access logs show task=asset.uploadCustomIcon (200) followed by a GET to a new .php under the media path.

Attack chain

• Version audit (do first): Confirm SP Page Builder is 6.6.2 or newer on every Joomla site. In the Joomla admin: Extensions → Manage → filter "Page Builder", or check administrator/components/com_sppagebuilder/sppagebuilder.xml for the <version> string.
• Web access-log signature: Search access logs for task=asset.uploadCustomIcon with a POST and 200, especially from unauthenticated sources, followed shortly by a GET to a .php under /media/com_sppagebuilder/. That POST→GET pair is the exploitation fingerprint.
• Web-shell file sweep: On the web root, list any .php under /media/com_sppagebuilder/assets/ (and iconfont/) — this tree should contain fonts/icons, never PHP. Also look for recently-modified ZIP archives there.
• Rogue admin review: In Joomla Users, flag any Super User with an email ending @secure.local or any admin account created around the exploitation window. Verify against your change record.
• Integrity: Diff the Joomla install against a known-good baseline; review configuration.php exposure and recently-changed files across the web root.

Q1 and Q4 are portable web-shell detections — they generalize beyond this CVE to any PHP-app RCE, so promoting them hardens you against the next Joomla/WordPress upload bug too.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_WEBSHELL_SHA256,prevent,critical,2027-01-12,SP Page Builder web shell,cve:CVE-2026-48908
ipv4,REPLACE_WITH_ATTACKER_IP,detect,high,2026-10-12,CVE-2026-48908 exploit source (from your logs),cve:CVE-2026-48908

# httpd/nginx/php-fpm -> shell/recon child (web-shell command exec)
# ZIP or .php written under /media/com_sppagebuilder/assets/(iconfont/)
# Reverse-shell one-liner (bash -i /dev/tcp, python pty.spawn, nc -e) under web parent
# Web parent making outbound connections to external host

# Access log: POST index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon => 200
#   then GET /media/com_sppagebuilder/assets/**/*.php
# Joomla Super Admin with email ending @secure.local
# New/modified .php or .zip under /media/com_sppagebuilder/assets/

# SP Page Builder >= 6.6.2 (fix released 2026-06-14)
# Deny PHP execution in /media and /images (web-server config)
# Web-app user cannot write into web-served code dirs
# WAF rule: block unauth POST to task=asset.uploadCustomIcon

No reliable attacker C2 IP set is published — the CSV uses REPLACE_WITH_… placeholders you fill from your own access logs after identifying the exploit source. The durable detections are behavioral (above).

• Telemetry ready: Confirm a Falcon Linux sensor is on every Joomla web host. Shared/managed hosting may not permit a sensor — fall back to web-log hunts (§7).
• Benign baseline: Run Q1 and Q3 in monitor for 3–7 days; catalog any plugin that legitimately shells out or calls external APIs before promoting to Prevent.
• Positive test: In a lab, drop a benign PHP page that runs id and request it — confirm Q1 fires. Write a test ZIP under the media path — confirm Q2 fires.
• Promotion: Q1 and Q4 are strong Prevent candidates after baseline. Q2 → Detect. Q3 stays Detect/hunt (correlate with Q1/Q4).

1 · Find vulnerable version + web shells (Linux, run per web host)

# SP Page Builder version
grep -Ri '<version>' \
  /var/www/*/administrator/components/com_sppagebuilder/sppagebuilder.xml 2>/dev/null

# Any PHP (or ZIP) under the media assets tree = suspicious
find /var/www -path '*com_sppagebuilder/assets*' \( -name '*.php' -o -name '*.zip' \) \
  -printf '%TY-%Tm-%Td %p\n' 2>/dev/null

2 · Access-log signature sweep

# POST to the vulnerable controller returning 200
grep -E 'task=asset\.uploadCustomIcon' /var/log/apache2/*access* /var/log/nginx/*access* 2>/dev/null \
  | grep -E 'POST' | grep -E ' 200 '
# Follow-on GETs to planted php under the media path
grep -E 'GET .*com_sppagebuilder/assets/.*\.php' /var/log/apache2/*access* /var/log/nginx/*access* 2>/dev/null

3 · Block PHP execution in upload dirs (Apache example)

# In the vhost / .htaccess for /media and /images:
<Directory /var/www/html/media>
  <FilesMatch "\.(php|phtml|php[0-9]|phar)$">
    Require all denied
  </FilesMatch>
</Directory>
# NGINX equivalent: location ~* /(media|images)/.*\.php$ { return 403; }

Known gaps: The initial upload (T1190) and the hidden Joomla Super Admin (T1136.001) are application-layer events not visible to endpoint process telemetry — cover them with the web-access-log and Joomla-user audits in §7. A bare .php web-shell write may not raise a file-write event; Q2 catches the ZIP-delivery variant, and §7 covers direct PHP drops. Managed/shared hosting without a Falcon sensor is the largest gap — rely on §7 there. Validation gates (§11) must pass before promoting Q1/Q4 to Prevent.