Kent Lamb, the director of support for Docker Hub, said in a statement the unauthorised access had been noticed on 25 April.
A single Docker Hub database, which was used to store non-financial data, was discovered to have been breached and it had now been secured, he added.
Among the data that could have been stolen were usernames and hashed passwords for a small percentage of the 190,000 users, as well as GitHub and BitBucket tokens for Docker autobuilds, Lamb said.
On the Docker breach: Even if your company doesn't rely on Docker Hub for production, if a developer in your org enabled auto builds and linked to GitHub via oauth for a personal project, when that oauth token is compromised, _all_ repos on GH they had access to are vulnerable.— Kenn White (@kennwhite) April 27, 2019
Docker Hub is used for building images that are then deployed elsewhere. An attacker who gains access could theoretically modify an image to contain any code of his/her choice.
Any user whose account was known to have been affected would be notified by email, Lamb said. "We have sent a password reset link to each user whose password hash may have been impacted."
He said anyone who received such a link would have had their password hash potentially exposed.
"We have invalidated it and sent you a password reset link as a precaution. If you are using autobuilds and your GitHub or BitBucket repositories have been unlinked from Docker Hub, you will need to relink those repositories for autobuilds to work correctly," Lamb said.
Lavi Lazarovitz, Security Research Team Lead at privileged account security firm CyberArk, said the breach could lead to a classic supply chain attack made possible, seemingly, by compromise of privileged tokens.
"The autobuild functionality is used to integrate the code repository with Docker Hub so every change to the code will trigger a build of a new image for developers and DevOps engineers to use," he told iTWire.
"The tokens are used for authentication and usually allow only limited read access to the code and its metadata, thus changing code won’t be possible in most cases – exposure of private repositories will be possible.
"So why worry? Because when write access is granted to the access token, the publicly available image that relies on the compromised code repository might be backdoored or infected and so potentially affect apps and services that rely on the compromised image."
As an example, Lazarovitz said a developer might choose to download a Web server image that had been backdoored and so expose its own server.
"Multiply that by the number of developers using this service and it’s easy to see how large the potential attack surface could be," he added.