How did tainted code infect 18,000 SolarWinds customers without touching source control?

The SolarWinds Sunburst incident involved tainted code injected into software builds between February and June 2020. Former CISO Tim Brown described the event as a build supply chain attack because the malicious code was never present in the source code repository. This distinction reshaped how the industry views software integrity and vendor risk management during the swampUP 2026 conference in New York.

Root cause

The root cause was identified as a compromise of the build process rather than the source code itself. Brown noted that the engineering team searched the source code but found nothing. Instead, they discovered that three specific product versions produced during the four-month window contained the malicious payload. The exact method of entry into the build system was not detailed in the initial categorization, leading to the term "build supply chain issue."

Attack path

The attack path bypassed source code controls entirely. Brown stated that the code had never been in source code control but somehow made it into the final product. Once shipped, the payload reached a vast network of critical infrastructure. Brown noted that SolarWinds was part of the power grid, nuclear facilities, and military systems globally. The payload’s potential impact was broad because it could have been anything the attackers chose.

Affected versions

Three products or versions of the product produced between February and June 2020 contained the tainted code. Sales and support teams determined that 18,000 customers had downloaded these specific versions. The breach was not limited to a single software release but spanned multiple builds created during that specific production window, complicating the identification of affected systems across the customer base.

Mitigation

• Verify if any software versions downloaded between February and June 2020 are still in use.
• Audit build pipelines to ensure code integrity from source to final artifact.
• Review vendor security practices, specifically how they protect their build environments.
• Implement strict change management protocols to detect unauthorized modifications in production.

What it means for organisations

Teams should evaluate their dependency on third-party software vendors and understand the security of those vendors' build processes. Organizations need to ask suppliers how they protect their compilation environments from unauthorized access. Internal stakeholders, including legal and risk management, must be informed about potential liability from supply chain compromises. Reviewing incident response plans for large-scale vendor breaches is essential. Ensure that monitoring tools can detect anomalies in software behavior, not just network traffic. Regular audits of software integrity checks help identify if builds have been tampered with before deployment.

What to do and how to stay safe: SolarWinds

• Check inventory for software versions released during the compromised window.
• Monitor for unusual behavior in applications that may indicate hidden payloads.
• Review vendor security questionnaires to assess their build environment protections.
• Update incident response plans to include scenarios involving trusted vendor compromises.

Step-by-step guide: Data Breaches Explained: How to Spot the Leak Before It Hurts

General security guidance from the CloudSec Press newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Was the Sunburst malware in the source code?

No, former CISO Tim Brown stated the code had never been in source code control.

How many customers were affected by the tainted builds?

Approximately 18,000 customers downloaded the compromised versions between February and June 2020.

What type of attack was this classified as?

It was classified as a build supply chain attack because the code entered during the build process.