Rowhammer and Cold Boot: A Dated History of Attacks on DRAM

Two families of research broke the assumption that DRAM is a passive, trustworthy box. Cold boot attacks (USENIX Security 2008) showed memory keeps secrets for seconds to minutes after power loss. Rowhammer (ISCA 2014) showed that reading one row can flip bits in another. Neither is fully fixed in shipping hardware, so you mitigate in layers.

Below: the research history with dates and venues, from the 2008 cold boot paper to the 2025 Phoenix attack on DDR5; the mitigation track (ECC, target row refresh, refresh rate changes, DDR5 RFM and PRAC, memory encryption, software isolation) and what each one buys; and read only commands to see where your own machines stand.

Key takeaways

• Cold boot (2008) recovered disk encryption keys from DRAM after power was cut; chilled chips kept data for many minutes.
• Rowhammer (2014) caused bit flips in 110 of 129 DDR3 modules. Project Zero turned it into privilege escalation on 9 March 2015.
• Target row refresh (TRR) did not end it: TRRespass (2020), Blacksmith (2021) and Phoenix (2025, DDR5) all bypassed it.
• Half-Double (2021) showed flips two rows away from the hammered row.
• ECC raises the bar but has been bypassed; DDR5 on die ECC did not stop Phoenix.
• PRAC, added to DDR5 in April 2024, is the most principled fix so far, but Google said in September 2025 that current DDR5 systems lack it.
• Memory encryption addresses cold boot. Without integrity, Google sees no meaningful Rowhammer protection from it.
• Rowhammer is a hardware supply chain problem: the mitigations live in parts and firmware you buy, and software patches only narrow the paths.

A dated timeline of DRAM attacks and mitigations

Dates come from the papers, the research groups' project pages, Google's blogs and JEDEC's announcement. Where a source gives only a year or a conference, so does the table.

For the hardware history underneath this table, see Memory evolution: from core to DDR5, HBM and CXL.

What is Rowhammer, in plain terms?

DRAM stores each bit as a small charge in a capacitor. Charge leaks, so the memory controller refreshes every row on a schedule, typically within 64 milliseconds. To read any byte, the chip "activates" its whole row into a row buffer and then writes it back.

Rowhammer is what happens when one row is activated very many times inside a single refresh window. Each activation disturbs the electrically neighbouring rows a little. Do it often enough before those neighbours are refreshed and some of their cells flip from 1 to 0 or the reverse. The hammered row is the "aggressor"; the rows that flip are "victims".

The security problem is isolation. Operating systems and hypervisors assume that writing to your own memory cannot change anyone else's. Rowhammer breaks that below the level where any permission check runs. If a page table, a key or a security check sits in a victim row, one flipped bit can change who is allowed to do what.

Two facts shape everything that follows. The fault is physical, a side effect of packing smaller cells closer together, so it tends to worsen with density. And every mitigation is a race: refresh, pause or detect before enough activations pile up. Most defences are about counting activations cheaply, and attackers keep finding the gaps in the counting.

What did Kim et al. show in 2014, and on which DRAM?

The founding paper is "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors" by Yoongu Kim, Ross Daly, Jeremie Kim, Chris Fallin, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai and Onur Mutlu of Carnegie Mellon University and Intel Labs, presented at ISCA 2014.

• 129 DDR3 modules (972 chips) from three major manufacturers, tested on an FPGA platform.
• 110 modules (836 chips) had errors. Every module made in 2012 and 2013 was affected, pointing to a recent consequence of scaling.
• As few as 139 thousand accesses to an address caused an error, and up to one in 1.7 thousand cells was susceptible.
• Errors reproduced on real Intel (Sandy Bridge, Ivy Bridge, Haswell) and AMD (Piledriver) systems with a small user level program.
• Root cause: repeated toggling of a row's wordline accelerates charge leakage in nearby rows.

Two findings still frame the debate. The authors noted that SECDED ECC (single error correct, double error detect) is "not failsafe", because one hammered row can put several flips in the same word. And they proposed PARA (probabilistic adjacent row activation): each time a row opens, refresh its neighbours with a small probability. PARA needs no counters. The counter based designs the industry shipped instead became the next decade's target.

How did Project Zero turn bit flips into privilege escalation in 2015?

On 9 March 2015, Mark Seaborn, with contributions from Thomas Dullien, published "Exploiting the DRAM rowhammer bug to gain kernel privileges" on Google's Project Zero blog. It moved Rowhammer from a reliability curiosity to a security bug. At a conceptual level:

