CVE-2026-48908 — Joomla SP Page Builder Validação e Detecção

Validação laboratorial da CVE-2026-48908 no componente Joomla SP Page Builder, focada em evidências técnicas, reconstrução de eventos e oportunidades de detecção defensiva.

O repositório documenta um teste controlado no qual o endpoint asset.uploadCustomIcon do SP Page Builder aceitou arquivos de ícones carregados que resultaram na escrita de artefatos PHP sob o diretório de mídia do Joomla. A invocação do arquivo PHP carregado via HTTP levou à execução de comandos como o usuário do processo do servidor web. A atividade resultante de HTTP, arquivos, processos, autenticação e rede foi capturada usando logs do contêiner Apache, auditd do Linux, tcpdump, telemetria do Docker, monitoramento de alterações de arquivos e capturas de tela do host Windows.

[!IMPORTANT] Este repositório contém apenas relatórios e capturas de tela. Código de exploit ofensivo, fonte de payload, arquivos PCAP brutos e pacotes de evidência do host bruto não são intencionalmente incluídos. O material destina-se à validação de vulnerabilidades, engenharia de SOC, desenvolvimento de detecção, preparação para resposta a incidentes e pesquisa autorizada.

Relatórios

• Relatório de validação em inglês
• Relatório de validação em polonês

Ambos os relatórios contêm a metodologia completa do teste, excertos de evidências, linha do tempo de eventos, evidência de alterações em arquivos, indicadores de rede, orientações de mitigação, recomendações de auditoria e exemplo de lógica SIEM.

Estrutura do repositório

.
├── README.md
├── SHA256SUMS.txt
├── reports/
│   ├── CVE-2026-48908_SP_Page_Builder_detection_EN.pdf
│   └── CVE-2026-48908_SP_Page_Builder_detection_PL.pdf
└── screenshots/
    ├── 01_poc_upload_and_code_execution.png
    ├── 02_http_whoami_www_data.png
    ├── 03_tcp_callback_ncat.png
    ├── 04_reverse_shell_session.png
    └── 05_root_access_and_su_failure_redacted.png

Nenhuma fonte de exploit, fonte de payload, PCAP bruto, pacote de evidência Docker bruto ou arquivos fonte DOCX estão incluídos.

Ambiente de teste

A raiz web do Joomla /var/www/html era suportada pelo volume Docker joomla5-builders_joomla_data. Isto é importante para a detecção: docker diff não forneceu visibilidade detalhada das alterações de arquivos dentro do volume, por isso o monitoramento de arquivos teve que depender de listagens de arquivos com consciência de volume e orientação de monitoramento do lado do host.

O que foi validado

O teste foi realizado em um ambiente laboratorial isolado e autorizado. A validação cobriu a seguinte sequência:

1. O Joomla 5 foi implantado no Docker com o SP Page Builder instalado.
2. Um projeto público listado nas Referências foi usado como referência inicial de validação.
3. O endpoint asset.uploadCustomIcon do SP Page Builder aceitou arquivos de ícones carregados no ambiente laboratorial.
4. Novos diretórios e arquivos foram criados sob /media/com_sppagebuilder/assets/iconfont/.
5. O conteúdo carregado incluía extensões PHP com maiúsculas/minúsculas misturadas e um arquivo .htaccess que alterava o tratamento do PHP para a extensão .PHP.
6. O artefato PHP carregado foi invocado via HTTP e executou comandos controlados.
7. Um callback TCP único para o host Windows confirmou conectividade de saída.
8. Um teste controlado de reverse shell confirmou a execução interativa de comandos como o usuário do servidor web.
9. Tentativas de acessar /root e de trocar de usuário com su - falharam.
10. Evidências de telemetria do lado da vítima e capturas de tela do Windows foram correlacionadas em uma única linha do tempo UTC.

Os relatórios intencionalmente documentam evidências e lógica de detecção sem distribuir um exploit reutilizável ou implementação de payload.

Resultado confirmado

O teste laboratorial confirmou:

