go package report

Is github.com/coreos/ignition safe?

1 known vulnerability, worst severity MODERATE.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so go packages are not covered.


      cvss
      0.0
      medium

      severity band, no base score published

      epss
      0.00%
      medium

      chance of exploitation in 30 days, 69th percentile of all CVEs

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — GHSA-hj57-j5cw-2mwp, the advisory selected below

      // 1 advisories

      GHSA-hj57-j5cw-2mwp

      MODERATECVE-2022-1706
      // impact

      Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information.

      // patches

      Ignition 2.14.0 and later adds a new systemd service, ignition-delete-config.service, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor.

      If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking ignition-delete-config.service. For example:

      {
        "ignition": {
          "version": "3.0.0"
        },
        "systemd": {
          "units": [
            {
              "name": "ignition-delete-config.service",
              "mask": true
            }
          ]
        }
      }
      // workarounds

      Avoid storing secrets in Ignition configs. In addition to VMware, many cloud platforms allow unprivileged software in a VM to retrieve the Ignition config from a networked cloud metadata service. While platform-specific mitigation is possible, such as firewall rules that prevent access to the metadata service, it's best to store secrets in a dedicated platform such as Hashicorp Vault.

      // advice to linux distributions

      Linux distributions that ship Ignition should ensure the new ignition-delete-config.service is installed and enabled by default.

      In addition, we recommend shipping a service similar to ignition-delete-config.service that runs when existing machines are upgraded, similar to the one in https://github.com/coreos/fedora-coreos-config/pull/1738. Consider giving your users advance notice of this change, and providing instructions for masking ignition-delete-config.service on existing nodes if users have tooling that requires the Ignition config to remain accessible in VM metadata.

      // references

      For more information, see #1300 and #1350.

      // for more information

      If you have any questions or comments about this advisory, open an issue in Ignition or email the CoreOS development mailing list.

      // cvss v3.1 vector

      CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

      Attack vector
      Network
      Attack complexity
      Low
      Privileges required
      Low
      User interaction
      None
      Scope
      Unchanged
      Confidentiality
      High
      Integrity
      None
      Availability
      None

      Checked 2026-09-28 at 19:45 UTC. The most recent advisory here was published 2022-05-25. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.