• Testing: 29 x86 laptops, all with non ECC memory; 15 showed bit flips. Desktops tested showed none, possibly because their ECC masked flips.
• Two exploits. One escaped the Native Client (NaCl) sandbox, whose code validator assumes the hardware behaves correctly. The other ran as an ordinary Linux process and flipped bits in its own page table entries until it gained read and write access to all physical memory.
• Mitigation was uneven. NaCl stopped allowing the cache flush instruction the exploit used. The Linux escalation, the authors wrote, was "harder to mitigate on existing machines."
• BIOS refresh changes slow it down. On one laptop, a BIOS update stretched time to first flip from under 5 minutes to about 40 minutes. Slower, not fixed.
• Standards were moving. LPDDR4 specified TRR and a Maximum Activate Count, without using the word Rowhammer.

The Linux kernel made a structural change you can still see in its documentation: since Linux 4.0, only processes with CAP_SYS_ADMIN can read physical frame numbers from /proc/PID/pagemap, and since 4.2 the field is zeroed for everyone else, because that information "helps in exploiting Rowhammer vulnerability."

Drammer: Rowhammer reaches phones (2016)

VUSec at Vrije Universiteit Amsterdam took Rowhammer to ARM. Drammer, presented at ACM CCS 2016 in Vienna, was described by its authors as the first Android root exploit relying on no software vulnerability, delivered by an app needing no permissions. It obtained predictable, physically contiguous memory through Android's own memory manager rather than cache flush instructions or pagemap.

The project page reports 27 devices tested for the paper, with bit flips on 18. Disclosure to Google began on 25 July 2016; Google told partners on 3 October and shipped a change in the November 2016 Android Security Bulletin (CVE-2016-6728). The researchers said the patch "complicates our attack" without eradicating it. That is the recurring shape of software fixes for Rowhammer: close the easiest route to controlling physical memory, leave the physics alone.

Why did target row refresh fail to stop it?

By the time DDR4 was widespread, the industry message was that in DRAM mitigations, broadly called Target Row Refresh, had solved the problem. TRR tracks rows being activated heavily and refreshes their neighbours early. The catch is in "tracks": a chip cannot afford a counter per row, so TRR samples or keeps a small table of suspects. Whatever is not tracked is not protected.

TRRespass (IEEE S&P 2020)

Pietro Frigo, Emanuele Vannacci and colleagues from VU Amsterdam, ETH Zurich and Qualcomm found that classic double sided hammering produced no flips on 42 recent DDR4 modules. Then they hammered many aggressor rows at once. Activate more rows than the tracker can follow, and some victims never get their early refresh.

Their fuzzer found TRR bypassing patterns on 13 of 42 DDR4 modules from all three major manufacturers, and on 5 of 13 phones. (The project page says 12 of 42 in its prose; the paper and the page's own results table list 13.) Disclosure was 10 March 2020, CVE-2020-10255, coordinated with the Dutch National Cyber Security Centre. Doubling the refresh rate did not stop all flips.

Blacksmith (November 2021, IEEE S&P 2022)

ETH Zurich's COMSEC group noticed that every earlier pattern hammered its aggressors uniformly. Blacksmith varied the order, regularity and intensity of activations, describing patterns by frequency, phase and amplitude. On 40 DDR4 devices, a 12 hour fuzzing run found flips on all 40, and the team measured how many flips were usable against three published targets (page table entries, an SSH host's RSA key, a sudo password check). Disclosure through the Swiss NCSC began in early 2021; Blacksmith went public on 15 November 2021 as CVE-2021-42114. Since DRAM in the field cannot be updated, the authors warned, it "will remain vulnerable for many years."

ZenHammer (March 2024) and the first DDR5 flips

ZenHammer, from the same group, reverse engineered address mapping on AMD Zen 2 and Zen 3 and found flips on 7 of 10 DDR4 devices on Zen 2 and 6 of 10 on Zen 3. On Zen 4 it tested ten DDR5 devices and triggered about 42 thousand flips on one, which the authors called the first public report of DDR5 flips on commodity systems. They read the nine clean devices as a need for better patterns, not proof of safety. AMD was told on 26 February 2024, disclosure followed on 25 March 2024, and the paper appeared at USENIX Security 2024.

Phoenix (September 2025): DDR5 in default settings