• upload não autorizado através do endpoint asset.uploadCustomIcon do SP Page Builder;
• criação de artefatos PHP e .htaccess sob o diretório de mídia do Joomla;
• execução do lado do servidor do artefato PHP carregado após uma requisição HTTP;
• execução no contexto do usuário do processo Apache/PHP;
• conectividade TCP de saída do contêiner Joomla para o host Windows;
• uma sessão interativa de reverse shell como www-data;
• nenhuma escalada de privilégio confirmada para root.

Dentro do contêiner, a identidade efetiva era:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

A tentativa falha de escalada de privilégio era visível como:

cd root
bash: cd: root: Permission denied
su -
Password:
su: Authentication failure

Evidências principais

Validação do PoC público e comportamento de upload

O PoC público testou várias variantes de extensão e confirmou que uma combinação envolvendo uma extensão PHP com maiúsculas/minúsculas misturadas e .htaccess poderia levar à execução na configuração laboratorial.

Execução de código como o usuário do servidor web

Uma requisição HTTP controlada executou whoami, e o navegador exibiu o usuário do processo efetivo.

Callback TCP único

Antes do teste interativo, um callback de mensagem única mais seguro foi usado para confirmar conectividade de saída do ambiente alvo para o host Windows na porta TCP 4444.

Sessão reverse shell

A sessão interativa confirmou execução como www-data, Linux como sistema operacional e um diretório de trabalho sob o caminho de mídia do Joomla SP Page Builder.

Tentativa falha de acesso root

Tentativas de acessar /root e autenticar com su - falharam. A captura de tela foi editada para não publicar a senha do teste.

Linha do tempo reconstruída

A linha do tempo completa está disponível em ambos os relatórios PDF. Os eventos mais importantes foram:

Metodologia de coleta de evidências

Linux e Docker

O host vítima coletou:

• eventos auditd para execve;
• captura de pacotes usando tcpdump;
• metadados, logs, eventos, listagens de processos e diferenças no sistema de arquivos do contêiner Docker;
• monitoramento periódico de alterações de arquivos a partir de dentro do contêiner;
• listagens de arquivos para a raiz web do Joomla, diretórios temporários e caminhos de mídia relevantes;
• estado selecionado do contêiner antes e depois do teste.

O teste também identificou uma limitação de monitoramento: como /var/www/html era suportado por um volume Docker, docker diff não mostrou criação detalhada de arquivos sob /var/www/html/media/com_sppagebuilder/assets/iconfont/. O monitoramento de integridade de arquivos deve, portanto, cobrir o caminho real do host que suporta o volume.

Windows

As evidências do host Windows foram intencionalmente limitadas a capturas de tela relevantes para o relatório:

• saída do PoC público;
• saída do navegador para whoami;
• saída do Ncat para o callback único;
• saída do Ncat para a sessão reverse shell;
• tentativa falha de /root e su - com a senha editada.

Oportunidades de deteção mais importantes

1. Upload através do SP Page Builder

Monitore telemetria HTTP, proxy reverso, WAF ou de rede para a seguinte combinação:

POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon
User-Agent contains: sppb-rce-poc
Status: 200, 201, or 204

Em produção, não confie apenas no User-Agent do PoC público. O endpoint e o padrão de upload inesperado são indicadores mais estáveis do que o valor do User-Agent.

2. Arquivo executável ou .htaccess sob o caminho de ícones do SP Page Builder

Monitore telemetria de arquivos para novos ou modificados correspondentes a:

/media/com_sppagebuilder/assets/iconfont/*/fonts/*.php
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.PHP
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.pHp
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.Php
/media/com_sppagebuilder/assets/iconfont/*/fonts/.htaccess

A presença de .htaccess contendo AddType application/x-httpd-php .PHP em um diretório de upload de mídia é um indicador de alto valor.

3. Requisição GET para um arquivo PHP carregado com parâmetros de comando

Correlacione a atividade de upload com requisições HTTP subsequentes para caminhos como:

