Red Hat has disclosed an Important-severity vulnerability, tracked as CVE-2026-75939, in the oc-mirror plugin used by OpenShift Container Platform 4 to mirror releases into disconnected, air-gapped registries. The flaw sits in how the tool validates the PGP signature attached to a release before trusting it.
What happened
oc-mirror is supposed to check the cryptographic signature on every release it pulls down and refuse anything that isn't signed by a legitimate Red Hat key. According to Red Hat's advisory, a flawed step in that validation sequence means a specially crafted PGP message carrying a valid-looking Red Hat key ID can pass the check even when the underlying signature has been forged.
To exploit it, an attacker needs the ability to intercept or tamper with traffic between an organization's oc-mirror instance and the signature endpoint it talks to — for example by sitting on the network path or abusing a misconfigured proxy. From there, they can substitute a hostile release payload for a legitimate one. Because oc-mirror trusts the forged signature, it mirrors the malicious image straight into the target's private, disconnected registry as if it were an official Red Hat release.
Red Hat rates the bug as network-exploitable with no privileges or user interaction required, though real-world exploitation carries high attack complexity since the attacker has to successfully manipulate signature-related traffic. The CVSS vector reflects high confidentiality and integrity impact and no impact on availability. The affected component is openshift4/oc-mirror-plugin-rhel9; the RHEL 8 build isn't affected because it doesn't ship the plugin. Red Hat also cautions that older packages across affected minor streams should be treated as vulnerable unless explicitly marked otherwise.
Why it matters
Disconnected and air-gapped OpenShift deployments lean on mirrored registries precisely because they're assumed to be a trusted, offline source of software. If a forged release makes it into that registry, cluster administrators and automated installation pipelines have no reason to question it before deploying it. A single poisoned image can translate directly into unauthorized code execution, tampering with running workloads, credential theft, or broader data access inside environments that were specifically built to be isolated from this kind of supply-chain risk.
At the time of disclosure, Red Hat says no mitigation meets its standard deployment and stability bar, so there's no clean interim fix — just a set of compensating controls until updated packages ship.
What to do
- Lock down signature endpoints. Restrict network access to the servers oc-mirror talks to for signature verification, and enforce TLS inspection on that path so tampering is harder to pull off unnoticed.
- Treat release-mirroring as high risk for now. Until Red Hat ships security errata for the affected plugin, don't assume mirrored content is automatically clean.
- Independently verify what you promote. Validate release digests through a separate, trusted channel before pushing mirrored images into production.
- Audit what's already there. Review recent mirrored releases and disconnected registry access controls for anything that looks out of place.
- Watch for the fix. Track Red Hat's security advisories for CVE-2026-75939 and apply updated packages as soon as they're available.