CVE-2025-32432: Execução remota de código não autenticado no Craft CMS

Através de uma análise detalhada deste fluxo de trabalho, os nossos colegas identificaram que o método AssetsController::actionGenerateTransform é invocado sempre que uma solicitação POST é enviada para o ponto final exposto. Esta função recupera o parâmetro handle diretamente do corpo da solicitação e o encaminha para processamento posterior na próxima etapa.

Na etapa seguinte, o método ImageTransforms::normalizeTransform() é chamado. Esse método recebe o parâmetro handle fornecido pelo utilizador e o converte em um objeto ImageTransform. Como o objeto é criado diretamente a partir de uma entrada não confiável, isso representa um ponto crítico de risco no fluxo de execução.

Durante este processo, todos os pares chave-valor da matriz $transform controlada pelo utilizador (originária do parâmetro handle) são mesclados numa matriz de configuração. O método normalizeTransform então passa esta matriz para Craft::createObject(), que é responsável por instanciar um novo objeto ImageTransform.

A vulnerabilidade decorre da forma como Craft::createObject() (envolvendo Yii::createObject() do Yii) processa matrizes de configuração. Como esse mecanismo usa o contentor DI para instanciar e configurar objetos diretamente da matriz não validada, os atacantes podem obter controlo sobre o processo de construção do objeto.

Quando uma carga maliciosa é passada, o construtor do objeto (herdado da classe Model ) invoca o método App::configure().

Este método itera sobre cada propriedade na matriz controlada pelo invasor e atribui-as ao novo objeto.

When App::configure() assigns properties from the attacker-controlled configuration array, most keys are mapped directly onto the object. However, if a key begins with the prefix as, the assignment is routed through Component::__set, Yii’s magic setter. This method interprets as <name> as an instruction to attach a behavior (mixin) to the object.

Uma carga maliciosa desse tipo pode ser criada para explorar a forma como Component::__set processa propriedades com o prefixo as, como por exemplo:

De acordo com a nossa análise, a implementação do Component::__set inclui uma salvaguarda: quando um comportamento é anexado por meio dessa propriedade, a estrutura verifica se a classe especificada na matriz de configuração é uma subclasse válida do yii\base\Behavior. Essa verificação tem como objetivo impedir que classes arbitrárias sejam anexadas diretamente aos componentes.

No entanto, essa proteção não é tão eficaz quanto parece. A fraqueza vem da forma como o Yii::createObject lida com matrizes de configuração.

Ao instanciar um objeto, Yii::createObject dá prioridade ao parâmetro especial __class. Se essa chave estiver presente, o seu valor é usado como a classe de destino para a instanciação, e a chave de classe padrão na matriz de configuração é ignorada.

O invasor pode criar uma carga útil para o comportamento de exploração que inclui duas chaves:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - Uma classe legítima que estende yii\base\Behavior. Este valor existe apenas para satisfazer a verificação is_subclass_of em Component::__set, permitindo que a execução continue sem gerar um erro.
2. '__class' => '\yii\rbac\PhpManager' - O alvo real do invasor. Esta é a classe "gadget" que eles querem instanciar.

Quando o código é executado, Component::__set passa na verificação de segurança porque apenas inspeciona a chave da classe. No entanto, quando a estrutura chama posteriormente Yii::createObject para anexar o comportamento, dá precedência a __class, resultando na instanciação do objeto \yii\rbac\PhpManager escolhido pelo invasor.

O uso de \yii\rbac\PhpManager é intencional. Simplesmente criar um objeto não é suficiente para a exploração; para conseguir RCE, é necessária uma classe gadget com efeitos colaterais que possam ser transformados em armas. O PhpManager é um alvo comum em ataques POI (PHP Object Injection) devido ao seu fluxo de inicialização. Após a instanciação, o seu método init() chama load(), que então invoca loadFromFile($this->itemFile). Com o controlo sobre $this->itemFile, um invasor pode forçar a aplicação a carregar um ficheiro malicioso, transformando a criação de objetos em execução de código.

O perigo reside no método loadFromFile. Em PHP, um require executa o ficheiro de destino como código, portanto, se um invasor controlar o caminho do ficheiro, poderá acionar a execução de código arbitrário.

Para colocar código malicioso no servidor, o invasor explora os ficheiros de sessão PHP. Ao injetar PHP num parâmetro de solicitação, o Craft CMS guarda a carga útil num ficheiro de sessão durante o processo de redirecionamento. Posteriormente, quando o PhpManager carrega esse ficheiro, o código do invasor pode ser executado.

A cadeia de ataque completa funciona em três etapas. Primeiro, o invasor planta um PHP malicioso enviando uma URL criada, que o Craft CMS guarda num ficheiro de sessão. Em seguida, eles exploram o bypass __class no endpoint de transformação de imagem para carregar o gadget PhpManager e direcioná-lo para o ficheiro de sessão corrompido. Por fim, quando o PhpManager carrega o ficheiro, a carga útil do invasor é executada, concedendo RCE e controle total do servidor — geralmente por meio de um webshell ou shell reverso.