A privilege/trust-boundary flaw was found in the automation-controller instance
  install-bundle feature. The endpoint GET /api/controller/v2/instances/{id}/
  install_bundle/, restricted to System Administrators, returns a tarball
  containing a newly generated private key and an X.509 certificate signed by the
  receptor mesh certificate authority. The certificate's Common Name, DNS
  subject-alternative-name, and receptor node-id extension are copied verbatim
  from the instance's hostname, which the administrator chose freely when creating
  the instance; the certificate is hard-coded to a ten-year validity, uses a
  random serial number, and is never recorded in any issuance log or certificate
  revocation list, so it cannot be revoked without rotating the mesh CA across the
  entire fleet. Furthermore, the controller validates the hostname charset
  case-insensitively but enforces uniqueness case-sensitively, so an administrator
  can register a case variant of an existing control node's hostname — for
  example Controller.aap.svc alongside controller.aap.svc — and receive a
  mesh-CA-signed certificate whose DNS name TLS verifiers, which compare hostnames
  case-insensitively, accept as the genuine control node. The security
  significance depends on the deployment model. On a self-managed installation a
  System Administrator already controls the host that stores the mesh CA key, so
  minting a certificate is not an escalation. In a managed or hosted deployment,
  however, the customer holds controller superuser while the platform operator
  runs the mesh; there the flaw lets a customer-tier administrator obtain a
  long-lived, non-revocable mesh peer credential and, with an on-path network
  position, impersonate or intercept traffic to control and hybrid nodes at the
  TLS layer. The certificate does not grant direct code execution on mesh nodes,
  because receptor work submission is protected by a separate work-signing key
  whose private half is not distributed in the bundle.