Fedora CoreOS is designed for security and reliability, especially for running containerized workloads. It offers ways to lock down boot access using the GRUB bootloader password feature, and administrators can enable this using a special configuration file called Butane. In theory, this setup should prevent anyone with physical or console access from tampering with the system at boot, such as selecting non-default boot entries, editing kernel parameters, or diving into the GRUB command line.

However, CVE-2022-3675 revealed a serious flaw: due to a misconfiguration, recent Fedora CoreOS releases allow anyone at the console to select and boot old, non-default OS deployment entries from the GRUB menu—without needing the password. This opens a door to downgrade attacks, where an attacker could revert the system to an older, less secure state, bypassing recent updates or patches. Let’s break down what happened, how it works, and what you can do.

You can set up the password like this via a Butane config

variant: fcos
version: 1.4.
storage:
  files:
    - path: /etc/coreos/boot_settings.json
      contents:
        inline: |
          {
            "grub_password": "$6$rounds=4096$mysalt$abcdefghijk..."
          }

Reference

- Fedora Docs: Bootloader Password

The Vulnerability: Password Prompt Skipped for Downgrades

CVE-2022-3675 exposes a gap in this control. Due to a misapplied GRUB configuration, the system *does* ask for the password when editing kernel arguments or accessing the command line—but it does _not_ require a password to boot into older, non-default OSTree deployments from the boot menu.

This means anyone with physical or virtual console access (for example, on a cloud VM or in a data center) could:

Boot into the earlier state, *including* vulnerable versions

As a result, attackers could work around patches or configuration changes, regaining control or exposing the system until the next update.

Why It Happened

When building the GRUB configuration, Fedora CoreOS was supposed to tag all boot entries *except* the default with a password requirement. Instead, it only applied the password protection to certain actions (like editing), but not to non-default deployment entries.

Relevant GRUB Snippet (for illustration, not actual code)

menuentry "Fedora CoreOS (current)" { ... }
menuentry "Fedora CoreOS (rollback)" { 
    # Should require password, but does not!
}

The intention was to use the --users directive in the GRUB config for all entries other than the default, like so:

menuentry "Previous OS" --users root {
    # Should prompt for password
}

Hit <Enter> to boot. No password is requested!

5. The system starts with the older OS version, which may be missing recent security fixes or configurations.

Impact

- Potential to rollback to a state with vulnerability or misconfiguration (re-enabling default root passwords, outdated software, lacking security hardening, etc.)

Attackers could use this to bypass emergency mitigations or controls applied after an incident.

- Systems relying on bootloader password for update/rollback control are specifically at risk.

Mitigations & Fix

The Fedora CoreOS team addressed this by updating the logic which generates the GRUB configuration, ensuring that all non-default deployments are now protected by the bootloader password.

Update to the latest Fedora CoreOS release.

- Verify after updates that ALL boot entries (not just the default/current) require a password for selection. You can do this by rebooting and checking each entry.
- If you’re managing multiple hosts, consider hardening console access, and monitoring for unexpected downgrade boots.

Red Hat Security Advisory:

RHSA-2022:748 coreos: grub2: bootloader password not required for non-default OSTree deployments

Fedora CoreOS CVE Tracker:

CVE-2022-3675 at Fedora CoreOS GitHub

GRUB Authentication Manual:

GNU GRUB Security Features

Conclusion

CVE-2022-3675 serves as a crucial reminder: when securing your system with bootloader passwords, it's vital to confirm that rollback and downgrade paths are locked as tightly as the main options. Even robust security controls can be undermined by subtle misconfigurations.

Make sure you update your Fedora CoreOS nodes, double-check your boot menus, and stay aware that physical/console access is always a major security boundary—defend it well.


*This post is an exclusive deep dive from the author to help admins and users better understand and protect against downgrade attacks in container-native OSes. All code and explanations are original and paraphrased in simple terms. For further information, follow the above links and stay tuned to Fedora CoreOS advisories.*

Timeline

Published on: 11/03/2022 18:15:00 UTC
Last modified on: 03/01/2023 18:04:00 UTC