GPU VulnDB

Database/Control plane, storage & DevOps

Ansible Automation Controller: improper authorization lets a mounted service account token escalate privileges

CVSS 6.6CVE-2024-6840Control plane, storage & DevOpscurated

Impact

Automation Controller fails to authorize requests properly when they arrive carrying a Kubernetes service account token mounted via automountServiceAccountToken: true. An attacker who can send an HTTP request through the Kubernetes API server with such a token escalates to that service account inside the Controller, and the CVSS vector records a scope change - the compromise crosses out of the originating security authority. On a Kubernetes-hosted AAP that runs playbooks against the fleet, that is a pod-level token turning into automation-platform access. The record does not enumerate which service accounts are reachable, so treat the blast radius as whatever the mounted accounts in that namespace can do.

Who can reach it

Attacker able to reach the Kubernetes API server with a pod-mounted service account token - in practice someone with a workload in the cluster hosting Automation Controller. Authentication (the token) is required and Red Hat rates the privilege requirement high.

What to do

Apply RHSA-2024:6428 for Ansible Automation Platform 2.4 on RHEL 8/9 and restart the Controller pods. As defence in depth, set automountServiceAccountToken: false on pods that do not need the API server and restrict which service accounts can reach the Controller.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.