CVE-2025-32432: Ejecución remota de código sin autenticación en Craft CMS

Tras un análisis detallado de este flujo de trabajo, nuestros becarios determinaron que el método `AssetsController::actionGenerateTransform ` se invoca cada vez que se envía una solicitud POST al punto final expuesto. Esta función recupera el parámetro «handle» directamente del cuerpo de la solicitud y lo reenvía a la siguiente etapa para su posterior procesamiento.

En el siguiente paso, se invoca el método ImageTransforms::normalizeTransform(). Este método toma el parámetro «handle» proporcionado por el usuario y lo convierte en un objeto ImageTransform. Dado que el objeto se crea directamente a partir de datos de entrada no fiables, esto supone un punto crítico de riesgo en el flujo de ejecución.

Durante este proceso, todos los pares clave-valor del array $transform controlado por el usuario (procedente del parámetro handle) se fusionan en un array de configuración. A continuación, el método normalizeTransform pasa este array a Craft::createObject(), que se encarga de instanciar un nuevo objeto ImageTransform.

La vulnerabilidad se debe a la forma en que Craft::createObject() (que envuelve el método Yii::createObject() de Yii) procesa las matrices de configuración. Dado que este mecanismo utiliza el contenedor de inyección de dependencias para instanciar y configurar objetos directamente a partir de la matriz no validada, los atacantes podrían hacerse con el control del proceso de creación de objetos.

Cuando se pasa una carga maliciosa, el constructor del objeto (heredado de la clase Model ) invoca el método App::configure().

Este método recorre cada propiedad de la matriz controlada por el atacante y las asigna al nuevo 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.

Una de estas cargas maliciosas puede diseñarse para aprovechar la forma en que Component::__set procesa las propiedades que comienzan por «as», como, por ejemplo, este exploit:

Según nuestro análisis, la implementación de Component::__set incluye una medida de seguridad: cuando se adjunta un comportamiento a través de dicha propiedad, el marco comprueba que la clase especificada en la matriz de configuración sea una subclase válida de yii\base\Behavior. Esta comprobación tiene por objeto evitar que se adjunten clases arbitrarias directamente a los componentes.

Sin embargo, esta medida de seguridad no es tan eficaz como parece. La debilidad radica en la forma en que Yii::createObject gestiona las matrices de configuración.

Al instanciar un objeto, Yii::createObject da prioridad al parámetro especial __class. Si esta clave está presente, su valor se utiliza como clase de destino para la instanciación, y se ignora la clave «class» estándar del array de configuración.

El atacante puede crear una carga útil para el comportamiento del exploit que incluya dos claves:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - Una clase válida que hereda de yii\base\Behavior. Este valor existe únicamente para satisfacer la comprobación is_subclass_of en Component::__set, lo que permite que la ejecución continúe sin generar un error.
2. '__class' => '\yii\rbac\PhpManager' - El objetivo real del atacante. Se trata de la clase «gadget» que quiere instanciar.

Cuando se ejecuta el código, Component::__set supera la comprobación de seguridad, ya que solo inspecciona la clave de clase. Sin embargo, cuando el marco llama posteriormente a Yii::createObject para asociar el comportamiento, da prioridad a __class, lo que provoca que se instancie en su lugar el objeto \yii\rbac\PhpManager elegido por el atacante.

El uso de \yii\rbac\PhpManager es intencionado. La mera creación de un objeto no basta para aprovechar la vulnerabilidad; para lograr la ejecución de código remoto (RCE) se requiere una clase de gadget con efectos secundarios que puedan utilizarse como arma. PhpManager es un objetivo habitual en los ataques POI (inyección de objetos PHP) debido a su flujo de inicialización. Al instanciarse, su método init() llama a load(), que a su vez invoca a loadFromFile($this->itemFile). Al controlar $this->itemFile, un atacante puede obligar a la aplicación a cargar un archivo malicioso, transformando la creación de objetos en ejecución de código.

El peligro reside en el método `loadFromFile`. En PHP, la instrucción `require` ejecuta el archivo de destino como código, por lo que, si un atacante controla la ruta del archivo, puede provocar la ejecución de código arbitrario.

Para introducir código malicioso en el servidor, el atacante aprovecha los archivos de sesión de PHP. Al inyectar código PHP en un parámetro de solicitud, Craft CMS guarda la carga útil en un archivo de sesión durante el proceso de redireccionamiento. Posteriormente, cuando PhpManager carga este archivo, el código del atacante podría ejecutarse.

La cadena de ataque completa se desarrolla en tres fases. En primer lugar, el atacante introduce código PHP malicioso enviando una URL manipulada, que Craft CMS guarda en un archivo de sesión. A continuación, aprovecha la vulnerabilidad de elusión de __class en el punto final de transformación de imágenes para cargar el gadget PhpManager y dirigirlo hacia el archivo de sesión malicioso. Por último, cuando PhpManager carga el archivo, se ejecuta la carga útil del atacante, lo que le otorga ejecución remota de código (RCE) y control total del servidor, a menudo a través de un webshell o un shell inverso.