speed47/spectre-meltdown-checker: auditing CPU vulnerability mitigations on Linux and BSD

What the script answers that a CVE feed cannot

A vendor advisory tells you a CPU family is affected. It does not tell you whether the machine in front of you has the microcode, the kernel build and the boot parameters that close the hole. That gap is the entire reason this project exists. The README describes it as "a self-contained shell script to assess your system's resilience against the several transient execution CVEs that were published since early 2018, and give you guidance as to how to mitigate them."

The audience is narrow and specific. Fleet operators who inherit hardware and need to know which hosts are still exposed. Distribution maintainers and kernel developers checking that a mitigation patch actually reports as active. Anyone who has ever read a security bulletin, applied every update their package manager offered, and still could not say whether the machine was fixed. The script reads state from the running system instead of from a database keyed on model numbers, which is why it can distinguish a patched host from an unpatched one of the same SKU.

The CVE table in the README runs from Spectre V1 through much newer entries such as CVE-2025-54505, an AMD Zen1 floating-point divider stale data leak. It also tracks ARM64 silicon errata that have no assigned CVE, selectable with --errata and the associated --variant mnemonic, covering cores from Cortex-A55 through Neoverse-V3AE. That breadth is the point: the same command answers questions about a 2018 Intel laptop and a current ARM server.

How the checker reaches a verdict

The repository is one file, spectre-meltdown-checker.sh, plus packaging. There is no daemon, no agent and no database. The script runs, inspects the host, prints findings and exits.

The inputs it can read are visible in the Dockerfile's package list and the compose file's mounts. The image installs kmod, binutils, grep, perl, zstd, sqlite, procps, coreutils, iucode-tool and several compression tools. iucode-tool and /dev/cpu are there to read CPU microcode state; /lib/modules and /boot are mounted read-only so the script can inspect the kernel image and boot configuration; sqlite suggests it queries a local database, most likely the microcode data files a distribution ships rather than a remote service. The compose file sets network_mode: none, so whatever the checker concludes, it concludes offline.

That offline design is a deliberate constraint. A host with no route to the internet can still be audited, and the tool cannot phone home with a hardware inventory. The trade-off is freshness: the script knows about the CVEs baked into the release you are running, so a vulnerability announced after your copy was built will not appear until you update the script itself. The release cadence visible in the repository (v26.33.0420460, v26.36.0602723, v26.36.0913490) suggests the maintainer updates it as new CVEs land, but the currency of your verdict is your responsibility.

The README's risk table is the interpretive layer. It maps each CVE to attack directions (userland to kernel, userland to userland, VM to host, VM to VM) and to a mitigation. Note the directionality: Meltdown shows as exploitable userland to kernel but not userland to userland, while Variant 4 is the reverse. A report that says "mitigated" without you knowing which direction it means is not actionable, and the table is where that context lives.

Installing and running the checker on Linux

The repository is the distribution channel. Clone it, or download the single script, and run it. The README does not document a package-manager install step, and no published tarball URL appears in the repository, so treat the git checkout as the supported path.

git clone https://github.com/speed47/spectre-meltdown-checker.git
cd spectre-meltdown-checker
sudo ./spectre-meltdown-checker.sh

The script needs root because it reads microcode state and kernel image data. Without sudo it will report on what it can reach and skip the rest. Expect a per-CVE block: the CVE identifier, the aliases (Spectre V2, ZombieLoad, Downfall and so on), a status line, and a mitigation hint drawn from the same table the README publishes.

If you would rather not run a script from a checkout on the host, the repository includes a Docker path with the mounts already configured. The compose file defines a single service named spectre-meltdown-checker, so bring it up with:

docker compose up

The compose file builds from the local Dockerfile, tags the image spectre-meltdown-checker:latest, runs privileged, disables networking and mounts /boot, /dev/cpu and /lib/modules read-only. Privileged mode is required for the CPU and microcode reads; the read-only mounts are what keep the container from touching the host's boot files. Because the image is built from the checkout, the container's CVE knowledge is exactly as current as the commit you cloned. Rebuild after pulling to pick up new entries.

Where the verdict is thinner than it looks

A green status does not mean the machine is safe. It means the specific mechanism the script can observe is present. Several of the README's own mitigation entries are conditional in ways a status line cannot fully express.

