When rebuilding an operator catalog cache, oc-mirror v1's processCatalogRefs() (https://github.com/openshift/oc-mirror/blob/main/v1/pkg/cli/mirror/catalog_images.go#L312) function executes an opm binary extracted from a remote catalog image without any integrity verification.

The copyOPMBinary() function (https://github.com/openshift/oc-mirror/blob/main/v1/pkg/cli/mirror/catalog_images.go#L591-L640) reads the catalog image's ENTRYPOINT (L600) or CMD (L604-606) to locate the opm binary path, extracts it from the image layers via extractCatalog() (L613), and copies it to the workspace bin/ directory. In processCatalogRefs(), when withCacheRegeneration (L333) is true, this binary is set as opmCmdPath = filepath.Join(artifactDir, config.OpmBinDir, "opm") (L361) and executed directly via exec.Command(opmCmdPath, "serve", ...) (L376) on the operator's workstation. There is no signature verification, no digest check, and no integrity validation of the binary before execution.

A malicious operator catalog image can supply an arbitrary executable as its opm binary. When an administrator mirrors this catalog with --build-catalog-cache, the attacker-controlled binary is executed with the privileges of the user running oc-mirror.

This vulnerability is independent of the path traversal issue tracked as CVE-2026-101295. The CWE-22 fix (sanitizeArchivePath) does not mitigate this issue — the opm binary is extracted to a valid, sanitized path within the workspace and then executed without integrity checks.

The OPM_BINARY environment variable (L358-359), if set, causes oc-mirror to use a trusted local binary instead of the extracted one, fully mitigating this issue.

oc-mirror v2 does not execute extracted binaries and is not affected. v1 is deprecated since OCP 4.18 but still shipped and functional.