REDHAT-BUG-2527196: Medium severity Red Hat Ansible Automation Controller vulnerability
A missing-authorization information-disclosure flaw was found in the automation-controller API. The endpoint GET /api/v2/ping/ (also reachable as /api/controller/v2/ping/) is served by ApiV2PingView with permissionclasses=(AllowAny,) and authenticationclasses=(), making it fully anonymous by design so that the installer and load-balancer health probes can reach it. Beyond the intended liveness fields (high-availability flag and product version), the endpoint's GET handler enumerates every automation-mesh Instance (excluding hop nodes) and every InstanceGroup without any query scoping, and serializes them into the anonymous response. As a result, an unauthenticated remote attacker who can reach the Controller API learns the complete mesh inventory — each node's hostname, node type (control/hybrid/execution), UUID, last heartbeat, capacity, and exact AWX version — together with every instance group's name, capacity, and member hostnames, plus the deployment's install UUID and the active control node identifier. This is data that the authenticated /instances/ and /instancegroups/ endpoints protect behind authentication and role-based access control. Exposing it pre-authentication provides an attacker with detailed internal reconnaissance: it maps the control plane, identifies the highest-value nodes, and reveals exact software versions for targeted exploit selection. No credentials, job data, tenant data, or configuration secrets are exposed, so the confidentiality impact is limited and there is no impact on integrity or availability. The issue is that the endpoint over-serializes RBAC-gated topology into a response that is intentionally unauthenticated; the unauthenticated liveness check itself is expected behavior.
Affected Software
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated remote attacker who can reach the Controller API can request the ping endpoint. No credentials or Controller role is required because the endpoint permits anonymous access by design.
What information is exposed through the endpoint?
The response can disclose the full automation-mesh inventory and instance groups, including node hostnames, types, UUIDs, heartbeat times, capacity, AWX versions, group names, and member hostnames. It also exposes the deployment install UUID and active control node identifier.
Are standard health-check deployments affected?
The affected endpoint is intentionally anonymous so installers and load-balancer health probes can access it. Both /api/v2/ping/ and /api/controller/v2/ping/ reach the affected handler.
How can I determine whether my deployment is exposed?
From an unauthenticated network location that can reach the Controller API, request either ping endpoint and inspect whether the response includes instance or instance-group inventory details beyond liveness fields. Network reachability to the Controller API is the prerequisite for exposure.