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
  permission_classes=(AllowAny,) and authentication_classes=(), 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
  /instance_groups/ 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.