What happened
On April 25, 2019, Docker discovered unauthorized access to a single Docker Hub database. Data for approximately 190,000 accounts — slightly less than 5% of Hub users — may have been exposed: usernames, bcrypt password hashes, and the GitHub and Bitbucket access tokens that powered Docker's autobuild feature. Docker disclosed it two days later through emailed notices and a support announcement by Kent Lamb, its Director of Support.
The token exposure mattered far more than the passwords. ZDNet noted that most Docker Hub users are employees inside large companies, auto-building container images that get deployed to production. Anyone holding those tokens could reach private source repositories, or worse, quietly modify the Dockerfiles that build production software. Docker itself could not say whether the intruder had downloaded anything — only that access 'may have been exposed'.
Docker's response was the only safe one, and it was disruptive by design: reset exposed passwords, revoke every affected GitHub and Bitbucket token, and unlink the repositories. Users had to reconnect their repos and audit their GitHub and Bitbucket security logs for signs of misuse. On Docker's own forums, users reported unexpected 'Docker Cloud Build' deploy keys appearing in their GitHub repositories as the revoked integrations churned, and asked in vain how to tell whether their account had really been in the 190,000.
Docker never publicly identified the intruder or confirmed any exfiltration. It said official images were unaffected and rolled out additional security measures to guarantee their integrity. The lasting damage was to trust: the registry that the container ecosystem treats as plumbing had shown that a breach there hands an attacker keys to customers' source code, not just their logins.
What it cost
All affected passwords reset; every autobuild's GitHub/Bitbucket tokens revoked and repos unlinked — builds stayed broken until each owner reconnected
Why it happened
Long-lived OAuth tokens to GitHub and Bitbucket sat in one operational Hub database, so a single intrusion exposed customers' code pipelines rather than just their logins.
Docker Hub had become the de facto public registry for the entire container ecosystem, so its blast radius was the industry's, not one vendor's.
Docker could not determine whether data had been downloaded, leaving roughly 190,000 security teams to assume the worst and audit their repositories manually.
The accounts exposed were not average users but corporate autobuild operators, which made the credential exposure a live supply-chain risk rather than a routine password reset.
The lesson
A registry everyone treats as infrastructure is also a cache of upstream credentials. Long-lived source-control tokens in one operational database turned a brief intrusion into an industry-wide audit.
Aftermath
Docker reset affected passwords, revoked the autobuild tokens and unlinked repositories, and told customers to check their GitHub and Bitbucket logs for unexpected access. Official images were declared untouched, with extra integrity measures added. No exfiltration was ever confirmed and no attacker was publicly named. The incident became a standing citation in supply-chain security advice for keeping CI-to-source-control credentials short-lived and narrowly scoped.
FOLLOW THE EVIDENCE
The sources
- Docker Hub hack exposed data of 190,000 users zdnet.com
- Docker Hub Breach Hits 190,000 Accounts securityweek.com
- Docker Hub Security Breach details, signs/hints forums.docker.com