Docker and cache poisoning: the hidden risk in your builds

Cybersecurity
, , , , , , ,
1

Screenshot 2026-04-22 at 9.07.37 AM
Screenshot 2026-04-22 at 9.07.37 AM1182Ă—796 231 KB

What’s really happening

A new attack vector has been identified that allows compromising Docker builds without modifying the source code.

The problem lies in the use of layer caching. Docker reuses previously built layers to speed up processes, but if that cache is compromised, it can introduce malicious artifacts directly into the final image.

The result: your code can be clean, but the build won’t be.

Who it affects

This risk applies to practically any team using Docker:

  • CI/CD pipelines
  • Cloud builds
  • Shared runners
  • Multi-stage architectures

If you’re reusing cache between builds, you’re exposed.

Real impact (no hype)

This type of attack enables:

  • Injecting malicious binaries into production images
  • Completely bypassing code reviews
  • Persisting between builds through the cache

The most dangerous part: it leaves no obvious traces in the source code.

Real example of how it happens

A typical build might look like this:

docker build .

During the process something like this can appear:

Step 5/7 : RUN npm run build
 ---> Using cache

That Using cache is the sensitive point.

If a layer was previously compromised, Docker reuses it without additional validation, introducing malicious code without re-executing the step.

What you should do right now

Immediate actions:

docker build --no-cache .

Also:

  • Avoid reusing cache between projects
  • Use only trusted base images
  • Isolate build environments
  • Review which runners or pipelines share cached layers

Mitigation checklist

  • Use docker build --no-cache in sensitive pipelines
  • Implement image signing and verification
  • Don’t share cache between different repositories or projects
  • Rebuild images regularly from scratch
  • Pin base image versions and avoid latest
  • Monitor artifacts generated in each build
  • Review permissions and isolation of your runners
  • Audit dependencies and critical build process steps

What changes from now on

This type of vulnerability makes something clear: the build system is also part of the attack surface.

For years, many teams assumed that if the code was clean, the build would be too. That assumption no longer holds.

Now you also need to validate:

  • how the image is built
  • what layers are reused
  • who controls the cache
  • what artifacts end up in production

What you should review in your team today

Ask yourself these questions:

  • Do we share cache between projects or pipelines?
  • Are our builds reproducible?
  • Do we verify images before deploying?
  • Do we have visibility over the artifacts generated?
  • Can we rebuild a critical image without depending on previous cache?

If you can’t answer clearly, you probably have a blind spot in your pipeline.

Why this matters especially for small teams

Many small teams rely on defaults, shared runners, and inherited configurations to gain speed. That’s understandable, but it also opens space for silent risks.

When there’s no dedicated security team, the build pipeline often becomes a zone of implicit trust. That’s exactly why this type of threat matters: it forces you to review a part of the infrastructure that is rarely questioned.

Conclusion

Docker remains a key piece of the modern ecosystem, but this type of attack shows an important weakness in how we trust the build process.

The direction is clear:

  • less implicit trust
  • more verification
  • more isolation

It’s not about stopping Docker.

It’s about stopping assuming that everything coming out of the build is safe.