Look at the mitigation column. Spectre V1's entry reads "Recompile everything with LFENCE." That is not a kernel setting the script can verify. It is a property of every binary on the system, and a host can have a fully patched kernel while running userland code compiled without the barrier. The checker can tell you the kernel side; it cannot audit your application builds. Treat any Spectre V1 result as a statement about the kernel, not about your software supply chain.

Spectre V2 is similar. The mitigation is "Microcode + kernel update (or retpoline)," and the parenthetical matters. A host using retpoline rather than hardware-assisted mitigation is in a different security posture, and the difference is a kernel configuration choice, not a pass or fail. Read the detailed output rather than the headline.

The VM columns are the other soft spot. CVE-2018-12207 (iTLB Multihit) is marked as a host-level concern with the mitigation "Hypervisor update (or disable hugepages)." If you are running the checker inside a guest, the host's hypervisor state is outside its reach. A guest reporting mitigated tells you nothing about whether the host is. Run it on the hypervisor, not only inside the VMs.

Finally, the tool is diagnostic, not detective. It reports configuration state. It does not detect an attack in progress, does not monitor for exploitation attempts, and has no runtime component. If you need detection, this is the wrong tool and you should stop looking at it for that purpose.

How this differs from InSpectre and vendor tools

InSpectre, which appears in the related searches for this project, is a Windows utility from GRC that reports Spectre and Meltdown mitigation status on Windows. The approach is comparable in spirit, but the platform coverage is the dividing line. This project targets Linux and BSD. The README's CVE table, the Alpine-based Dockerfile and the /boot and /lib/modules mounts all assume a Unix-like host. If your fleet is Windows, InSpectre is the tool for the job and this one is not, regardless of how the search results interleave them.

The other difference is the surface area of what gets checked. A Windows utility typically reports the two original vulnerabilities plus the OS-level mitigations Microsoft shipped. This project's README enumerates roughly thirty CVEs and errata, including entries from 2024 and 2025 and ARM64 errata with no CVE at all. That is a much wider net, and it reflects the fact that transient execution research did not stop in 2018.

The trade-off runs the other way too. A vendor tool ships with the vendor's knowledge of the vendor's platform and is updated through the vendor's channel. This script is maintained by a single project, and its coverage of any given CVE depends on that project having added it. The README is the honest artifact here: if a CVE is not in the table, the script does not know about it. Check the table before you assume a clean report means comprehensive coverage.

Maintenance, licensing and what the repository does not say

The last push to the default branch was on 2026-09-13, and the most recent release, v26.36.0913490, carries the same timestamp. The prior releases were v26.36.0602723 on 2026-06-02 and v26.33.0420460 on 2026-04-20. That is a release roughly every six to eight weeks across the visible window, which is consistent with a project that adds entries as new CVEs are published. The repository is not archived.

Upgrade cost is low by design. The script is one file. Pulling a new release means replacing that file, or rebuilding the Docker image from the updated checkout. There is no migration, no schema, no configuration to carry forward. If you have wrapped the script in your own automation, the risk is output-format drift between releases rather than a breaking API change; the repository does not document a stability guarantee for the output format, so parse defensively.

The licence is listed as unknown in the repository metadata. No licence file or SPDX identifier appears in the top-level repository entries, and the README does not state terms. If you intend to redistribute the script, bundle it into a product, or run it as part of a commercial compliance workflow, resolve that question with the maintainer before you rely on it. This is not legal advice; it is a statement that the terms are not visible in what the repository publishes.

One more gap worth naming: the README does not document a rollback path for the mitigations it recommends. It tells you what is missing and what generally fixes it. It does not tell you how to revert a microcode update or a kernel parameter if a mitigation costs more performance than you can accept. That work is yours.

Editorial conclusion

Run it first on any Linux or BSD host whose CPU vulnerability posture you cannot state from memory, and read the per-CVE status lines rather than the summary count. Do not treat it as a detection tool for live exploitation, and do not run it expecting coverage of Windows or Android: the repository ships a shell script plus a Dockerfile, and the README's CVE table is the authoritative list of what it knows about. Before you build policy on the output, verify three things on your own hardware: that the microcode revision the script reads matches the one your vendor shipped, that the kernel command line it parsed is the one actually used at boot, and that any CVE reported as mitigated is also listed as mitigated for the attack direction you care about in the README's risk table.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. speed47/spectre-meltdown-checker on GitHub