Red Hat discloses CVSS 7.4 oc-mirror flaw: PGP signature check runs on incomplete input

A signature verdict reached too early

Red Hat disclosed a vulnerability in its OpenShift image mirroring tool on 21 September 2026, tracked as CVE-2026-75939 and rated 7.4 on the CVSS v3.1 scale, according to a write-up on dev.to. The affected component is openshift4/oc-mirror-plugin-rhel9, part of Red Hat OpenShift Container Platform 4. oc-mirror is the utility clusters rely on to copy Red Hat release images, operator catalogs and related content into a private registry, most often in disconnected or air-gapped deployments.

The root cause is a sequencing error rather than weak cryptography. The dev.to post, which summarises the vendor advisory alongside coverage from FreeBuf and 51Testing, explains that oc-mirror decides whether a PGP signature check has failed before it has finished reading the entire signed message body. Because the verdict is computed against incomplete input, a forged PGP message that borrows a legitimate Red Hat release key identifier can be accepted as authentic.

Preconditions and consequences

Mounting the attack is not trivial. According to the post, the attacker first needs the ability to intercept or modify traffic between an affected oc-mirror instance and the signature endpoints, which is why the advisory's metrics place attack complexity at high. From that vantage point, no prior privileges and no user interaction are required. Confidentiality and integrity impacts are rated high, while availability is unaffected.

If the traffic manipulation succeeds, oc-mirror can be coaxed into syncing a malicious release payload into the private registry of a disconnected environment. That, the post argues, is what turns a verification bug into a supply-chain incident: air-gapped installations treat whatever sits in their registry as already-vetted software. Once the payload lands, an administrator or an automated installation pipeline can select and deploy it, exposing the cluster to unauthorised code execution, application tampering, credential theft and access to sensitive data.

Which packages are affected

The write-up carries two scope notes. The RHEL 8 variant of the plugin is untouched, simply because the component does not exist in that release. Conversely, older packages within supported minor branches of the product inherit the flaw unless the advisory explicitly marks them as unaffected. Red Hat reportedly stated at disclosure time that it had no practical mitigation meeting its deployment and stability requirements, meaning no fix or workaround the vendor was prepared to endorse yet.

Compensating controls while waiting for a patch

The post suggests defensive steps operators can take in the meantime: restrict which networks oc-mirror hosts may reach en route to the signature endpoints; think carefully before deploying TLS inspection, since the interception capability it introduces is precisely what this attack depends on; watch private registries for unexpected changes to synced content; confirm release image digests through an independent trusted channel before promoting anything to production; audit recent sync activity and tighten access controls on the registry; and follow Red Hat's security advisory channel for the patched package.

Why it matters

The vulnerability is a useful reminder that cryptographic checks are only as good as the code that orchestrates them: a correct signature algorithm invoked at the wrong moment still produces the wrong answer. For OpenShift operators the stakes are amplified by the target, since the private registry is the trust anchor of a disconnected deployment and one tainted sync can fan out to many clusters through automated pipelines. With no endorsed fix available at disclosure, network restrictions and independent digest verification are the practical defences until Red Hat ships an update.