GHSA-862g-9h5m-m3qv
MEDIUMcoreos-installer < 0.10.0 writes world-readable Ignition config to installed system
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
coreos-installerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Impact
On systems installed with coreos-installer before 0.10.0, the user-provided Ignition config was written to /boot/ignition/config.ign with world-readable permissions, granting unprivileged users access to any secrets included in the config.
Default configurations of Fedora CoreOS and RHEL CoreOS do not include any unprivileged user accounts. In addition, instances launched from a cloud image, and systems provisioned with the ignition.config.url kernel argument, do not use the config.ign file and are unaffected.
Patches
coreos-installer 0.10.0 and later writes the Ignition config with restricted permissions.
Workarounds
On Fedora CoreOS systems installed from version 34.20210711.3.0 (stable), 34.20210711.2.0 (testing), 34.20210711.1.1 (next) and later, the /boot/ignition directory and its contents are removed after provisioning is complete. All Fedora CoreOS systems that have updated to these versions or later have automatically removed the /boot/ignition directory and no action is required.
On other systems, /boot/ignition/config.ign can be removed manually, as it is not used after provisioning is complete:
sudo mount -o remount,rw /boot
sudo rm -rf /boot/ignition
References
For more information, see https://github.com/coreos/fedora-coreos-tracker/issues/889.
For more information
If you have any questions or comments about this advisory, open an issue in coreos-installer or email the CoreOS development mailing list.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | coreos-installer | all versions | 0.10.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for coreos-installer. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update coreos-installer to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-862g-9h5m-m3qv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-862g-9h5m-m3qv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-862g-9h5m-m3qv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-862g-9h5m-m3qv in your dependencies?
O3 detects GHSA-862g-9h5m-m3qv across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.