CVE-2026-16460
Description
A flaw was found in bootc and ostree. Already-staged deployments are finalized without revalidating the deployment's container image against the current containers signature policy. Unsigned OS content staged under a prior permissive policy can remain bootable after policy is hardened to reject unsigned images, leading to full host compromise on reboot.
Statement
Container signature policy gates pull and import of bootc images, but does not revalidate content that is already staged for the next boot. Tightening /etc/containers/policy.json alone does not invalidate previously staged deployments; those deployments can still be finalized by ordinary reboot or by apply paths that unlock already-staged content. This issue is distinct from, and compositionally related to, the mutable-tag / default-policy. Systems that never stage unsigned content, or that clear staged deployments after hardening policy, are not exposed to this residual finalize path.
Mitigation
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
--- CME Mitigation Guidance (2026-10-20) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to revalidate container image signatures against active container signature policy before finalizing or booting staged ostree deployments in bootc and ostree: upgrade to the fixed Bootc/Ostree/Rpm Ostree/Rust Zincati builds, which revalidates container image signatures against the active container signature policy in /etc/containers/policy.json before finalizing or booting already-staged ostree deployments, closing all 2 injection vectors (host reboot into pending staged deployment, bootc upgrade --from-downloaded deployment application). Until patched, this is only a concern on Linux systems using bootc or ostree, including RHEL image-mode hosts — Non-Linux platforms are unaffected — so Clear all existing staged ostree deployments immediately after hardening /etc/containers/policy.json and ensure unsigned container images are never staged. As a compensating measure, Run SELinux in enforcing mode to confine processes running from finalized deployments to defined domains and Deploy IMA/EVM appraisal to verify executable file signatures at runtime and block untrusted binaries. These controls limit blast radius and contain exploitation, but they do not fix the underlying missing signature revalidation defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-712 Container Image Signing and Provenance Verification (Cosign/Sigstore) (high)
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.4 | N/A | 7.4 |
| Attack Vector | Local | N/A | Local |
| Attack Complexity | High | N/A | High |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | High | N/A | High |
Vector
Red Hat: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
cve.org: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Acknowledgements
Red Hat would like to thank Christopher Lusk (North Echo Security Research) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
