A Valid Red Hat Key ID Could Still Deliver a Forged OpenShift Release
A disconnected OpenShift environment is designed to reduce external dependency. A flaw in the tool that moves releases across that boundary could instead let a forged update arrive carrying a familiar Red Hat key identity.
CVE-2026-75939 affects the RHEL 9 build of the oc-mirror plugin. Red Hat rates it Important with a CVSS 3.1 score of 7.4. The RHEL 8 plugin is listed as not affected because the component is not present.
The check happened before the signed body was finished
Red Hat says the tool checks for PGP signature errors before the entire signed body has been processed. An attacker able to intercept or manipulate traffic to the signature endpoint could craft a message containing a valid Red Hat release key ID but a forged signature.
The tool may then accept and mirror a malicious release payload into the disconnected registry. The trust signal is real, but it has been evaluated at the wrong point in the verification process.
Disconnected does not mean verification can be weaker
Air-gapped and disconnected environments often concentrate trust in a small number of import workflows. When one of those workflows accepts a release, downstream clusters may treat it as approved precisely because the environment cannot consult external services during deployment.
- Identify every system using the RHEL 9
oc-mirrorplugin and record the exact package build. - Pause unverified release imports where the vulnerable plugin remains in use.
- Protect the connected staging host and the route to the signature endpoint from interception and unauthorised modification.
- Independently verify imported release digests and signatures with a fixed tool before promotion.
- Review recently mirrored content, workflow logs and registry writes for unexpected images or altered manifests.
- Keep a reproducible chain of custody from external retrieval to disconnected registry admission.
Red Hat’s advisory currently says no mitigation meets its normal criteria and lists the affected package without an erratum. Teams should monitor the vendor record for a fixed build rather than improvising a silent exception that permanently weakens release verification.
No exploitation is reported in Red Hat’s entry. The impact of CVE-2026-75939 comes from where it sits: at the narrow point where trusted software is admitted into an environment designed not to ask the outside world again.
Sources
- Red Hat Product Security advisory, published 21 September 2026.
- Red Hat machine-readable VEX record.
