Vulnerable Base Images

What Is Vulnerable Base Images?

Application dependencies get reviewed on every change. The operating system layer underneath them often does not. A floating tag like node:18 means the layer beneath your code changes whenever the registry serves something new, and flaws are found over time, so an image clean at ship time can be critical now. You'll scan a stale service image, find CVE-2023-4863 in libwebp, and turn it into remote code execution. Then you'll pin the base to an exact digest, rebuild, and rescan. Pinning has a cost: it needs a deliberate rebuild cadence.

What You'll Learn in Vulnerable Base Images

• Recognize that a floating base tag lets the operating system layer beneath your code change without anyone deciding it should
• Scan a deployed image for known vulnerabilities and turn CVE-2023-4863 in libwebp into working remote code execution
• Explain why an OS-layer flaw appears in no dependency file and is fixed by a base-image change rather than a package bump
• Pin the base image to an exact digest so every build pulls the same bytes and a base change becomes a reviewable commit
• Rebuild and rescan to prove the pin worked, and plan the deliberate rebuild cadence a pinned base image requires

Vulnerable Base Images — Training Steps

1. The scheduler image in the registry

   Bob has read access to Bremhollow's container registry from a leaked robot token. He is not looking at code — he is looking at how fresh the images are, because a service that has not rebuilt in a while is a service whose base image has quietly aged. The scheduler processes uploaded images, which makes what it is built on very interesting to him. Open its page and see what the registry says.

2. An image that stopped moving

   The registry does not have to be wrong to help Bob. One row tells him the deployed image is old and built on a floating base.

3. Scan the base for a way in

   Bob pulls the image and runs a vulnerability scanner over it, the same tool a defender would use. He is not interested in the application code. He wants a known, published vulnerability in the operating-system packages the base image dragged in, because those come with working exploits.

4. Turn the CVE into a shell

   A scanner finding is not an exploit until someone runs it. CVE-2023-4863 has a public proof-of-concept: a crafted WebP that overflows libwebp the moment it is decoded. The scheduler decodes every uploaded image, so Bob mounts the PoC file into a throwaway run of the vulnerable image and decodes it — proving the finding is a working remote-code-execution path before he ever touches production.

5. Where the vulnerability lives

   One beat on the mechanism before the response begins.

6. The scanner flags the fleet

   Bremhollow added image scanning to its pipeline, and the first full sweep of what is already running in production came back with something that cannot wait.

7. See it for yourself

   Before changing anything, Alice runs the same scan on the deployed image. She wants to see the finding, where it sits, and what the base actually is.

8. Open the Dockerfile

   The base image is chosen in one line of the Dockerfile. Everything the scanner found rode in on that line.

9. Find the floating base

   There is nothing misspelled or malformed here. The problem is a single line that says less than it should.

10. Pin the base by digest

    A tag is a label someone can move; a digest is the image's content fingerprint and can never point at anything else. Alice pins the base to an exact, current, slim node:18 by its digest, so every build from now on pulls the same audited bytes, and moving that pin becomes a deliberate, reviewable change.