Join our Newsletter — 33% off our NHI Course
Home› NHI Breaches› Docker Hub Breach 2019: How One Database Exposed…
Breach analysis Incident: 26 Apr 2019

Docker Hub Breach 2019: How One Database Exposed GitHub and Bitbucket Tokens for 190,000 Accounts

← All NHI breaches
By Lalit Choda, NHI Mgmt Group Updated 8 October 2026 9 min read
Category: NHI
Attack route: Not disclosed Identities: OAuth token Source control token
On this page

Late on Friday 26 April 2019, Docker told users of Docker Hub, its public container image registry, that an intruder had accessed one of its databases. In a notice signed by Kent Lamb, Director of Docker Support, the company said it had discovered the unauthorised access the day before, on 25 April 2019, and that data for about 190,000 accounts, less than 5% of Hub users, may have been exposed. The database held usernames, hashed passwords for a small percentage of users, and the GitHub and Bitbucket tokens that Docker Hub used to run automated builds from users' source code repositories. Those tokens are machine credentials that can read, and in some cases write to, private repositories. Docker revoked the exposed tokens and access keys, asked users to relink their accounts and check security logs, and said none of its official images had been compromised. Docker did not publish how the intruder got in, and no misuse of the tokens has been reported.

Key takeaways

  • Docker said an intruder had "a brief period" of unauthorised access to a single Docker Hub database, discovered on 25 April 2019 and disclosed to users the next day.
  • About 190,000 accounts were affected, less than 5% of Docker Hub users, according to Docker's notice as reported by BleepingComputer and Threatpost.
  • The most sensitive data was not passwords but GitHub and Bitbucket tokens stored for Docker's autobuild feature, which link Docker Hub to users' source code repositories.
  • Docker revoked the tokens and asked users to check their repository security logs. No misuse of the tokens has been reported, and the entry route was never published.
  • The identity lesson: every third-party integration that holds a token to your code repositories is part of your source code's attack surface.

At a glance

OrganisationDocker (Docker Hub container registry); users who linked GitHub or Bitbucket accounts for automated builds
WhenUnauthorised access discovered 25 April 2019; users notified late on 26 April 2019
AttackerUnknown; not publicly identified
Entry pointNot disclosed. Docker described unauthorised access to a single Hub database
Identities abusedGitHub and Bitbucket OAuth tokens stored by Docker Hub for autobuilds; Docker Hub usernames and hashed passwords
ImpactData for about 190,000 accounts exposed; repository tokens revoked; no confirmed misuse of the tokens and no compromise of official images, according to Docker
CategoryNHI. Incident class: confirmed NHI breach (stored source control tokens taken in a database breach; no confirmed misuse)

What happened

Docker Hub lets users link a GitHub or Bitbucket account so that Docker can build container images automatically whenever code changes. To do that, Docker stores a token for each linked account. In its notice to users, Docker wrote: "On Thursday, April 25th, 2019, we discovered unauthorized access to a single Hub database storing a subset of non-financial user data." BleepingComputer, which published the notice shortly before midnight on Friday 26 April, reported that the exposed data included usernames and hashed passwords for a small percentage of users, and GitHub and Bitbucket tokens for Docker autobuilds.

"Upon discovery, we acted quickly to intervene and secure the site," Docker said, as quoted by Threatpost. It described the access as lasting a "brief period". It revoked the GitHub and Bitbucket tokens and access keys tied to affected autobuilds, added monitoring tools, and said it was "enhancing our overall security processes and reviewing our policies." Users were asked to change their Docker Hub password and any other account using the same password. "We ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place," the company said, as quoted by SiliconANGLE. Docker said its investigation was ongoing; none of the sources reviewed for this page report a later explanation of how the intruder got in.

Security specialists focused on the tokens. Wei Lien Dang of StackRox told Threatpost that "it's possible that images in your Docker Hub repository may have been tampered with or overwritten" and advised users to verify images pushed over the previous several weeks. Snyk advised revoking and reissuing all GitHub tokens, including read-only ones, because read-only access still exposes private code, and resetting any credentials stored in source code. Docker told users that none of the official Docker images had been compromised, and Snyk said it knew of no successful supply chain attack resulting from the breach.

Timeline

DateEvent
25 April 2019Docker discovers unauthorised access to a single Docker Hub database.
26 April 2019Late that evening Docker emails affected users; BleepingComputer publishes the notice.
28 April 2019SiliconANGLE reports that Docker has revoked the exposed tokens and access keys.
29 April 2019Threatpost and Snyk publish analyses of the risk to linked GitHub and Bitbucket repositories.

