Un CVE recién publicado contra el automation-controller de Red Hat Ansible Automation Platform merece atención inmediata. CVE-2026-84474 permite que un atacante remoto con privilegios mínimos, o incluso no autenticado, dispare plantillas de trabajo contra hosts gestionados arbitrarios y obtenga ejecución remota de código utilizando las credenciales ya incorporadas en esas plantillas. El radio de impacto abarca toda la infraestructura gestionada que el controller controla.

El problema central se divide en dos partes. En primer lugar, el host_config_key (el secreto de callback de aprovisionamiento) es visible para cualquier usuario que tenga el permiso de solo lectura view_jobtemplate. Este tipo de permiso se otorga con frecuencia porque parece inofensivo. No lo es. En segundo lugar, cuando el controller se encuentra detrás del gateway de AAP con una lista de proxy permitidos vacía, confía ciegamente en la cabecera X-Forwarded-For suministrada por el cliente para identificar el host solicitante. Combinar la exposición del secreto con la falsificación de cabeceras permite a un atacante suplantar cualquier host del inventario de la plantilla de trabajo e iniciar su ejecución.

Desde una perspectiva de IAM, esto es un fallo de mínimo privilegio agravado por una frontera de confianza rota. El acceso de solo lectura a una plantilla de trabajo nunca debería incluir las credenciales o secretos que autentican los callbacks. Se trata de un defecto de diseño, no de una mala configuración por parte del equipo operativo, pero el impacto operativo recae directamente sobre ese equipo. El problema de confianza en X-Forwarded-For es un problema de capa independiente: la configuración del proxy (o su ausencia) se convierte en un control de seguridad, y una lista de permitidos vacía lo elimina por completo. Estas dos debilidades se encadenan con facilidad, lo que hace posible la explotación sin necesidad de privilegios de partida elevados.

Si Ansible Automation Platform está en ejecución en el entorno, las preguntas inmediatas son: quién tiene el permiso view_jobtemplate, con qué amplitud se ha otorgado, qué plantillas de trabajo tienen habilitados los callbacks de aprovisionamiento y qué credenciales están asociadas a esas plantillas. Las cuentas de servicio y las credenciales de automatización tienden a tener un alcance excesivo porque las personas priorizan el «que funcione» sobre el «que funcione con el acceso mínimo necesario». Aquí es donde ese hábito pasa factura.

Aplique el parche primero, pero no se detenga ahí. Tras aplicar la corrección del proveedor, audite qué plantillas de trabajo tienen configurado host_config_key y rote esos secretos. A continuación, revise la configuración de la lista de proxy permitidos para que el controller no confíe en cabeceras reenviadas arbitrarias. Por último, extraiga las asignaciones de permisos para view_jobtemplate y evalúe si cada titular realmente los necesita. Si no es posible justificar que un usuario o cuenta de servicio concreto tenga ese permiso, retírelo de inmediato.