During an OpenShift Agent-Based Installation (ABI), the bootstrap node runs approve-csr.service, which executes a script that automatically approves every pending CertificateSigningRequest (CSR) without validating the requested identity.

Note: Kubernetes CSRs are how nodes and components obtain TLS client certificates. The Common Name (CN) in the certificate determines the identity — e.g. system:admin grants full cluster-admin privileges.

Attack scenario - An attacker with network access to the Kubernetes API during the bootstrap window could:
1. Attacker sends a crafted header to the bootstrap node, gets the Ignition file, extracts a kubeconfig with limited privileges (enough to create/retrieve CSRs).
2. Submit a CSR with CN=system:admin.
3. The approve-csr script approves and signs the CSR without any validation checks.
4. The signed certificate is returned to the attacker.
5. The attacker builds a kubeconfig using that certificate which results in full cluster-admin access.

Note: This is only exploitable during the bootstrap phase of ABI installs, which is a narrow time window. The attacker must have network access to the bootstrap node's API server during that period.