Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local access to deployment staging
-
DeliveryStage unsigned OS image under permissive policy
-
ExploitSignature policy hardened to reject unsigned images
-
ExecutionStaged deployment finalized without revalidation
-
ImpactReboot boots unsigned content, full host compromise
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | Exploitation requires an image-mode bootc/ostree host where a deployment was staged while the container signature policy was permissive enough to accept unsigned (or non-conforming) images, followed by hardening of that policy to reject unsigned images before the staged deployment is finalized and the host reboots; the staged unsigned content is then finalized and booted without being revalidated against the new, stricter policy. Limiting factors that reduce real-world risk: local access is needed (AV:L), the attack is high-complexity (AC:H) because it depends on the specific timing/ordering of staging relative to the policy change, it applies only to bootc/ostree image-mode deployments (RHEL 8/9/10 image mode, OpenShift Container Platform 4, Red Hat Hardened Images), and realistically requires the ability to stage deployments, i.e. operator/local privilege despite the vendor's PR:N rating. |
| Impact | This is a signature-verification bypass (CWE-345) in bootc/ostree where a deployment staged while the container signature policy was permissive is finalized on reboot without re-checking it against the now-hardened policy, allowing unsigned OS content to boot and yield full host compromise (C:H/I:H/A:H). The CVSS 3.1 vector (7.4, AV:L/AC:H/PR:N/UI:N) describes a local, high-complexity, scope-unchanged issue, and the high complexity plus local vector already temper the otherwise severe impact. There is a notable internal tension: the vector lists PR:N, yet the described scenario requires an actor to have already staged a deployment and depends on a specific administrative sequence (permissive policy → stage unsigned content → harden policy → reboot), which in practice implies local privileged/operational access rather than a true zero-privilege attack - verify the privilege assumption with Red Hat. No EPSS score, KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis; combined with AC:H and the required policy-transition timing, real-world exploitation is a conditional/operational race rather than a mass-exploitable remote bug. Net: a legitimately high-impact integrity flaw worth patching on image-mode hosts, but its real priority is bounded by local access, high attack complexity, and the specific precondition that unsigned content was staged under a prior permissive policy. |
| Exploit ScenarioDerived | An operator (or an actor with local access to the host's staging workflow) stages an unsigned or improperly signed bootc/ostree container image while the container signature policy still permits unsigned content. The signature policy is subsequently hardened to reject unsigned images, but because the already-staged deployment is finalized without revalidation, the unsigned OS content remains bootable and executes on the next reboot, giving the attacker control of the booted host. No public exploit code is identified at time of analysis, and the high attack complexity reflects the required ordering of staging and policy changes. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 19, 2026
Signature-verification bypass in bootc and ostree image-mode deployments: a deployment staged while the container signature policy still accepted unsigned content remains bootable after the policy is hardened, because already-staged deployments are finalized on reboot without being revalidated against the current policy. An attacker who can stage a deployment under a permissive policy can therefore get unsigned OS content finalized and booted later, yielding full host compromise (C:H/I:H/A:H); the assessed vector is AV:L/AC:H with operator/local privilege (PR:L) despite the vendor's PR:N rating, and the flaw affects RHEL 8/9/10 image mode, OpenShift Container Platform 4, and Red Hat Hardened Images. No public exploit code was identified at time of analysis and there is no confirmed active exploitation (not in CISA KEV).
RemediationAI
No vendor-released patch version is identified in the available data - track the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-16460 and the tracking bug https://bugzilla.redhat.com/show_bug.cgi?id=2503167 for fixed bootc/ostree/rpm-ostree builds per RHEL stream and update the host image (bootc upgrade / rpm-ostree update) once they are published. Until then, compensating controls: before hardening a signature policy, do not leave previously staged deployments pending - discard staged-but-not-booted deployments (e.g. remove pending ostree/bootc deployments and reboot into the currently running, known-good deployment) so the next finalization revalidates against the hardened policy, accepting the operational cost of skipping a planned upgrade; and verify the currently booted deployment's image digest against the hardened policy manually before rebooting rather than relying on prior validation. Second, restrict who can stage deployments (sudo/polkit rights for bootc switch/upgrade and rpm-ostree deploy) to trusted operators, since the flaw requires that capability - this narrows the threat to privileged insiders and compromised operator accounts. Third, pin and audit the containers signature policy file for drift, with alerting on transitions from permissive to strict settings, so hardening events trigger an explicit revalidation cycle; this adds administrative overhead but closes the grandfathering window. Note that simply tightening the policy is not sufficient by itself, because the flaw is precisely the failure to re-check already-staged content.
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
bootc and ostree provide image-mode (immutable, container-image-based) operating system deployments on RHEL and related Red Hat products: the OS is shipped as a container image, staged locally as a new deployment, and finalized at the next reboot through the bootloader. Container signature policy (sigstore/skopeo-style policy in containers-policy.json) is intended to guarantee that only signed, trusted OS images are booted. The root cause is CWE-345 (insufficient verification of data authenticity): signature validation happens at staging time, but the finalization path trusts the cached deployment and does not re-evaluate the image reference against the policy in force at boot. Consequently a deployment staged under a permissive policy is grandfathered in after hardening, so unsigned or non-conforming content - potentially an attacker-controlled image with a modified kernel, initramfs, or systemd units - becomes the running root filesystem. The issue is a policy-timing/ordering flaw rather than a cryptographic break; it is specific to image-mode hosts (CPE entries cover RHEL 8, 9, and 10, OpenShift Container Platform 4, and Red Hat Hardened Images) and requires the ability to stage deployments, which is an operator-level capability, with high complexity due to the dependence on the exact ordering of staging relative to the policy change.
Know when Red Hat Enterprise Linux 10 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:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Local image-mode workflow (AV:L); depends on a specific staging-then-policy-hardening ordering (AC:H); staging unsigned content requires operator access, so PR:L rather than PR:N; booting attacker content fully compromises the host (C/I/A:H).
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-16460 undermines the signature-integrity guarantee on Red Hat's image-mode operating system stack - bootc/ostree deployments on RHEL 8, 9, and 10 image mode, OpenShift Container Platform 4, and Red Hat Hardened Images - because a deployment staged while signature enforcement was permissive can still be finalized and booted after the policy is hardened. In practice this means leadership cannot assume that tightening a signing policy retroactively protects already-staged hosts: an actor holding local operator privileges could get unsigned OS content running on production servers and container-platform nodes, yielding full host compromise. No public exploit code or confirmed active exploitation was identified at time of analysis, but the impacted systems are typically the control plane and fleet baseline, so the integrity of the entire estate depends on closing the gap.
No vendor-released patch identified at time of analysis; interim mitigations: enforce the hardened signature policy before any staging occurs, purge and re-stage every deployment created under a permissive policy, restrict staging and finalization privileges to a minimal audited operator group, verify booted images against signature attestation after each reboot, and monitor for signature-policy changes and anomalous staging activity.
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
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)CVE.org
More in Red Hat Enterprise Linux 10
View allHeap corruption via double-free in 389-ds-base's LDAP control parsing allows an unauthenticated remote attacker to crash
Remote code execution in Cockpit's web interface allows unauthenticated attackers to execute arbitrary commands on the h
Remote code execution in Samba's printing subsystem allows remote attackers to inject arbitrary shell commands via craft
Ghostscript can execute arbitrary shell commands with the privileges of its process when it renders a crafted PostScript
Use-after-free in librsvg during rendering of crafted SVG documents with nested XInclude directives and duplicate entity
A signed integer overflow vulnerability exists in the libtiff library's putcontig8bitYCbCr44tile function that leads to
The system CA trust store shipped in Red Hat's ca-certificates RPM packages includes eMudhra root authorities that signe
Authentication bypass in 389 Directory Server (shipped as Red Hat Directory Server 11-13 and within RHEL 6-10) lets remo
Remote code execution and privilege escalation in HPLIP (HP Linux Imaging and Printing) affects the hpcups print filter
Unauthenticated privilege escalation in FreeIPA (Red Hat Identity Management) allows a remote attacker to gain genuine a
A heap buffer overflow exists in libsoup's WebSocket permessage-deflate compression path: when a very large outbound mes
Remote code execution in libarchive on 32-bit systems allows unauthenticated attackers to execute arbitrary code via spe
EUVD-2026-104093
GHSA-72gj-m9xp-j6qc
NVD
CVE.org
EPSS
Vulnrichment
VulDB
Exploit-DB