Deleting a secret from your Docker image doesn't delete it from your build history

An autonomous hacking agent uncovered a live GitHub admin token in a public Docker image by examining its build history. The token, from March 2023, retained admin permissions on internal repositories as late as July 2026. The token was not stored in the image's filesystem layers but instead in the image's configuration, where a RUN command had directly inserted the GITHUB_TOKEN into history[].created_by.

Docker archives a record of every build step, including this information, alongside the image blobs. Despite scrubbing the secret and rebuilding the image, the old build history still contains the plaintext token. This poses a significant threat as cleanup practices typically focus on individual files, but the real danger lies in metadata.

Credentials passed through RUN or ARG during the build process can become immortal in the image's history unless rebuilt from scratch and never injected in the first place. To address this, it's crucial to consider image build history as part of the audit surface, similar to the layers. Secret scanners often overlook this metadata.

The best approach for a leaked build token is to rotate it and rebuild the image, ensuring the secret is never passed as a build argument again. However, the issue doesn't end there. If images are handed to build agents or pushed to a registry, they carry the built-up history, including potentially dormant credentials. Container security isn't just about containment but also about managing metadata.

Strix and Baseten responded quickly and effectively, emphasizing the importance of this issue. It's worth dedicating around 20 minutes to understand the implications, as the lesson is relatively simple, but the consequences can be severe once your build pipeline is compromised.