Phoenix, by ETH Zurich with Google, reverse engineered the enhanced in DRAM TRR on DDR5 modules from one major manufacturer. The mitigation's sampling repeats every 128 refresh intervals, and some intervals are barely sampled. Patterns that hammer in those blind spots, plus a self correcting way to stay in step with refreshes, flipped bits on all 15 modules tested. The team built what it describes as the first Rowhammer privilege escalation running in default settings on a DDR5 desktop, in as little as 109 seconds.

Disclosure ran from 6 June to 15 September 2025 (CVE-2025-6202). The researchers were told of a BIOS update for some client machines but could not verify it, and found that tripling the refresh rate stopped Phoenix on their systems.

What did Half-Double show about distance?

Until 2021 the working model was "distance one": hammer a row and only its immediate neighbours are at risk. On 25 May 2021, Google researchers Salman Qazi, Yoongu Kim, Nicolas Boichat, Eric Shiu and Mattias Nissler introduced Half-Double.

Given three consecutive rows A, B and C, they flipped bits in C by sending a very large number of activations to A and only a few dozen to B. The accesses to B appear to carry A's effect on to C. That is awkward for mitigations that refresh the immediate neighbours of a hammered row, because refreshing B is exactly the kind of access that helps.

Google called Half-Double "an intrinsic property of the underlying silicon substrate", not a blind spot in one vendor's logic, and a likely sign that coupling grows stronger and longer range as cells shrink. The post pointed to JEDEC's JEP300-1 and JEP301-1 mitigation documents and asked server, client, mobile, automotive and IoT makers to work on a fix together.

Does ECC stop Rowhammer?

No. It raises the bar and turns many attacks into detectable errors or crashes, but it does not stop a determined attacker.

• Side band ECC typically corrects one bit and detects two per word. Kim et al. warned in 2014 that hammering can put several flips in one word.
• ECCploit (VUSec, 2018) produced reliable flips that bypass ECC on server memory, against a common belief that ECC servers were safe.
• TRRespass, Blacksmith and ZenHammer each say ECC makes exploitation harder but cannot fully protect, given how many flips modern DDR4 produces.
• DDR5 on die ECC is a reliability feature inside each chip. Phoenix showed flips accumulating faster than it corrects them.
• Google's September 2025 post says current ECC schemes "were not designed as a security measure."

Still run ECC where you can. Correctable error counts are one of the few signals an operator can see, and a sudden rise on one DIMM deserves attention whatever the cause.

What do DDR5 RFM and PRAC do?

Both let the DRAM and the controller cooperate on counting activations, instead of leaving it all to undocumented logic inside the chip.

Refresh Management (RFM). DDR5 added an RFM command that gives the DRAM extra time for mitigative refreshes during heavy activity; the controller keeps per bank counters and issues RFM when a threshold is crossed. Per the Phoenix paper, RFM is optional, device specific and needs controller support, and prior work found the controllers in AMD Zen 4, Intel Alder Lake and Raptor Lake do not send it. A feature that is never invoked protects nothing.

Per Row Activation Counting (PRAC). JEDEC published JESD79-5C on 17 April 2024. PRAC "precisely counts DRAM activations on a wordline granularity", in JEDEC's words, and when a row is activated too often the DRAM alerts the system to pause traffic and make time to mitigate. JEDEC frames it as data integrity work. Google, which says it helped define PRAC, describes it as deterministic Rowhammer detection that tracks every row. The same release deprecated Partial Array Self Refresh, citing security concerns without detail.

The caveat is timing. In September 2025 Google wrote that current DDR5 systems lack PRAC support, which it expects in upcoming DDR5 and LPDDR6 versions. A DDR5 label tells you little; you need to know whether the specific DRAM and memory controller implement PRAC and whether firmware enables it.

Spec comparison: DRAM generations and Rowhammer findings

The pools, platforms and years differ, so read this as a trend, not a ranking. Nothing in it supports calling any generation immune.

Mitigations compared: what each control actually buys

What did cold boot show, and do modern memory encryption features close it?

Rowhammer corrupts memory; cold boot reads it. "Lest We Remember: Cold Boot Attacks on Encryption Keys", by J. Alex Halderman, Seth Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph Calandrino, Ariel Feldman, Jacob Appelbaum and Edward Felten, appeared at the 17th USENIX Security Symposium in 2008.

