Secrets Don’t Leak. We Let Them Hang Around Too Long.

Docker Hub Secrets Exposure:
A December 2025 report by cybersecurity firm Flare Systems revealed over 10,000 Docker images on Docker Hub that were publicly exposing live API keys, cloud access tokens, and other sensitive credentials from more than 100 organizations. Many of these leaks were attributed to “shadow IT” accounts and developers failing to revoke keys after removing them from containers.

Yep, I copied that directly from Google results.
Because I need to write a blog for homework.

But the reason I actually care is simpler: I use Docker myself.
And I used to have a really hard-to-kick habit of hardcoding secrets into .env files.

Wait a minute… is this the exact same kind of mistake that just gave a “cybersecurity” firm a heart attack?

This Wasn’t a Hack. Let’s Be Honest.

This wasn’t a zero-day.
This wasn’t elite hacking.
This wasn’t even really an “attack”.

It was secrets mismanagement at scale.

What Flare actually found was painfully boring:

• Public Docker images
• Built and pushed by real developers
• Containing valid, live secrets
• Accessible to anyone who could pull the image

These weren’t theoretical keys. They worked.

AWS access keys.
API tokens.
Database credentials.
Cloud provider secrets.

Pull image → extract layer → read secret → authenticate.

That’s it.
No exploit chain.
No malware.

Alright, Enough Explaining (a.k.a. This Is Where ChatGPT Usually Ruins It)

That’s it.
(Yes, that was ChatGPT explaining it again. Hahahaha. I’m lazy.)

So let’s break it down, shall we.

A dev builds a container.
They use classic .env files.
Maybe ENV instructions in the Dockerfile.
Maybe ARG values passed at build time.

The secret touches the build process.

Yummy.

The image gets pushed to the mother Hub.

Now now… the secret is what?

Yeah, embedded into the image.
By design.

Tsk.
Tsk.
Tsk.

Cue Me Cracking Up at My Own Servers

Here’s the kicker.

I’m cracking up and I admit it looking at some images I have running on my servers.
(Of course I won’t tell you what I have running on my servers, duh.)

Out of the 5 docker services I host, all had docker, and I tried to do best practices of not hardcoding secrets…

Well normally I call my password manager CLI and key in my secrets interactively, or have an encrypted secrets file that’s not in the VM, just needs to be called.. (extra overhead I know, but that’s how the mind of a security analyst to you.)

Then the Uncomfortable Questions Linger…

Even with this setup:

• Can secrets still end up in a child process somewhere?
• Can they be dumped as an env variable on error?
• When I snapshot VMs while secrets are loaded, do they get “snapshot-ted” too?
• What about logs????
• Are these damn secrets radioactive once loaded???

This is why I had to react to this very new news (pun intended).

Flare didn’t find secrets pulled from password managers, they found secrets that were static, embedded, forgotten and still valid…

Short answer, yes albeit temporarily. Once in memory, secrets can leak through debugging, logging, crashes, snapshots, error handling... waaaah....

So I Digress. For the Love of Groot…

For the love of groot, what am I preaching?

Well I’m saying: the Docker Hub / Flare incident is not about Docker, that’s not supposed to be the headline.

It should read, “Secrets, where they live and how long they live there” (boring!)

>>> let me ask Chat GPT to put a punchier headline! <<<

Anyway, my main point: if a secret exists longer than necessary, in more places than necessary, without visibility or expiry, it will leak.

I store mine in 1Password (this is not a paid post), however, the principle I preach is the same, secrets should be fetched, not stored.

Get this, you don’t own secrets, yes, you borrow them briefly.

Now if you think that sits well with you, then our attitude toward mis-managing secrets can finally start to change.

OWASP Best Practices (a.k.a. the “stop doing dumb stuff with secrets” checklist)

• Don’t hardcode secrets (in code, Dockerfiles, Compose files, or “temporary” .env files).
• Centralize secrets in a proper secrets manager / vault and fetch them at runtime.
• Least privilege: give services the minimum access needed, not “admin because it’s easier.”
• Rotate and revoke keys when exposed (removing the string isn’t revoking the credential).
• Audit and monitor secret access (if you can’t detect weird access, you’re basically guessing).

Source (the thing I copied from Google 😅):
Read the Flare report →