CVE-2026-48908-joomla-sp-page-builder-detection

Validates CVE-2026-48908 in Joomla SP Page Builder with unauthorized icon upload leading to PHP code execution. Includes auditd/PCAP evidence, event timeline, and SOC detection recommendations for defensive research.

Both reports contain the full test methodology, evidence excerpts, event timeline, file-change evidence, network indicators, mitigation guidance, audit recommendations, and example SIEM logic.

Repository structure

No exploit source, payload source, raw PCAP, raw Docker evidence package, or DOCX source files are included.

Test environment

The Joomla webroot /var/www/html was backed by the Docker volume joomla5-builders_joomla_data. This matters for detection: docker diff did not provide detailed visibility into file changes inside the volume, so file monitoring had to rely on volume-aware file listings and host-side monitoring guidance.

What was validated

The test was performed in an isolated and authorized laboratory environment. The validation covered the following sequence:

1. Joomla 5 was deployed in Docker with SP Page Builder installed.
2. A public project listed in References was used as the initial validation reference.
3. The SP Page Builder asset.uploadCustomIcon endpoint accepted uploaded icon archives in the laboratory environment.
4. New directories and files were created under /media/com_sppagebuilder/assets/iconfont/.
5. The uploaded content included mixed-case PHP extensions and an .htaccess file that changed PHP handling for the .PHP extension.
6. The uploaded PHP artifact was invoked over HTTP and executed controlled commands.
7. A one-time TCP callback to the Windows host confirmed outbound connectivity.
8. A controlled reverse shell test confirmed interactive command execution as the web server user.
9. Attempts to access /root and to switch user with su - failed.
10. Evidence from victim-side telemetry and Windows screenshots was correlated into a single UTC timeline.

The reports intentionally document evidence and detection logic without distributing a reusable exploit or payload implementation.

Confirmed result

The laboratory test confirmed:

• unauthorized upload through the SP Page Builder asset.uploadCustomIcon endpoint;
• creation of PHP and .htaccess artifacts under the Joomla media directory;
• server-side execution of the uploaded PHP artifact after an HTTP request;
• execution in the context of the Apache/PHP process user;
• outbound TCP connectivity from the Joomla container to the Windows host;
• an interactive reverse shell session as www-data;
• no confirmed privilege escalation to root.

Inside the container, the effective identity was:

The failed privilege-escalation attempt was visible as:

Key evidence

Public PoC validation and upload behavior

The public PoC tested several extension variants and confirmed that a combination involving a mixed-case PHP extension and .htaccess could lead to execution in the laboratory setup.

Code execution as the web server user

A controlled HTTP request executed whoami, and the browser displayed the effective process user.

One-time TCP callback

Before the interactive test, a safer single-message callback was used to confirm outbound connectivity from the target environment to the Windows host on TCP port 4444.

Reverse shell session

The interactive session confirmed execution as www-data, Linux as the operating system, and a working directory under the Joomla SP Page Builder media path.

Failed root access attempt

Attempts to access /root and authenticate with su - failed. The screenshot is redacted to avoid publishing the test password.

Reconstructed timeline

The complete timeline is available in both PDF reports. The most important events were:

Evidence collection methodology

Linux and Docker

The victim host collected:

• auditd events for execve;
• packet capture using tcpdump;
• Docker container metadata, logs, events, process listings, and filesystem differences;
• periodic file-change polling from inside the container;
• file listings for the Joomla webroot, temporary directories, and relevant media paths;
• selected container state before and after the test.

The test also identified a monitoring limitation: because /var/www/html was backed by a Docker volume, docker diff did not show detailed file creation under /var/www/html/media/com_sppagebuilder/assets/iconfont/. File integrity monitoring should therefore cover the real host path backing the volume.

Windows

The Windows host evidence was intentionally limited to report-relevant screenshots:

• public PoC output;
• browser output for whoami;
• Ncat output for the one-time callback;
• Ncat output for the reverse shell session;
• failed /root and su - attempt with the password redacted.

