A newly published CVE against Red Hat Ansible Automation Platform's automation-controller is worth stopping whatever you're doing for. CVE-2026-84474 lets a minimally privileged, or even unauthenticated, remote attacker trigger job templates against arbitrary managed hosts and get remote code execution using the credentials already baked into those templates. The blast radius here is the entire managed infrastructure that controller touches.

Here's the core problem, broken into two pieces. First, the host_config_key (the provisioning-callback secret) is visible to any user who holds a read-only view_jobtemplate permission. That's the kind of permission you hand out freely because it feels harmless. It isn't. Second, when the controller sits behind the AAP gateway with an empty proxy allow-list, it blindly trusts the client-supplied X-Forwarded-For header to identify the calling host. Combine secret exposure with header spoofing and an attacker can impersonate any host in the job template's inventory and kick off execution.

From an IAM perspective, this is a least-privilege failure compounded by a broken trust boundary. Read-only access to a job template should never include the credentials or secrets that authenticate callbacks. That's a design flaw, not a misconfiguration on your end, but the operational impact lands squarely on your team. The X-Forwarded-For trust issue is a separate layer problem: your proxy configuration (or lack of one) becomes a security control, and an empty allow-list removes it entirely. These two weaknesses chain together cleanly, which is what makes this exploitable without elevated starting privileges.

If you're running Ansible Automation Platform in your environment, the immediate questions are: who holds view_jobtemplate permission, how broadly is that granted, which job templates have provisioning callbacks enabled, and what credentials are attached to those templates? Service accounts and automation credentials tend to be over-scoped because people optimize for "it works" over "it works with the minimum access it needs." This is where that habit bites you.

Patch first, but don't stop there. After you apply the vendor fix, audit which job templates have host_config_key set and rotate those secrets. Then review your proxy allow-list configuration so the controller isn't trusting arbitrary forwarded headers. Finally, pull the permission assignments for view_jobtemplate and ask whether every holder actually needs it. If you can't justify a specific user or service account having that permission, remove it now.