Bug 2515215 (CVE-2026-19706)

Summary:	CVE-2026-19706 openshift/installer: OpenShift Installer: Unconditional CSR approval during Agent-Based Installation (ABI) bootstrap
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	akhatavk, aos-team-art-private, asdas, dpaolell, gparvin, jbalunas, jdelft, jupierce, lgamliel, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhaigner, sbratsla, security-response-team, sghai, sidsharm, suppawar, tsze, vlaad
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	During ABI bootstrap, the bootstrap node's approve-csr.service approves and signs every CSR without identity validation. An attacker on the install network can retrieve the unauthenticated Ignition file (ports 22623/22624), extract a limited kubeconfig, submit a CSR for CN=system:admin, receive the signed certificate, and gain full cluster-admin access. Exploitable only during the narrow bootstrap window.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Deadline:	2026-11-09

Description OSIDB Bzimport 2026-08-13 10:35:08 UTC

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.