Craft CMS stores user-provided content in session files

Craft CMS grava o parâmetro returnUrl (usado para redirecionar o usuário após login) dentro do arquivo de sessão PHP no servidor, sem sanitizar seu conteúdo. Como um cliente não autenticado controla esse parâmetro e o nome do arquivo de sessão é previsível a partir do cookie de sessão retornado, isso permite plantar conteúdo arbitrário — incluindo código PHP — em um caminho de arquivo conhecido no servidor. Isoladamente o impacto é baixo (é só uma escrita de conteúdo, sem execução); o risco real aparece quando essa falha é encadeada com uma vulnerabilidade de inclusão/leitura de arquivo, como a CISA aponta explicitamente ao referenciar CVE-2025-32432.

A falha é classificada como CWE-472 (External Control of Assumed-Immutable Web Parameter). Quando um cliente não autenticado faz uma requisição a uma URL que exige login, o Craft CMS redireciona para a tela de login e armazena a URL de retorno solicitada (returnUrl) na sessão PHP, sem sanitizar seu valor. O PHP grava essa sessão em disco em /var/lib/php/sessions, em um arquivo nomeado sess_[session_value], onde session_value é o identificador de sessão devolvido ao cliente no header Set-Cookie da própria resposta HTTP.

Como o parâmetro returnUrl não passa por sanitização antes de ser serializado no arquivo de sessão, um atacante pode incluir ali qualquer string — inclusive tags e código PHP — e o Craft vai persistir esse conteúdo literalmente no arquivo em disco. O atacante conhece tanto o diretório quanto o nome do arquivo (derivado do cookie de sessão que ele mesmo recebeu), então tem escrita controlada em um local de arquivo previsível no filesystem do servidor.

O patch (PR #17220) resolve o problema sanitizando o valor do returnUrl antes de salvá-lo na sessão, tanto no branch 4.x quanto no 5.x. Segundo o próprio mantenedor (angrybrad), o Craft 3.x também é afetado pelo mesmo comportamento, mas é descrito como 'vulnerabilidade trivial' que, isoladamente, não é explorável — e o Craft 3 está fora de suporte de segurança há mais de um ano, então não recebeu correção.

O vetor CVSS 4.0 fornecido (VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) reflete exatamente essa natureza: impacto de integridade baixo e nenhum impacto direto de confidencialidade ou disponibilidade. A nota CVSS 6.9 mede a escrita de conteúdo controlado, não uma execução de código — a criticidade real da cadeia de ataque vem de outro lugar.

O vetor primário não exige autenticação: basta que o atacante requisite uma URL protegida por login enviando um returnUrl malicioso (por exemplo, contendo marcação PHP) como parâmetro. O servidor responde com um Set-Cookie contendo o identificador de sessão, e o atacante já sabe, a partir dele, o nome exato do arquivo sess_[session_value] que foi criado em /var/lib/php/sessions no servidor, com o payload gravado dentro.

O ponto crítico é que essa CVE, por si só, apenas cria o arquivo malicioso no disco — não existe caminho nativo no Craft para incluir ou executar esse arquivo. A CISA documenta explicitamente que a exploração real observada encadeia essa falha com CVE-2024-58136/CVE-2025-32432, uma vulnerabilidade de inclusão de arquivo local (LFI) relacionada ao Yii2/Craft que permite referenciar e executar arquivos arbitrários no servidor — nesse caso, o arquivo de sessão recém-plantado com código PHP. É essa combinação que produz execução remota de código completa e foi o vetor de ataques em massa contra instalações Craft CMS observados em campanhas de 2025.

O CVE está no catálogo KEV da CISA, confirmando exploração ativa in the wild — mas como parte da cadeia com CVE-2025-32432, não isoladamente. Ambientes que não possuem a vulnerabilidade de LFI complementar (já corrigida) ficam expostos apenas ao risco de ter um arquivo com conteúdo controlado por terceiros gravado em disco, sem mecanismo direto de execução.

Atualizar para Craft CMS 4.15.3 (branch 4.x) ou 5.7.5 (branch 5.x), que sanitizam o returnUrl antes de gravá-lo na sessão. Instalações Craft 3.x permanecem tecnicamente afetadas mas não recebem correção — o branch está fora de suporte de segurança há mais de um ano; a única mitigação real ali é migrar para uma versão suportada.

Como a exploração de impacto real depende do encadeamento com CVE-2025-32432 (LFI/RCE via Yii2), garantir que essa vulnerabilidade também esteja corrigida é tão importante quanto aplicar o patch desta CVE — corrigir só uma das duas pontas da cadeia reduz o risco, mas ambientes que não conseguem atualizar imediatamente devem tratar as duas como um único problema de remediação.

Não há menção nas fontes de um paliativo de configuração (WAF rule, flag, permissão de diretório) publicado pelo fornecedor como alternativa ao patch — o fix está apenas no código de sanitização do returnUrl. Restringir escrita/leitura do diretório de sessões PHP a nível de sistema operacional reduz a superfície, mas não é uma mitigação endossada pelo fornecedor e tem custo operacional (pode quebrar sessões de outras aplicações no mesmo host, se compartilhado).

Nos logs de acesso web, procurar requisições não autenticadas a rotas protegidas contendo parâmetros returnUrl com conteúdo anômalo — tags PHP (<?php), marcação HTML ou payloads de script — em vez de um caminho relativo legítimo. Em nível de filesystem, verificar arquivos em /var/lib/php/sessions com conteúdo que inclua código PHP ou HTML, o que não deveria ocorrer em uso normal.

Como o dano relevante só se materializa combinado com CVE-2025-32432, correlacionar esses achados com sinais de exploração de LFI (requisições a endpoints de transformação de assets ou geração de imagens apontando para caminhos de sessão) fornece indício mais forte de tentativa de exploração completa, e não apenas do gadget isolado.