Most important detection opportunities

1. Upload through SP Page Builder

Monitor HTTP, reverse-proxy, WAF, or network telemetry for the following combination:

In production, do not rely only on the public PoC User-Agent. The endpoint and unexpected upload pattern are more stable indicators than the User-Agent value.

2. Executable file or .htaccess under the SP Page Builder icon path

Monitor file telemetry for new or modified files matching:

The presence of .htaccess containing AddType application/x-httpd-php .PHP in a media upload directory is a high-value indicator.

3. GET request to an uploaded PHP file with command parameters

Correlate upload activity with subsequent HTTP requests to paths like:

Higher confidence is reached when the request targets a PHP-like extension and includes parameters such as t= and c=.

4. Shell or interpreter activity from the web service account

High-value process indicators include:

5. Outbound connection from the web container

Alert when a shell or interpreter launched by the web server process initiates an outbound connection to a workstation or unusual destination port. The laboratory event used TCP port 4444, but production detection should not depend on a single port.

6. Failed privilege-escalation attempts after web execution

The test produced a failed su - attempt. Monitor for authentication helpers such as unix_chkpwd, writes to /var/log/btmp, and interactive commands following web-service account compromise.

SOC triage guidance

When the HTTP upload indicator is detected, the SOC should immediately correlate it with:

• the source IP, user agent, and HTTP status;
• whether the target Joomla instance has SP Page Builder installed and whether the version is vulnerable;
• new directories under /media/com_sppagebuilder/assets/iconfont/;
• new PHP-like files or .htaccess files under Joomla media directories;
• HTTP GET requests to the newly created files shortly after upload;
• command-like query parameters such as t= and c=;
• process creation by the web server user, especially shell or interpreter processes;
• outbound connections from the web container or web service account;
• discovery commands such as whoami, id, uname, hostname, pwd, ip, ifconfig, netstat, or ss;
• authentication failures, credential access attempts, persistence, or lateral movement after initial execution.

A single upload event is not always sufficient on its own. The strongest alert combines upload, file creation, file access, process execution, and outbound network telemetry within the same short time window.

Recommended mitigations

1. Update SP Page Builder to version 6.6.2 or newer.
2. Review /media/com_sppagebuilder/assets/iconfont/ and the broader Joomla media directory for PHP-like files and .htaccess artifacts.
3. Remove any unexpected PHP, .htaccess, .phtml, .phar, archive, or executable artifacts from upload directories.
4. Disable PHP execution in upload and media directories at the Apache, Nginx, and PHP-FPM layer.
5. Restrict or alert on access to the asset.uploadCustomIcon endpoint from untrusted networks.
6. Monitor web service child processes and outbound connections from web containers.
7. Deploy FIM, eBPF, auditd, or EDR coverage for Docker volumes that contain the application webroot.
8. Do not rely on docker diff alone for webroot monitoring when application data is stored in Docker volumes or bind mounts.

Scope and limitations

• The validation was performed against one Joomla 5 Docker instance with SP Page Builder installed.
• The observed impact was code execution as the web server process user www-data; privilege escalation to root was not confirmed.
• The result confirms the tested path and configuration. It does not prove that every deployment, reverse proxy, web server, PHP handler, or operating system behaves identically.
• Offensive exploit code, payload source, raw PCAP files, raw Docker evidence packages, and DOCX source files are not distributed in this repository.
• The reports contain selected evidence excerpts rather than full raw logs, to keep the material readable and focused on detection.

References

• NVD - CVE-2026-48908
• CVE.org - CVE-2026-48908
• CISA Known Exploited Vulnerabilities Catalog
• Public project used as the initial validation reference
• JoomShaper SP Page Builder

Responsible-use notice

This material is provided for defensive security research, vulnerability management, detection engineering, incident-response preparation, and authorized testing. Do not use it against systems without explicit permission.