How it happened: the identity attack path

  1. Repository tokens held by a third party. Users linked GitHub and Bitbucket accounts to Docker Hub, which stored a token per account so it could build images from their code.
  2. Unknown access route. An intruder gained access to the Docker Hub database holding those tokens. Docker did not publish how.
  3. Tokens and password hashes exposed. The database contained usernames, hashed passwords for a small share of users and the autobuild tokens for about 190,000 accounts in total.
  4. Potential reach into source code. Depending on scope, the tokens could read private repositories and potentially change code that Docker Hub would then build into images.
  5. Revocation. Docker revoked the tokens and access keys, forcing users to relink their accounts and check repository logs.

Impact

  • Confirmed: unauthorised access to a Docker Hub database with data for about 190,000 accounts, including usernames, some hashed passwords and GitHub and Bitbucket autobuild tokens.
  • Not reported: no misuse of the tokens and no compromise of official Docker images has been reported. Docker did not disclose how long the attacker had the data beyond "a brief period" of access.
  • Potential: read access to private source code, and where tokens allowed it, changes to repositories or to images built from them. Experts urged users to review recently pushed images.
  • Disruption: affected users had to relink source providers before automated builds would work again.

What this means for NHI governance

The Docker Hub breach is a third-party token problem. Users granted a build service standing access to their source code repositories, and that service kept the tokens in a database. When the database was breached, the users' repositories were exposed even though nothing in their own environment had changed. The same pattern recurred three years later in the GitHub OAuth Token Breach 2022, where stolen Heroku and Travis CI tokens were used to download private repositories.

The governance answer is to treat every OAuth grant to a third-party service as a non-human identity you own: know which services hold tokens to your repositories, what scope each has, and how to revoke them quickly. Prefer integrations that use narrowly scoped, short-lived installation tokens over user-level OAuth tokens with broad access. Docker Hub's role as an image registry adds a second risk, the one the Docker Hub Secrets Leak 2025 shows from another angle: images and the pipelines that build them are themselves a home for secrets. Our SaaS and OAuth App Governance Guide and Third-Party Access Guide cover these controls.

Recommendations

  • Inventory third-party services that hold tokens to your code. Review OAuth grants and app installations on GitHub, Bitbucket and other code hosts, and remove the ones you no longer use. See our SaaS and OAuth App Governance Guide.
  • Prefer narrowly scoped, short-lived integration tokens. Use app-based integrations limited to specific repositories rather than user-level OAuth tokens with access to everything. See the Third-Party Access Guide.
  • Revoke and reissue tokens when a provider is breached. Include read-only tokens, and rotate any secrets stored in the repositories those tokens could read. See the Leaked Credential Response Playbook.
  • Review repository audit logs after a third-party breach. Look for clones, pushes and settings changes made through the provider's tokens.
  • Verify and sign the images you build. Check recently built images against source and use image signing so that tampered images are rejected at deployment.
  • Keep secrets out of source code. If a token exposes your repositories, secrets in them are exposed too. See our Secrets Management Guide.

Frequently asked questions

What data was exposed in the 2019 Docker Hub breach?

Docker said a single Hub database was accessed, exposing data for about 190,000 accounts: usernames, hashed passwords for a small percentage of users, and GitHub and Bitbucket tokens used for Docker's automated builds.

Why were the GitHub and Bitbucket tokens important?

The tokens let Docker Hub access users' source code repositories to build images. In an attacker's hands they could have exposed private code and, where permissions allowed, changes to repositories. Docker revoked them, and no misuse has been reported.

How did attackers get into Docker Hub?

Docker did not publicly explain how the intruder gained access. Its notice described a brief period of unauthorised access to a single database and said the investigation was ongoing.

GitHub OAuth Token Breach 2022 · Docker Hub Secrets Leak 2025 · Homebrew GitHub Token Exposure 2018 · SaaS and OAuth App Governance Guide · Third-Party Access Guide

How NHI Mgmt Group can help

Third-party integrations often hold the broadest tokens to your code, and they are rarely reviewed. We help organisations map which services hold access to their repositories, cut those grants down to what is needed and prepare to revoke them fast when a provider is breached. See our NHI and AI agent security training.

References

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 8 October 2026.
Based on the public sources listed under References. Details may change as investigations continue.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org