/media/com_sppagebuilder/assets/iconfont/*/fonts/*

Maior confiança é alcançada quando a requisição tem como alvo uma extensão similar a PHP e inclui parâmetros como t= e c=.

4. Atividade de shell ou interpretador a partir da conta do serviço web

Indicadores de processo de alto valor incluem:

user: www-data, apache, or nginx
process: bash, sh, dash, or php
command line contains: /dev/tcp, bash -i, redirection operators, or unusual interpreter execution

5. Conexão de saída do contêiner web

Alerte quando um shell ou interpretador iniciado pelo processo do servidor web iniciar uma conexão de saída para uma estação de trabalho ou porta de destino incomum. O evento laboratorial usou a porta TCP 4444, mas a detecção em produção não deve depender de uma única porta.

6. Tentativas falhas de escalada de privilégio após execução web

O teste produziu uma tentativa falha de su -. Monitore por auxiliares de autenticação como unix_chkpwd, gravações em /var/log/btmp e comandos interativos após comprometimento da conta do serviço web.

Orientação de triagem SOC

Quando o indicador de upload HTTP for detectado, o SOC deve imediatamente correlacioná-lo com:

• o IP de origem, agente de usuário e status HTTP;
• se a instância Joomla alvo tem o SP Page Builder instalado e se a versão é vulnerável;
• novos diretórios sob /media/com_sppagebuilder/assets/iconfont/;
• novos arquivos similares a PHP ou arquivos .htaccess sob diretórios de mídia do Joomla;
• requisições HTTP GET para os arquivos recém-criados logo após o upload;
• parâmetros de consulta semelhantes a comandos, como t= e c=;
• criação de processos pelo usuário do servidor web, especialmente processos de shell ou interpretador;
• conexões de saída do contêiner web ou da conta do serviço web;
• comandos de descoberta como whoami, id, uname, hostname, pwd, ip, ifconfig, netstat ou ;

Um único evento de upload nem sempre é suficiente por si só. O alerta mais forte combina upload, criação de arquivo, acesso a arquivo, execução de processo e telemetria de rede de saída dentro da mesma janela de tempo curta.

Mitigações recomendadas

1. Atualize o SP Page Builder para a versão 6.6.2 ou superior.
2. Revise /media/com_sppagebuilder/assets/iconfont/ e o diretório de mídia mais amplo do Joomla em busca de arquivos similares a PHP e artefatos .htaccess.
3. Remova quaisquer artefatos PHP, .htaccess, .phtml, .phar, arquivos ou executáveis inesperados de diretórios de upload.
4. Desabilite a execução de PHP em diretórios de upload e mídia na camada Apache, Nginx e PHP-FPM.
5. Restrinja ou alerte sobre acesso ao endpoint asset.uploadCustomIcon a partir de redes não confiáveis.
6. Monitore processos filhos do serviço web e conexões de saída de contêineres web.
7. Implante FIM, eBPF, auditd ou cobertura EDR para volumes Docker que contêm a raiz web da aplicação.
8. Não confie apenas em docker diff para monitoramento da raiz web quando os dados da aplicação estiverem armazenados em volumes Docker ou bind mounts.

Escopo e limitações

• A validação foi realizada contra uma instância Docker do Joomla 5 com SP Page Builder instalado.
• O impacto observado foi execução de código como o usuário do processo do servidor web www-data; escalada de privilégio para root não foi confirmada.
• O resultado confirma o caminho e a configuração testados. Não prova que toda implantação, proxy reverso, servidor web, manipulador PHP ou sistema operacional se comporte de forma idêntica.
• Código de exploit ofensivo, fonte de payload, arquivos PCAP brutos, pacotes de evidência Docker brutos e arquivos fonte DOCX não são distribuídos neste repositório.
• Os relatórios contêm excertos selecionados de evidências em vez de logs brutos completos, para manter o material legível e focado na detecção.

Referências

• NVD - CVE-2026-48908
• CVE.org - CVE-2026-48908
• Catálogo de Vulnerabilidades Exploradas Conhecidas da CISA
• Projeto público usado como referência inicial de validação
• JoomShaper SP Page Builder

Aviso de uso responsável

Este material é fornecido para pesquisa de segurança defensiva, gestão de vulnerabilidades, engenharia de detecção, preparação para resposta a incidentes e testes autorizados. Não o utilize contra sistemas sem permissão explícita.