Internal machines used by Cisco researchers were targeted via SolarWinds as the impact of the colossal hacking campaign on the tech sector becomes apparent, Bloomberg reported.

Roughly two dozen computers in a Cisco lab were compromised through malicious updates to SolarWinds’ Orion network monitoring platform, Bloomberg reported, citing a person familiar with the incident. The San Jose, Calif.-based networking giant told CRN its security team moved quickly to address the issue, and that there isn’t currently any known impact to Cisco offers or products.

“While Cisco does not use SolarWinds Orion for its enterprise network management or monitoring, we have identified and mitigated affected software in a small number of lab environments and a limited number of employee endpoints,” Cisco said in a statement. “We continue to investigate all aspects of this evolving situation with the highest priority.”

Network management and monitoring are key parts of Cisco’s machinery and software, which Bloomberg said directly look at data traffic moving through a network. Access to that flow could provide a malicious actor with multiple avenues to cause harm, according to Bloomberg. Cisco told CRN there’s no evidence at this time to indicate customer data has been exposed as a result of the compromise.

The company didn’t respond to CRN questions about the number of machines affected as well as who in the organization was using the compromised machines. Cisco is the third tech vendor to get publicly ensnared in the fallout from the SolarWinds hack in the past 24 hours, following in the footsteps of Microsoft and VMware.

Reuters reported late Thursday that Microsoft was compromised via SolarWinds, with suspected Russian hackers then using Microsoft’s own products to further the attacks on other victims. Microsoft told CRN Thursday that sources for the Reuters report are “misinformed or misinterpreting their information,“ but acknowledged the software giant had ”detected malicious SolarWinds binaries” in its environment.”

Then Friday afternoon, KrebsOnSecurity reported that a VMware vulnerability allowing federated authentication abuse and access to protected data was used by the SolarWinds hackers to attack high-value targets. VMware told CRN Friday that it had received no notification or indication that this vulnerability “was used in conjunction with the SolarWinds supply chain compromise.”

FireEye put the state-sponsored hacking campaign in the public consciousness Dec. 8 when the company disclosed that it was breached in an attack designed to gain information on some of the company’s government customers. The attacker was able to access some of FireEye’s internal systems but apparently didn’t exfiltrate data from the company’s primary systems that store customer information.

After FireEye, the next several organizations to be publicly identified as victims of the SolarWinds hack were all federal agencies, including the U.S. Departments of Defense, State, Treasury, Homeland Security and Commerce, according to reports from Reuters and others.

Contrary to public perception at the time, Microsoft President Brad Smith disclosed Thursday that a decisive plurality – 44 percent – of the company’s customers compromised through SolarWinds are actually in the IT sector, and includes software and security firms as well as IT services and equipment providers.

Some 18 percent of the compromised Microsoft customers are government agencies, another 18 percent are think tanks or non-governmental organizations (NGOs), and 9 percent are government contractors, according to Smith. He said that more than 40 Microsoft customers were precisely targeted and compromised through SolarWinds Orion, roughly 80 percent whom are located in the United States.

Overview of the Breach

In late April 2019, Docker — the widely used container platform that lets engineering teams build, ship, and run applications in isolated environments — announced that an unauthorized party had gained access to one of its databases. Approximately 190,000 user accounts were affected. The exposed data included:

• Usernames
• Hashed passwords
• GitHub and Bitbucket OAuth access tokens (for a subset of affected users)

Docker disclosed the incident through its Support Center and via direct notification to potentially affected users, rather than through its main blog or social media channels — a communications decision that drew criticism from the security community.

What Was Compromised and Why It Matters

Usernames and Hashed Passwords

For users whose only exposed data was a username and a hashed password, the immediate risk was relatively limited — provided Docker used a strong hashing algorithm (such as bcrypt) with appropriate salting. Hashed passwords are not directly usable by an attacker; however, weak or commonly used passwords can still be cracked through dictionary attacks or rainbow table lookups. Users who reused their Docker password on other services faced a much higher risk of credential stuffing attacks on those accounts.

GitHub and Bitbucket Access Tokens — The Higher-Risk Exposure

The more serious concern involved OAuth access tokens for GitHub and Bitbucket. Docker Hub supports automated builds — a feature that links a Docker Hub repository to a source code repository on GitHub or Bitbucket so that a new container image is built automatically whenever code is pushed. These integrations rely on OAuth tokens that grant Docker Hub permission to read (and sometimes write) to the linked repositories.

According to reporting by Bleeping Computer, depending on the permissions granted to each token, a malicious actor in possession of these tokens could potentially:

• Read private source code repositories
• Modify repository contents, including injecting malicious code into build pipelines
• Trigger downstream supply-chain attacks affecting consumers of those Docker images

Docker stated that it revoked all known compromised access tokens promptly upon discovering the breach, which should have prevented active exploitation of those tokens after the revocation point. However, any access that occurred before revocation cannot be ruled out without a thorough audit of repository access logs.

Recommended Remediation Steps

Docker advised affected users to take the following actions. Even if you were not directly notified, these are good security hygiene practices for any Docker Hub account holder:

1. Change your Docker Hub password immediately. Choose a strong, unique password not used on any other service.
2. Check for password reuse. If you used the same password elsewhere, change it on those services as well. Consider using a password manager.
3. Reconnect GitHub and Bitbucket integrations. If your account used automated builds, revoke the existing OAuth connection and re-authorize it to generate a fresh token. Do this from the settings pages of both Docker Hub and the respective source code platform.
4. Audit your repository access logs. Review recent activity in your GitHub or Bitbucket repositories for any unexpected commits, branch modifications, or access from unfamiliar IPs.
5. Enable multi-factor authentication (MFA). Where supported, enable MFA on Docker Hub, GitHub, and Bitbucket to add a layer of protection beyond passwords alone.
6. Review OAuth token permissions. Apply the principle of least privilege when re-authorizing integrations — grant only the repository permissions that are actually required for the automated build workflow.

Broader Implications: Supply Chain Security

This incident is a clear example of why supply chain security matters in a containerized DevOps workflow. Automated build pipelines that connect source code repositories to image registries are a powerful productivity feature — but they also represent a trust boundary that attackers can exploit. If a token with write access to a repository is compromised, an attacker could inject malicious code that ends up packaged into a Docker image and pulled by downstream users, potentially at scale.

Teams that rely on Docker Hub automated builds or similar CI/CD integrations should treat OAuth tokens as high-value secrets, rotate them regularly, and monitor for anomalous repository activity as part of standard operations.

Context: Timing and Disclosure Approach

The breach was disclosed during a particularly active period for Docker. The company had just announced a partnership with Arm on April 24, 2019, aimed at simplifying deployment to cloud, edge, and IoT environments running Arm-based processors. DockerCon, the company’s annual container industry conference, also ran from April 29 to May 2. Docker’s choice to disclose the breach via its Support Center rather than its main communications channels was noted by observers as a way of limiting the incident’s visibility during a high-profile week for the company.

Regardless of the communications strategy, the incident highlights that even infrastructure vendors trusted to secure development pipelines are not immune to breaches — and that users of any platform bear responsibility for applying available security controls on their own accounts.

Further Learning: Docker Security

If this incident has prompted you to review your Docker security posture more broadly, consider exploring dedicated training on container security practices, including image scanning, secrets management, runtime security, and network policy configuration. DevOpsSchool offers a course titled Deep Dive into Docker Security that covers advanced Docker security topics for practitioners.