Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessGain on-path/MITM position to signature endpoint
-
DeliveryIntercept oc-mirror signature request
-
ExploitCraft PGP with valid Red Hat key ID + forged signature
-
ExecutionFlawed early error-check accepts forged signature
-
PersistMirror malicious release payload into disconnected registry
-
ImpactCompromise integrity of downstream deployments
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Signature verification
|
| Exploitation Conditions | Requires the attacker to occupy a man-in-the-middle / on-path position capable of intercepting or manipulating oc-mirror's network traffic to the release signature endpoint (reflected in CVSS AC:H). The victim must be actively running an oc-mirror operation that performs PGP release-image signature verification, typically in a disconnected/air-gapped OpenShift 4 registry-mirroring workflow. No authentication is needed against oc-mirror itself (PR:N) and no user interaction beyond running the normal mirror process (UI:N), but the on-path requirement and the need for an in-progress mirror operation are the practical limiting factors that keep this from being trivially exploitable. |
| Impact | This is a genuine cryptographic-signature-verification bypass (CWE-347) in openshift/oc-mirror, but the real-world risk is moderate and gated by a demanding attack precondition. The Red Hat CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, 7.4) correctly encodes AC:H - the attacker must hold a man-in-the-middle position against traffic to the signature endpoint, which is the single biggest limiter. No EPSS score, no CISA KEV entry, and no public POC were supplied, so exploitation is theoretical at analysis time; there is no signal of widespread opportunistic attacks. I partially dispute the impact weighting: the vulnerability's direct effect is integrity (accepting a forged-signature release payload), so I:H is well justified, but C:H is generous - the flaw does not itself disclose data, and confidentiality/availability loss would only follow downstream from deploying a poisoned payload. Net: a real integrity-focused priority for organizations running disconnected/air-gapped OpenShift mirroring who cannot fully trust the network path to the signature endpoint, but not a drop-everything internet-wide threat given AC:H and no exploitation evidence. |
| Exploit ScenarioDerived | An attacker who can intercept or tamper with network traffic between oc-mirror and the release signature endpoint (e.g., a compromised proxy, rogue on-path device, or DNS/TLS-stripping position) crafts a PGP message that carries a legitimate Red Hat release key ID but a forged signature. Because oc-mirror checks for signature errors before the full signed body is processed, the forged message passes verification, and the tool mirrors an attacker-controlled malicious release payload into the disconnected registry. No public exploit code was identified at time of analysis, and the network-manipulation requirement (AC:H) makes this an opportunistic-to-targeted attack rather than a trivial one. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 21, 2026
Signature verification bypass in Red Hat's openshift/oc-mirror tool allows an attacker who can intercept or manipulate traffic to the release-signature endpoint to have a forged PGP-signed release payload accepted and mirrored into a disconnected OpenShift 4 registry. The defect (CWE-347) causes oc-mirror to evaluate signature errors before the full signed body has been processed, so a message carrying a legitimate Red Hat release key ID but an invalid signature can pass validation during a normal mirror operation. Exploitation is gated by a demanding precondition: the attacker must already hold a man-in-the-middle/on-path position on the network path and the victim must be actively running an oc-mirror signature-verifying operation; no credentials against oc-mirror are required (PR:N) and no user interaction beyond running the mirror process is needed (UI:N). The realistic impact is integrity-only, since the assessed vector scores C:N/I:H/A:N, and no public exploit has been identified at time of analysis.
RemediationAI
No vendor-released patch identified at time of analysis; Red Hat's advisory page at https://access.redhat.com/security/cve/CVE-2026-75939 and the tracking Bugzilla at https://bugzilla.redhat.com/show_bug.cgi?id=2517976 should be monitored for the errata and exact fixed oc-mirror/OpenShift 4 build, and only versions named in that errata should be treated as remediated. Until a fix is available, the most effective control is to remove the attack precondition: run oc-mirror only over trusted, encrypted transport with strict certificate validation and certificate pinning where feasible, since breaking the on-path/AC:H requirement neutralizes the bypass - the trade-off is operational complexity in environments with inspecting proxies, which must then be explicitly trusted rather than transparently intercepting. Independently verify release integrity out of band before trusting mirrored content, for example by validating the payload's digest/checksum against a value obtained through a separate trusted channel and by re-running signature verification manually with the standard gpg tooling over the fully assembled payload (the manual check bypasses the flawed in-tool ordering logic, at the cost of an extra step per mirror operation and dependence on operator discipline). Where policy permits, mirror exclusively from a hardened internal source registry that is populated and signed through a controlled pipeline rather than directly from upstream endpoints, and treat any release payload that only oc-mirror - and not an independent gpg verification - vouches for as untrusted. Air-gapped consumers should also validate the mirrored content at the receiving side before deployment, so a payload that slipped through during mirroring is caught before it reaches clusters.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
oc-mirror is Red Hat's CLI utility for replicating OpenShift Container Platform 4 release images, operator catalogs, and related content into a local or disconnected (air-gapped) registry; release payloads carry PGP signatures that oc-mirror is supposed to verify against Red Hat release keys before content is trusted and mirrored. The root cause falls under CWE-347, Improper Verification of Cryptographic Signature, and specifically concerns message-processing order: the implementation checks for signature errors before the entire signed body has been consumed, meaning the verification result is computed against an incomplete or attacker-controlled view of the PGP message rather than the full canonical signed content. In PGP (RFC 4880) terminology this is the class of bug where one-pass signature packets, signature packet ordering, or armoring/cleartext-framing handling lets an attacker present a message whose key ID matches a trusted Red Hat release key while the actual signature does not validate over the real payload. The result is an authentication/integrity bypass at the trust boundary between the release distribution channel and the customer's registry - an attacker who injects content on that path can get malicious images accepted as if Red Hat signed them. The supplied tags include "Authentication Bypass" and a generic "Jwt Attack" label alongside the correct OpenShift Container Platform 4 product tagging; the JWT tag appears to be a generic signature-bypass categorization rather than a description of the actual PGP mechanism, and the CPE strings confirm the affected platform is Red Hat OpenShift Container Platform 4. Consistent with the independent assessment, the weakness yields no confidentiality or availability impact (C:N/A:N) and a high integrity impact (I:H), with the high attack complexity reflecting the on-path requirement.
Know when Red Hat Openshift Container Platform 4 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
AC:H for the required MITM position; PR:N/UI:N as no oc-mirror auth or interaction is needed; primary impact is integrity (forged payload), so I:H with C:N/A:N - I dispute Red Hat's C:H as downstream, not direct.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in openshift/oc-mirror. The tool incorrectly verifies PGP (Pretty Good Privacy) release image signatures by checking for signature errors before the entire signed body is processed, leading to a bypass of the signature verification. A remote attacker, by intercepting or manipulating network traffic to the signature endpoint, could exploit this to craft a PGP message with a valid Red Hat release key ID but a forged signature. This enables the oc-mirror tool to accept and mirror a malicious release payload into a disconnected registry, potentially compromising the integrity of software deployments.
Executive ViewAI
Red Hat's openshift/oc-mirror utility, used to populate disconnected OpenShift 4 registries, contains a high-severity signature-verification bypass that can allow a forged release payload to be accepted and mirrored for downstream clusters to trust. Organizations relying on oc-mirror for air-gapped or restricted-network OpenShift deployments are affected, and leadership should care because a compromised mirror can inject unverified content into the software supply chain. Exploitation is unauthenticated but requires an attacker to already hold a man-in-the-middle position on the network path while a mirror operation is running, and no public exploit identified at time of analysis.
No vendor-released patch identified at time of analysis. Interim mitigations include performing mirror operations only over trusted, segmented networks or authenticated TLS tunnels to prevent on-path manipulation, manually verifying release signatures and digests out-of-band against Red Hat's published metadata before importing into the disconnected registry, restricting access to the release-signature endpoint, and auditing previously mirrored payloads for integrity.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
Remote code execution in Samba's printing subsystem allows remote attackers to inject arbitrary shell commands via craft
Elevated-privilege container restoration in CRI-O 1.34 and later, including downstream Red Hat OpenShift Container Platf
The system CA trust store shipped in Red Hat's ca-certificates RPM packages includes eMudhra root authorities that signe
Privilege escalation in Red Hat Advanced Cluster Management's multicloud-operators-subscription controller lets a low-pr
Remote code execution in libarchive on 32-bit systems allows unauthenticated attackers to execute arbitrary code via spe
Unauthenticated path traversal in gvproxy, the network forwarder shipped in the gvisor-tap-vsock package (used by Podman
Out-of-bounds read in the GnuTLS DTLS handshake reassembly logic lets remote unauthenticated attackers trigger an intege
Local privilege escalation in Performance Co-Pilot (PCP) on Red Hat Enterprise Linux 6 through 10 and OpenShift Containe
Local-to-domain-wide root privilege escalation in SSSD's LDAP sudo provider allows an authenticated LDAP directory user
Symlink-following file overwrite on the Ansible control node is possible in ansible-core when a user runs `ansible-galax
A use-after-free race condition in QEMU's 9pfs (virtfs) passthrough subsystem allows a malicious guest user to escape th
Privilege escalation in Red Hat OpenShift Container Platform 4's insights-runtime-extractor DaemonSet lets an authentica
EUVD-2026-83918
GHSA-vhqx-cfmx-mjq9
NVD
CVE.org
EPSS
Exploit-DB