Craft CMS Allows Remote Code Execution

Falha de execução remota de código pré-autenticação no controller de assets do Craft CMS, explorável via requisição HTTP não autenticada contra a rota de geração de transformação de imagens. É uma correção adicional para a CVE-2023-41892: o patch original validou o parâmetro assetId mas deixou o parâmetro handle sem validação de tipo, permitindo reabrir a mesma classe de bug. Está no catálogo KEV da CISA com exploração confirmada em campanha real, tem CVSS 10.0, EPSS próximo de 1.0, módulo Metasploit e template Nuclei públicos — é praticamente exploração garantida em qualquer instância não corrigida e exposta.

O ponto vulnerável é o método actionGenerateTransform() em src/controllers/AssetsController.php. Esse endpoint recebe os parâmetros de corpo assetId e handle para gerar uma transformação de imagem sob demanda. Antes da correção, o código pegava getRequiredBodyParam('handle') e usava o valor diretamente, sem checar se era uma string — um atacante podia enviar handle como array (por exemplo, handle[]=x) em vez de string.

Essa falta de validação de tipo (CWE-20, com efeito de CWE-843 type confusion) é a mesma classe de problema explorada na CVE-2023-41892 original, onde o parâmetro assetId aceitava um tipo inesperado e alimentava uma cadeia de deserialização/instanciação de objeto PHP (na linha de CWE-502) que o Craft/Yii2 processava internamente na geração da transformação, eventualmente permitindo que o atacante forçasse a execução de código no servidor. O fornecedor tratou o assetId na correção de 2023, mas o vetor equivalente via handle continuou aberto até esta CVE — por isso a descrição oficial chama isso de 'fix adicional' para a falha antiga, não uma vulnerabilidade nova e independente.

O commit de correção (e1c8544) é minimalista: adiciona um `if (!is_string($handle)) { throw new BadRequestHttpException(...) }` antes de qualquer uso do parâmetro. O tamanho da correção confirma que o problema real é ausência de validação de entrada num ponto que alimenta uma cadeia de gadget já conhecida do ecossistema Yii2/Craft, não uma lógica de negócio nova.

O vetor é uma requisição HTTP não autenticada (PR:N, UI:N no vetor CVSS) contra a action de geração de transformação de assets, que em muitas instalações Craft é acessível publicamente porque o front-end usa esse endpoint para gerar variações de imagem sob demanda. O atacante precisa apenas conseguir alcançar a rota via rede (AV:N) e enviar um assetId válido — em instalações típicas, IDs de asset são sequenciais e fáceis de enumerar ou descobrir via HTML público — junto com um handle malformado (array em vez de string) para acionar o caminho de código vulnerável.

A complexidade de ataque é baixa (AC:L): não exige condição de corrida, timing ou conhecimento de segredos internos, só a capacidade de montar a requisição corretamente. O resultado documentado por pesquisadores e pela exploração ativa observada é execução de código arbitrário no servidor, tipicamente usada para gravar um webshell acessível via HTTP, dando ao atacante controle total do processo PHP e, por consequência, do host.

Há exploração confirmada em campanha real (motivo da entrada no catálogo KEV da CISA), com PoC pública, módulo Metasploit e template Nuclei disponíveis — isso baixa a barreira para qualquer scanner automatizado de internet incluir a checagem. Instâncias expostas sem patch devem ser tratadas como já comprometidas ou sob varredura ativa, não apenas 'vulneráveis'.

Atualizar é a única mitigação com respaldo do fornecedor: 3.9.15 para o ramo 3.x, 4.14.15 para o ramo 4.x, 5.6.17 para o ramo 5.x. Instâncias que aplicaram apenas o patch da CVE-2023-41892 (dezembro de 2024, versões 3.9.14/4.x/5.x correspondentes) permanecem vulneráveis a este bypass — é preciso confirmar a versão exata pós-abril de 2025, não só que 'já foi corrigido para o RCE anterior'.

Não há workaround oficial documentado pelo fornecedor além do patch — a lógica vulnerável está no controller core de assets, usado por padrão em qualquer site que sirva imagens com transformação. Como controle compensatório não vendor-endorsed, é possível bloquear no WAF ou proxy reverso requisições POST para a rota de geração de transformação (actions/assets/generate-transform) que enviem o parâmetro handle como array (múltiplas ocorrências de handle[] no corpo) em vez de valor único — isso reduz risco mas não substitui o patch, pois não cobre variações do payload.

Não funciona como mitigação: restringir apenas o painel administrativo ou exigir autenticação no /admin, já que o endpoint vulnerável é acionado pelo front-end público, não pela área administrativa.

Em logs de acesso web, procurar requisições POST para a action de geração de transformação de assets (rota do tipo actions/assets/generate-transform, dependendo de como o site expõe o front controller) contendo o parâmetro handle enviado múltiplas vezes ou em formato de array em vez de string única — esse é o indicador estrutural do bypass. Após o patch, tentativas desse tipo geram BadRequestHttpException com a mensagem de handle inválido nos logs de aplicação; a ausência desse erro em ambiente não corrigido não significa ausência de exploração, apenas que o patch não estava presente para bloquear.

Complementarmente, verificar arquivos inesperados gravados em diretórios acessíveis via web (cache de transformação de assets, storage/runtime) como sinal de webshell pós-exploração, e cruzar timestamps de criação desses arquivos com entradas de log da rota vulnerável. Não há assinatura de rede única e confiável documentada pelas fontes revisadas além do padrão de parâmetro handle malformado.