• DRAM contents decay over seconds even at normal operating temperature once power is cut.
• Cooling stretches that. Duster spray on the chips reached about minus 50 degrees Celsius, where fewer than 1 percent of bits decayed after 10 minutes unpowered. In liquid nitrogen, decay was 0.17 percent after an hour.
• Decay is predictable, so damaged key schedules can be repaired; the team reconstructed most 128 bit AES keys within seconds.
• They defeated widely used disk encryption products of the day, including those built into Windows and macOS, because keys stay in RAM while a disk is unlocked, including on sleeping or screen locked laptops.

Disk encryption protects a powered off disk. It does not protect a running or sleeping machine whose key sits in RAM, and power off is not an instant wipe.

Do memory encryption features close it?

Partly. The Linux kernel documentation describes AMD Secure Memory Encryption (SME) as encrypting pages when written to DRAM and decrypting them when read, and says it can protect DRAM contents from physical attacks. If someone chills and transplants the modules, they get ciphertext, because the key lives in the processor. Per-VM features (AMD SEV and SEV-SNP, and Intel TDX, which the kernel docs say uses Multi-Key Total Memory Encryption) extend this to guest memory.

Two limits. It only works if it is on: the same documentation says that if the BIOS does not enable SME, Linux cannot activate it even with mem_encrypt=on. And it does nothing for a running, unlocked machine, since anything the system can decrypt, an attacker who controls the system can read.

On laptops, the OS vendor's guidance is the practical answer. Microsoft's BitLocker countermeasures page says preboot authentication (TPM plus PIN) keeps keys out of memory until a user authenticates, which "helps mitigate DMA and memory remanence attacks." For high risk cases it recommends TPM plus PIN, disabling standby, and shutting down or hibernating before a device leaves an authorised user's control, and it describes the Memory Overwrite Request (MOR) bit as part of the platform's defences.

Memory encryption, preboot authentication and shutdown instead of sleep close most of the 2008 attack surface. None of them closes Rowhammer. See also CWE-1330: remanent data after memory erase.

Why Rowhammer is a hardware supply chain problem

Look at the last column of the mitigations table. Almost every control is set by someone other than the person running the workload:

• The DRAM maker decides cell geometry, TRR design and on die ECC, and has not documented TRR; researchers needed FPGA rigs to reverse engineer it.
• The CPU vendor decides whether the controller sends RFM, supports PRAC, or offers memory encryption with or without integrity.
• Platform firmware sets refresh rates and whether encryption and PRAC are enabled.
• You choose which parts and firmware to buy and install, and which features to turn on.

DRAM chips cannot be patched after production. Software can remove one route to precise physical memory control, as Linux did with pagemap and Android did after Drammer, or harden one sensitive structure. It cannot add counters to a chip. That makes Rowhammer exposure a property of your bill of materials, with the same questions you ask of software dependencies: which component, which version, which supplier, which known issues, which remediation path. See Hardware supply chain trust boundaries.

Software does carry some of it

Libraries that keep long lived secrets in memory can be hardened against fault injection, for example by verifying a cryptographic result before releasing it. NVD published CVE-2024-1545 on 29 August 2024, describing a Rowhammer fault injection weakness in the RSA decryption path of wolfSSL 5.6.6 usable by a co-resident attacker. That kind of issue is fixed the normal way: upgrade the library everywhere it ships. See CVE-2024-1545: wolfSSL RSA and Rowhammer.

What matters for cloud tenants versus laptop owners?

Cloud tenants cannot inspect DIMMs, so ask the provider in writing what memory protections the fleet uses and whether dedicated hosts are available for sensitive workloads. Confidential VMs address the operator side of the threat but, per Google's assessment, encryption without integrity does not remove Rowhammer risk. Keep long term secrets in hardware security modules or managed key services where you can.

Laptop owners face Rowhammer only from code already running on the machine, so updates and care about what you install carry most of the weight. Cold boot is the more practical laptop risk: use preboot authentication, and shut down or hibernate before a device leaves your hands.

How do you track which platforms in your fleet have which mitigations?

You cannot buy your way out with one SKU, but you can know what you have. Record per host model:

• CPU family and microcode version
• Memory type, module part numbers and manufacturer
• ECC: supported, enabled, reporting to the OS
• BIOS or UEFI version and any documented refresh or Rowhammer settings
• RFM and PRAC support if the platform vendor states it (often "unknown")
• Memory encryption: capable, enabled in firmware, active in the OS
• Laptop disk encryption protector (TPM only versus TPM plus PIN)
• Correctable error counts over time

Most of these do not change after deployment, so the work is the first pass and updates when firmware moves. Keep them next to your software inventory; CycloneDX supports hardware bills of materials if you want a standard format. See HBOM vs SBOM.

