Un CVE récemment publié contre l'automation-controller de Red Hat Ansible Automation Platform mérite qu'on s'y arrête immédiatement. CVE-2026-84474 permet à un attaquant distant disposant de privilèges minimaux, voire non authentifié, de déclencher des modèles de tâches contre des hôtes gérés arbitraires et d'obtenir une exécution de code à distance en utilisant les identifiants déjà intégrés dans ces modèles. Le rayon d'impact couvre l'ensemble de l'infrastructure gérée que le contrôleur administre.

Voici le problème central, décomposé en deux parties. Premièrement, le host_config_key (le secret de rappel de provisionnement) est visible par tout utilisateur qui détient une permission view_jobtemplate en lecture seule. C'est le genre de permission qu'on distribue librement parce qu'elle semble inoffensive. Elle ne l'est pas. Deuxièmement, lorsque le contrôleur est placé derrière la passerelle AAP avec une liste d'autorisation de proxy vide, il fait confiance aveuglément à l'en-tête X-Forwarded-For fourni par le client pour identifier l'hôte appelant. La combinaison de l'exposition du secret et de la falsification d'en-tête permet à un attaquant d'usurper l'identité de n'importe quel hôte dans l'inventaire du modèle de tâche et de déclencher l'exécution.

Du point de vue de l'IAM, il s'agit d'un échec du principe du moindre privilège, aggravé par une frontière de confiance défaillante. L'accès en lecture seule à un modèle de tâche ne devrait jamais inclure les identifiants ou les secrets qui authentifient les rappels. C'est un défaut de conception, non une mauvaise configuration de votre côté, mais l'impact opérationnel retombe directement sur votre équipe. Le problème de confiance envers X-Forwarded-For est un problème de couche distinct : votre configuration de proxy (ou son absence) devient un contrôle de sécurité, et une liste d'autorisation vide le supprime entièrement. Ces deux faiblesses se combinent aisément, ce qui rend l'exploitation possible sans privilèges de départ élevés.

Si vous exploitez Ansible Automation Platform dans votre environnement, les questions immédiates sont les suivantes : qui détient la permission view_jobtemplate, dans quelle mesure est-elle accordée, quels modèles de tâches ont les rappels de provisionnement activés, et quels identifiants sont associés à ces modèles? Les comptes de service et les identifiants d'automatisation ont tendance à être surdimensionnés parce que les équipes optimisent pour « ça fonctionne » plutôt que pour « ça fonctionne avec l'accès minimal nécessaire ». C'est là que cette habitude vous rattrape.

Appliquez le correctif en priorité, mais ne vous arrêtez pas là. Après avoir appliqué le correctif du fournisseur, vérifiez quels modèles de tâches ont le host_config_key défini et effectuez une rotation de ces secrets. Ensuite, révisez la configuration de votre liste d'autorisation de proxy afin que le contrôleur ne fasse pas confiance à des en-têtes transmis arbitraires. Finalement, extrayez les attributions de permission pour view_jobtemplate et demandez-vous si chaque détenteur en a réellement besoin. Si vous ne pouvez pas justifier qu'un utilisateur ou un compte de service spécifique dispose de cette permission, retirez-la maintenant.