DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

oc-mirror CVE-2026-75939: A Signature Check That Runs in the Wrong Order

#openshift #supplychain #pgp #disconnected

oc-mirror CVE-2026-75939: A Signature Check That Runs in the Wrong Order

Red Hat disclosed CVE-2026-75939 on 21 September 2026 with a CVSS v3.1 score of 7.4. The affected component is openshift4/oc-mirror-plugin-rhel9 in Red Hat OpenShift Container Platform 4. The tool that syncs release images, operator catalogs and related content into a private registry can be made to accept a forged PGP message, and the defect is one of ordering.

The logic error

According to the vendor advisory, oc-mirror has a validation order defect when processing PGP-signed release images. The tool performs the signature error check before it has finished processing the full signed message body. A forged PGP message that carries a legitimate Red Hat release key id can therefore be judged trustworthy, because the check is completed on incomplete input.

What an attacker needs and gains

Exploitation requires the ability to intercept or modify traffic between an affected oc-mirror instance and the signature endpoints. No prior privileges are needed and no user interaction is required, and the impact on confidentiality and integrity is rated high, with no availability impact. The attack complexity is high for that reason: the traffic manipulation has to succeed.
If it does, the tool syncs a malicious release payload into the private registry of a disconnected environment. Disconnected and air-gapped estates treat registry content as reviewed software, which is what makes the outcome a supply-chain problem rather than a single-host compromise. Once the payload is in the registry, an administrator or an automated installation pipeline can select it and deploy it, after which the cluster faces unauthorized code execution, application tampering, credential theft and unauthorized access to sensitive data.

Scope detail worth noting

The RHEL 8 variant of the plugin is not affected because the component does not exist in that release. Older packages in supported minor product branches inherit the flaw unless the advisory marks them as unaffected. Red Hat stated that at disclosure there was no practical mitigation that met its deployment and stability standards.

Practical mitigation

  1. Restrict network access from oc-mirror hosts to the signature endpoints, and be deliberate about deploying TLS inspection, since the same interception capability is what the flaw requires.
  2. Monitor private registries for unexpected changes to synced content.
  3. Verify release image digests through an independent trusted channel before promoting anything to production.
  4. Review access control on the private registry and audit what has been synced recently.
  5. Track the Red Hat security advisory channel for the fixed package.

References

Top comments (0)