Step by step: see where your machines stand

Every command below is read only. Nothing here hammers memory, changes firmware or alters settings. Run them on hosts you own or administer.

1. Identify memory type and ECC (Linux)

# Memory array: shows "Error Correction Type"
sudo dmidecode -t 16 | grep -E "Error Correction Type|Maximum Capacity"

# Each module: type, speed, maker and part number
sudo dmidecode -t 17 | grep -E "^\s+(Type|Speed|Manufacturer|Part Number):" | sort | uniq -c

If the error correction type reads "None", the platform is not running side band ECC, whatever the modules support. DDR5 on die ECC does not show up here.

2. Check that ECC errors are reported (Linux)

The kernel's EDAC subsystem exposes counters under /sys/devices/system/edac, documented in the kernel RAS guide.

# Corrected (ce) and uncorrected (ue) counts per memory controller
grep -H . /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ue_count 2>/dev/null

# Per DIMM counts, if the driver supports them
grep -H . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count 2>/dev/null

# If rasdaemon is installed, a summary of logged errors
sudo ras-mc-ctl --error-count

No edac directory usually means no EDAC driver for your controller, so errors are not reaching you even if ECC is on.

3. Check memory encryption capability and status (Linux)

# CPU capability flags (capability only, not proof it is enabled)
grep -o -w -E "sme|sev|sev_es|sev_snp|tme" /proc/cpuinfo | sort -u

# What the kernel actually turned on at boot
sudo dmesg | grep -i -E "memory encryption|SME|SEV|TDX|TME"

# Kernel command line, to see whether mem_encrypt was requested
cat /proc/cmdline

4. Confirm the kernel hides physical addresses (Linux)

uname -r

Kernels from 4.2 on zero physical frame numbers in /proc/PID/pagemap for processes without CAP_SYS_ADMIN. A 3.x kernel still in service has bigger problems than Rowhammer.

5. Check laptop disk encryption protectors and sleep states (Windows)

In an elevated PowerShell or Command Prompt:

# Shows key protectors, for example "TPM" versus "TPM And PIN"
manage-bde -protectors -get C:

# Lists available sleep and hibernate states
powercfg /a

6. Record the result

A small JSON record per host model is enough to start:

{
  "host_model": "example-server-gen2",
  "cpu_family": "x86_64 vendor family and model",
  "bios_version": "2.14.1",
  "memory_type": "DDR5 RDIMM",
  "module_part_numbers": ["PART-NUMBER-A"],
  "ecc_side_band": "enabled",
  "edac_reporting": true,
  "refresh_setting": "vendor default",
  "rfm_supported": "unknown",
  "prac_supported": "unknown",
  "memory_encryption": "capable, enabled in firmware, active",
  "checked": "2026-10-23"
}

"Unknown" is an honest, useful value: it tells procurement which questions to put to the platform vendor at the next refresh.

Common mistakes

• Assuming DDR5 is immune. Phoenix flipped bits on every DDR5 module it tested from one manufacturer and built a working exploit.
• Treating ECC as a Rowhammer fix. It turns many attacks into detectable errors. ECCploit bypassed it.
• Reading a CPU flag as proof of protection. sme or tme in /proc/cpuinfo is capability. Check firmware and boot logs.
• Assuming PRAC is present because the standard exists. Google said in September 2025 that current DDR5 systems lack it.
• Counting on memory encryption to stop Rowhammer. It helps with cold boot; without integrity it does not help with Rowhammer.
• Leaving laptops asleep with TPM only disk encryption. Keys stay in RAM. Use preboot authentication and shut down for travel.
• Ignoring correctable error counts. They are cheap telemetry and the only Rowhammer adjacent signal most operators see.
• Skipping BIOS updates. Refresh and controller changes ship in firmware; Project Zero saw one update stretch time to first flip from minutes to about 40.
• Forgetting the software side. A library hardened against fault injection only helps once every bundled copy is upgraded.

FAQ

What is Rowhammer in simple terms?

Repeatedly activating one row of DRAM disturbs neighbouring rows enough to flip bits before they are refreshed. Attackers aim those flips at data they should not be able to touch, such as page tables or keys.

Who discovered Rowhammer?

Yoongu Kim and colleagues at Carnegie Mellon University and Intel Labs, in a paper at ISCA 2014. Google Project Zero published the first privilege escalation exploits on 9 March 2015.

