Joomla Extension - icagenda.com - Remote Code Execution in iCaganda extension for Joomla < 4.0.8/3.9.15

O componente iCagenda para Joomla permite que qualquer visitante não autenticado envie um arquivo PHP através do formulário público de submissão de eventos e o execute no servidor, resultando em comprometimento total. O CVSS 4.0 de 10.0 é justificado no cenário mais grave, mas a execução do PHP só ocorre em sites rodando Joomla 6 — em Joomla 2.5, 3, 4 e 5 o core bloqueia uploads inseguros por padrão, e o impacto se reduz a criação de eventos não aprovados sem login. A falha está no catálogo KEV da CISA com exploração ativa confirmada antes mesmo da divulgação pública completa.

Existem dois defeitos combinados na mesma funcionalidade. O primeiro é upload irrestrito de arquivo (CWE-434, classificação usada pela CISA no KEV): o formulário frontend 'Submit an Event' do iCagenda tem um campo de anexo cujo processamento grava o arquivo enviado com a extensão original, sem allowlist de extensões, sem verificação de MIME type e sem inspeção de conteúdo, diretamente em images/icagenda/frontend/attachments/ sob a raiz web pública.

O segundo defeito é controle de acesso inadequado (CWE-284, classificação usada no PoC do pesquisador): o iCagenda tem uma opção que restringe quem pode submeter eventos, normalmente configurada como 'Registered' (apenas usuários logados). Essa verificação é aplicada somente na view que decide se o formulário é exibido na tela — o controller que processa de fato a submissão, acessível em index.php?option=com_icagenda&task=registration.submit, nunca checa essa permissão. Isso significa que a restrição de acesso é cosmética: qualquer requisição POST direta ao endpoint de processamento contorna a exigência de login, independentemente da configuração do site.

O atacante controla o conteúdo do arquivo e sua extensão (o valor de jform[attachment]), o único fator fora de seu controle é se a instância de Joomla subjacente permite a execução do PHP resultante — o que, segundo o advisory do fornecedor (JoomliC), só acontece no Joomla 6, já que versões anteriores do core Joomla filtram uploads potencialmente perigosos por padrão nesse caminho.

Não é necessária conta nem sessão autenticada. O atacante obtém um token de formulário CSRF de qualquer página pública do iCagenda (por exemplo, a lista de eventos) e envia uma requisição POST diretamente ao endpoint de processamento com um arquivo .php disfarçado de anexo. A opção 'Registered only' do componente não bloqueia essa requisição porque a checagem nunca chega ao controller.

Em sites rodando Joomla 6, o arquivo gravado em images/icagenda/frontend/attachments/ é executável: uma segunda requisição GET a esse caminho executa o PHP enviado, entregando execução remota de comando completa — leitura de dados, modificação de conteúdo, instalação de backdoor ou uso do servidor como pivô. Em Joomla 2.5, 3, 4 e 5, o mesmo bypass de autenticação existe, mas o core bloqueia a execução do upload malicioso; o resultado nesses casos é limitado à criação de eventos não aprovados por um visitante anônimo, um impacto bem menor que o sugerido pelo CVSS de 10.0.

Houve exploração ativa antes da divulgação pública completa: um pesquisador identificou em log de acesso de cliente um bot autoidentificado com User-Agent icagenda-batch/1.0 fazendo o upload seguido imediatamente de uma requisição ao arquivo enviado — padrão de quem já sabia exatamente onde bater. O próprio fornecedor (JoomliC) relatou ataques automatizados desde 15/06/2026, 08h UTC. A CISA incluiu a falha no catálogo KEV em 10/07/2026 com prazo de correção de apenas três dias (13/07/2026), sob a diretriz BOD 26-04 — prazo curtíssimo que reflete a gravidade e a exploração confirmada, não um risco teórico.

Atualizar para iCagenda 4.0.8 (linha 4.x, lançada em 15/06/2026) ou 3.9.15 (linha 3.x legada, lançada em 16/06/2026) é a correção. Não há detalhamento técnico disponível sobre exatamente o que a versão corrigida altera no código de validação de upload ou no controller de submissão — apenas que ambos os problemas (upload sem restrição e bypass de controle de acesso) são endereçados nessas versões.

Se a atualização imediata não for possível, a única alternativa real documentada é remover ou renomear temporariamente a pasta do componente com_icagenda no servidor, o que elimina o vetor mas derruba toda a funcionalidade de calendário/eventos do site — custo alto, mas efetivo. Um mito que precisa ser desfeito explicitamente: despublicar o componente na área administrativa do Joomla NÃO protege contra a falha, porque o endpoint de processamento (task=registration.submit) permanece acessível independentemente do estado de publicação ou de o menu de submissão estar visível.

Dependência do core do Joomla não é mitigação suficiente: mesmo que o site rode uma versão do Joomla anterior à 6 (onde o upload malicioso não é executado), o bypass de controle de acesso continua ativo e permite criação de eventos não aprovados por qualquer visitante sem login — um problema de integridade que só a atualização do componente resolve.

Procurar em logs de acesso web por requisições POST para index.php?option=com_icagenda&task=registration.submit (ou variações com task=submit) contendo um campo jform[attachment] com extensão executável (.php, .phtml, etc.), seguidas de requisições GET para caminhos sob /images/icagenda/frontend/attachments/ com o mesmo padrão de nome de arquivo — especialmente se a URL contiver parâmetros suspeitos como ?cmd=. O User-Agent icagenda-batch/1.0 foi observado em ataques reais reportados pelo fornecedor e por pesquisadores, mas é trivialmente forjável pelo atacante; tratar como indicador adicional de triagem, não como confirmação isolada de comprometimento. Na ausência desses padrões nos logs, revisar diretamente o conteúdo da pasta de anexos por arquivos com extensão executável é o método mais confiável de detecção retroativa.