Vulnerable Base Images

What Is Vulnerable Base Images?

An application's dependencies get reviewed. The operating system underneath them often does not. A floating base image tag means the layer beneath your code changes without anyone deciding it should, and a stale one means known vulnerabilities ship to production every deploy. This exercise covers an exploitable flaw in the OS layer: watch an attacker use it, then pin the base image by digest, move to a slim base, and gate the pipeline on a scan.

What You'll Learn in Vulnerable Base Images

• The layer underneath your application changes without anyone deciding it should, so you cannot say what OS packages are in production or when they last changed.
• That every build pulls the exact same bytes, so a change to the base is a deliberate, reviewable commit rather than a silent event.
• A deliberate rebuild cadence, because a pinned base stops receiving patches until someone moves the pin.
• The flaw is in the OS layer beneath the application, so no dependency file mentions it and the fix is a base-image change rather than a package bump.

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.