Is DDR5 vulnerable to Rowhammer?

Yes. ZenHammer reported DDR5 flips in March 2024, and Phoenix (September 2025, CVE-2025-6202) flipped bits on 15 of 15 DDR5 modules from one manufacturer, with a privilege escalation in default settings.

Does ECC memory prevent Rowhammer?

No. It makes attacks harder and surfaces many flips as errors, but ECCploit bypassed it in 2018.

What is target row refresh (TRR)?

An in DRAM mitigation that tracks frequently activated rows and refreshes their neighbours early. Because it tracks only a few rows, TRRespass, Blacksmith and Phoenix found patterns that slip past it.

What is PRAC in DDR5?

Per Row Activation Counting, added in JEDEC's JESD79-5C on 17 April 2024. The DRAM counts activations per row and tells the host to pause and mitigate when a threshold is reached.

What is a cold boot attack?

Reading keys and other secrets out of DRAM after power is cut, relying on memory fading over seconds to minutes, longer when chilled. Halderman et al. demonstrated it at USENIX Security 2008.

Does memory encryption stop cold boot attacks?

It stops a moved or chilled module from revealing plaintext, if firmware enables it. It does not protect a running, unlocked machine.

Can a website trigger Rowhammer?

Research has, from JavaScript; Google's Half-Double post cites SMASH doing it without cache management instructions. Browser and OS updates narrowed those paths, but the hardware issue remains.

Where Safeguard fits, honestly

Safeguard does not test DRAM, read module data, configure refresh rates, check TRR or PRAC, scan firmware or generate hardware bills of materials. The hardware side of Rowhammer and cold boot is outside its scope. Where it does help is the software that carries Rowhammer related fixes: cryptographic libraries hardened against fault injection, like the wolfSSL issue above, and the OS and container images where tools such as rasdaemon live. Safeguard scans repositories, container images and SBOM files, matches components against vulnerability databases, and shows which projects contain a given component and version, so you can find every build still bundling an affected library version and move it forward.

Fix it without waiting for upstream

Rowhammer fixes in silicon come from DRAM and CPU vendors on hardware timelines, but the software around them moves on your schedule. Cryptographic libraries ship fault injection hardening as ordinary releases, and every rebuilt server image or laptop pulls those dependencies again, so the same patch discipline you apply to application code applies here.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

To try it on your own machine, download Safeguard from https://safeguard.sh/download and see the CLI documentation at https://docs.safeguard.sh/docs/cli .

See how Safeguard would help

The first demo sets up Safeguard's local runner on your own machine, approves it with a device code and runs a scan from the terminal. On a host where you build server images, the same flow shows which library versions, including cryptographic libraries, went into the image. It covers software only; it says nothing about the DIMMs.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same approve each step flow applies when a library ships fault injection hardening and you need to move a project to the fixed version.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. With that in place you can ask which projects still carry a particular library version while keeping control of what the assistant can touch.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Kim et al., Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors, ISCA 2014 (PDF)
• Google Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges, 9 March 2015
• VUSec: Drammer, Flip Feng Shui goes mobile
• VUSec: ECCploit, ECC memory vulnerable to Rowhammer attacks after all
• VUSec: TRRespass project page
• Frigo et al., TRRespass: Exploiting the Many Sides of Target Row Refresh, IEEE S&P 2020 (PDF)
• Google Security Blog: Introducing Half-Double, 25 May 2021
• ETH Zurich COMSEC: Blacksmith
• ETH Zurich COMSEC: ZenHammer
• ETH Zurich COMSEC: Phoenix, Rowhammer attacks on DDR5
• Phoenix: Rowhammer Attacks on DDR5 with Self-Correcting Synchronization, IEEE S&P 2026 (PDF)
• Google Security Blog: Supporting Rowhammer research to protect the DRAM ecosystem, 15 September 2025
• JEDEC JESD79-5C announcement, 17 April 2024, as republished by Silicon UK
• Halderman et al., Lest We Remember: Cold Boot Attacks on Encryption Keys, USENIX Security 2008 (PDF)
• Linux kernel documentation: AMD memory encryption
• Linux kernel documentation: Intel Trust Domain Extensions (TDX)
• Linux kernel documentation: Examining process page tables (pagemap)
• Linux kernel documentation: Reliability, Availability and Serviceability (RAS)
• Microsoft Learn: BitLocker countermeasures
• NVD: CVE-2024-1545

Last reviewed: 23 October 2026.