Red Hat has disclosed a high-severity security flaw in the oc-mirror utility used to move OpenShift content into disconnected environments. The vulnerability, tracked as CVE-2026-75939, can cause the tool to accept a forged release-image signature under specific attack conditions.
The issue matters because signature verification is intended to establish that release content came from a trusted source and was not altered before it reaches a registry. In a disconnected or air-gapped deployment, mirrored content may later become the source from which clusters obtain software, so a failure at this trust boundary can have consequences beyond the mirroring step.
Key takeaways
- CVE-2026-75939 affects OpenShift's
oc-mirrorutility and is rated High, with a CVSS 3.1 base score of 7.4. - The weakness is improper cryptographic-signature verification, classified as CWE-347.
- An attacker would need to intercept or manipulate network traffic to the signature endpoint; the advisory rates attack complexity as high.
- No privileges or user interaction are required once the necessary network position or traffic-manipulation capability exists.
- Administrators using
oc-mirrorfor disconnected registries should check Red Hat's CVE record and product advisories for the affected build in their environment and apply the vendor's remediation when available.
What is CVE-2026-75939?
The vulnerability is in the way oc-mirror processes PGP signatures associated with release images. According to the published advisory, the tool checks for signature errors before the entire signed body has been processed. That sequencing error can result in an invalid signature being treated as valid.
A remote attacker who can intercept or manipulate traffic to the signature endpoint could craft a PGP message that refers to a valid Red Hat release key ID while carrying a forged signature. If the conditions are met, oc-mirror may accept the message and mirror a malicious release payload into a disconnected registry.
This does not mean that any unauthenticated internet user can automatically compromise an OpenShift cluster. The published CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N: the issue is network-reachable but has high attack complexity. The attack scenario specifically depends on an adversary being able to intercept or alter the relevant network traffic.
Why signature verification matters to oc-mirror
Organisations use oc-mirror to transfer container images and related OpenShift content from connected sources into registries that serve disconnected environments. The project provides controls around image signatures and trust policy, including secure signature verification.
Cryptographic signatures are part of the software-supply-chain trust model. A valid signature can establish that content was signed by the expected key and has not been modified in a way that invalidates that signature. Simply recognising a trusted key identifier is not enough: the signature itself has to be cryptographically validated against the complete signed content.
CVE-2026-75939 breaks that assumption in the affected verification path. The danger is therefore not merely an incorrect status message. A forged payload that passes the check can cross a security boundary and be stored in a registry that operators expect to contain trusted release material.
What could an attacker gain?
The advisory describes potential compromise of both confidentiality and integrity as high, while availability impact is rated none in the CVSS base vector. The immediate security concern is the ability to introduce malicious release content into the mirroring workflow.
The ultimate effect would depend on how an organisation uses the affected registry and whether malicious content is subsequently consumed. The CVE description establishes the possibility of accepting and mirroring a malicious release payload; it should not be read as evidence that every affected installation has been compromised.
Who should pay attention?
The issue is particularly relevant to teams that use OpenShift oc-mirror to maintain disconnected registries. That includes environments where direct internet access is restricted and release images are deliberately staged through a controlled mirroring process.
Security teams should identify which oc-mirror build is deployed rather than assuming that every OpenShift component has the same exposure. Vulnerability status can vary by product stream and package, and Red Hat's current CVE and errata data should be treated as the authoritative source for affected and fixed builds.
What administrators should do
- Inventory oc-mirror deployments. Identify systems and automation that use
oc-mirror, especially workflows feeding disconnected registries. - Check the official CVE record. Compare the installed package or image with Red Hat's affected-product and remediation information for CVE-2026-75939.
- Apply the vendor-provided fix when available for your stream. Do not infer a safe version from an unrelated OpenShift advisory.
- Protect the network path. Because the documented attack requires interception or manipulation of traffic to the signature endpoint, preserve TLS verification and investigate proxies, mirrors or other components that can alter that path.
- Review mirrored content if exposure is suspected. If there is evidence that the relevant network path may have been controlled by an attacker, treat the integrity of content mirrored during the exposure window as a security investigation rather than relying solely on the vulnerable signature check.
What not to conclude from the disclosure
The public advisory describes a vulnerability and an exploitation path; it does not by itself establish that the flaw is being actively exploited in the wild. It also does not establish that every disconnected OpenShift registry contains malicious images.
Likewise, the CVSS score is a standardised severity assessment, not a measurement of the probability that a particular organisation will be attacked. Actual risk depends on the affected software version, network architecture, use of oc-mirror and an attacker's ability to manipulate the signature-fetching path.
A software-supply-chain trust problem
The broader lesson is that verification code has to validate both identity and integrity completely. A trusted key ID is only a reference to an identity; cryptographic verification of the complete signed object is what establishes whether the content should actually be trusted.
For organisations that deliberately isolate production environments, mirroring is an important control, but isolation does not eliminate supply-chain risk. The connected side of the transfer process remains a trust boundary. CVE-2026-75939 is a reminder to keep the tooling at that boundary patched and to verify the integrity assumptions on which disconnected deployments rely.
