High priorityDisclosed

Advisory · CVE-2026-16487

Unsigned bootc image updates can install attacker content on RHEL image-mode hosts

Red Hat says bootc hosts using the default containers signature policy can apply unsigned content when a mutable image tag is updated, letting an attacker who can update that tag place arbitrary OS content that runs as the host root filesystem on reboot. CVSS 3.1 8.1.

Advisory published October 19, 2026Independent summary
Vendor
Red Hat
Product
bootc
Identifier / CWE
CVE-2026-16487
CWE-345
Action timing
Immediate
ELI5

Explain it like I’m five

The update system checks the name on the delivery tag but not the seal on the box. Anyone who can relabel the delivery can swap in their own box, and the host installs it as its own operating system at the next reboot.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Host follows a mutable tag

    A Red Hat Enterprise Linux image-mode host is enrolled to a mutable bootc image tag and uses a signature policy that permits unsigned content for that registry.

  2. 02Tag is updated

    An attacker who can update that tag points it at unsigned content they control.

  3. 03Unsigned content is applied

    An automatic or manual bootc upgrade falls through to insecureAcceptAnything for the registry and applies the unsigned content instead of rejecting it.

  4. 04Reboot runs attacker content

    On reboot the staged content runs as the host root filesystem, giving the attacker control of the operating system.

What happened

Red Hat disclosed CVE-2026-16487 on October 19, 2026, and rates it CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The flaw is in bootc when it operates with the default containers signature policy: automatic or manual upgrades of a mutable image tag may apply unsigned content for registries that fall through to insecureAcceptAnything. An attacker who can update that tag can have arbitrary OS content executed as the host root filesystem on reboot.

Per Red Hat, this affects Red Hat Enterprise Linux image-mode (bootc) hosts that are enrolled to a mutable image tag and use a containers signature policy that permits unsigned content for that registry, including the default insecureAcceptAnything fall-through for registries without explicit signed scopes. Hosts that only pull from registries with an enforced signature policy, or that pin updates to digests or a signed identity, are not affected by this specific chain. Red Hat also states that Red Hat OpenShift Container Platform 4 is not affected, because RHCOS updates are applied by the Machine Config Operator using digest-pinned images from the OpenShift release payload.

Red Hat notes that persistence of /var across a bootc rollback is expected platform behavior, not a separate flaw, but it matters here: attacker state kept in /var can survive a naive rollback. The Red Hat bulletin gives mitigation steps and does not state a fixed package version, so this advisory does not name one.

What to do

  1. Inventory Red Hat Enterprise Linux image-mode (bootc) hosts, and note which ones follow a mutable image tag and what signature policy each registry uses.
  2. Pin bootc updates to image digests, or configure /etc/containers/policy.json to reject unsigned content by default and allow only explicitly trusted signed scopes, following the Red Hat mitigation.
  3. Until the policy is hardened, disable automatic updates by stopping the bootc-fetch-apply-updates.timer, per Red Hat.
  4. Review registry and tag history for unexpected updates to tags your hosts follow, and check who can push or retag images in those registries.
  5. After a suspected malicious image, do not rely on bootc rollback alone: audit and remediate persistent /var, including /var/roothome, then re-enroll the host to a trusted signed image, per Red Hat.
  6. Confirm each host’s effective policy and pinned digest after the change, not just that a config file was edited.

Management note

This is a supply-chain trust failure in the operating system update path itself, scored high rather than critical because the attacker first needs the ability to update a tag your hosts follow. That precondition points at the real control: registry write access and signature policy are now part of your OS patching boundary. Harden the policy and pin digests before the next automatic update window, not after it.