Engine Templates

A critical zero‑day vulnerability has been identified in SP Page Builder (com_sppagebuilder) affecting Joomla installations. The vendor has released an emergency patch in version 6.6.2.
If you are running any 6.x version up to and including 6.6.1, you are vulnerable.

From a security standpoint, this issue enables unauthenticated Remote Code Execution (RCE) via arbitrary file upload. Exploitation is active.

Executive Summary

• Impact: Full site compromise
• Attack vector: Unauthenticated arbitrary PHP file upload
• Affected versions: SP Page Builder 6.x ≤ 6.6.1
• Fixed in: 6.6.2
• Risk level: Critical

At EngineTemplates, we strongly advise immediate remediation and post‑patch compromise assessment.

Root Cause Analysis

The vulnerability resides in an internal task handler:

asset.uploadCustomIcon

Security Failures Identified

• Missing authentication enforcement
• Insufficient authorization checks
• No proper CSRF validation
• Inadequate file type restrictions
• Upload destination is web-accessible

Result

An attacker can:

1. Submit a crafted request without authentication
2. Upload a malicious .php payload
3. Execute the payload via direct HTTP access

This leads to full server-side code execution under the web process user.

Why Disabling the Extension Is Not Mitigation

Disabling SP Page Builder does not eliminate exposure.
The vulnerable endpoint remains reachable at the application level.

Only upgrading to 6.6.2 removes the attack surface.

What Changed in 6.6.2

The patched version implements:

• Mandatory authenticated session validation
• Proper authorization enforcement
• Required CSRF token validation
• Rejection of anonymous task execution

The upload handler is now appropriately gated.

Post‑Patch Risk: Persistence Mechanisms

If exploitation occurred prior to patching, the attacker likely established persistence.

Updating alone is insufficient if compromise has already happened.

1) Rogue Super User Accounts

Observed indicators include:

• Accounts named “Web Editor” or “Admin Backup”
• Email suffix:
  @secure.local
  

This domain is not legitimate for Joomla user accounts.
Presence of such users = confirmed compromise.

2) PHP Backdoor Deployment

Attackers deploy file‑manager‑style backdoors (with PHP/SQL execution capability) in multiple locations.

Common paths:

• images/.../fonts/
• media/com_admin/
• media/regularlabs/

Common filename pattern:

• users.php

Content indicator:

PHP File manager

Multiple copies are typically deployed to ensure redundancy.

Immediate Remediation Plan

Step 1 — Upgrade to 6.6.2

Option A: Joomla Update Manager

• System → Updates → Check for Updates
• Update SP Page Builder

Option B: Manual Install

• Download 6.6.2 from the vendor
• Install via Extensions → Manage → Install

If files were renamed or partially removed as a temporary measure, perform a clean reinstall of 6.6.2.
Do not restore legacy files.

Step 2 — Compromise Assessment

A) Audit Joomla Users

• Review all Super Users
• Remove any unknown accounts
• Specifically check for @secure.local emails

B) Search Filesystem for Backdoors

Search for:

• Unexpected .php files under /images/
• users.php in /media/com_admin/
• users.php in /media/regularlabs/

If one backdoor is found, continue scanning. Assume multiple implants.

C) Log Correlation Warning

Joomla timestamps use the timezone defined in configuration.php.
Server logs frequently use UTC.

Convert timezones before correlating events to avoid false negatives.

If Compromise Is Confirmed

Treat the environment as fully breached.

Required actions:

1. Delete all unauthorized admin users
2. Remove every backdoor file copy
3. Rotate credentials:
   • Joomla admin passwords
   • Database credentials
   • FTP/SSH keys
4. Invalidate active sessions
5. Conduct full integrity review

Do not assume containment after removing a single malicious file.

Temporary Containment (If Immediate Upgrade Is Impossible)

As an interim measure:

• Block requests containing asset.uploadCustomIcon
• Block encoded traversal patterns (e.g., %2e)

This is not a fix. It reduces exposure window only.

Hardening Recommendations

To reduce impact of future upload vulnerabilities:

• Disable PHP execution in /images/ and /media/
• Implement WAF rules targeting suspicious task parameters
• Deploy file integrity monitoring
• Restrict write permissions where possible

Layered defense reduces blast radius but does not replace patching.

Recommended Action Order

1. Upgrade SP Page Builder to 6.6.2 immediately
2. Perform compromise audit (users + filesystem)
3. Remove persistence mechanisms
4. Rotate all credentials
5. Apply server-level hardening

At EngineTemplates, we recommend treating this as a priority incident if you operate Joomla in production. Rapid patching plus forensic verification is essential to ensure complete remediation.

If your infrastructure team requires assistance evaluating exposure or implementing hardening controls, act without delay.