No. Deleting a tag removes a label, not the image, and even deleting the image does not touch workloads that already pulled it. Running pods keep their layers, nodes cache images, mirrors hold copies, and anything referencing the digest may still work. Fix the exposure by redeploying patched workloads, then clean up the registry.
What deleting actually does
A tag points at a digest. Remove the tag and the digest may still exist and be pullable by digest, depending on the registry and its cleanup rules. Even if the registry deletes the content, three other places hold it.
- Running containers keep using the image they started with.
- Nodes cache layers. The Kubernetes documentation says the container runtime uses cached layers when they are already present, and that all pods can use any image cached on a node.
- Mirrors and pull-through caches hold copies that your registry deletion does not reach.
Why Kubernetes defaults matter
The same page explains that when a pull policy is not set and the image has a specific tag, the default is IfNotPresent, which makes the kubelet skip the pull when the image already exists. So a node that has the vulnerable image will keep serving it to new pods until the cache is cleared or the pod references a different image. If your deployments use a tag that you replaced, new pods on nodes with the old cached image may still start the old version.
That is one of the strongest arguments for referencing images by digest, since a new digest cannot be satisfied by an old cache.
The correct order
- Build the patched image and note its digest.
- Update the workload to reference the new digest and roll it out.
- Confirm no running pod still uses the old digest. See find which pods run a vulnerable image.
- Check mirrors, pull-through caches and base images of other services for the old digest.
- Only then block or delete the old image in the registry.
Deleting first can also cause harm: a pod that restarts after the image is gone may fail to start, turning a vulnerability into an outage.
Blocking instead of deleting
If you need to stop anyone from using the image right away, prefer a block over deletion. An admission rule that denies the digest prevents new pods while leaving the evidence in place. See should admission control block critical image vulnerabilities. Keep the image and its scan record for investigation and audit, then delete under your retention policy.
What about a compromised image
If the image itself was malicious, not just vulnerable, the order changes: block immediately, then investigate what ran. See is a supply chain incident over when the registry removes the package for why removal is not the end.
Checklist
| Check | Done when |
|---|---|
| New digest deployed | All workloads reference it |
| Old digest running anywhere | Query returns none |
| Mirrors and caches | Old digest purged or blocked |
| Registry | Old digest blocked, then removed on schedule |
| Evidence | Scan result and decision retained |
Where Safeguard fits
Safeguard keeps scan and SBOM records by image so you can answer which services contain a flawed package, and its policies and gates can stop that image from being promoted. Try a free scan.
Quick check
If I delete the image, do running pods stop?
No. They continue with the layers they already pulled. They may fail to restart if the image is needed again.
Why reference images by digest?
A digest names exact content, so a new digest cannot be satisfied by an old cached image on a node.
Sources
Last reviewed: 19 October 2026.
